From stevebeemonkey at monkey-media.co.uk Wed Jul 5 05:59:02 2006 From: stevebeemonkey at monkey-media.co.uk (steve@monkey-media.co.uk) Date: Wed, 5 Jul 2006 04:59:02 -0700 Subject: [Rxtx] No output on WinXP Message-ID: <1152100742.44aba986565e7@www.webmail.ezpublishing.com> Hi there, I've installed RXTX 2.1.7 under Win XP, copying the .jar and .dll files according to the instructions given. I've changed the javax.comm import to gnu.io, but when I run the following code the only output I get is: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Then the program ends, without listing any of the ports. What am I doing wrong? Cheers, Steve Here's my code: ---------------------------------------- import gnu.io.*; import java.util.*; public class PortList { public static void main(String [] args) { Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while(portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); if( portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("Serial port: " + portId.getName()); } else if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { System.out.println("Parallel port: " + portId.getName()); } else System.out.println("Other port: " + portId.getName()); } } } ------------------------------- From tjarvi at qbang.org Wed Jul 5 07:57:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 5 Jul 2006 07:57:22 -0600 (MDT) Subject: [Rxtx] No output on WinXP In-Reply-To: <1152100742.44aba986565e7@www.webmail.ezpublishing.com> References: <1152100742.44aba986565e7@www.webmail.ezpublishing.com> Message-ID: On Wed, 5 Jul 2006, steve at monkey-media.co.uk wrote: > > > Hi there, > > I've installed RXTX 2.1.7 under Win XP, copying the .jar and .dll files > according to the instructions given. > > I've changed the javax.comm import to gnu.io, but when I run the following code > the only output I get is: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Then the program ends, without listing any of the ports. > > What am I doing wrong? > > Cheers, > > Steve > > Here's my code: > > ---------------------------------------- > > import gnu.io.*; > import java.util.*; > > public class PortList > { > public static void main(String [] args) > { > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > while(portList.hasMoreElements()) { > CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); > if( portId.getPortType() == > CommPortIdentifier.PORT_SERIAL) > { > System.out.println("Serial port: " + > portId.getName()); > } else if (portId.getPortType() == > CommPortIdentifier.PORT_PARALLEL) > { > System.out.println("Parallel port: " + > portId.getName()); > } else > System.out.println("Other port: " + > portId.getName()); > } > } > } > > ------------------------------- > If you have a port open with another terminal such as hyperterminal or even another copy of your application using rxtx, the port will not be enumerated. rxtx enumerates ports by opening prospective ports and doing a timed out read. If the port is open by another application, the open will fail. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Wed Jul 5 15:44:05 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Wed, 5 Jul 2006 15:44:05 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EA89@hqexchange3.dot.state.co.us> Trent, I did put some debug statements and the "index" returned to me in the while loop is "0" (see the code below) and it gets into the infinite loop, I can put a break statement but don't know the ramifications of it. Can you explain in what scenarios the index can be "0" or are we somehow in the native code loosing refrences to the indexes? Thanks Again Pawan Kharbanda while( searching ) { index = master_index; if( index ) { while( index->fd != fd && index->next ) index = index->next; if ( index->fd == fd ) searching = 0; } else report("Index"+index"x"); <<<<<< The code gets to this statement and index is returned as "0" and I don't see anyway to break out of this looop after. if( searching ) { report("@"); usleep(1000); } } -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, June 29, 2006 6:21 AM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports > Here is how you can test if you have resources/ test environment. > Write a program and try to open/close different ports(I will say have > a minimum of four) randomly and very frequently(may be 30 seconds), I > am pretty sure you will see the deadlocks and it happens in the native > call to interrptEventLoop in RXTXPort.java in removeEventListener() > method call. Hi Pawan I'll try to find a way to reproduce this. One thing to note is that you are using different kernel drivers (digi) to perform this task. So I probably will not be able to reproduce the exact same environment. In general, multiport kernel drivers have been tested far less than typical serial drivers. This may or may not be an issue. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Wed Jul 5 18:50:01 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Wed, 5 Jul 2006 18:50:01 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EA96@hqexchange3.dot.state.co.us> Trent, Sorry for so many emails, but as I mentioned earlier I will write a test to replicate the Locking problem. I am attaching a Java file to replicate the problem. You need atleast 4-5 ports to simulate the problem. Here is how to run the program. In the TestOpenClosePort.java please change the Serial Ports names(Add the ports installed on your machine). Then compile your java file and run as "java TestOpenClosePort 100" (100 is the no of times you want to open and close the port in one single thread). I have tested this with the Digi Boxes and able to replicate this over and over in Single JVM. Hope this test helps track down the problem. Thanks Pawan Kharbanda -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, June 29, 2006 6:21 AM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports > Here is how you can test if you have resources/ test environment. > Write a program and try to open/close different ports(I will say have > a minimum of four) randomly and very frequently(may be 30 seconds), I > am pretty sure you will see the deadlocks and it happens in the native > call to interrptEventLoop in RXTXPort.java in removeEventListener() > method call. Hi Pawan I'll try to find a way to reproduce this. One thing to note is that you are using different kernel drivers (digi) to perform this task. So I probably will not be able to reproduce the exact same environment. In general, multiport kernel drivers have been tested far less than typical serial drivers. This may or may not be an issue. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: TestOpenClosePort.java Type: application/octet-stream Size: 6038 bytes Desc: TestOpenClosePort.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060705/82f8488f/TestOpenClosePort-0355.obj From tjarvi at qbang.org Wed Jul 5 22:48:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 5 Jul 2006 22:48:52 -0600 (MDT) Subject: [Rxtx] Locked Ports In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3EA89@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03F3EA89@hqexchange3.dot.state.co.us> Message-ID: On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did put some debug statements and the "index" returned to me in > the while loop is "0" (see the code below) and it gets into the infinite > loop, I can put a break statement but don't know the ramifications of > it. Can you explain in what scenarios the index can be "0" or are we > somehow in the native code loosing refrences to the indexes? > > Thanks Again > Pawan Kharbanda > > while( searching ) > { > index = master_index; > > if( index ) > { > while( index->fd != fd && > index->next ) index = index->next; > if ( index->fd == fd ) searching = 0; > } > else > report("Index"+index"x"); <<<<<< The code gets > to this statement and index is returned as "0" and I don't see anyway to > break out of this looop after. > if( searching ) > { > report("@"); > usleep(1000); > } > } > Hi Pawan I am reading with interest :) So it sounds like this is a thread safe problem. The thing I don't understand here is open and close are synchronized in RXTXPort.java. I thought that would prevent any thread problems with the linked list. Looking closer, the linked list is actually populated in eventLoop/MonitorThread which is not synchronized. So you may be able to synchronize on an object in RXTXPort.java. A seperate native call would probably be required for the initalization to prevent a deadlock. A solution might involve making finalize_event_info_struct() and initialise_event_info_struct() [uk spelling?] thread safe with glib. http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads.html#id2786034 glib also has more robust linked lists which could be used. Thats the indirectly the problem found in termios.c for windows. The disadvantage is we would require linking to glib which is another step for systems that don't come with it. The advantage would be reduced code size we have to maintain. We could borrow bits of glib as the licenses are the same. Another solution might be to just use pthread_mutex_lock and unlock. http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html I don't think that would work on windows though. It would require linking cygwin.dll which would not work with nonGPL projects in practice. -- Trent Jarvi tjarvi From neville_seed at yahoo.com Thu Jul 6 06:42:29 2006 From: neville_seed at yahoo.com (neville seed) Date: Thu, 6 Jul 2006 05:42:29 -0700 (PDT) Subject: [Rxtx] port to palm OS? Message-ID: <20060706124230.55790.qmail@web51015.mail.yahoo.com> hello. Has rxtx been ported to PalmOS? regards neville __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From neville_seed at yahoo.com Thu Jul 6 06:43:44 2006 From: neville_seed at yahoo.com (neville seed) Date: Thu, 6 Jul 2006 05:43:44 -0700 (PDT) Subject: [Rxtx] example code Message-ID: <20060706124344.5063.qmail@web51013.mail.yahoo.com> hello. Could anyone provide me with example code of how to read from the serial port. regards neville __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From naranjo.manuel at gmail.com Thu Jul 6 06:48:20 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Thu, 06 Jul 2006 09:48:20 -0300 Subject: [Rxtx] port to palm OS? In-Reply-To: <20060706124230.55790.qmail@web51015.mail.yahoo.com> References: <20060706124230.55790.qmail@web51015.mail.yahoo.com> Message-ID: <44AD0694.1090703@gmail.com> neville seed wrote: > hello. > > Has rxtx been ported to PalmOS? > > regards > neville > I'm interested on this. Do you need rxtx ported to J2ME or to Superwaba?. Superwaba has it owns implementation of a serial port, but it is not rxtx. Regards, Manuel From joachim at buechse.de Thu Jul 6 07:20:57 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 6 Jul 2006 15:20:57 +0200 Subject: [Rxtx] port to palm OS? In-Reply-To: <20060706124230.55790.qmail@web51015.mail.yahoo.com> References: <20060706124230.55790.qmail@web51015.mail.yahoo.com> Message-ID: Which version of PalmOS are you targeting? I have been doing some Java on PalmOS programming for the Palm Vx using the JVM from Esmertec. The problem there was, that PalmOS can only process one kernel call at a time (it is (was?) not a multithreading OS). Threads were implemented by the VM. In a situation like this, any kind of "abort" mechanism is very difficult to handle - from what I know about the RXTX code and the way close() would have to be implemented it's the same as rewriting RXTX. Newer versions of PalmOS might have improved in this respect... Best regards, Joachim On 06.07.2006, at 14:42, neville seed wrote: > hello. > > Has rxtx been ported to PalmOS? > > regards > neville > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From neville_seed at yahoo.com Thu Jul 6 08:23:29 2006 From: neville_seed at yahoo.com (neville seed) Date: Thu, 6 Jul 2006 07:23:29 -0700 (PDT) Subject: [Rxtx] port to palm OS? In-Reply-To: Message-ID: <20060706142329.91625.qmail@web51005.mail.yahoo.com> The palmOS would be version 5.x however i am new to both palm and java. As such I would have to find out any questions. --- Joachim Buechse wrote: > Which version of PalmOS are you targeting? > > I have been doing some Java on PalmOS programming > for the Palm Vx > using the JVM from Esmertec. The problem there was, > that PalmOS can > only process one kernel call at a time (it is (was?) > not a > multithreading OS). Threads were implemented by the > VM. In a > situation like this, any kind of "abort" mechanism > is very difficult > to handle - from what I know about the RXTX code and > the way close() > would have to be implemented it's the same as > rewriting RXTX. Newer > versions of PalmOS might have improved in this > respect... > > Best regards, > Joachim > > On 06.07.2006, at 14:42, neville seed wrote: > > > hello. > > > > Has rxtx been ported to PalmOS? > > > > regards > > neville > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From jhaysonn at gmail.com Thu Jul 6 08:58:07 2006 From: jhaysonn at gmail.com (jhaysonn pathak) Date: Thu, 6 Jul 2006 10:58:07 -0400 Subject: [Rxtx] RXTX install (jhaysonn pathak) Message-ID: Thanks for the install tip. I figured out how to do the cvs update, but in my MACOSX_IDE dir I didn't have any Xcode folders and searching my computer, I only have 3 Xcode folders (one for application support, one for Max/MSP and one in developer tools). I have tried building each of the different *.xcodeproj files and in eachone they have little toolbox looking items that are in red (i assume that means it can't find them). Some of them I manage to locate but some of them just aren't on my computer. In any event, I still can't find the libserial.jnilib. After the update I read the README.OSX and it did make it seem a lot easier, but for the future, if I finally create a libserial.jnilib I don't know what the 'JavaVM' is in reference to this line "Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required)." PS - How do I uninstall everything RXTX so that I can try and re-download and re-install everything? From joachim at buechse.de Thu Jul 6 09:12:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 6 Jul 2006 17:12:24 +0200 Subject: [Rxtx] RXTX install (jhaysonn pathak) In-Reply-To: References: Message-ID: <98F15662-544D-41B5-8229-BB1DB6B6FD43@buechse.de> The Java VM ist the Java Virtual Machine. It runs your application. For the rest of your message ... your description is much to unprecise to help. To start, you could describe what IS in the MACOSX_IDE folder and its subfolders. On 06.07.2006, at 16:58, jhaysonn pathak wrote: > Thanks for the install tip. I figured out how to do the cvs update, > but in my MACOSX_IDE dir I didn't have any Xcode folders and searching > my computer, I only have 3 Xcode folders (one for application support, > one for Max/MSP and one in developer tools). I have tried building > each of the different *.xcodeproj files and in eachone they have > little toolbox looking items that are in red (i assume that means it > can't find them). Some of them I manage to locate but some of them > just aren't on my computer. In any event, I still can't find the > libserial.jnilib. > > After the update I read the README.OSX and it did make it seem a lot > easier, but for the future, if I finally create a libserial.jnilib I > don't know what the 'JavaVM' is in reference to this line > > "Put > libSerial.jnilib > in the directory of the application (the JavaVM will find it > there). Add > RXTXComm.jar > to the application classpath or include the classes in the > application jar. > (Some applications already include the RXTX classes in their > application jar, > in which case only the file libSerial.jnilib is required)." > > PS - How do I uninstall everything RXTX so that I can try and > re-download and re-install everything? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jul 6 09:20:16 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 6 Jul 2006 17:20:16 +0200 Subject: [Rxtx] RXTX install (jhaysonn pathak) In-Reply-To: References: Message-ID: <8F03CA0E-44F4-434F-AA7E-3A8B5054AA6F@buechse.de> Rethinking about your problem... I think you should try a cvs up -d Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 06.07.2006, at 16:58, jhaysonn pathak wrote: > Thanks for the install tip. I figured out how to do the cvs update, > but in my MACOSX_IDE dir I didn't have any Xcode folders and searching > my computer, I only have 3 Xcode folders (one for application support, > one for Max/MSP and one in developer tools). I have tried building > each of the different *.xcodeproj files and in eachone they have > little toolbox looking items that are in red (i assume that means it > can't find them). Some of them I manage to locate but some of them > just aren't on my computer. In any event, I still can't find the > libserial.jnilib. > > After the update I read the README.OSX and it did make it seem a lot > easier, but for the future, if I finally create a libserial.jnilib I > don't know what the 'JavaVM' is in reference to this line > > "Put > libSerial.jnilib > in the directory of the application (the JavaVM will find it > there). Add > RXTXComm.jar > to the application classpath or include the classes in the > application jar. > (Some applications already include the RXTX classes in their > application jar, > in which case only the file libSerial.jnilib is required)." > > PS - How do I uninstall everything RXTX so that I can try and > re-download and re-install everything? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Thu Jul 6 10:19:17 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Thu, 06 Jul 2006 13:19:17 -0300 Subject: [Rxtx] port to palm OS? In-Reply-To: <20060706142329.91625.qmail@web51005.mail.yahoo.com> References: <20060706142329.91625.qmail@web51005.mail.yahoo.com> Message-ID: <44AD3805.3010609@gmail.com> neville seed wrote: > The palmOS would be version 5.x however i am new to > both palm and java. As such I would have to find out > any questions. > Hello if you are new you could use Superwaba, url: www.superwaba.com, which is not exactly Java but works great, and has a serial port. If you need any more info please let me know. Manuel From Pawan.Kharbanda at dot.state.co.us Thu Jul 6 12:49:50 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 6 Jul 2006 12:49:50 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EB11@hqexchange3.dot.state.co.us> Trent, I did made the eventLoop() call in the Monitor Thread synchronized, it improved but still see the same problem. Your comment > A solution might involve making finalize_event_info_struct() and > initialise_event_info_struct() [uk spelling?] thread safe with glib. I didn't follow this how I can implement this. I am not a C guy, can you help me understand how I can implement this? Thanks Pawan Kharbanda -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, July 05, 2006 10:49 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did put some debug statements and the "index" returned to me in > the while loop is "0" (see the code below) and it gets into the > infinite loop, I can put a break statement but don't know the > ramifications of it. Can you explain in what scenarios the index can > be "0" or are we somehow in the native code loosing refrences to the indexes? > > Thanks Again > Pawan Kharbanda > > while( searching ) > { > index = master_index; > > if( index ) > { > while( index->fd != fd && > index->next ) index = index->next; > if ( index->fd == fd ) searching = 0; > } > else > report("Index"+index"x"); <<<<<< The code gets to this statement > and index is returned as "0" and I don't see anyway to break out of > this looop after. > if( searching ) > { > report("@"); > usleep(1000); > } > } > Hi Pawan I am reading with interest :) So it sounds like this is a thread safe problem. The thing I don't understand here is open and close are synchronized in RXTXPort.java. I thought that would prevent any thread problems with the linked list. Looking closer, the linked list is actually populated in eventLoop/MonitorThread which is not synchronized. So you may be able to synchronize on an object in RXTXPort.java. A seperate native call would probably be required for the initalization to prevent a deadlock. A solution might involve making finalize_event_info_struct() and initialise_event_info_struct() [uk spelling?] thread safe with glib. http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. html#id2786034 glib also has more robust linked lists which could be used. Thats the indirectly the problem found in termios.c for windows. The disadvantage is we would require linking to glib which is another step for systems that don't come with it. The advantage would be reduced code size we have to maintain. We could borrow bits of glib as the licenses are the same. Another solution might be to just use pthread_mutex_lock and unlock. http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html I don't think that would work on windows though. It would require linking cygwin.dll which would not work with nonGPL projects in practice. -- Trent Jarvi tjarvi _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From zhanglong at adventnet.com Wed Jul 5 20:44:18 2006 From: zhanglong at adventnet.com (zhanglong) Date: Thu, 06 Jul 2006 10:44:18 +0800 Subject: [Rxtx] rxtx can not read data from serialport Message-ID: <44AC7902.8070407@adventnet.com> Dear sir, When I use rxrx2.1-7-bin-r2?I can write data into serialport,But can not read data from serialport on windowsXP. I can not write and read data from serialport on Redhat Linux9.0. I can get serialport list on my machine.And no error with open serialport. I can get and read data from serialport on windowsXP with SUN's javacomm20-win32.zip. How can I read data on windows and write,read data on Linux with rxtx? Best Regards, Zhanglong From tjarvi at qbang.org Thu Jul 6 19:07:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 19:07:13 -0600 (MDT) Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: <44AC7902.8070407@adventnet.com> References: <44AC7902.8070407@adventnet.com> Message-ID: On Thu, 6 Jul 2006, zhanglong wrote: > Dear sir, > > When I use rxrx2.1-7-bin-r2??I can write data into serialport,But can > not read data from serialport on windowsXP. > I can not write and read data from serialport on Redhat Linux9.0. > I can get serialport list on my machine.And no error with open serialport. > > I can get and read data from serialport on windowsXP with SUN's > javacomm20-win32.zip. > > How can I read data on windows and write,read data on Linux with rxtx? > > Hi Zhanglong Make sure that you specify the flow control, timeout and threshold that you want. The defaults may vary between rxtx and Sun. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jul 6 19:10:25 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 19:10:25 -0600 (MDT) Subject: [Rxtx] Controlling Individual Signals DTR and RTS In-Reply-To: References: Message-ID: On Thu, 29 Jun 2006, Chris Pine wrote: > Dear Moussa Ba, > I hope I am not being too forward, but we are having the exact same > issue with needing to control DTR from RXTX in Linux. Did you ever have any > luck figuring it out? > > Thank you very much for your time, > Hi Chris Are you using an unusual serial port? It could be that the port does not support DTR/RTS. Especially if its an inexpensive USB->Serial dongle. I'll double check Linux tomorrow but I'm fairly sure it works. I have verified windows after a questions like yours. Some multiport cards and usb dongles do not support everything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jul 6 19:17:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 19:17:09 -0600 (MDT) Subject: [Rxtx] Locked Ports In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3EB11@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03F3EB11@hqexchange3.dot.state.co.us> Message-ID: Hi Pawan There is an example of doing this in the link I provided below. They make a pointer to the function they want to be thread safe and then use that with the glib functions. I'm not ready to just toss out a quick hack because I'd like to think through this a bit to make sure I understand what types of problems we may run into. The code still hung in the same place after synchronizing the eventLoop? I think that eventLoop needs to be refactored to pull out the initialization code so people do not need to run the monitor. On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did made the eventLoop() call in the Monitor Thread synchronized, it > improved but still see the same problem. > > Your comment >> A solution might involve making finalize_event_info_struct() and >> initialise_event_info_struct() [uk spelling?] thread safe with glib. > > I didn't follow this how I can implement this. I am not a C guy, can you > help me understand how I can implement this? > > Thanks > Pawan Kharbanda > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Wednesday, July 05, 2006 10:49 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] Locked Ports > > On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > >> Trent, >> I did put some debug statements and the "index" returned to me in >> the while loop is "0" (see the code below) and it gets into the >> infinite loop, I can put a break statement but don't know the >> ramifications of it. Can you explain in what scenarios the index can >> be "0" or are we somehow in the native code loosing refrences to the > indexes? >> >> Thanks Again >> Pawan Kharbanda >> >> while( searching ) >> { >> index = master_index; >> >> if( index ) >> { >> while( index->fd != fd && >> index->next ) index = index->next; >> if ( index->fd == fd ) searching = 0; >> } >> else >> report("Index"+index"x"); <<<<<< The code gets > to this statement >> and index is returned as "0" and I don't see anyway to break out of >> this looop after. >> if( searching ) >> { >> report("@"); >> usleep(1000); >> } >> } >> > > Hi Pawan > > I am reading with interest :) > > So it sounds like this is a thread safe problem. > > The thing I don't understand here is open and close are synchronized in > RXTXPort.java. I thought that would prevent any thread problems with > the linked list. Looking closer, the linked list is actually populated > in eventLoop/MonitorThread which is not synchronized. > > So you may be able to synchronize on an object in RXTXPort.java. A > seperate native call would probably be required for the initalization to > prevent a deadlock. > > A solution might involve making finalize_event_info_struct() and > initialise_event_info_struct() [uk spelling?] thread safe with glib. > > http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. > html#id2786034 > > glib also has more robust linked lists which could be used. Thats the > indirectly the problem found in termios.c for windows. The disadvantage > is we would require linking to glib which is another step for systems > that don't come with it. The advantage would be reduced code size we > have to maintain. We could borrow bits of glib as the licenses are the > same. > > Another solution might be to just use pthread_mutex_lock and unlock. > > http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html > > I don't think that would work on windows though. It would require > linking cygwin.dll which would not work with nonGPL projects in > practice. > > -- > Trent Jarvi > tjarvi > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Pawan.Kharbanda at dot.state.co.us Thu Jul 6 21:46:08 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 6 Jul 2006 21:46:08 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EB35@hqexchange3.dot.state.co.us> Trent, Just curious to know if you were able to replicate the problem with my example? Pawan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, July 06, 2006 7:17 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports Hi Pawan There is an example of doing this in the link I provided below. They make a pointer to the function they want to be thread safe and then use that with the glib functions. I'm not ready to just toss out a quick hack because I'd like to think through this a bit to make sure I understand what types of problems we may run into. The code still hung in the same place after synchronizing the eventLoop? I think that eventLoop needs to be refactored to pull out the initialization code so people do not need to run the monitor. On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did made the eventLoop() call in the Monitor Thread synchronized, > it improved but still see the same problem. > > Your comment >> A solution might involve making finalize_event_info_struct() and >> initialise_event_info_struct() [uk spelling?] thread safe with glib. > > I didn't follow this how I can implement this. I am not a C guy, can > you help me understand how I can implement this? > > Thanks > Pawan Kharbanda > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Wednesday, July 05, 2006 10:49 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] Locked Ports > > On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > >> Trent, >> I did put some debug statements and the "index" returned to me in >> the while loop is "0" (see the code below) and it gets into the >> infinite loop, I can put a break statement but don't know the >> ramifications of it. Can you explain in what scenarios the index can >> be "0" or are we somehow in the native code loosing refrences to the > indexes? >> >> Thanks Again >> Pawan Kharbanda >> >> while( searching ) >> { >> index = master_index; >> >> if( index ) >> { >> while( index->fd != fd && >> index->next ) index = index->next; >> if ( index->fd == fd ) searching = 0; >> } >> else >> report("Index"+index"x"); <<<<<< The code gets > to this statement >> and index is returned as "0" and I don't see anyway to break out of >> this looop after. >> if( searching ) >> { >> report("@"); >> usleep(1000); >> } >> } >> > > Hi Pawan > > I am reading with interest :) > > So it sounds like this is a thread safe problem. > > The thing I don't understand here is open and close are synchronized > in RXTXPort.java. I thought that would prevent any thread problems > with the linked list. Looking closer, the linked list is actually > populated in eventLoop/MonitorThread which is not synchronized. > > So you may be able to synchronize on an object in RXTXPort.java. A > seperate native call would probably be required for the initalization > to prevent a deadlock. > > A solution might involve making finalize_event_info_struct() and > initialise_event_info_struct() [uk spelling?] thread safe with glib. > > http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. > html#id2786034 > > glib also has more robust linked lists which could be used. Thats the > indirectly the problem found in termios.c for windows. The > disadvantage is we would require linking to glib which is another step > for systems that don't come with it. The advantage would be reduced > code size we have to maintain. We could borrow bits of glib as the > licenses are the same. > > Another solution might be to just use pthread_mutex_lock and unlock. > > http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html > > I don't think that would work on windows though. It would require > linking cygwin.dll which would not work with nonGPL projects in > practice. > > -- > Trent Jarvi > tjarvi > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jul 6 21:53:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 21:53:49 -0600 (MDT) Subject: [Rxtx] Locked Ports In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3EB35@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03F3EB35@hqexchange3.dot.state.co.us> Message-ID: Pawan: I'm sure I can reproduce the problem. What you have described makes very good sense and has changed how I think about rxtx. 64 ports. Take your design specs and write 'open source' on them. On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > Trent, > Just curious to know if you were able to replicate the problem > with my example? > > Pawan > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Thursday, July 06, 2006 7:17 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] Locked Ports > > > Hi Pawan > > There is an example of doing this in the link I provided below. They > make a pointer to the function they want to be thread safe and then use > that with the glib functions. > > I'm not ready to just toss out a quick hack because I'd like to think > through this a bit to make sure I understand what types of problems we > may run into. > > The code still hung in the same place after synchronizing the eventLoop? > > > > > I think that eventLoop needs to be refactored to pull out the > initialization code so people do not need to run the monitor. > > On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > >> Trent, >> I did made the eventLoop() call in the Monitor Thread synchronized, >> it improved but still see the same problem. >> >> Your comment >>> A solution might involve making finalize_event_info_struct() and >>> initialise_event_info_struct() [uk spelling?] thread safe with glib. >> >> I didn't follow this how I can implement this. I am not a C guy, can >> you help me understand how I can implement this? >> >> Thanks >> Pawan Kharbanda >> >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > >> Of Trent Jarvi >> Sent: Wednesday, July 05, 2006 10:49 PM >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] Locked Ports >> >> On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: >> >>> Trent, >>> I did put some debug statements and the "index" returned to me in >>> the while loop is "0" (see the code below) and it gets into the >>> infinite loop, I can put a break statement but don't know the >>> ramifications of it. Can you explain in what scenarios the index can >>> be "0" or are we somehow in the native code loosing refrences to the >> indexes? >>> >>> Thanks Again >>> Pawan Kharbanda >>> >>> while( searching ) >>> { >>> index = master_index; >>> >>> if( index ) >>> { >>> while( index->fd != fd && >>> index->next ) index = index->next; >>> if ( index->fd == fd ) searching = 0; >>> } >>> else >>> report("Index"+index"x"); <<<<<< The code gets >> to this statement >>> and index is returned as "0" and I don't see anyway to break out of >>> this looop after. >>> if( searching ) >>> { >>> report("@"); >>> usleep(1000); >>> } >>> } >>> >> >> Hi Pawan >> >> I am reading with interest :) >> >> So it sounds like this is a thread safe problem. >> >> The thing I don't understand here is open and close are synchronized >> in RXTXPort.java. I thought that would prevent any thread problems >> with the linked list. Looking closer, the linked list is actually >> populated in eventLoop/MonitorThread which is not synchronized. >> >> So you may be able to synchronize on an object in RXTXPort.java. A >> seperate native call would probably be required for the initalization >> to prevent a deadlock. >> >> A solution might involve making finalize_event_info_struct() and >> initialise_event_info_struct() [uk spelling?] thread safe with glib. >> >> > http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. >> html#id2786034 >> >> glib also has more robust linked lists which could be used. Thats the > >> indirectly the problem found in termios.c for windows. The >> disadvantage is we would require linking to glib which is another step > >> for systems that don't come with it. The advantage would be reduced >> code size we have to maintain. We could borrow bits of glib as the >> licenses are the same. >> >> Another solution might be to just use pthread_mutex_lock and unlock. >> >> http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html >> >> I don't think that would work on windows though. It would require >> linking cygwin.dll which would not work with nonGPL projects in >> practice. >> >> -- >> Trent Jarvi >> tjarvi >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pascal at quies.net Fri Jul 7 08:45:59 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Fri, 7 Jul 2006 16:45:59 +0200 Subject: [Rxtx] Java installer Message-ID: <200607071645.59765.pascal@quies.net> Hello everybody, We need a *simple* installer for the RXTX extension. I'm working on a pure Java installer right now. Let's get this thing working over the weekend. The license of choise is the modified BSD license. My plan is to make a JAR with: * the RXTX binaries * a simple API to detect any installed version * a simple Swing installer * a executeable detector: java -jar communicationapi.jar detect javax.comm * a executable installer: java -jar communicationapi.jar install gnu.io * Java 1.2 compatible Comments? _The Java API_: class CommunicationAPI { CommunicationAPI() CommunicationAPI(String path) boolean available() boolean supportsRS232() boolean supportsRS485() boolean supportsI2C() boolean supportsIEEE1280() static void main(String[] args) static boolean installRXTX(boolean headless) } Comments? To get this working we need binaries. Who is having what? The package from the official site has the following: * Linux: i686, x86_64, ia64 * Solaris: sparc32, sparc64 * Windows: i386 Now that's a start. I had to modify the code (what a mess!) to get it working on OpenBSD but I don't have the time to get it working for every platform. Any help here? From j.a.horsmeier at wanadoo.nl Fri Jul 7 09:11:24 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Fri, 7 Jul 2006 17:11:24 +0200 Subject: [Rxtx] Java installer In-Reply-To: <200607071645.59765.pascal@quies.net> Message-ID: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> > Pascal S. de Kloe wrote: > We need a *simple* installer for the RXTX extension. > I'm working on a pure Java installer right now. Let's get > this thing working > over the weekend. The license of choise is the modified BSD license. > > My plan is to make a JAR with: > * the RXTX binaries > * a simple API to detect any installed version > * a simple Swing installer > * a executeable detector: java -jar communicationapi.jar > detect javax.comm > * a executable installer: java -jar communicationapi.jar > install gnu.io > * Java 1.2 compatible > > Comments? Have a look at IzPack: http://www.izforge.com/izpack/ I use it all the time to install rxtx as part of our application. kind regards, Jos From brian at mbari.org Fri Jul 7 10:01:27 2006 From: brian at mbari.org (Brian Schlining) Date: Fri, 7 Jul 2006 09:01:27 -0700 Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: <44AC7902.8070407@adventnet.com> References: <44AC7902.8070407@adventnet.com> Message-ID: On Jul 5, 2006, at 7:44 PM, zhanglong wrote: > Dear sir, > > When I use rxrx2.1-7-bin-r2?I can write data into serialport,But can > not read data from serialport on windowsXP. > I can not write and read data from serialport on Redhat Linux9.0. > I can get serialport list on my machine.And no error with open > serialport. > > I can get and read data from serialport on windowsXP with SUN's > javacomm20-win32.zip. > > How can I read data on windows and write,read data on Linux with rxtx? On windows, if all else fails you may need to use this flow control: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_IN); Also, for some command/response applications that I've tried with RXTX, I find that if I write to the serialport and then immediately try to read from it I get byte arrays filled with zeros, no matter what I set the recieveTimeout to (this has occurred on both Mac OS X and Windows). The workaround that I found was to very briefly put the I/O thread to sleep, like so: // DO set up and get I/O streams //in = serialPort.getInputStream(); //out = serialPort.getOutputStream(); out.write(someByteArray); try { Thread.sleep(10); catch (InterruptedException e) { // handle exception } in.read(anotherByteArray); Note: I've never had to put the thread to sleep using Java comm, only with RXTX. Anyone know why this might be? Cheers B Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060707/f0799573/attachment-0353.html From pascal at quies.net Fri Jul 7 16:55:03 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 00:55:03 +0200 Subject: [Rxtx] Java installer In-Reply-To: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> Message-ID: <200607080055.04501.pascal@quies.net> Op vrijdag 7 juli 2006 17:11, schreef Jos A. Horsmeier: > > Pascal S. de Kloe wrote: > > > > We need a *simple* installer for the RXTX extension. > > I'm working on a pure Java installer right now. Let's get > > this thing working > > over the weekend. The license of choise is the modified BSD license. > > > > My plan is to make a JAR with: > > * the RXTX binaries > > * a simple API to detect any installed version > > * a simple Swing installer > > * a executeable detector: java -jar communicationapi.jar > > detect javax.comm > > * a executable installer: java -jar communicationapi.jar > > install gnu.io > > * Java 1.2 compatible > > > > Comments? > > Have a look at IzPack: http://www.izforge.com/izpack/ > I use it all the time to install rxtx as part of our application. Hello Jos, Thanks for the idea. Could you publish the IzPack configuration and the binaries? That would be very helpful since the current installation procedure is somewhat "unprofessional". ;) IzPack is great but this API is a little more than that. It allows java applications who require the extension to detect available versions and install RXTX on the fly if needed. Is Izpack: * able to install binaries for the right platform (os + hardware architecture)? * Java 1.2 compatible * able to run from the command line? I need as many pre-compiled binaries as possible. Could you help me with that? The detection system already works. Thanks again, Pascal PS Is the gnu.io namespace still necessary? I couldn't find the problem. From naranjo.manuel at gmail.com Fri Jul 7 17:04:31 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 07 Jul 2006 20:04:31 -0300 Subject: [Rxtx] Java installer In-Reply-To: <200607080055.04501.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: <44AEE87F.60202@gmail.com> Pascal: I will be a little short with my answer but very informative :) > Could you publish the IzPack configuration and the binaries? That would be > very helpful since the current installation procedure is > somewhat "unprofessional". ;) > > IzPack is great but this API is a little more than that. It allows java > applications who require the extension to detect available versions and > install RXTX on the fly if needed. > > Is Izpack: > * able to install binaries for the right platform (os + hardware > architecture)? Yes. > * Java 1.2 compatible Yes of course > * able to run from the command line? Yes, and can run from command line detecting which is the underlaying os. I have attached an old version of one of my installer, I can't find the last one, but it is like this one. In this you will see how to detect the OS and architecture and install binaries for that plataform. Regards, Manuel -------------- next part -------------- A non-text attachment was scrubbed... Name: installer.xml Type: text/xml Size: 4683 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060707/fbc3be3c/installer-0353.xml From pascal at quies.net Fri Jul 7 18:35:29 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 02:35:29 +0200 Subject: [Rxtx] Java installer In-Reply-To: <44AEE87F.60202@gmail.com> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <44AEE87F.60202@gmail.com> Message-ID: <200607080235.29486.pascal@quies.net> Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: > > Is Izpack: > > * able to install binaries for the right platform (os + hardware > > architecture)? > > Yes. > > > * Java 1.2 compatible > > Yes of course > > > * able to run from the command line? > > Yes, and can run from command line detecting which is the underlaying os. > I have attached an old version of one of my installer, I can't find the > last one, but it is like this one. In this you will see how to detect > the OS and architecture and install binaries for that plataform. > Regards, > Manuel You are right. IzPack looks like the right tool for this job. As far as I can see there is no commandline support but I'll get over it. ;) I'll link my detection system to the IzPack installation procedure and publish the results. From tjarvi at qbang.org Fri Jul 7 19:00:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 7 Jul 2006 19:00:56 -0600 (MDT) Subject: [Rxtx] Controlling Individual Signals DTR and RTS In-Reply-To: References: Message-ID: On Thu, 6 Jul 2006, Trent Jarvi wrote: > On Thu, 29 Jun 2006, Chris Pine wrote: > >> Dear Moussa Ba, >> I hope I am not being too forward, but we are having the exact same >> issue with needing to control DTR from RXTX in Linux. Did you ever have any >> luck figuring it out? >> >> Thank you very much for your time, >> > > Hi Chris > > Are you using an unusual serial port? It could be that the port does not > support DTR/RTS. Especially if its an inexpensive USB->Serial dongle. > > I'll double check Linux tomorrow but I'm fairly sure it works. I have > verified windows after a questions like yours. Some multiport cards and > usb dongles do not support everything. > I double checked that DTR and RTS are working. The system was a 64 bit opteron with an inexexpensive dual port serial card. Suse 9.3 rxtx 2.1-7 (final). I just used the demo SerialBlackBox that used to come with commapi modified to use rxtx 2.1. The serial card was a NetMos PCI NM9835CV with a 16C550 high speed UART dual port. These are not expensive cards. Everything worked fine. I could see the voltage flipping back and forth on the scope for both DTR(pin 4) and CTS(pin 7). You are not the first to report problems. But everytime I try to reproduce the problem, it appears to work. I suspect it is either hardware or kernel driver related and not specific to RXTX. Note that playing with RTS and DTR with hardware flow control enabled does not make sense as those pins are used for the flow control. I've not looked at many USB serial dongles but I have noticed that some are not as good as others. I think one lacked DTR/CTS support. Another one appeared to be fully functional. The one I noticed no issues with was the Hawking Tech HUC232S on windows. I did not test it on Mac OS X or Linux. The same variability can be observed with multiport serial cards. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jul 7 19:15:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 7 Jul 2006 19:15:06 -0600 (MDT) Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: References: <44AC7902.8070407@adventnet.com> Message-ID: On Fri, 7 Jul 2006, Brian Schlining wrote: > Also, for some command/response applications that I've tried with RXTX, I > find that if I write to the serialport and then immediately try to read from > it I get byte arrays filled with zeros, no matter what I set the > recieveTimeout to (this has occurred on both Mac OS X and Windows). The > workaround that I found was to very briefly put the I/O thread to sleep, like > so: > > // DO set up and get I/O streams > //in = serialPort.getInputStream(); > //out = serialPort.getOutputStream(); > > out.write(someByteArray); > try { > Thread.sleep(10); > catch (InterruptedException e) { > // handle exception > } > in.read(anotherByteArray); > > Note: I've never had to put the thread to sleep using Java comm, only with > RXTX. Anyone know why this might be? Hi Brian Interesting. Is this something that can be reproduced with a loopback connection or something commonly available? I was unaware of this behavior. Is it restricted to something that quickly opens, writes, reads and closes the port by chance? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jul 7 19:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 7 Jul 2006 19:39:37 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607080055.04501.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > Is the gnu.io namespace still necessary? I couldn't find the problem. Hi Pascal CommAPI is a little different in that it was grandfathered into the javax namespace with its own license at the time. It is my understanding that if CommAPI went through the JSR process, anyone would _clearly_ be able to implement a javax.comm package and RXTX would then be one of the first to do so. I believe Doug has expressed some interest in RXTX trying to work with the JSR process. Besides the license questions, there is the fact that RXTX has extensions to CommAPI which could cause confusion in the namespace. Not being a lawyer and *really* not liking to talk to lawyers in my free time, it is better to be safe than sorry. The lawyers tend to come in wolf packs when they do come. There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay there as long as we are just geeks trying to figure out if a license does or does not allow us to implement in the javax.comm namespace. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Sat Jul 8 05:30:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 13:30:24 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: <200607081330.24381.pascal@quies.net> Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > > Is the gnu.io namespace still necessary? I couldn't find the problem. > > Hi Pascal > > CommAPI is a little different in that it was grandfathered into the javax > namespace with its own license at the time. > > It is my understanding that if CommAPI went through the JSR process, > anyone would _clearly_ be able to implement a javax.comm package and RXTX > would then be one of the first to do so. I believe Doug has expressed > some interest in RXTX trying to work with the JSR process. > > Besides the license questions, there is the fact that RXTX has extensions > to CommAPI which could cause confusion in the namespace. Not being a > lawyer and *really* not liking to talk to lawyers in my free time, it is > better to be safe than sorry. The lawyers tend to come in wolf packs > when they do come. > > There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay > there as long as we are just geeks trying to figure out if a license does > or does not allow us to implement in the javax.comm namespace. Nicely said. :) The whole point of namespaces is to create a universal registry of, in this case, classes. This gnu.io namespace is very inconvenient. We feel the same way about lawyers. However I'd like to go into the details of the license (see attachment) if you don't mind? The first license does not apply since RXTX does not use the software. The second one at point 3 specifies our options. > 3. You may not modify the Java Platform Interface ("JPI", identified as > classes contained within the "java" package or any subpackages of the > "java" package), by creating additional classes within the JPI or otherwise > causing the addition to or modification of the classes in the JPI. RXTX is a extension. > In the event that you create an additional class and associated API(s) > which (i) extends the functionality of the Java platform, and (ii) is > exposed to third party software developers for the purpose of developing > additional software which invokes such additional API, you must promptly > publish broadly an accurate specification for such API for free use by all > developers. That's the way we operate. :) > You may not create, or authorize your licensees to create additional > classes, interfaces, or subpackages that are in any way identified as > "java", "javax", "sun" or similar convention as specified by Sun in any > naming convention designation. They don't want additional components in the Communication API since they don't want a mess in theire namespace. So we *can* use javax.comm for the core: javax.comm.CommDriver javax.comm.CommPort javax.comm.CommPortIdentifier javax.comm.CommPortOwnershipListener javax.comm.NoSuchPortException javax.comm.PortInUseException javax.comm.UnsupportedCommOperationException ...and for the default hardware support: javax.comm.SerialPort javax.comm.SerialPortEvent javax.comm.SerialPortEventListener javax.comm.ParralelPort javax.comm.ParralelPortEvent javax.comm.ParralelPortEventListener ...but RXTX aditional hardware support has to go somewhere else like: org.rxtx.RS485Port org.rxtx.RS485PortEvent org.rxtx.RS485PortEventListener org.rxtx.I2CPort org.rxtx.I2CPortEvent org.rxtx.I2CPortEventListener Right? -------------- next part -------------- Sun Microsystems, Inc. Binary Code License Agreement READ THE TERMS OF THIS AGREEMENT AND ANY PROVIDED SUPPLEMENTAL LICENSE TERMS (COLLECTIVELY "AGREEMENT") CAREFULLY BEFORE OPENING THE SOFTWARE MEDIA PACKAGE. BY OPENING THE SOFTWARE MEDIA PACKAGE, YOU AGREE TO THE TERMS OF THIS AGREEMENT. IF YOU ARE ACCESSING THE SOFTWARE ELECTRONICALLY, INDICATE YOUR ACCEPTANCE OF THESE TERMS BY SELECTING THE "ACCEPT" BUTTON AT THE END OF THIS AGREEMENT. IF YOU DO NOT AGREE TO ALL THESE TERMS, PROMPTLY RETURN THE UNUSED SOFTWARE TO YOUR PLACE OF PURCHASE FOR A REFUND OR, IF THE SOFTWARE IS ACCESSED ELECTRONICALLY, SELECT THE "DECLINE" BUTTON AT THE END OF THIS AGREEMENT. 1. LICENSE TO USE. Sun grants you a non-exclusive and non-transferable license for the internal use only of the accompanying software and documentation and any error corrections provided by Sun (collectively "Software"), by the number of users and the class of computer hardware for which the corresponding fee has been paid. 2. RESTRICTIONS. Software is confidential and copyrighted. Title to Software and all associated intellectual property rights is retained by Sun and/or its licensors. Except as specifically authorized in any Supplemental License Terms, you may not make copies of Software, other than a single copy of Software for archival purposes. Unless enforcement is prohibited by applicable law, you may not modify, decompile, or reverse engineer Software. Licensee acknowledges that Licensed Software is not designed or intended for use in the design, construction, operation or maintenance of any nuclear facility. Sun Microsystems, Inc. disclaims any express or implied warranty of fitness for such uses. No right, title or interest in or to any trademark, service mark, logo or trade name of Sun or its licensors is granted under this Agreement. 3. LIMITED WARRANTY. Sun warrants to you that for a period of ninety (90) days from the date of purchase, as evidenced by a copy of the receipt, the media on which Software is furnished (if any) will be free of defects in materials and workmanship under normal use. Except for the foregoing, Software is provided "AS IS". Your exclusive remedy and Sun's entire liability under this limited warranty will be at Sun's option to replace Software media or refund the fee paid for Software. 4. DISCLAIMER OF WARRANTY. UNLESS SPECIFIED IN THIS AGREEMENT, ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT THESE DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. 5.LIMITATION OF LIABILITY. TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF OR RELATED TO THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. In no event will Sun's liability to you, whether in contract, tort (including negligence), or otherwise, exceed the amount paid by you for Software under this Agreement. The foregoing limitations will apply even if the above stated warranty fails of its essential purpose. 6. TERMINATION. This Agreement is effective until terminated. You may terminate this Agreement at any time by destroying all copies of Software. This Agreement will terminate immediately without notice from Sun if you fail to comply with any provision of this Agreement. Upon Termination, you must destroy all copies of Software. 7. EXPORT REGULATIONS. All Software and technical data delivered under this Agreement are subject to US export control laws and may be subject to export or import regulations in other countries. You agree to comply strictly with all such laws and regulations and acknowledge that you have the responsibility to obtain such licenses to export, re-export, or import as may be required after delivery to you. 8. U.S. GOVERNMENT RESTRICTED RIGHTS. If Software is being acquired by or on behalf of the U.S. Government or by a U.S. Government prime contractor or subcontractor (at any tier), then the Government's rights in Software and accompanying documentation will be only as set forth in this Agreement; this is in accordance with 48 CFR 227.7201 through 227.7202-4 (for Department of Defense (DOD) acquisitions) and with 48 CFR 2.101 and 12.212 (for non-DOD acquisitions). 9. GOVERNING LAW. Any action related to this Agreement will be governed by California law and controlling U.S. federal law. No choice of law rules of any jurisdiction will apply. 10, SEVERABILITY. If any provision of this Agreement is held to be unenforceable, this Agreement will remain in effect with the provision omitted, unless omission would frustrate the intent of the parties, in which case this Agreement will immediately terminate. 11. INTEGRATION This Agreement is the entire agreement between you and Sun relating to its subject matter. It supersedes all prior or contemporaneous oral or written communications, proposals, representations and warranties and prevails over any conflicting or additional terms of any quote, order, acknowledgment, or other communication between the parties relating to its subject matter during the term of this Agreement. No modification of this Agreement will be binding, unless in writing and signed by an authorized representative of each party. JAVA OPTIONAL PACKAGE JAVAX.COMM 3.0 SUPPLEMENTAL LICENSE TERMS These supplemental license terms ("Supplemental Terms") add to or modify the terms of the Binary Code License Agreement (collectively, the "Agreement"). Capitalized terms not defined in these Supplemental Terms shall have the same meanings ascribed to them in the Agreement. These Supplemental Terms shall supersede any inconsistent or conflicting terms in the Agreement, or in any license contained within the Software. 1. Software Internal Use and Development License Grant. Subject to the terms and conditions of this Agreement, including, but not limited to Section 3 (Java(TM) Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce internally and use internally the binary form of the Software, complete and unmodified, for the sole purpose of designing, developing and testing your Java applets and applications ("Programs"). 2. License to Distribute Software. In addition to the license granted in Section 1 (Software Internal Use and Development License Grant) of these Supplemental Terms, subject to the terms and conditions of this Agreement, including but not limited to, Section 3 (Java Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce and distribute the Software in binary code form only, provided that you (i) distribute the Software complete and unmodified and only bundled as part of your Programs, (ii) do not distribute additional software intended to replace any component(s) of the Software, (iii) do not remove or alter any proprietary legends or notices contained in the Software, (iv) only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (v) agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software. 3. Java Technology Restrictions. You may not modify the Java Platform Interface ("JPI", identified as classes contained within the "java" package or any subpackages of the "java" package), by creating additional classes within the JPI or otherwise causing the addition to or modification of the classes in the JPI. In the event that you create an additional class and associated API(s) which (i) extends the functionality of the Java platform, and (ii) is exposed to third party software developers for the purpose of developing additional software which invokes such additional API, you must promptly publish broadly an accurate specification for such API for free use by all developers. You may not create, or authorize your licensees to create additional classes, interfaces, or subpackages that are in any way identified as "java", "javax", "sun" or similar convention as specified by Sun in any naming convention designation. 4. Trademarks and Logos. You acknowledge and agree as between you and Sun that Sun owns the SUN, SOLARIS, JAVA, JINI, FORTE, and iPLANET trademarks and all SUN, SOLARIS, JAVA, JINI, FORTE, and iPLANET-related trademarks, service marks, logos and other brand designations ("Sun Marks"), and you agree to comply with the Sun Trademark and Logo Usage Requirements currently located at http://www.sun.com/policies/trademarks. Any use you make of the Sun Marks inures to Sun's benefit. 5. Source Code. Software may contain source code that is provided solely for reference purposes pursuant to the terms of this Agreement. Source code may not be redistributed unless expressly provided for in this Agreement. 6. Termination for Infringement. Either party may terminate this Agreement immediately should any Software become, or in either party's opinion be likely to become, the subject of a claim of infringement of any intellectual property right. For inquiries please contact: Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, California 95054. (LFI#143217/Form ID#011801) From tjarvi at qbang.org Sat Jul 8 10:12:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 10:12:55 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607081330.24381.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <200607081330.24381.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> Is the gnu.io namespace still necessary? I couldn't find the problem. >> >> Hi Pascal >> >> CommAPI is a little different in that it was grandfathered into the javax >> namespace with its own license at the time. >> >> It is my understanding that if CommAPI went through the JSR process, >> anyone would _clearly_ be able to implement a javax.comm package and RXTX >> would then be one of the first to do so. I believe Doug has expressed >> some interest in RXTX trying to work with the JSR process. >> >> Besides the license questions, there is the fact that RXTX has extensions >> to CommAPI which could cause confusion in the namespace. Not being a >> lawyer and *really* not liking to talk to lawyers in my free time, it is >> better to be safe than sorry. The lawyers tend to come in wolf packs >> when they do come. >> >> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay >> there as long as we are just geeks trying to figure out if a license does >> or does not allow us to implement in the javax.comm namespace. > > Nicely said. :) > > The whole point of namespaces is to create a universal registry of, in this > case, classes. This gnu.io namespace is very inconvenient. > > We feel the same way about lawyers. However I'd like to go into the details of > the license (see attachment) if you don't mind? > > The first license does not apply since RXTX does not use the software. The > second one at point 3 specifies our options. > >> 3. You may not modify the Java Platform Interface ("JPI", identified as >> classes contained within the "java" package or any subpackages of the >> "java" package), by creating additional classes within the JPI or otherwise >> causing the addition to or modification of the classes in the JPI. > > RXTX is a extension. > >> In the event that you create an additional class and associated API(s) >> which (i) extends the functionality of the Java platform, and (ii) is >> exposed to third party software developers for the purpose of developing >> additional software which invokes such additional API, you must promptly >> publish broadly an accurate specification for such API for free use by all >> developers. > > That's the way we operate. :) > >> You may not create, or authorize your licensees to create additional >> classes, interfaces, or subpackages that are in any way identified as >> "java", "javax", "sun" or similar convention as specified by Sun in any >> naming convention designation. > > They don't want additional components in the Communication API since they > don't want a mess in theire namespace. > > So we *can* use javax.comm for the core: > javax.comm.CommDriver > javax.comm.CommPort > javax.comm.CommPortIdentifier > javax.comm.CommPortOwnershipListener > javax.comm.NoSuchPortException > javax.comm.PortInUseException > javax.comm.UnsupportedCommOperationException > > ...and for the default hardware support: > javax.comm.SerialPort > javax.comm.SerialPortEvent > javax.comm.SerialPortEventListener > javax.comm.ParralelPort > javax.comm.ParralelPortEvent > javax.comm.ParralelPortEventListener > > ...but RXTX aditional hardware support has to go somewhere else like: > org.rxtx.RS485Port > org.rxtx.RS485PortEvent > org.rxtx.RS485PortEventListener > org.rxtx.I2CPort > org.rxtx.I2CPortEvent > org.rxtx.I2CPortEventListener > > Right? > I do not disagree with anything you said :) RXTX and Sun agree with each other almost completely but not exactly. I think there are three uses of CommAPI and Sun is mainly interested in one. 1) Point of sale. This is the direction Sun is going with limited resources thats causing some problems. They would obviously cause fewer problems with more resources just like rxtx would work with them better with more resources. I'm sure if you talk to people in this area they are very optimitsic about what CommAPI could be. 2) Instrument Control. This is my area of interest as its my job too. I'm still formulating opinions here and it is far to early to say much but I'm very optimistic about what CommAPI could be. 3) Hobby and other hardware control. Circuts, road signs, rxtx in cell phones controlling TVs, you name it. People asking about palm, wince, embeded hardware. This is why I thought it was important to open source rxtx in the beginning and still find it my primary motive to read rxtx email every morning and evening. The optimism here is abundant and self explained. Nothing would make me happier than having someone get a working demo of controlling LEDs with parallel ports that could be used by people learning. So everyone agrees with almost everything. Nobody is looking for conflicts. But these various interests have not been _clearly_ formalized. Licenses are tools for manipulating behavior. Until the above is clearly in line with each other, the license will be a tool for lawyers to cause problems for people working for free. This is why I support a move to go through the JSR process and formalize the relationship. My concern is not really Sun comming after RXTX with Lawyers. I have a great deal of respect for Sun going back to their sunsite project. My concern is how lawyers think. They look at the intent which is not all in line. Then I get what feels like insane conference calls that cost companies over $2000 an hour which pisses me off to no end. Companies paying lawyers to take time from developers for free. This really does happen when a fortune 50 company developer asks their legal department if they can use rxtx. I don't have enough bullets for that. The way you avoid this is formalize everones intent so lawyers don't make conference call meetings in outlook. I want to put those lawyers out of work and if it takes a little discomfort, thats perfectly fine. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Sat Jul 8 11:44:40 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 19:44:40 +0200 Subject: [Rxtx] Fwd: Re: Java installer Message-ID: <200607081944.41123.pascal@quies.net> For some reason the first mail failed... ---------- Doorgestuurd bericht ---------- Subject: Re: [Rxtx] Java installer Date: zaterdag 8 juli 2006 17:18 From: "Pascal S. de Kloe" To: RXTX Developers and Users Hello Manuel, In case of a JDK the installation goes into the "jre" directory. I can't find a simple way to get this information into a variable of IzPack. (see attachment) Do you have a idea? Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: > Pascal: > I will be a little short with my answer but very informative :) > > > Could you publish the IzPack configuration and the binaries? That would > > be very helpful since the current installation procedure is > > somewhat "unprofessional". ;) > > > > IzPack is great but this API is a little more than that. It allows java > > applications who require the extension to detect available versions and > > install RXTX on the fly if needed. > > > > Is Izpack: > > * able to install binaries for the right platform (os + hardware > > architecture)? > > Yes. > > > * Java 1.2 compatible > > Yes of course > > > * able to run from the command line? > > Yes, and can run from command line detecting which is the underlaying os. > I have attached an old version of one of my installer, I can't find the > last one, but it is like this one. In this you will see how to detect > the OS and architecture and install binaries for that plataform. > Regards, > Manuel ------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: izpack.xml Type: text/xml Size: 1401 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060708/413315d2/izpack-0352.xml From joachim at buechse.de Sat Jul 8 10:02:18 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 8 Jul 2006 18:02:18 +0200 Subject: [Rxtx] Java installer In-Reply-To: <200607080055.04501.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: <7D4FA261-44FA-4A6E-8EB9-7A7B0116BB2C@buechse.de> Hello Pascal, as soon as the 2.1.8 version is "released" I'll happily provide you with a precompiled library for Mac OSX. The currently tagged version is 2.17 which has a non standard implementation for OSX. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 08.07.2006, at 00:55, Pascal S. de Kloe wrote: > > I need as many pre-compiled binaries as possible. > Could you help me with that? > > The detection system already works. > > Thanks again, > > Pascal > > > PS > Is the gnu.io namespace still necessary? I couldn't find the problem. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 8 09:18:09 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 17:18:09 +0200 Subject: [Rxtx] Java installer In-Reply-To: <44AEE87F.60202@gmail.com> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <44AEE87F.60202@gmail.com> Message-ID: <200607081718.09605.pascal@quies.net> Hello Manuel, In case of a JDK the installation goes into the "jre" directory. I can't find a simple way to get this information into a variable of IzPack. (see attachment) Do you have a idea? Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: > Pascal: > I will be a little short with my answer but very informative :) > > > Could you publish the IzPack configuration and the binaries? That would > > be very helpful since the current installation procedure is > > somewhat "unprofessional". ;) > > > > IzPack is great but this API is a little more than that. It allows java > > applications who require the extension to detect available versions and > > install RXTX on the fly if needed. > > > > Is Izpack: > > * able to install binaries for the right platform (os + hardware > > architecture)? > > Yes. > > > * Java 1.2 compatible > > Yes of course > > > * able to run from the command line? > > Yes, and can run from command line detecting which is the underlaying os. > I have attached an old version of one of my installer, I can't find the > last one, but it is like this one. In this you will see how to detect > the OS and architecture and install binaries for that plataform. > Regards, > Manuel -------------- next part -------------- A non-text attachment was scrubbed... Name: izpack.xml Type: text/xml Size: 1401 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060708/fa6f5a81/izpack-0352.xml From naranjo.manuel at gmail.com Sat Jul 8 12:52:23 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 15:52:23 -0300 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607081944.41123.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> Message-ID: <44AFFEE7.3090306@gmail.com> Pascal: I can't get exactly your point, but my installer was to avoid modifying the users JDK or JRE. Download this app made by me, and you will get my point: http://www.aircable.net/downloads/AIRcable_Configuration_Utility_v0.2_ALPHA_1.zip, this app bundles RXTX library inside the zip file, and does not need RXTX installed on the Users system. Manuel > For some reason the first mail failed... > > > ---------- Doorgestuurd bericht ---------- > > Subject: Re: [Rxtx] Java installer > Date: zaterdag 8 juli 2006 17:18 > From: "Pascal S. de Kloe" > To: RXTX Developers and Users > > Hello Manuel, > > In case of a JDK the installation goes into the "jre" directory. > I can't find a simple way to get this information into a variable of IzPack. > (see attachment) > > Do you have a idea? > > Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: >> Pascal: >> I will be a little short with my answer but very informative :) >> >>> Could you publish the IzPack configuration and the binaries? That would >>> be very helpful since the current installation procedure is >>> somewhat "unprofessional". ;) >>> >>> IzPack is great but this API is a little more than that. It allows java >>> applications who require the extension to detect available versions and >>> install RXTX on the fly if needed. >>> >>> Is Izpack: >>> * able to install binaries for the right platform (os + hardware >>> architecture)? >> Yes. >> >>> * Java 1.2 compatible >> Yes of course >> >>> * able to run from the command line? >> Yes, and can run from command line detecting which is the underlaying os. >> I have attached an old version of one of my installer, I can't find the >> last one, but it is like this one. In this you will see how to detect >> the OS and architecture and install binaries for that plataform. >> Regards, >> Manuel > > ------------------------------------------------------- > > > ------------------------------------------------------------------------ > > > > > RXTX > 2... > http://www.rxtx.org/ > 1.2 > uninstallRXTX > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Jul 8 12:53:32 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 15:53:32 -0300 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607081944.41123.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> Message-ID: <44AFFF2C.8090005@gmail.com> Even more, the variable ${CURRENT_JRE} referees to the actuall JVM as far as I know, so you will have no difference in installing towards a JDK. > For some reason the first mail failed... > > > ---------- Doorgestuurd bericht ---------- > > Subject: Re: [Rxtx] Java installer > Date: zaterdag 8 juli 2006 17:18 > From: "Pascal S. de Kloe" > To: RXTX Developers and Users > > Hello Manuel, > > In case of a JDK the installation goes into the "jre" directory. > I can't find a simple way to get this information into a variable of IzPack. > (see attachment) > > Do you have a idea? > > Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: >> Pascal: >> I will be a little short with my answer but very informative :) >> >>> Could you publish the IzPack configuration and the binaries? That would >>> be very helpful since the current installation procedure is >>> somewhat "unprofessional". ;) >>> >>> IzPack is great but this API is a little more than that. It allows java >>> applications who require the extension to detect available versions and >>> install RXTX on the fly if needed. >>> >>> Is Izpack: >>> * able to install binaries for the right platform (os + hardware >>> architecture)? >> Yes. >> >>> * Java 1.2 compatible >> Yes of course >> >>> * able to run from the command line? >> Yes, and can run from command line detecting which is the underlaying os. >> I have attached an old version of one of my installer, I can't find the >> last one, but it is like this one. In this you will see how to detect >> the OS and architecture and install binaries for that plataform. >> Regards, >> Manuel > > ------------------------------------------------------- > > > ------------------------------------------------------------------------ > > > > > RXTX > 2... > http://www.rxtx.org/ > 1.2 > uninstallRXTX > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Jul 8 12:54:22 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 15:54:22 -0300 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <200607081330.24381.pascal@quies.net> Message-ID: <44AFFF5E.50603@gmail.com> > > I do not disagree with anything you said :) > > RXTX and Sun agree with each other almost completely but not exactly. I > think there are three uses of CommAPI and Sun is mainly interested in one. > > 1) Point of sale. This is the direction Sun is going with limited > resources thats causing some problems. They would obviously cause fewer > problems with more resources just like rxtx would work with them better > with more resources. I'm sure if you talk to people in this area they are > very optimitsic about what CommAPI could be. > > 2) Instrument Control. This is my area of interest as its my job too. I'm > still formulating opinions here and it is far to early to say much but I'm > very optimistic about what CommAPI could be. > > 3) Hobby and other hardware control. Circuts, road signs, rxtx in cell > phones controlling TVs, you name it. People asking about palm, wince, > embeded hardware. This is why I thought it was important to open source > rxtx in the beginning and still find it my primary motive to read rxtx > email every morning and evening. The optimism here is abundant and self > explained. Nothing would make me happier than having someone get a > working demo of controlling LEDs with parallel ports that could be used by > people learning. > > So everyone agrees with almost everything. Nobody is looking for > conflicts. But these various interests have not been _clearly_ > formalized. Licenses are tools for manipulating behavior. Until the > above is clearly in line with each other, the license will be a tool for > lawyers to cause problems for people working for free. This is why I > support a move to go through the JSR process and formalize the > relationship. > > My concern is not really Sun comming after RXTX with Lawyers. I have a > great deal of respect for Sun going back to their sunsite project. My > concern is how lawyers think. They look at the intent which is not all in > line. Then I get what feels like insane conference calls that cost > companies over $2000 an hour which pisses me off to no end. Companies > paying lawyers to take time from developers for free. This really does > happen when a fortune 50 company developer asks their legal department if > they can use rxtx. I don't have enough bullets for that. > > The way you avoid this is formalize everones intent so lawyers don't > make conference call meetings in outlook. I want to put those lawyers out > of work and if it takes a little discomfort, thats perfectly fine. > > -- > Trent Jarvi > tjarvi at qbang.org > > Trent: GREAT MAIL, I hate lawyers too. From naranjo.manuel at gmail.com Sat Jul 8 07:52:47 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 10:52:47 -0300 Subject: [Rxtx] Java installer In-Reply-To: <200607080235.29486.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <44AEE87F.60202@gmail.com> <200607080235.29486.pascal@quies.net> Message-ID: <44AFB8AF.50403@gmail.com> > > You are right. IzPack looks like the right tool for this job. > > As far as I can see there is no commandline support but I'll get over it. ;) Actually there is a way to execute native app in the Underlaying OS. Check out the JavaDOC and all the documentation given by them. If you need to also generate warper around the jar files, check this projects out: http://launch4j.sourceforge.net and http://jsmooth.sourceforge.net/ I have been able to make and exe with jsmooth that does not need to have RXTX installed if you want I can send the source of it. But it is simple. Do not put the jar inside the exe file, and add to the classpath relative paths to rxtx jar and then your jar file, and then add to the JVM command line (I can't remeber the actual name of it :P) -Djava.library.path=bin\ (Or were ever you installed the binary package). I have tryied doing the same with Java Comm from Sun but it actually is imposible, the main difference to me that make me move to RXTX, was that there is no need to have the javax.comm.properties file, which gave me lot of headaches. Regards, Manuel. From naranjo.manuel at gmail.com Sat Jul 8 08:03:58 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 11:03:58 -0300 Subject: [Rxtx] License question. Message-ID: <44AFBB4E.70808@gmail.com> Hi: I have a question, haven't you ever thought about changing RXTX license from GNU/GPL to a more open license like Apache v2 or BSD like?. As far as I understand if I make an application that uses RXTX libraries, I must release my app under the GNU/GPL. I have no problem with that in fact I'm an Open Source user and defender. The fact is that in same cases the applications made by one, could get into hands of a company that needs to release a Closed Source app. I understand that using GNU/GPL do not give you the power to do this, but a more "open" license like Apache does. By "open" I mean that the license respects the Open Source license, but also lives the user the opportunity to use the library in closed source programs. I have seen that there is an exception to the license that applies to RXTX v2.0-5 and above, the only problem with it is that Java Comm Api (the jar file) needs the file javax.comm.properties installed correctly, which in lot of cases is a headache. RXTX jar does not need this, actually I think that RXTX is more user friendly than Java Comm. Maybe there has been a discussion like this before, but I just wanted to ask, and to get an answer that is adequate to our time. Regards, Manuel From pascal at quies.net Sat Jul 8 14:03:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:03:13 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <44AFFF2C.8090005@gmail.com> References: <200607081944.41123.pascal@quies.net> <44AFFF2C.8090005@gmail.com> Message-ID: <200607082203.13696.pascal@quies.net> Op zaterdag 8 juli 2006 20:53, schreef Manuel Naranjo: > Even more, the variable ${CURRENT_JRE} referees to the actuall JVM as > far as I know, so you will have no difference in installing towards a JDK. As far as the installation instructions go the location of the libraries is the following. Windows * JRE: $JAVA_HOME/bin/ * JDK: $JAVA_HOME/jre/bin/ UNIX * JRE: $JAVA_HOME/lib/ * JRE: $JAVA_HOME/jre/lib/ From pascal at quies.net Sat Jul 8 14:04:50 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:04:50 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <44AFFEE7.3090306@gmail.com> References: <200607081944.41123.pascal@quies.net> <44AFFEE7.3090306@gmail.com> Message-ID: <200607082204.50712.pascal@quies.net> Op zaterdag 8 juli 2006 20:52, schreef Manuel Naranjo: > Pascal: > I can't get exactly your point, but my installer was to avoid modifying > the users JDK or JRE. Download this app made by me, and you will get my > point: > http://www.aircable.net/downloads/AIRcable_Configuration_Utility_v0.2_ALPHA >_1.zip, this app bundles RXTX library inside the zip file, and does not need > RXTX installed on the Users system. > Manuel I didn't get the point indeed and I still don't get it. :$ The installation instructions state that RXTX.jar must be in the classpath and the libraries should go as my previous mail stated. Do you have another way? I don't have Windows so i can't run that EXE. From pascal at quies.net Sat Jul 8 14:05:40 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:05:40 +0200 Subject: [Rxtx] Java installer In-Reply-To: <7D4FA261-44FA-4A6E-8EB9-7A7B0116BB2C@buechse.de> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <7D4FA261-44FA-4A6E-8EB9-7A7B0116BB2C@buechse.de> Message-ID: <200607082205.40527.pascal@quies.net> Op zaterdag 8 juli 2006 18:02, schreef Joachim Buechse: > as soon as the 2.1.8 version is "released" I'll happily provide you ? > with a precompiled library for Mac OSX. The currently tagged version ? > is 2.17 which has a non standard implementation for OSX. Perfect! :) Do you have a idea when that will be? Like this month? From pascal at quies.net Sat Jul 8 14:14:44 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:14:44 +0200 Subject: [Rxtx] Java installer In-Reply-To: <44AFB8AF.50403@gmail.com> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080235.29486.pascal@quies.net> <44AFB8AF.50403@gmail.com> Message-ID: <200607082214.45115.pascal@quies.net> Op zaterdag 8 juli 2006 15:52, schreef Manuel Naranjo: > > You are right. IzPack looks like the right tool for this job. > > > > As far as I can see there is no commandline support but I'll get over it. > > ;) > > Actually there is a way to execute native app in the Underlaying OS. > Check out the JavaDOC and all the documentation given by them. > If you need to also generate warper around the jar files, check this > projects out: > http://launch4j.sourceforge.net and http://jsmooth.sourceforge.net/ > I have been able to make and exe with jsmooth that does not need to > have RXTX installed if you want I can send the source of it. But it is > simple. > Do not put the jar inside the exe file, and add to the classpath > relative paths to rxtx jar and then your jar file, and then add to the > JVM command line (I can't remeber the actual name of it :P) > -Djava.library.path=bin\ (Or were ever you installed the binary package). > I have tryied doing the same with Java Comm from Sun but it actually is > imposible, the main difference to me that make me move to RXTX, was that > there is no need to have the javax.comm.properties file, which gave me > lot of headaches. > Regards, > Manuel. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Those are verry interresting and impressive tools for Windows. However, I wanted (and still do) a universal installer for all supported platforms as a single JAR. IzPack seemed quite suitable but it is limited and not well written so I'me still searching... Thanks for the help though. :) From pascal at quies.net Sat Jul 8 14:19:59 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:19:59 +0200 Subject: [Rxtx] License question. In-Reply-To: <44AFBB4E.70808@gmail.com> References: <44AFBB4E.70808@gmail.com> Message-ID: <200607082219.59514.pascal@quies.net> I thought of the same thing. The modified BSD license would certainly make it more eazy and acceptable for Sun to include RXTX in theire products. Unfortunately in general people who chose GPL don't like other licenses. ;) Op zaterdag 8 juli 2006 16:03, schreef Manuel Naranjo: > Hi: > I have a question, haven't you ever thought about changing RXTX license > from GNU/GPL to a more open license like Apache v2 or BSD like?. > As far as I understand if I make an application that uses RXTX > libraries, I must release my app under the GNU/GPL. I have no problem > with that in fact I'm an Open Source user and defender. > The fact is that in same cases the applications made by one, could get > into hands of a company that needs to release a Closed Source app. I > understand that using GNU/GPL do not give you the power to do this, but > a more "open" license like Apache does. By "open" I mean that the > license respects the Open Source license, but also lives the user the > opportunity to use the library in closed source programs. > I have seen that there is an exception to the license that applies to > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > (the jar file) needs the file javax.comm.properties installed correctly, > which in lot of cases is a headache. RXTX jar does not need this, > actually I think that RXTX is more user friendly than Java Comm. > Maybe there has been a discussion like this before, but I just wanted to > ask, and to get an answer that is adequate to our time. > Regards, > Manuel > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jul 8 15:30:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 15:30:31 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <44AFBB4E.70808@gmail.com> References: <44AFBB4E.70808@gmail.com> Message-ID: On Sat, 8 Jul 2006, Manuel Naranjo wrote: > Hi: > I have a question, haven't you ever thought about changing RXTX license > from GNU/GPL to a more open license like Apache v2 or BSD like?. > As far as I understand if I make an application that uses RXTX > libraries, I must release my app under the GNU/GPL. I have no problem > with that in fact I'm an Open Source user and defender. > The fact is that in same cases the applications made by one, could get > into hands of a company that needs to release a Closed Source app. I > understand that using GNU/GPL do not give you the power to do this, but > a more "open" license like Apache does. By "open" I mean that the > license respects the Open Source license, but also lives the user the > opportunity to use the library in closed source programs. > I have seen that there is an exception to the license that applies to > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > (the jar file) needs the file javax.comm.properties installed correctly, > which in lot of cases is a headache. RXTX jar does not need this, > actually I think that RXTX is more user friendly than Java Comm. > Maybe there has been a discussion like this before, but I just wanted to > ask, and to get an answer that is adequate to our time. > Regards, > Manuel Hi Manuel As one of the primary copyright 'owners' and a representative of all the people who have worked on RXTX I feel very compelled to comment on this. I often observe this misconception and just ignore it. RXTX is very commercial friendly both in open and closed source. The license is LGPL not GPL. This allows for linking to any application you like without sharing yoru application code. It is not unlike Apache or BSD in that sense. I like the BSD license but not in this case. The difference is you can not keep your changes to rxtx itself if your product is distributed in practice. To me this makes no sense and is a basic flaw in BSD licensing for libraries. I have _no_ intentions of "competing" with various incarnations of RXTX. If you use RXTX in your commercial application, I hope for two things. First I want you to do well for using rxtx even if you somehow compete with me in the commercial world. Second I want to see changes to RXTX come back to RXTX so we all do well for choosing RXTX. This is not possible with the BSD, MIT ... licenses. They result in multiple forks from the code and this is used to disrupt 'standards' by companies you would recognize (I no longer mention any company when saying bad things without fair notice). Your code is your code. Thats how the LGPL works. But don't take RXTX and fork it where I or anyone else that has worked on RXTX can see it. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Sat Jul 8 16:06:17 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 00:06:17 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> Message-ID: <200607090006.18197.pascal@quies.net> Op zaterdag 8 juli 2006 23:30, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Manuel Naranjo wrote: > > Hi: > > I have a question, haven't you ever thought about changing RXTX license > > from GNU/GPL to a more open license like Apache v2 or BSD like?. > > As far as I understand if I make an application that uses RXTX > > libraries, I must release my app under the GNU/GPL. I have no problem > > with that in fact I'm an Open Source user and defender. > > The fact is that in same cases the applications made by one, could get > > into hands of a company that needs to release a Closed Source app. I > > understand that using GNU/GPL do not give you the power to do this, but > > a more "open" license like Apache does. By "open" I mean that the > > license respects the Open Source license, but also lives the user the > > opportunity to use the library in closed source programs. > > I have seen that there is an exception to the license that applies to > > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > > (the jar file) needs the file javax.comm.properties installed correctly, > > which in lot of cases is a headache. RXTX jar does not need this, > > actually I think that RXTX is more user friendly than Java Comm. > > Maybe there has been a discussion like this before, but I just wanted to > > ask, and to get an answer that is adequate to our time. > > Regards, > > Manuel > > Hi Manuel > > As one of the primary copyright 'owners' and a representative of all the > people who have worked on RXTX I feel very compelled to comment on this. > I often observe this misconception and just ignore it. > > RXTX is very commercial friendly both in open and closed source. The > license is LGPL not GPL. This allows for linking to any application you > like without sharing yoru application code. It is not unlike Apache or > BSD in that sense. I like the BSD license but not in this case. > > The difference is you can not keep your changes to rxtx itself if your > product is distributed in practice. To me this makes no sense and is a > basic flaw in BSD licensing for libraries. I have _no_ intentions of > "competing" with various incarnations of RXTX. If you use RXTX in your > commercial application, I hope for two things. First I want you to do > well for using rxtx even if you somehow compete with me in the commercial > world. Second I want to see changes to RXTX come back to RXTX so we all > do well for choosing RXTX. > > This is not possible with the BSD, MIT ... licenses. They result in > multiple forks from the code and this is used to disrupt 'standards' by > companies you would recognize (I no longer mention any company when > saying bad things without fair notice). > > Your code is your code. Thats how the LGPL works. But don't take RXTX > and fork it where I or anyone else that has worked on RXTX can see it. > > -- > Trent Jarvi Hallo Trent, The BSD license wants to give and GPL wants to improve the public available content. What do you prefer? If you build the code to provide everyone a better experience then the BSD license would be suitable since the business acceptance is much higher. If you see this as a crucial component to build a complete free Java infrastructure that has no place for commerce then the GPL would be better In both situations RXTX will be free. I say that the chance a company would not contribute does not outweight the chance that the API is less available to the users. The entire API is a dead end. Mustang has USB support. Please let's make this as good as it gets. From tjarvi at qbang.org Sat Jul 8 16:09:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 16:09:31 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <200607082219.59514.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > I thought of the same thing. The modified BSD license would certainly make it > more eazy and acceptable for Sun to include RXTX in theire products. > > Unfortunately in general people who chose GPL don't like other licenses. ;) > If Sun can not accept the license, thats their problem. I have no problem with Sun distributing RXTX and working with the community. I've even stepped down as then primary and given that power to Doug to facilitate different opinions. For licensing changes, I am the primary copyright owner and have very strong opinions though I have a great deal of respect for everyone that has contributed to RXTX. Sun has their process and we have our process - screwy but a process and real. RXTX is not going to rubber stamp into any company without process that gives major power to the contributors to RXTX. There is a community here and it is not Sun's. (It isn't "gnu" either; the license is closest) This isn't about Trent. He is a wierd guy you should fear. That said, I'm not fundamentally against Sun distributing RXTX and changing package names. What I am fundametally against is multiple RXTXs. There isnt enough space for that game. -- Trent Jarvi tarvi at qbang.org From pascal at quies.net Sat Jul 8 16:25:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 00:25:24 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> Message-ID: <200607090025.24884.pascal@quies.net> Op zondag 9 juli 2006 00:09, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > > I thought of the same thing. The modified BSD license would certainly > > make it more eazy and acceptable for Sun to include RXTX in theire > > products. > > > > Unfortunately in general people who chose GPL don't like other licenses. > > ;) > > If Sun can not accept the license, thats their problem. > > I have no problem with Sun distributing RXTX and working with the > community. I've even stepped down as then primary and given that power to > Doug to facilitate different opinions. For licensing changes, I am the > primary copyright owner and have very strong opinions though I have a > great deal of respect for everyone that has contributed to RXTX. > > Sun has their process and we have our process - screwy but a process and > real. RXTX is not going to rubber stamp into any company without process > that gives major power to the contributors to RXTX. There is a community > here and it is not Sun's. (It isn't "gnu" either; the license is closest) > This isn't about Trent. He is a wierd guy you should fear. Hahaha, I found him very reasonable. The LGPL is not going to prevent forks. Any company which would take the code and keep little improvements to theirselves is stupid since they throw away a great deal of support and they know it. RXTX works. It needs a huge cleanup and more strict platform definitions but that's just a matter of time. What do you have to loose? From tjarvi at qbang.org Sat Jul 8 16:33:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 16:33:32 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <200607090025.24884.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> <200607090025.24884.pascal@quies.net> Message-ID: On Sun, 9 Jul 2006, Pascal S. de Kloe wrote: > Op zondag 9 juli 2006 00:09, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> I thought of the same thing. The modified BSD license would certainly >>> make it more eazy and acceptable for Sun to include RXTX in theire >>> products. >>> >>> Unfortunately in general people who chose GPL don't like other licenses. >>> ;) >> >> If Sun can not accept the license, thats their problem. >> >> I have no problem with Sun distributing RXTX and working with the >> community. I've even stepped down as then primary and given that power to >> Doug to facilitate different opinions. For licensing changes, I am the >> primary copyright owner and have very strong opinions though I have a >> great deal of respect for everyone that has contributed to RXTX. >> >> Sun has their process and we have our process - screwy but a process and >> real. RXTX is not going to rubber stamp into any company without process >> that gives major power to the contributors to RXTX. There is a community >> here and it is not Sun's. (It isn't "gnu" either; the license is closest) >> This isn't about Trent. He is a wierd guy you should fear. > > Hahaha, I found him very reasonable. > > The LGPL is not going to prevent forks. No it will not, but it will allow for you or me to view forks and absorb them. It renders forks of RXTX useless at the price of whatever product is shipped. I would ask that you consider the larger picture here. Termios and DCB are almost dead but almost being used like a VISA interface. Everyone just wants it to work but it does not always. So your proposal is to make mulitiple deal protocols? -- Trent Jarvi tjarvi at qbang.org From naranjo.manuel at gmail.com Sat Jul 8 17:20:44 2006 From: naranjo.manuel at gmail.com (Naranjo Manuel Francisco) Date: Sat, 8 Jul 2006 20:20:44 -0300 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> Message-ID: <360bc8300607081620x4e5d0f23h88fef8d81e6b6a0b@mail.gmail.com> Sorry, my mistake then, I thought the license was GPL not LGPL, I guess I readed some thing badly. I have readed all the emails, and you are right, there is no need for a Fork of RXTX, I think it works right as it is. So I can make my app Apache v2 with out any worry, because RXTX is LGPL :), great then. From tjarvi at qbang.org Sat Jul 8 17:57:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 17:57:05 -0600 (MDT) Subject: [Rxtx] License question ver2. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> <200607090025.24884.pascal@quies.net> Message-ID: Are there any more questions relating to this subject? From tjarvi at qbang.org Sat Jul 8 21:14:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 21:14:09 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <200607090006.18197.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607090006.18197.pascal@quies.net> Message-ID: On Sun, 9 Jul 2006, Pascal S. de Kloe wrote: > Op zaterdag 8 juli 2006 23:30, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Manuel Naranjo wrote: >>> Hi: >>> I have a question, haven't you ever thought about changing RXTX license >>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>> As far as I understand if I make an application that uses RXTX >>> libraries, I must release my app under the GNU/GPL. I have no problem >>> with that in fact I'm an Open Source user and defender. >>> The fact is that in same cases the applications made by one, could get >>> into hands of a company that needs to release a Closed Source app. I >>> understand that using GNU/GPL do not give you the power to do this, but >>> a more "open" license like Apache does. By "open" I mean that the >>> license respects the Open Source license, but also lives the user the >>> opportunity to use the library in closed source programs. >>> I have seen that there is an exception to the license that applies to >>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>> (the jar file) needs the file javax.comm.properties installed correctly, >>> which in lot of cases is a headache. RXTX jar does not need this, >>> actually I think that RXTX is more user friendly than Java Comm. >>> Maybe there has been a discussion like this before, but I just wanted to >>> ask, and to get an answer that is adequate to our time. >>> Regards, >>> Manuel >> >> Hi Manuel >> >> As one of the primary copyright 'owners' and a representative of all the >> people who have worked on RXTX I feel very compelled to comment on this. >> I often observe this misconception and just ignore it. >> >> RXTX is very commercial friendly both in open and closed source. The >> license is LGPL not GPL. This allows for linking to any application you >> like without sharing yoru application code. It is not unlike Apache or >> BSD in that sense. I like the BSD license but not in this case. >> >> The difference is you can not keep your changes to rxtx itself if your >> product is distributed in practice. To me this makes no sense and is a >> basic flaw in BSD licensing for libraries. I have _no_ intentions of >> "competing" with various incarnations of RXTX. If you use RXTX in your >> commercial application, I hope for two things. First I want you to do >> well for using rxtx even if you somehow compete with me in the commercial >> world. Second I want to see changes to RXTX come back to RXTX so we all >> do well for choosing RXTX. >> >> This is not possible with the BSD, MIT ... licenses. They result in >> multiple forks from the code and this is used to disrupt 'standards' by >> companies you would recognize (I no longer mention any company when >> saying bad things without fair notice). >> >> Your code is your code. Thats how the LGPL works. But don't take RXTX >> and fork it where I or anyone else that has worked on RXTX can see it. >> >> -- >> Trent Jarvi > > Hallo Trent, > > The BSD license wants to give and GPL wants to improve the public available > content. What do you prefer? > > If you build the code to provide everyone a better experience then the BSD > license would be suitable since the business acceptance is much higher. > If you see this as a crucial component to build a complete free Java > infrastructure that has no place for commerce then the GPL would be better > In both situations RXTX will be free. > > I say that the chance a company would not contribute does not outweight the > chance that the API is less available to the users. > The entire API is a dead end. Mustang has USB support. Please let's make this > as good as it gets. Hi Pascal I can not speak for any company here. I just happen to have become interesting to companies. With RXTX, the intent has always been to improve functionality. I don't play between the two worlds except for borrowing a scope at late in the evening. Thats rxtx and there is nothing else going on. Note that the RXTX library is LGPL. I would be interested in knowing where the GPL confusion comes from. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Jul 9 04:46:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 09 Jul 2006 06:46:49 -0400 Subject: [Rxtx] Java installer In-Reply-To: <200607082214.45115.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080235.29486.pascal@quies.net> <44AFB8AF.50403@gmail.com> <200607082214.45115.pascal@quies.net> Message-ID: Hi All, The problem of improving Java's ability to install and configure applications is a topic of current research. Configuration is a loaded word. When I think of configuration, I think, discover the properties of the operating environment and configure the software to work within that environment. Properties may include, but are not limited to, number and kind of monitors, serial ports, JVM versions, native method libs, graphics cards, graphics libs, write access to directories, changing the default screen saver (a new research topic) etc. There are two deployment solutions I can think of, please correct me, if I have left something out: 1. A source code distro with build tools (i.e., make and or ant) that enable the user to do a build for the target platform. 2. A binary distro built for each platform. Now, Java (in theory), is compile once, run anywhere. This assumes you don't use native methods. Once you start using native methods, you end up with many builds of the libs (one for each supported platform). Assuming you want binary distros for each platform, then you are faced with how to deploy them. Here are two basic approaches I know: 1. Build an application installer 2. Build a web-start distribution Some would argue for the application installer, as this is what many people are used to. Others will argue for a web-start distro. For a JNI-based application, like one that makes use of RXTX, I don't know which approach is "better". To know, one must first establish what "better" means. I think there must be (at least) two properties here: 1. Minimal installation effort 2. Trust. For minimal installation effort, I think that I should be able to download software, on demand, and just run it. Updates are obtained with minimal effort. Everything just works. And on all platforms that I use. For trust, I want to make sure I know the author and am able to hold someone accountable for application creation. I need to be able to thwart man-in-the-middle attacks and assure my user-base that I have signed off on my software. I have been making use of web-start, as a multi-year experiment. I have had mixed results. Particularly with more complex installs that make use of Java3d. In my view, several open problems remain. And cross-platform testing is needed for each major new application, platform, or major native method revision. On the other hand, I have had some good results with Java web start and RXTX. I can cite: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Which is an address book program that should identify your serial port and enable dialing via the modem. The web start system seems to be able to adapt to multiple operating environments. The question of how well this deploys remains open. It should work on mac, windows and linux. If people want to try it and give me feedback, I would appreciate it. Deployment is semi-automatic using Project Initium. This is described in: http://show.docjava.com:8086/pub/document/jot/web.pdf and http://show.docjava.com:8086/pub/document/jot/initium.pdf Thanks! - Doug >Op zaterdag 8 juli 2006 15:52, schreef Manuel Naranjo: >> > You are right. IzPack looks like the right tool for this job. >> > >> > As far as I can see there is no commandline support but I'll get over it. >> > ;) >> >> Actually there is a way to execute native app in the Underlaying OS. >> Check out the JavaDOC and all the documentation given by them. >> If you need to also generate warper around the jar files, check this > > projects out: > > http://launch4j.sourceforge.net and http://jsmooth.sourceforge.net/ > > I have been able to make and exe with jsmooth that does not need to >> have RXTX installed if you want I can send the source of it. But it is >> simple. >> Do not put the jar inside the exe file, and add to the classpath >> relative paths to rxtx jar and then your jar file, and then add to the >> JVM command line (I can't remeber the actual name of it :P) > > -Djava.library.path=bin\ (Or were ever you installed the binary package). >> I have tryied doing the same with Java Comm from Sun but it actually is >> imposible, the main difference to me that make me move to RXTX, was that >> there is no need to have the javax.comm.properties file, which gave me >> lot of headaches. >> Regards, >> Manuel. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >Those are verry interresting and impressive tools for Windows. >However, I wanted (and still do) a universal installer for all supported >platforms as a single JAR. IzPack seemed quite suitable but it is limited and >not well written so I'me still searching... > >Thanks for the help though. :) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 9 05:15:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 13:15:13 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607090006.18197.pascal@quies.net> Message-ID: <200607091315.14053.pascal@quies.net> Op zondag 9 juli 2006 05:14, schreef Trent Jarvi: > Hi Pascal > > I can not speak for any company here. I just happen to have become > interesting to companies. > > With RXTX, the intent has always been to improve functionality. > > I don't play between the two worlds except for borrowing a scope at late > in the evening. Thats rxtx and there is nothing else going on. > > Note that the RXTX library is LGPL. I would be interested in knowing > where the GPL confusion comes from. Hi Trent, The license is stated clearly everywhere so don't worry. You are right that the LGPL should not be a problem for companies. The problem is, especially in larger companies, that the people who take the decissions think differend. When they hear about the demands of the license they rather spend "some" money on a commercial solution just to be sure because the trouble it might cause is not worth it. From pascal at quies.net Sun Jul 9 05:15:41 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 13:15:41 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607090025.24884.pascal@quies.net> Message-ID: <200607091315.41848.pascal@quies.net> Op zondag 9 juli 2006 00:33, schreef Trent Jarvi: > I would ask that you consider the larger picture here. Termios and DCB > are almost dead but almost being used like a VISA interface. Everyone > just wants it to work but it does not always. > > So your proposal is to make mulitiple deal protocols? No, nothing like that. Just use native calls where possible. I'll send you some things this week anyway. From pascal at quies.net Sun Jul 9 05:52:11 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 13:52:11 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607082214.45115.pascal@quies.net> Message-ID: <200607091352.11696.pascal@quies.net> Op zondag 9 juli 2006 12:46, schreef Dr. Douglas Lyon: > Hi All, > The problem of improving Java's ability to > install and configure applications is a topic of current research. > > Configuration is a loaded word. When I think of configuration, > I think, discover the properties of the operating environment and > configure the software to work within that environment. > > Properties may include, but are not limited to, number and > kind of monitors, serial ports, JVM versions, native method libs, > graphics cards, graphics libs, write access to directories, > changing the default screen saver (a new research topic) etc. > > There are two deployment solutions I can think of, > please correct me, if I have left something out: > 1. A source code distro with build tools (i.e., make and or ant) that > enable the user to do a build for the target platform. > 2. A binary distro built for each platform. > > Now, Java (in theory), is compile once, run anywhere. This assumes you > don't use native methods. Once you start using native methods, > you end up with many builds of the libs (one for each supported platform). > > Assuming you want binary distros for each platform, then you are faced with > how to deploy them. Here are two basic approaches I know: > 1. Build an application installer > 2. Build a web-start distribution > > Some would argue for the application installer, as this is what > many people are used to. Others will argue for a web-start distro. > > For a JNI-based application, like one that makes use of RXTX, > I don't know which approach is "better". To know, one must > first establish what "better" means. I think there must be (at least) two > properties here: > 1. Minimal installation effort > 2. Trust. > > For minimal installation effort, I think that I should be able to download > software, on demand, and just run it. Updates are obtained with minimal > effort. Everything just works. And on all platforms that I use. > > For trust, I want to make sure I know the author and am able to hold > someone accountable for application creation. I need to be able to thwart > man-in-the-middle > attacks and assure my user-base that I have signed off on my software. > > I have been making > use of web-start, as a multi-year experiment. > > I have had mixed results. Particularly with more complex installs > that make use of Java3d. In my view, several open problems remain. > And cross-platform testing is needed for each major new application, > platform, or major native method revision. > > On the other hand, I have had some good results with Java web start > and RXTX. I can cite: > http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jn >lp Which is an address book program that should identify your > serial port and enable dialing via the modem. > > The web start system seems to be able to adapt to multiple operating > environments. The question of how well this deploys remains open. > > It should work on mac, windows and linux. If people want to try it > and give me feedback, I would appreciate it. > > Deployment is semi-automatic using Project Initium. This is described in: > http://show.docjava.com:8086/pub/document/jot/web.pdf > and > http://show.docjava.com:8086/pub/document/jot/initium.pdf > > Thanks! > - Doug Hello Dough, We are bumping into the same problems. Youre web-based plan is definitely the way to go. I still didn't find a way to get around two IzPack problems without hacking into the code and it's taking too long so I started again on the inital plan. The CommunicationAPI class does leave the trust thing up to the implementation. This means that users can download and run the JAR and other applications can include the jar to install things if needed. If you could "Initum" this process then RXTX has no installating limits anymore. From joachim at buechse.de Sun Jul 9 07:13:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 9 Jul 2006 15:13:34 +0200 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44AFBB4E.70808@gmail.com> References: <44AFBB4E.70808@gmail.com> Message-ID: <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> Manuel, a simple way to avoid the javax.comm.properties file is to include a class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } into your application jar file and make sure, that you include the javax.comm jar after it. That's all you need. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 08.07.2006, at 16:03, Manuel Naranjo wrote: > Hi: > I have a question, haven't you ever thought about changing RXTX > license > from GNU/GPL to a more open license like Apache v2 or BSD like?. > As far as I understand if I make an application that uses RXTX > libraries, I must release my app under the GNU/GPL. I have no problem > with that in fact I'm an Open Source user and defender. > The fact is that in same cases the applications made by one, could get > into hands of a company that needs to release a Closed Source app. I > understand that using GNU/GPL do not give you the power to do this, > but > a more "open" license like Apache does. By "open" I mean that the > license respects the Open Source license, but also lives the user the > opportunity to use the library in closed source programs. > I have seen that there is an exception to the license that applies to > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > (the jar file) needs the file javax.comm.properties installed > correctly, > which in lot of cases is a headache. RXTX jar does not need this, > actually I think that RXTX is more user friendly than Java Comm. > Maybe there has been a discussion like this before, but I just > wanted to > ask, and to get an answer that is adequate to our time. > Regards, > Manuel > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Sun Jul 9 07:19:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 9 Jul 2006 15:19:43 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607082203.13696.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> <44AFFF2C.8090005@gmail.com> <200607082203.13696.pascal@quies.net> Message-ID: <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> Pascal, I would strongly suggest NOT to follow these installation instructions for OSX. It "poisons" the global Java VM with a specific implementation of RXTX. Plus: there is not one, but several Java VMs installed on every version of OSX. An application specific file and global preference pane defines which VM launches which application. There is really no good reason to install RXTX globally. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 08.07.2006, at 22:03, Pascal S. de Kloe wrote: > > As far as the installation instructions go the location of the > libraries is > the following. > > Windows > * JRE: $JAVA_HOME/bin/ > * JDK: $JAVA_HOME/jre/bin/ > > UNIX > * JRE: $JAVA_HOME/lib/ > * JRE: $JAVA_HOME/jre/lib/ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 9 09:01:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 17:01:24 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> References: <200607081944.41123.pascal@quies.net> <200607082203.13696.pascal@quies.net> <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> Message-ID: <200607091701.24661.pascal@quies.net> Op zondag 9 juli 2006 15:19, schreef Joachim Buechse: > Pascal, > > I would strongly suggest NOT to follow these installation > instructions for OSX. It "poisons" the global Java VM with a specific > implementation of RXTX. Plus: there is not one, but several Java VMs > installed on every version of OSX. An application specific file and > global preference pane defines which VM launches which application. > There is really no good reason to install RXTX globally. I see your points. How can you use the extension non-globally? I asked the same thing for Windows to Manuel. The system will allow you to detect any implementation. So the "poison" becomes a alternative. Applications can install the extension if needed to the current runtime with something like: CommunicationAPI comm = new CommunicationAPI(); if (! comm.available()) { if (comm.installRXTX()) restart(); else handleError("I need the extension!"); } From naranjo.manuel at gmail.com Sun Jul 9 10:36:21 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 09 Jul 2006 13:36:21 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> Message-ID: <44B13085.2000805@gmail.com> Joachim, Does that really work???? I will try it later, thanks :) Manuel > Manuel, > > a simple way to avoid the javax.comm.properties file is to include a > class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > into your application jar file and make sure, that you include the > javax.comm jar after it. That's all you need. > > Regards, > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 08.07.2006, at 16:03, Manuel Naranjo wrote: > >> Hi: >> I have a question, haven't you ever thought about changing RXTX >> license >> from GNU/GPL to a more open license like Apache v2 or BSD like?. >> As far as I understand if I make an application that uses RXTX >> libraries, I must release my app under the GNU/GPL. I have no problem >> with that in fact I'm an Open Source user and defender. >> The fact is that in same cases the applications made by one, could get >> into hands of a company that needs to release a Closed Source app. I >> understand that using GNU/GPL do not give you the power to do this, >> but >> a more "open" license like Apache does. By "open" I mean that the >> license respects the Open Source license, but also lives the user the >> opportunity to use the library in closed source programs. >> I have seen that there is an exception to the license that applies to >> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >> (the jar file) needs the file javax.comm.properties installed >> correctly, >> which in lot of cases is a headache. RXTX jar does not need this, >> actually I think that RXTX is more user friendly than Java Comm. >> Maybe there has been a discussion like this before, but I just >> wanted to >> ask, and to get an answer that is adequate to our time. >> Regards, >> Manuel >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jul 9 10:50:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Jul 2006 10:50:11 -0600 (MDT) Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44B13085.2000805@gmail.com> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> Message-ID: I won't prevent people from discussing this hack. You can discuss anything on the list including things I do not agree with. But I do not agree with that hack. That is not in line with the history of RXTX respecting all that contribute including Sun. If you do this, it is your own thing. Agreeing to disagree is fine and usually the default here :). I just want to make it clear I do disagree. On Sun, 9 Jul 2006, Manuel Naranjo wrote: > Joachim, > Does that really work???? I will try it later, thanks :) > Manuel > >> Manuel, >> >> a simple way to avoid the javax.comm.properties file is to include a >> class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> into your application jar file and make sure, that you include the >> javax.comm jar after it. That's all you need. >> >> Regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 08.07.2006, at 16:03, Manuel Naranjo wrote: >> >>> Hi: >>> I have a question, haven't you ever thought about changing RXTX >>> license >>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>> As far as I understand if I make an application that uses RXTX >>> libraries, I must release my app under the GNU/GPL. I have no problem >>> with that in fact I'm an Open Source user and defender. >>> The fact is that in same cases the applications made by one, could get >>> into hands of a company that needs to release a Closed Source app. I >>> understand that using GNU/GPL do not give you the power to do this, >>> but >>> a more "open" license like Apache does. By "open" I mean that the >>> license respects the Open Source license, but also lives the user the >>> opportunity to use the library in closed source programs. >>> I have seen that there is an exception to the license that applies to >>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>> (the jar file) needs the file javax.comm.properties installed >>> correctly, >>> which in lot of cases is a headache. RXTX jar does not need this, >>> actually I think that RXTX is more user friendly than Java Comm. >>> Maybe there has been a discussion like this before, but I just >>> wanted to >>> ask, and to get an answer that is adequate to our time. >>> Regards, >>> Manuel >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From naranjo.manuel at gmail.com Sun Jul 9 11:43:33 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 09 Jul 2006 14:43:33 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> Message-ID: <44B14045.9030601@gmail.com> Trent: Do you know any other way, to use Java Comm API with RXTX with out the javax.comm.properties?. Have any information about how is the JSR going? Regards, Manuel > > I won't prevent people from discussing this hack. You can discuss > anything on the list including things I do not agree with. > > But I do not agree with that hack. That is not in line with the history > of RXTX respecting all that contribute including Sun. If you do this, > it is your own thing. > > Agreeing to disagree is fine and usually the default here :). I just > want to make it clear I do disagree. > > On Sun, 9 Jul 2006, Manuel Naranjo wrote: > >> Joachim, >> Does that really work???? I will try it later, thanks :) >> Manuel >> >>> Manuel, >>> >>> a simple way to avoid the javax.comm.properties file is to include a >>> class >>> >>> package com.sun.comm; >>> public class SolarisDriver extends gnu.io.RXTXCommDriver { >>> } >>> >>> into your application jar file and make sure, that you include the >>> javax.comm jar after it. That's all you need. >>> >>> Regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich >>> >>> >>> On 08.07.2006, at 16:03, Manuel Naranjo wrote: >>> >>>> Hi: >>>> I have a question, haven't you ever thought about changing RXTX >>>> license >>>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>>> As far as I understand if I make an application that uses RXTX >>>> libraries, I must release my app under the GNU/GPL. I have no problem >>>> with that in fact I'm an Open Source user and defender. >>>> The fact is that in same cases the applications made by one, could get >>>> into hands of a company that needs to release a Closed Source app. I >>>> understand that using GNU/GPL do not give you the power to do this, >>>> but >>>> a more "open" license like Apache does. By "open" I mean that the >>>> license respects the Open Source license, but also lives the user the >>>> opportunity to use the library in closed source programs. >>>> I have seen that there is an exception to the license that applies to >>>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>>> (the jar file) needs the file javax.comm.properties installed >>>> correctly, >>>> which in lot of cases is a headache. RXTX jar does not need this, >>>> actually I think that RXTX is more user friendly than Java Comm. >>>> Maybe there has been a discussion like this before, but I just >>>> wanted to >>>> ask, and to get an answer that is adequate to our time. >>>> Regards, >>>> Manuel >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Jul 9 11:53:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Jul 2006 11:53:19 -0600 (MDT) Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44B14045.9030601@gmail.com> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> Message-ID: Hi Manuel I do not know of another way. If you look at rxtx.org, even the compiled version is hard to find, always late and not what you want. At rxtx.org we just worry about the source and do a minimal effort to provide binaries. I'd love nothing more than someone to start selling RXTX binaries or working with us like Doug is to deliver the problems solved to users. The Free here is Freedom. Not price. There is a need for services rxtx.org is not able to provide well. That said I do not ever expect to recieve anything. It just makes sense for everyone to work together and compete outside of the source. On Sun, 9 Jul 2006, Manuel Naranjo wrote: > Trent: > Do you know any other way, to use Java Comm API with RXTX with out the > javax.comm.properties?. > Have any information about how is the JSR going? > Regards, > Manuel >> >> I won't prevent people from discussing this hack. You can discuss >> anything on the list including things I do not agree with. >> >> But I do not agree with that hack. That is not in line with the history >> of RXTX respecting all that contribute including Sun. If you do this, >> it is your own thing. >> >> Agreeing to disagree is fine and usually the default here :). I just >> want to make it clear I do disagree. >> >> On Sun, 9 Jul 2006, Manuel Naranjo wrote: >> >>> Joachim, >>> Does that really work???? I will try it later, thanks :) >>> Manuel >>> >>>> Manuel, >>>> >>>> a simple way to avoid the javax.comm.properties file is to include a >>>> class >>>> >>>> package com.sun.comm; >>>> public class SolarisDriver extends gnu.io.RXTXCommDriver { >>>> } >>>> >>>> into your application jar file and make sure, that you include the >>>> javax.comm jar after it. That's all you need. >>>> >>>> Regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >>>> >>>> >>>> On 08.07.2006, at 16:03, Manuel Naranjo wrote: >>>> >>>>> Hi: >>>>> I have a question, haven't you ever thought about changing RXTX >>>>> license >>>>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>>>> As far as I understand if I make an application that uses RXTX >>>>> libraries, I must release my app under the GNU/GPL. I have no problem >>>>> with that in fact I'm an Open Source user and defender. >>>>> The fact is that in same cases the applications made by one, could get >>>>> into hands of a company that needs to release a Closed Source app. I >>>>> understand that using GNU/GPL do not give you the power to do this, >>>>> but >>>>> a more "open" license like Apache does. By "open" I mean that the >>>>> license respects the Open Source license, but also lives the user the >>>>> opportunity to use the library in closed source programs. >>>>> I have seen that there is an exception to the license that applies to >>>>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>>>> (the jar file) needs the file javax.comm.properties installed >>>>> correctly, >>>>> which in lot of cases is a headache. RXTX jar does not need this, >>>>> actually I think that RXTX is more user friendly than Java Comm. >>>>> Maybe there has been a discussion like this before, but I just >>>>> wanted to >>>>> ask, and to get an answer that is adequate to our time. >>>>> Regards, >>>>> Manuel >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From naranjo.manuel at gmail.com Sun Jul 9 12:04:28 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 09 Jul 2006 15:04:28 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> Message-ID: <44B1452C.60208@gmail.com> Trent Jarvi wrote: > > Hi Manuel > > I do not know of another way. If you look at rxtx.org, even the > compiled version is hard to find, always late and not what you want. At > rxtx.org we just worry about the source and do a minimal effort to > provide binaries. Then that probes my theory, RXTX is much better than Java comm :) > I'd love nothing more than someone to start selling RXTX binaries or > working with us like Doug is to deliver the problems solved to users. > The Free here is Freedom. Not price. There is a need for services > rxtx.org is not able to provide well. That said I do not ever expect to > recieve anything. It just makes sense for everyone to work together and > compete outside of the source. I would like to contribute with the project giving support, I have worked using JSmooth and IzPack, and been able to make things that make RXTX easier to use and install. I will try to debug them, and send them to the mailing list, so you can do what ever you want with this :). Regards, Manuel From tjarvi at qbang.org Sun Jul 9 22:15:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Jul 2006 22:15:28 -0600 (MDT) Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44B1452C.60208@gmail.com> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> <44B1452C.60208@gmail.com> Message-ID: On Sun, 9 Jul 2006, Manuel Naranjo wrote: > Trent Jarvi wrote: >> >> Hi Manuel >> >> I do not know of another way. If you look at rxtx.org, even the >> compiled version is hard to find, always late and not what you want. At >> rxtx.org we just worry about the source and do a minimal effort to >> provide binaries. > Then that probes my theory, RXTX is much better than Java comm :) > >> I'd love nothing more than someone to start selling RXTX binaries or >> working with us like Doug is to deliver the problems solved to users. >> The Free here is Freedom. Not price. There is a need for services >> rxtx.org is not able to provide well. That said I do not ever expect to >> recieve anything. It just makes sense for everyone to work together and >> compete outside of the source. > I would like to contribute with the project giving support, I have > worked using JSmooth and IzPack, and been able to make things that make > RXTX easier to use and install. I will try to debug them, and send them > to the mailing list, so you can do what ever you want with this :). > Regards, Hi Manuel This is interesting. There are some checks and balances that we do at rxtx.org to make sure random material does not get in. It isn't personal just a low bar that must be crossed. After you get your changes in, you will know that others must cross the same bar. The basic question asked is "Does this change reflect the intent and work of those that have contributed to RXTX." Perhaps Doug is the best person to be the bar here. I'm more than willing to admit my limitations and obviously this is a limitation I face. If Doug is willing to take this task, I'd be glad to give him CVS write access which is more than overdue as he is the official maintainer now :) He then could optionally give you write access if your changes are fine and you represent a bar for new changes. I trust Doug. We do take the bar seriously as you can see. But it is not intended to prevent fair use of RXTX or prevent facilitating new uses. If we don't manage expectations here, there will be all sorts of problems and issues. -- Trent Jarvi tjarvi at qbang.org From zhanglong at adventnet.com Mon Jul 10 02:02:20 2006 From: zhanglong at adventnet.com (zhanglong) Date: Mon, 10 Jul 2006 16:02:20 +0800 Subject: [Rxtx] rxtx can not read data from serialport Message-ID: <44B2098C.6050407@adventnet.com> Dear brian and tjarvi, Thank you! After I set flowcontrol as FLOWCONTROL_RTSCTS_IN serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_IN); Then I can read and write data from serial port on Windows. But On linux9.0,No response,no data. I can get serialport list on my machine.And no error when I open serialport. I use Wevecom GSM modem device.I install Linux in VWware Workstation. And VWware Workstation install on windowsXP,So windowsXP and redhat Linux9.0 are on the same PC. On windows,I use COM1 serialport. On Linux,I use /dev/ttyS0 serialport. I hava test with SerialPort.FLOWCONTROL_XONXOFF_IN flow control,But still no data. How to set flow control,timeout and threshold on linux9.0? Thanks & Regards, Zhanglong -------------- next part -------------- A non-text attachment was scrubbed... Name: ListPort.java Type: text/x-java Size: 1659 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060710/334802b0/ListPort-0351.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: listport return on Windows and Linux.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060710/334802b0/listportreturnonWindowsandLinux-0351.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: TwoWaySerialComm.java Type: text/x-java Size: 3516 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060710/334802b0/TwoWaySerialComm-0351.bin From joachim at buechse.de Mon Jul 10 02:53:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 10 Jul 2006 10:53:09 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607091701.24661.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> <200607082203.13696.pascal@quies.net> <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> <200607091701.24661.pascal@quies.net> Message-ID: <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> The problem is, that once the libraries are installed in JAVA_HOME/ lib they will be loaded in preference to classes in your application classpath. If all you want is to use RXTX, then: - put the native lib in your application directory - include the javax.comm classes and RXTX classes in your application classpath - add the little stub class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } before the javax.comm classes in your application classpath. Alternatively you could also include the native lib in your application jar, extract it at runtime to a temp file, load it with System.load(). This will work on Windows and OSX. I didn't test it on Linux, but it should work. Regards, Joachim On 09.07.2006, at 17:01, Pascal S. de Kloe wrote: > Op zondag 9 juli 2006 15:19, schreef Joachim Buechse: >> Pascal, >> >> I would strongly suggest NOT to follow these installation >> instructions for OSX. It "poisons" the global Java VM with a specific >> implementation of RXTX. Plus: there is not one, but several Java VMs >> installed on every version of OSX. An application specific file and >> global preference pane defines which VM launches which application. >> There is really no good reason to install RXTX globally. > > I see your points. > How can you use the extension non-globally? I asked the same thing > for Windows > to Manuel. > > The system will allow you to detect any implementation. So the > "poison" > becomes a alternative. Applications can install the extension if > needed to > the current runtime with something like: > > CommunicationAPI comm = new CommunicationAPI(); > if (! comm.available()) { > if (comm.installRXTX()) > restart(); > else > handleError("I need the extension!"); > } > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jul 10 06:07:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 10 Jul 2006 06:07:23 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607081330.24381.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <200607081330.24381.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> Is the gnu.io namespace still necessary? I couldn't find the problem. >> >> Hi Pascal >> >> CommAPI is a little different in that it was grandfathered into the javax >> namespace with its own license at the time. >> >> It is my understanding that if CommAPI went through the JSR process, >> anyone would _clearly_ be able to implement a javax.comm package and RXTX >> would then be one of the first to do so. I believe Doug has expressed >> some interest in RXTX trying to work with the JSR process. >> >> Besides the license questions, there is the fact that RXTX has extensions >> to CommAPI which could cause confusion in the namespace. Not being a >> lawyer and *really* not liking to talk to lawyers in my free time, it is >> better to be safe than sorry. The lawyers tend to come in wolf packs >> when they do come. >> >> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay >> there as long as we are just geeks trying to figure out if a license does >> or does not allow us to implement in the javax.comm namespace. > > Nicely said. :) > > The whole point of namespaces is to create a universal registry of, in this > case, classes. This gnu.io namespace is very inconvenient. > > We feel the same way about lawyers. However I'd like to go into the details of > the license (see attachment) if you don't mind? > > The first license does not apply since RXTX does not use the software. The > second one at point 3 specifies our options. > >> 3. You may not modify the Java Platform Interface ("JPI", identified as >> classes contained within the "java" package or any subpackages of the >> "java" package), by creating additional classes within the JPI or otherwise >> causing the addition to or modification of the classes in the JPI. > > RXTX is a extension. > >> In the event that you create an additional class and associated API(s) >> which (i) extends the functionality of the Java platform, and (ii) is >> exposed to third party software developers for the purpose of developing >> additional software which invokes such additional API, you must promptly >> publish broadly an accurate specification for such API for free use by all >> developers. > > That's the way we operate. :) > >> You may not create, or authorize your licensees to create additional >> classes, interfaces, or subpackages that are in any way identified as >> "java", "javax", "sun" or similar convention as specified by Sun in any >> naming convention designation. > > They don't want additional components in the Communication API since they > don't want a mess in theire namespace. > > So we *can* use javax.comm for the core: > javax.comm.CommDriver > javax.comm.CommPort > javax.comm.CommPortIdentifier > javax.comm.CommPortOwnershipListener > javax.comm.NoSuchPortException > javax.comm.PortInUseException > javax.comm.UnsupportedCommOperationException > > ...and for the default hardware support: > javax.comm.SerialPort > javax.comm.SerialPortEvent > javax.comm.SerialPortEventListener > javax.comm.ParralelPort > javax.comm.ParralelPortEvent > javax.comm.ParralelPortEventListener > > ...but RXTX aditional hardware support has to go somewhere else like: > org.rxtx.RS485Port > org.rxtx.RS485PortEvent > org.rxtx.RS485PortEventListener > org.rxtx.I2CPort > org.rxtx.I2CPortEvent > org.rxtx.I2CPortEventListener > > Right? > The one thing this discussion does not cover is in SerialPort.java. See the extensions to commapi listed after the following line: /* ---------------------- end of commapi ------------------------ */ The intent is not to break commapi but it could be perceived as so. The extensions added have been placed there as requested by users of RXTX. It would be nice to discuss these modifications with Sun and perhaps have some added to the final version of CommAPI. Some of them may not make sense while others do. Some can not be implemented in a platform neutral fashion. It would not make sense for RXTX to just bring these into Sun's namespace without due process. This is why I am fundamentally apposed to people "poisoning" Sun's namespace with RXTX 2.1 although I understand that is not their intent. These modifications are not advertised and their use is discouraged. But they are there. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Mon Jul 10 06:47:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 10 Jul 2006 14:47:24 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607081330.24381.pascal@quies.net> Message-ID: <200607101447.25071.pascal@quies.net> Op maandag 10 juli 2006 14:07, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > > Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: > >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > >>> Is the gnu.io namespace still necessary? I couldn't find the problem. > >> > >> Hi Pascal > >> > >> CommAPI is a little different in that it was grandfathered into the > >> javax namespace with its own license at the time. > >> > >> It is my understanding that if CommAPI went through the JSR process, > >> anyone would _clearly_ be able to implement a javax.comm package and > >> RXTX would then be one of the first to do so. I believe Doug has > >> expressed some interest in RXTX trying to work with the JSR process. > >> > >> Besides the license questions, there is the fact that RXTX has > >> extensions to CommAPI which could cause confusion in the namespace. Not > >> being a lawyer and *really* not liking to talk to lawyers in my free > >> time, it is better to be safe than sorry. The lawyers tend to come in > >> wolf packs when they do come. > >> > >> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay > >> there as long as we are just geeks trying to figure out if a license > >> does or does not allow us to implement in the javax.comm namespace. > > > > Nicely said. :) > > > > The whole point of namespaces is to create a universal registry of, in > > this case, classes. This gnu.io namespace is very inconvenient. > > > > We feel the same way about lawyers. However I'd like to go into the > > details of the license (see attachment) if you don't mind? > > > > The first license does not apply since RXTX does not use the software. > > The second one at point 3 specifies our options. > > > >> 3. You may not modify the Java Platform Interface ("JPI", identified as > >> classes contained within the "java" package or any subpackages of the > >> "java" package), by creating additional classes within the JPI or > >> otherwise causing the addition to or modification of the classes in the > >> JPI. > > > > RXTX is a extension. > > > >> In the event that you create an additional class and associated API(s) > >> which (i) extends the functionality of the Java platform, and (ii) is > >> exposed to third party software developers for the purpose of developing > >> additional software which invokes such additional API, you must promptly > >> publish broadly an accurate specification for such API for free use by > >> all developers. > > > > That's the way we operate. :) > > > >> You may not create, or authorize your licensees to create additional > >> classes, interfaces, or subpackages that are in any way identified as > >> "java", "javax", "sun" or similar convention as specified by Sun in any > >> naming convention designation. > > > > They don't want additional components in the Communication API since they > > don't want a mess in theire namespace. > > > > So we *can* use javax.comm for the core: > > javax.comm.CommDriver > > javax.comm.CommPort > > javax.comm.CommPortIdentifier > > javax.comm.CommPortOwnershipListener > > javax.comm.NoSuchPortException > > javax.comm.PortInUseException > > javax.comm.UnsupportedCommOperationException > > > > ...and for the default hardware support: > > javax.comm.SerialPort > > javax.comm.SerialPortEvent > > javax.comm.SerialPortEventListener > > javax.comm.ParralelPort > > javax.comm.ParralelPortEvent > > javax.comm.ParralelPortEventListener > > > > ...but RXTX aditional hardware support has to go somewhere else like: > > org.rxtx.RS485Port > > org.rxtx.RS485PortEvent > > org.rxtx.RS485PortEventListener > > org.rxtx.I2CPort > > org.rxtx.I2CPortEvent > > org.rxtx.I2CPortEventListener > > > > Right? > > The one thing this discussion does not cover is in SerialPort.java. See > the extensions to commapi listed after the following line: > > /* ---------------------- end of commapi ------------------------ */ > > The intent is not to break commapi but it could be perceived as so. The > extensions added have been placed there as requested by users of RXTX. It > would be nice to discuss these modifications with Sun and perhaps have > some added to the final version of CommAPI. > > Some of them may not make sense while others do. Some can not be > implemented in a platform neutral fashion. It would not make sense > for RXTX to just bring these into Sun's namespace without due process. > > This is why I am fundamentally apposed to people "poisoning" Sun's > namespace with RXTX 2.1 although I understand that is not their intent. > > These modifications are not advertised and their use is discouraged. But > they are there. Hi Trent, So you are saying that gnu.io.SerialPort has some aditional methods over javax.comm.SerialPort? That does not change the API at all but it would be a problem if people would start using those methods in the javax.comm namespace in the same way like some people use the com.sun namespace. Could wrapper classes at javax.comm do the job? In that way RXTX stays in its namespace, javadoc can notice the aditional methods and the Communication API will be available as expected. From pascal at quies.net Mon Jul 10 06:48:09 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 10 Jul 2006 14:48:09 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> References: <200607081944.41123.pascal@quies.net> <200607091701.24661.pascal@quies.net> <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> Message-ID: <200607101448.09594.pascal@quies.net> Op maandag 10 juli 2006 10:53, schreef Joachim Buechse: > If all you want is to use RXTX, then: > > - put the native lib in your application directory > - include the javax.comm classes and RXTX classes in your application > classpath > - add the little stub class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > before the javax.comm classes in your application classpath. > > Alternatively you could also include the native lib in your > application jar, extract it at runtime to a temp file, load it with > System.load(). So java will load the native libraries automaticly if they are in the same directory as the Java application? Why isn't this very interresting information noticed in the documentation or is that too obvious and I simply didn't knew? From naranjo.manuel at gmail.com Mon Jul 10 06:56:10 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Mon, 10 Jul 2006 09:56:10 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> <44B1452C.60208@gmail.com> Message-ID: <44B24E6A.1010805@gmail.com> Trent Jarvi wrote: > On Sun, 9 Jul 2006, Manuel Naranjo wrote: > >> Trent Jarvi wrote: >>> Hi Manuel >>> >>> I do not know of another way. If you look at rxtx.org, even the >>> compiled version is hard to find, always late and not what you want. At >>> rxtx.org we just worry about the source and do a minimal effort to >>> provide binaries. >> Then that probes my theory, RXTX is much better than Java comm :) >> >>> I'd love nothing more than someone to start selling RXTX binaries or >>> working with us like Doug is to deliver the problems solved to users. >>> The Free here is Freedom. Not price. There is a need for services >>> rxtx.org is not able to provide well. That said I do not ever expect to >>> recieve anything. It just makes sense for everyone to work together and >>> compete outside of the source. >> I would like to contribute with the project giving support, I have >> worked using JSmooth and IzPack, and been able to make things that make >> RXTX easier to use and install. I will try to debug them, and send them >> to the mailing list, so you can do what ever you want with this :). >> Regards, > > > Hi Manuel > > This is interesting. There are some checks and balances that we do at > rxtx.org to make sure random material does not get in. It isn't personal > just a low bar that must be crossed. After you get your changes in, you > will know that others must cross the same bar. The basic question asked > is "Does this change reflect the intent and work of those that have > contributed to RXTX." > > Perhaps Doug is the best person to be the bar here. I'm more than willing > to admit my limitations and obviously this is a limitation I face. > > If Doug is willing to take this task, I'd be glad to give him CVS write > access which is more than overdue as he is the official maintainer now :) > He then could optionally give you write access if your changes are fine > and you represent a bar for new changes. I trust Doug. > > We do take the bar seriously as you can see. But it is not intended to > prevent fair use of RXTX or prevent facilitating new uses. If we don't > manage expectations here, there will be all sorts of problems and issues. > > -- > Trent Jarvi > tjarvi at qbang.org > > Trent, What I want to send you is not a modification to rxtx, it just a developers helper if you want to put a name to it. I have make an IzPack installer, which installs RXTX binaries depending on underlaying OS. And make an JSmooth warper that launches my app with out the need to have rxtx installed on the host JVM folder, it only need the RXTX to be in the bin\ of my app. I think this is more useful for Wiki than to the main project. Another thing I have experience in PalmOS programming, when ever I have time, I will investigate about the JNI of J2ME and try to port RXTX to Palm, I do not know when I will start, because I have a lot of work now. Regards, Manuel From christopher.dawes at the-logic-group.com Mon Jul 10 08:00:15 2006 From: christopher.dawes at the-logic-group.com (christopher.dawes@the-logic-group.com) Date: Mon, 10 Jul 2006 15:00:15 +0100 Subject: [Rxtx] Chris Dawes/Retaillogic/NISABA is out of the office. Message-ID: I will be out of the office starting 10/07/2006 and will not return until 11/07/2008. Hello, unfortunately I no longer work for The Logic Group, if you're trying to contact me on a work related issue please contact Pete Avery (pete.avery at the-logic-group.com) however if it is a personal matter please e-mail root at ants.me.uk or phone 07899 842 759. Thanks Christopher Dawes From tjarvi at qbang.org Mon Jul 10 08:19:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 10 Jul 2006 08:19:52 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607101447.25071.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607081330.24381.pascal@quies.net> <200607101447.25071.pascal@quies.net> Message-ID: On Mon, 10 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 10 juli 2006 14:07, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: >>>> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>>>> Is the gnu.io namespace still necessary? I couldn't find the problem. >>>> >>>> Hi Pascal >>>> >>>> CommAPI is a little different in that it was grandfathered into the >>>> javax namespace with its own license at the time. >>>> >>>> It is my understanding that if CommAPI went through the JSR process, >>>> anyone would _clearly_ be able to implement a javax.comm package and >>>> RXTX would then be one of the first to do so. I believe Doug has >>>> expressed some interest in RXTX trying to work with the JSR process. >>>> >>>> Besides the license questions, there is the fact that RXTX has >>>> extensions to CommAPI which could cause confusion in the namespace. Not >>>> being a lawyer and *really* not liking to talk to lawyers in my free >>>> time, it is better to be safe than sorry. The lawyers tend to come in >>>> wolf packs when they do come. >>>> >>>> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay >>>> there as long as we are just geeks trying to figure out if a license >>>> does or does not allow us to implement in the javax.comm namespace. >>> >>> Nicely said. :) >>> >>> The whole point of namespaces is to create a universal registry of, in >>> this case, classes. This gnu.io namespace is very inconvenient. >>> >>> We feel the same way about lawyers. However I'd like to go into the >>> details of the license (see attachment) if you don't mind? >>> >>> The first license does not apply since RXTX does not use the software. >>> The second one at point 3 specifies our options. >>> >>>> 3. You may not modify the Java Platform Interface ("JPI", identified as >>>> classes contained within the "java" package or any subpackages of the >>>> "java" package), by creating additional classes within the JPI or >>>> otherwise causing the addition to or modification of the classes in the >>>> JPI. >>> >>> RXTX is a extension. >>> >>>> In the event that you create an additional class and associated API(s) >>>> which (i) extends the functionality of the Java platform, and (ii) is >>>> exposed to third party software developers for the purpose of developing >>>> additional software which invokes such additional API, you must promptly >>>> publish broadly an accurate specification for such API for free use by >>>> all developers. >>> >>> That's the way we operate. :) >>> >>>> You may not create, or authorize your licensees to create additional >>>> classes, interfaces, or subpackages that are in any way identified as >>>> "java", "javax", "sun" or similar convention as specified by Sun in any >>>> naming convention designation. >>> >>> They don't want additional components in the Communication API since they >>> don't want a mess in theire namespace. >>> >>> So we *can* use javax.comm for the core: >>> javax.comm.CommDriver >>> javax.comm.CommPort >>> javax.comm.CommPortIdentifier >>> javax.comm.CommPortOwnershipListener >>> javax.comm.NoSuchPortException >>> javax.comm.PortInUseException >>> javax.comm.UnsupportedCommOperationException >>> >>> ...and for the default hardware support: >>> javax.comm.SerialPort >>> javax.comm.SerialPortEvent >>> javax.comm.SerialPortEventListener >>> javax.comm.ParralelPort >>> javax.comm.ParralelPortEvent >>> javax.comm.ParralelPortEventListener >>> >>> ...but RXTX aditional hardware support has to go somewhere else like: >>> org.rxtx.RS485Port >>> org.rxtx.RS485PortEvent >>> org.rxtx.RS485PortEventListener >>> org.rxtx.I2CPort >>> org.rxtx.I2CPortEvent >>> org.rxtx.I2CPortEventListener >>> >>> Right? >> >> The one thing this discussion does not cover is in SerialPort.java. See >> the extensions to commapi listed after the following line: >> >> /* ---------------------- end of commapi ------------------------ */ >> >> The intent is not to break commapi but it could be perceived as so. The >> extensions added have been placed there as requested by users of RXTX. It >> would be nice to discuss these modifications with Sun and perhaps have >> some added to the final version of CommAPI. >> >> Some of them may not make sense while others do. Some can not be >> implemented in a platform neutral fashion. It would not make sense >> for RXTX to just bring these into Sun's namespace without due process. >> >> This is why I am fundamentally apposed to people "poisoning" Sun's >> namespace with RXTX 2.1 although I understand that is not their intent. >> >> These modifications are not advertised and their use is discouraged. But >> they are there. > > Hi Trent, > > So you are saying that gnu.io.SerialPort has some aditional methods over > javax.comm.SerialPort? > That does not change the API at all but it would be a problem if people would > start using those methods in the javax.comm namespace in the same way like > some people use the com.sun namespace. > Could wrapper classes at javax.comm do the job? In that way RXTX stays in its > namespace, javadoc can notice the aditional methods and the Communication API > will be available as expected. Hi Pascal Yes. There are additional methods in gnu.io.SerialPort. We clearly mark those as extensions to CommAPI and discourage their use. There just isn't a way to get the intended functionality out of CommAPI without them. I think the right thing to do here may be to remove these methods to avoid unintentional polution of the javax namespace if people are going to be putting these classes in that namespace. The way people are using RXTX 2.1 is not the same as it was originally pictured. Thats fine but we need to be responsible. We need to prevent what could be a problem. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Mon Jul 10 08:57:10 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 10 Jul 2006 16:57:10 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101447.25071.pascal@quies.net> Message-ID: <200607101657.11223.pascal@quies.net> > Yes. There are additional methods in gnu.io.SerialPort. We clearly mark > those as extensions to CommAPI and discourage their use. There just isn't > a way to get the intended functionality out of CommAPI without them. If you don't want the users to use the methods then make them class protected (remove the word "public" before the method) and if you can't do that we might do the following: ---- SerialPort.java package javax.comm class SerialPort extends gnu.io.SerialPort { public void rxtxOnlyMethod() { throw new Error("Don't use this method here!\nUse gnu.io.SerialPort instead"); } ---- end From neville_seed at yahoo.com Mon Jul 10 10:20:12 2006 From: neville_seed at yahoo.com (neville seed) Date: Mon, 10 Jul 2006 09:20:12 -0700 (PDT) Subject: [Rxtx] writing first application and compiling In-Reply-To: Message-ID: <20060710162012.9888.qmail@web51015.mail.yahoo.com> Can anyone recommend a starting place for writing, compiling and uploading the first app, ie a simple hello world. It seems that the PALM SDK does not have a build environment. I am happy to develop under linux of windows. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From bob_tai2001 at yahoo.com Mon Jul 10 14:48:30 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 10 Jul 2006 13:48:30 -0700 (PDT) Subject: [Rxtx] Java installer Message-ID: <20060710204830.53745.qmail@web32810.mail.mud.yahoo.com> Hi Manuel, I found your post from the newsletter, hope I am not off topic. You mention there is a IZpack installer for Rxtx? I been waiting for this type of deplyment idea from Rxtx! is this documented in the web site? I am in windows environment but didn't want to create classpath for each workstation. I rather install :) I apologize for cutting into this topic. Bob > >Trent, >What I want to send you is not a modification to rxtx, it just a >developers helper if you want to put a name to it. I have make an IzPack installer, which installs RXTX binaries depending on underlaying OS. And make an JSmooth warper that launches my app with out the need to have rxtx installed on the host JVM folder, it only need the RXTX to be in the bin\ of my app. I think this is more useful for Wiki than to the main project. Another thing I have experience in PalmOS programming, when ever I have time, I will investigate about the JNI of J2ME and try to port RXTX to Palm, I do not know when I will start, because I have a lot of work now. Regards, Manuel __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From naranjo.manuel at gmail.com Mon Jul 10 15:10:21 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Mon, 10 Jul 2006 18:10:21 -0300 Subject: [Rxtx] Java installer In-Reply-To: <20060710204830.53745.qmail@web32810.mail.mud.yahoo.com> References: <20060710204830.53745.qmail@web32810.mail.mud.yahoo.com> Message-ID: <44B2C23D.8050901@gmail.com> Bob, Hi, not this is not a RXTX installer, I have develop an installer with IzPack which actually installs RXTX and my hole app, and I think this can be useful for RXTX users, Regards, Manuel > Hi Manuel, > > I found your post from the newsletter, hope I am not > off topic. You mention there is a IZpack installer > for Rxtx? I been waiting for this type of deplyment > idea from Rxtx! is this documented in the web site? > I am in windows environment but didn't want to create > classpath for each workstation. I rather install :) > > I apologize for cutting into this topic. > > Bob > >> Trent, >> What I want to send you is not a modification to > rxtx, it just a >> developers > helper if you want to put a name to it. I have make an > IzPack > installer, > which installs RXTX binaries depending on underlaying > OS. And make an > JSmooth warper that launches my app with out the need > to have rxtx > installed > on the host JVM folder, it only need the RXTX to be in > the bin\ of my > app. > I think this is more useful for Wiki than to the main > project. > Another thing I have experience in PalmOS programming, > when ever I have > time, > I will investigate about the JNI of J2ME and try to > port RXTX to Palm, > I do not know when I will start, because I have a lot > of work now. > Regards, > Manuel > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From brian at mbari.org Tue Jul 11 11:59:24 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 11 Jul 2006 10:59:24 -0700 Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: References: <44AC7902.8070407@adventnet.com> Message-ID: <485C28F0-CA08-4393-9E34-4C8E7F22C125@mbari.org> Hi Trent, On Jul 7, 2006, at 6:15 PM, Trent Jarvi wrote: > On Fri, 7 Jul 2006, Brian Schlining wrote: >> Also, for some command/response applications that I've tried with >> RXTX, I >> find that if I write to the serialport and then immediately try to >> read from >> it I get byte arrays filled with zeros, no matter what I set the >> recieveTimeout to (this has occurred on both Mac OS X and >> Windows). The >> workaround that I found was to very briefly put the I/O thread to >> sleep, like >> so: >> >> // DO set up and get I/O streams >> //in = serialPort.getInputStream(); >> //out = serialPort.getOutputStream(); >> >> out.write(someByteArray); >> try { >> Thread.sleep(10); >> catch (InterruptedException e) { >> // handle exception >> } >> in.read(anotherByteArray); >> >> Note: I've never had to put the thread to sleep using Java comm, >> only with >> RXTX. Anyone know why this might be? > > Hi Brian > > Interesting. Is this something that can be reproduced with a loopback > connection or something commonly available? I was unaware of this > behavior. Is it restricted to something that quickly opens, > writes, reads > and closes the port by chance? I've encountered this while using RXTX to talk to VCR's that support RS422; I've never tried it with a loopback connection. Note that connection setup is: PC[RS232] <---> RS232/422 Converter <---> VCR[RS422] The application I'm using it for opens a connection and keeps it open for the life of the application. It makes a lot of read and writes when running...probably about as fast as the VCR hardware supports; with Javacomm, I think it was on the order of an IO transaction every 40ms. However even if I perform an IO read/write every 2 seconds with RXTX I still encounter the same problem, so it's not a matter of the frequency of the IO transactions. If you want to look at the code a test example can be found at https://svn.sourceforge.net/svnroot/vars/trunk/vars/src/test/java/ test/org/mbari/vcr/SimpleReadRxtx.java. The actual production code is at https://svn.sourceforge.net/svnroot/vars/trunk/vars/src/main/java/ org/mbari/vcr/rs422/VCR.java. The methods that you might be interested in to see how the code is used are initComm(), sendCommand (), getResponse() in VCR.java. You'll notice Thread.sleep(IO_DELAY) sprinkled in the sendCommand() methods and getResponse(). Without that I get arrays of zeros returned. If the IO_DELAY is less than 15ms then sending commands works fine but reading the responses is not reliable; I mostly get problems when trying to read the last few bytes or a response. Again, everything works fine with Sun's Javacomm w/o the Thread.sleep() on windows. Also, FYI, I tried to run this on a Mac using RXTX 2.0, but I ran into thread synchronization issues. These issues went away when I switched to RXTX 2.1. Cheers B ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining MBARI Software Engineer brian at mbari.org (831)775-1855 http://www.mbari.org/staff/brian I went to the woods because I wished to live deliberately, to front only the essential facts of life, and see if I could not learn what it had to teach, and not, when I came to die, discover that I had not lived. ~ Henry Thoreau -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060711/59b607f3/attachment-0349.html From ajmas at sympatico.ca Wed Jul 12 13:46:51 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 12 Jul 2006 15:46:51 -0400 Subject: [Rxtx] writing first application and compiling Message-ID: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Take a look in the Wiki. I have added a couple of examples in there: http://rxtx.qbang.org/wiki/index.php/Examples Andre > > From: neville seed > Date: 2006/07/10 Mon PM 12:20:12 EDT > To: RXTX Developers and Users > Subject: [Rxtx] writing first application and compiling > > > Can anyone recommend a starting place for writing, > compiling and uploading the first app, ie a simple > hello world. > > It seems that the PALM SDK does not have a build > environment. I am happy to develop under linux of windows. > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Jul 12 19:22:25 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 12 Jul 2006 19:22:25 -0600 (MDT) Subject: [Rxtx] writing first application and compiling In-Reply-To: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Thank you for doing this Andre. I'm sure it will get well used by people learning. I think the old commapi examples are no longer easily available so these are really needed. On Wed, 12 Jul 2006, Andre-John Mas wrote: > Hi, > > Take a look in the Wiki. I have added a couple of examples in there: > > http://rxtx.qbang.org/wiki/index.php/Examples > > Andre > >> >> From: neville seed >> Date: 2006/07/10 Mon PM 12:20:12 EDT >> To: RXTX Developers and Users >> Subject: [Rxtx] writing first application and compiling >> >> >> Can anyone recommend a starting place for writing, >> compiling and uploading the first app, ie a simple >> hello world. >> >> It seems that the PALM SDK does not have a build >> environment. I am happy to develop under linux of windows. >> >> __________________________________________________ >> Do You Yahoo!? >> Tired of spam? Yahoo! Mail has the best spam protection around >> http://mail.yahoo.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Thu Jul 13 17:21:26 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Thu, 13 Jul 2006 19:21:26 -0400 Subject: [Rxtx] writing first application and compiling In-Reply-To: References: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <54D55D35-A143-43AA-AF03-B89ADE9B9246@sympatico.ca> No problems. I would also like to encourage anyone else to contribute other useful stuff they might have. On 12-Jul-06, at 21:22 , Trent Jarvi wrote: > > Thank you for doing this Andre. > > I'm sure it will get well used by people learning. I think the old > commapi examples are no longer easily available so these are really > needed. > > On Wed, 12 Jul 2006, Andre-John Mas wrote: > >> Hi, >> >> Take a look in the Wiki. I have added a couple of examples in there: >> >> http://rxtx.qbang.org/wiki/index.php/Examples >> >> Andre >> >>> >>> From: neville seed >>> Date: 2006/07/10 Mon PM 12:20:12 EDT >>> To: RXTX Developers and Users >>> Subject: [Rxtx] writing first application and compiling >>> >>> >>> Can anyone recommend a starting place for writing, >>> compiling and uploading the first app, ie a simple >>> hello world. >>> >>> It seems that the PALM SDK does not have a build >>> environment. I am happy to develop under linux of windows. >>> >>> __________________________________________________ >>> Do You Yahoo!? >>> Tired of spam? Yahoo! Mail has the best spam protection around >>> http://mail.yahoo.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Sat Jul 8 15:05:46 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sat, 08 Jul 2006 17:05:46 -0400 Subject: [Rxtx] License question. In-Reply-To: <200607082219.59514.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> Message-ID: <44B01E2A.9010207@suespammers.org> Pascal S. de Kloe wrote: > I thought of the same thing. The modified BSD license would certainly make it > more eazy and acceptable for Sun to include RXTX in theire products. > > Unfortunately in general people who chose GPL don't like other licenses. ;) i have a general preference for BSD, but i'll defend RXTX here. RXTX is LGPL, not GPL. they're different, look it up. richard From pascal at quies.net Sun Jul 16 17:40:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 17 Jul 2006 01:40:13 +0200 Subject: [Rxtx] Java installer In-Reply-To: <200607101657.11223.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> Message-ID: <200607170140.14116.pascal@quies.net> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: > > Yes. There are additional methods in gnu.io.SerialPort. We clearly mark > > those as extensions to CommAPI and discourage their use. There just > > isn't a way to get the intended functionality out of CommAPI without > > them. > > If you don't want the users to use the methods then make them class > protected (remove the word "public" before the method) and if you can't do > that we might do the following: > > ---- SerialPort.java > package javax.comm > > class SerialPort extends gnu.io.SerialPort { > > public void > rxtxOnlyMethod() { > throw new Error("Don't use this method here!\nUse gnu.io.SerialPort > instead"); > } > ---- end So how about it, Trent? Can we ship those classes with the next release? From pascal at quies.net Sun Jul 16 17:45:42 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 17 Jul 2006 01:45:42 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> References: <200607081944.41123.pascal@quies.net> <200607091701.24661.pascal@quies.net> <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> Message-ID: <200607170145.43156.pascal@quies.net> Op maandag 10 juli 2006 10:53, schreef Joachim Buechse: > Alternatively you could also include the native lib in your > application jar, extract it at runtime to a temp file, load it with > System.load(). That works indeed. :) I'll finish my "detection class" with such a loader and the RXTX package tomorrow. Then one can simply include the JAR in the classpath and run org.rxtx.CommunicationAPI.initialize() to make sure the API is available. From tjarvi at qbang.org Sun Jul 16 18:59:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 16 Jul 2006 18:59:06 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607170140.14116.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> <200607170140.14116.pascal@quies.net> Message-ID: On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>> Yes. There are additional methods in gnu.io.SerialPort. We clearly mark >>> those as extensions to CommAPI and discourage their use. There just >>> isn't a way to get the intended functionality out of CommAPI without >>> them. >> >> If you don't want the users to use the methods then make them class >> protected (remove the word "public" before the method) and if you can't do >> that we might do the following: >> >> ---- SerialPort.java >> package javax.comm >> >> class SerialPort extends gnu.io.SerialPort { >> >> public void >> rxtxOnlyMethod() { >> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >> instead"); >> } >> ---- end > > So how about it, Trent? > > Can we ship those classes with the next release? Hi Pascal I'm not going to say what people can or can not ship. I'm going to propose removing all of the above extensions from SerialPort.java. I think it is the best thing to do after cooling off a bit. But thats all I've considered at this point. I'm in favor of removing the extensions and staying in gnu.io which more importantly means staying at arms length from javax. I can remove the extensions, put a windows fix in, bump the versions and tag the releases without changing packages if everyone agrees to that. If people want to know why CommAPI has not gone through a JSR which makes it clear rxtx can be in javax.comm and explains how conformancy is determined, I do not think this is the right forum though you can freely do so. -- Trent Jarvi tjarvi at qbang.org From phillip at uow.edu.au Sun Jul 16 22:08:30 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Mon, 17 Jul 2006 14:08:30 +1000 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application" in Mac OSX Message-ID: Hi I downloaded RXTX 2.1-7r2 http://rxtx.org/ (latest download), found the MacOSX folder, manually installed RXTXcomm.jar and librxtxSerial.jnilib in / Library/Java/Extensions and manually setup /var/spool/ucp and became a member of it. I have tried two programs (both built in XCode - TwoWaySerialComm and SerialDemo). Both can find the serial ports but throw a 'port in use exception' with the error "Unknown Application" when I try to open the port. The following is part of the code of TwoWaySerialComm void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { System.out.println("Current owner is " + portIdentifier.getCurrentOwner()); System.out.println("Name is " + this.getClass().getName()); CommPort commPort = portIdentifier.open(this.getClass ().getName(),2000); //throws exception if ( commPort instanceof SerialPort ) The method connect is called from main: public static void main ( String[] args ) { try { listPorts(); (new TwoWaySerialComm()).connect("/dev/tty.KeySerial1"); The following is the console run log of a program TwoWaySerialComm [Session started at 2006-07-14 14:50:29 +1000.] Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.modem - Serial /dev/cu.modem - Serial /dev/tty.KeySerial1 - Serial /dev/cu.KeySerial1 - Serial /dev/tty.USA28X2b2P2.2 - Serial /dev/cu.USA28X2b2P2.2 - Serial 6 ports found Current owner is null Name is TwoWaySerialComm gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:48) at TwoWaySerialComm.main(TwoWaySerialComm.java:163) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at apple.launcher.LaunchRunner.run(LaunchRunner.java:88) at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:50) at apple.launcher.JavaApplicationLauncher.launch (JavaApplicationLauncher.java:52) TwoWaySerialComm has exited with status 0. I am stuck, Can you help me please. thanks Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From pascal at quies.net Mon Jul 17 06:12:09 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 17 Jul 2006 14:12:09 +0200 Subject: [Rxtx] JSR In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607170140.14116.pascal@quies.net> Message-ID: <200607171412.09571.pascal@quies.net> Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: > On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > > Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: > >>> Yes. There are additional methods in gnu.io.SerialPort. We clearly > >>> mark those as extensions to CommAPI and discourage their use. There > >>> just isn't a way to get the intended functionality out of CommAPI > >>> without them. > >> > >> If you don't want the users to use the methods then make them class > >> protected (remove the word "public" before the method) and if you can't > >> do that we might do the following: > >> > >> ---- SerialPort.java > >> package javax.comm > >> > >> class SerialPort extends gnu.io.SerialPort { > >> > >> public void > >> rxtxOnlyMethod() { > >> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort > >> instead"); > >> } > >> ---- end > > > > So how about it, Trent? > > > > Can we ship those classes with the next release? > > Hi Pascal > > I'm not going to say what people can or can not ship. I'm going to > propose removing all of the above extensions from SerialPort.java. I > think it is the best thing to do after cooling off a bit. > > But thats all I've considered at this point. I'm in favor of removing the > extensions and staying in gnu.io which more importantly means staying at > arms length from javax. > > I can remove the extensions, put a windows fix in, bump the versions and > tag the releases without changing packages if everyone agrees to that. > If people want to know why CommAPI has not gone through a JSR which makes > it clear rxtx can be in javax.comm and explains how conformancy is > determined, I do not think this is the right forum though you can freely > do so. Hi Trent, If I understand it correctly you don't want to put those javax.comm classes in the distribution until a JSR completes. :( Sun wants a JSR too to change the API: > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. How about it? I can spend 5 hours a week. From tjarvi at qbang.org Mon Jul 17 07:32:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 07:32:06 -0600 (MDT) Subject: [Rxtx] JSR In-Reply-To: <200607171412.09571.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607170140.14116.pascal@quies.net> <200607171412.09571.pascal@quies.net> Message-ID: On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: >> On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: >>> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>>> Yes. There are additional methods in gnu.io.SerialPort. We clearly >>>>> mark those as extensions to CommAPI and discourage their use. There >>>>> just isn't a way to get the intended functionality out of CommAPI >>>>> without them. >>>> >>>> If you don't want the users to use the methods then make them class >>>> protected (remove the word "public" before the method) and if you can't >>>> do that we might do the following: >>>> >>>> ---- SerialPort.java >>>> package javax.comm >>>> >>>> class SerialPort extends gnu.io.SerialPort { >>>> >>>> public void >>>> rxtxOnlyMethod() { >>>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>>> instead"); >>>> } >>>> ---- end >>> >>> So how about it, Trent? >>> >>> Can we ship those classes with the next release? >> >> Hi Pascal >> >> I'm not going to say what people can or can not ship. I'm going to >> propose removing all of the above extensions from SerialPort.java. I >> think it is the best thing to do after cooling off a bit. >> >> But thats all I've considered at this point. I'm in favor of removing the >> extensions and staying in gnu.io which more importantly means staying at >> arms length from javax. >> >> I can remove the extensions, put a windows fix in, bump the versions and >> tag the releases without changing packages if everyone agrees to that. >> If people want to know why CommAPI has not gone through a JSR which makes >> it clear rxtx can be in javax.comm and explains how conformancy is >> determined, I do not think this is the right forum though you can freely >> do so. > > Hi Trent, > > If I understand it correctly you don't want to put those javax.comm classes in > the distribution until a JSR completes. :( > > Sun wants a JSR too to change the API: >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. > > How about it? I can spend 5 hours a week. Yes. I'm all in favor of this. Dr. Doug Lyon is our fearless leader in these matters and has final say. He has asked everyone if they have an issue with going through the JSR. I have seen no responses though some may have responeded to him in private. I am now working for The MathWorks in a related field. To best represent the RXTX community, we have asked Doug to be the neutral maintainer. This does not mean he is taking on all the work like making releases. He has the ability to and the power. But thats not really spending his time efficiently. It does mean when there are decisions to be made that may have conflicts, he has final say. The easy solution :) is to bug Trent or Doug and see if they will just go into javax.comm namespace. The right solution is to work with Doug and try to get the JSR process completed. I'm willing to help too as time permits. I'm willing to work with Doug. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Jul 17 09:11:20 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 17 Jul 2006 11:11:20 -0400 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Message-ID: <20060717151120.RSBG13653.tomts36-srv.bellnexxia.net@smtp1.sympatico.ca> I am told that this is an issue that will be resolved in 2.1-8. The changes are already in version control, so you can use that. I have and it resolved the problem for me. Phillip McKerrow wrote: > > Hi > > I downloaded RXTX 2.1-7r2 http://rxtx.org/ (latest download), > found the MacOSX folder, > manually installed RXTXcomm.jar and librxtxSerial.jnilib in / > Library/Java/Extensions and > manually setup /var/spool/ucp and became a member of it. > > I have tried two programs (both built in XCode - TwoWaySerialComm and > SerialDemo). Both can find the serial ports but throw a 'port in use > exception' with the error "Unknown Application" when I try to open > the port. > > The following is part of the code of TwoWaySerialComm > void connect ( String portName ) throws Exception > { > CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > if ( portIdentifier.isCurrentlyOwned() ) > { > System.out.println("Error: Port is currently in use"); > } > else > { > System.out.println("Current owner is " + > portIdentifier.getCurrentOwner()); > System.out.println("Name is " + this.getClass().getName()); > CommPort commPort = portIdentifier.open(this.getClass > ().getName(),2000); //throws exception > > if ( commPort instanceof SerialPort ) > > > The method connect is called from main: > public static void main ( String[] args ) > { > try > { > listPorts(); > (new TwoWaySerialComm()).connect("/dev/tty.KeySerial1"); > > > The following is the console run log of a program TwoWaySerialComm > [Session started at 2006-07-14 14:50:29 +1000.] > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > /dev/tty.modem - Serial > /dev/cu.modem - Serial > /dev/tty.KeySerial1 - Serial > /dev/cu.KeySerial1 - Serial > /dev/tty.USA28X2b2P2.2 - Serial > /dev/cu.USA28X2b2P2.2 - Serial > 6 ports found > Current owner is null > Name is TwoWaySerialComm > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at TwoWaySerialComm.connect(TwoWaySerialComm.java:48) > at TwoWaySerialComm.main(TwoWaySerialComm.java:163) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at apple.launcher.LaunchRunner.run(LaunchRunner.java:88) > at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:50) > at apple.launcher.JavaApplicationLauncher.launch > (JavaApplicationLauncher.java:52) > > TwoWaySerialComm has exited with status 0. > > I am stuck, Can you help me please. > > thanks > Phillip > > > ---------------------------------------------------------------------- > Phillip McKerrow http:// > www.uow.edu.au/~phillip/ > School of Information Technology and Computer Science > University of Wollongong * > Northfields Avenue, * * > Wollongong, NSW, 2522. + > AUSTRALIA * the land of the > southern cross > tel : +61 2 4221 3771 fax : +61 2 4221 4170 > > God so loved the world that he gave his one and only Son (Jesus), > that whoever believes in him shall not perish but have eternal life. > John 3:16 > ---------------------------------------------------------------------- > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Mon Jul 17 10:34:14 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 17 Jul 2006 12:34:14 -0400 Subject: [Rxtx] summary of issues In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607170140.14116.pascal@quies.net> <200607171412.09571.pascal@quies.net> Message-ID: Hi All, As I see it, at this stage of the discussion, I think it would be helpful to summarize the concerns. Let me see if I can get this straight, and please correct me, if I am wrong: 1. Sun is making no progress on improving the CommAPI spec. 2. We are seeking to reinvigorate a JSR for the CommAPI in order to keep sun involved. 3. Meanwhile we are extending the RXTX API, with non- commAPI improvements. 4. People are worried that the improvements will be non-portable, when the commAPI re-activates. 5. I have asked for feedback on the JSR approach and obtained zero response. 6. My limited imagination does not see any drawback to taking the JSR approach (except, possibly, from the overhead of a committee, or some license issue that I do not understand). 7. http://www.jcp.org/en/jsr/detail?id=922 shows the status of the JSR now. Status: Withdrawn The sun contact is: vincent.zhang at sun.com I have written to Vincent at Sun to ask him what would be involved with reactivation of JSR 922. If I hear back I will let you know. If there are any objections or suggestions, please let me know. Thanks! - Doug >On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > >> Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: >>> On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: >>>> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>>>> Yes. There are additional methods in gnu.io.SerialPort. We clearly >>>>>> mark those as extensions to CommAPI and discourage their use. There >>>>>> just isn't a way to get the intended functionality out of CommAPI >>>>>> without them. >>>>> >>>>> If you don't want the users to use the methods then make them class >>>>> protected (remove the word "public" before the method) and if you can't >>>>> do that we might do the following: >>>>> >>>>> ---- SerialPort.java >>>>> package javax.comm >>>>> >>>>> class SerialPort extends gnu.io.SerialPort { >>>>> >>>>> public void >>>>> rxtxOnlyMethod() { >>>>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>>>> instead"); >>>>> } >>>>> ---- end >>>> >>>> So how about it, Trent? >>>> >>>> Can we ship those classes with the next release? >>> >>> Hi Pascal >>> >>> I'm not going to say what people can or can not ship. I'm going to >>> propose removing all of the above extensions from SerialPort.java. I >>> think it is the best thing to do after cooling off a bit. >>> >>> But thats all I've considered at this point. I'm in favor of removing the >>> extensions and staying in gnu.io which more importantly means staying at >>> arms length from javax. >>> >>> I can remove the extensions, put a windows fix in, bump the versions and >>> tag the releases without changing packages if everyone agrees to that. >>> If people want to know why CommAPI has not gone through a JSR which makes >>> it clear rxtx can be in javax.comm and explains how conformancy is >>> determined, I do not think this is the right forum though you can freely >>> do so. >> >> Hi Trent, >> >> If I understand it correctly you don't want to put those >>javax.comm classes in >> the distribution until a JSR completes. :( >> >> Sun wants a JSR too to change the API: >>> Ultimately the COMMAPI would be better served if a Java >>> Community Process JSR (http://www.jcp.org) was opened and >>> the COMMAPI was rearchitected to provide a more pluggable >>> framework to improve cross-platform support. Such an >>> architecture would embody a better defined and better >>> documented SPI interface, including a way for comm. ports >>> to be revealed to the client application through the API >>> via platform-aware plugins. Similarly, native code used >>> to access comm port in general could be handled more >>> flexibly using a plugin model, whereby on any platform, >>> multiple native modules could be in use simultaneously. >> >> How about it? I can spend 5 hours a week. > >Yes. I'm all in favor of this. Dr. Doug Lyon is our fearless leader in >these matters and has final say. He has asked everyone if they have an >issue with going through the JSR. I have seen no responses though some >may have responeded to him in private. > >I am now working for The MathWorks in a related field. To best represent >the RXTX community, we have asked Doug to be the neutral maintainer. >This does not mean he is taking on all the work like making releases. He >has the ability to and the power. But thats not really spending his time >efficiently. It does mean when there are decisions to be made that may >have conflicts, he has final say. > >The easy solution :) is to bug Trent or Doug and see if they will just go >into javax.comm namespace. The right solution is to work with Doug and >try to get the JSR process completed. I'm willing to help too as time >permits. > >I'm willing to work with Doug. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jul 17 11:31:58 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 17 Jul 2006 13:31:58 -0400 Subject: [Rxtx] JSR Message-ID: <20060717173158.USWI24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> In the meantime could these methods not be added to a child class. This way the extra functionality can be provided, but you would have to explictly check to see of the class is an RXTX specifc interface. For example: class RxTxCommPort extends CommPort { //RxTx specific methods } CommPort port = commPortIdentifierInstance.open(...); if ( port instanceof RxTxCommPort ) { // do RxTx specifc stuff } // continue doing usual stuff Andre > > From: "Pascal S. de Kloe" > Date: 2006/07/17 Mon AM 08:12:09 EDT > To: RXTX Developers and Users > Subject: [Rxtx] JSR > > Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: > > On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > > > Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: > > >>> Yes. There are additional methods in gnu.io.SerialPort. We clearly > > >>> mark those as extensions to CommAPI and discourage their use. There > > >>> just isn't a way to get the intended functionality out of CommAPI > > >>> without them. > > >> > > >> If you don't want the users to use the methods then make them class > > >> protected (remove the word "public" before the method) and if you can't > > >> do that we might do the following: > > >> > > >> ---- SerialPort.java > > >> package javax.comm > > >> > > >> class SerialPort extends gnu.io.SerialPort { > > >> > > >> public void > > >> rxtxOnlyMethod() { > > >> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort > > >> instead"); > > >> } > > >> ---- end > > > > > > So how about it, Trent? > > > > > > Can we ship those classes with the next release? > > > > Hi Pascal > > > > I'm not going to say what people can or can not ship. I'm going to > > propose removing all of the above extensions from SerialPort.java. I > > think it is the best thing to do after cooling off a bit. > > > > But thats all I've considered at this point. I'm in favor of removing the > > extensions and staying in gnu.io which more importantly means staying at > > arms length from javax. > > > > I can remove the extensions, put a windows fix in, bump the versions and > > tag the releases without changing packages if everyone agrees to that. > > If people want to know why CommAPI has not gone through a JSR which makes > > it clear rxtx can be in javax.comm and explains how conformancy is > > determined, I do not think this is the right forum though you can freely > > do so. > > Hi Trent, > > If I understand it correctly you don't want to put those javax.comm classes in > the distribution until a JSR completes. :( > > Sun wants a JSR too to change the API: > > Ultimately the COMMAPI would be better served if a Java > > Community Process JSR (http://www.jcp.org) was opened and > > the COMMAPI was rearchitected to provide a more pluggable > > framework to improve cross-platform support. Such an > > architecture would embody a better defined and better > > documented SPI interface, including a way for comm. ports > > to be revealed to the client application through the API > > via platform-aware plugins. Similarly, native code used > > to access comm port in general could be handled more > > flexibly using a plugin model, whereby on any platform, > > multiple native modules could be in use simultaneously. > > How about it? I can spend 5 hours a week. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From joachim at buechse.de Mon Jul 17 11:59:19 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 17 Jul 2006 19:59:19 +0200 Subject: [Rxtx] Bumping versions In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> <200607170140.14116.pascal@quies.net> Message-ID: <6ABAF770-41AE-4BA0-800D-2DCC8025FCA8@buechse.de> Hello Trent, I would appreciate if we could get to a version 2.1.8. In fact as several recent posting have shown, almost anyone working on OSX would appreciate getting there. Should anything be removed before that? I dont know. There is nothing wrong with having 2.1.9 following shortly after 2.1.8. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 17.07.2006, at 02:59, Trent Jarvi wrote: > On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > >> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>> Yes. There are additional methods in gnu.io.SerialPort. We >>>> clearly mark >>>> those as extensions to CommAPI and discourage their use. There >>>> just >>>> isn't a way to get the intended functionality out of CommAPI >>>> without >>>> them. >>> >>> If you don't want the users to use the methods then make them class >>> protected (remove the word "public" before the method) and if you >>> can't do >>> that we might do the following: >>> >>> ---- SerialPort.java >>> package javax.comm >>> >>> class SerialPort extends gnu.io.SerialPort { >>> >>> public void >>> rxtxOnlyMethod() { >>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>> instead"); >>> } >>> ---- end >> >> So how about it, Trent? >> >> Can we ship those classes with the next release? > > Hi Pascal > > I'm not going to say what people can or can not ship. I'm going to > propose removing all of the above extensions from SerialPort.java. I > think it is the best thing to do after cooling off a bit. > > But thats all I've considered at this point. I'm in favor of > removing the > extensions and staying in gnu.io which more importantly means > staying at > arms length from javax. > > I can remove the extensions, put a windows fix in, bump the > versions and > tag the releases without changing packages if everyone agrees to that. > If people want to know why CommAPI has not gone through a JSR which > makes > it clear rxtx can be in javax.comm and explains how conformancy is > determined, I do not think this is the right forum though you can > freely > do so. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jul 17 12:40:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 12:40:32 -0600 (MDT) Subject: [Rxtx] Bumping versions In-Reply-To: <6ABAF770-41AE-4BA0-800D-2DCC8025FCA8@buechse.de> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> <200607170140.14116.pascal@quies.net> <6ABAF770-41AE-4BA0-800D-2DCC8025FCA8@buechse.de> Message-ID: Hi Joachim I will work with you towards that. I'm going to the Linux Symposium this week which should mean I have time to tinker. I'll work on rxtx while riding in a carpool to Ottawa. On Mon, 17 Jul 2006, Joachim Buechse wrote: > Hello Trent, > > I would appreciate if we could get to a version 2.1.8. In fact as > several recent posting have shown, almost anyone working on OSX would > appreciate getting there. Should anything be removed before that? I > dont know. There is nothing wrong with having 2.1.9 following shortly > after 2.1.8. > > Regards, > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 17.07.2006, at 02:59, Trent Jarvi wrote: > >> On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: >> >>> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>>> Yes. There are additional methods in gnu.io.SerialPort. We >>>>> clearly mark >>>>> those as extensions to CommAPI and discourage their use. There >>>>> just >>>>> isn't a way to get the intended functionality out of CommAPI >>>>> without >>>>> them. >>>> >>>> If you don't want the users to use the methods then make them class >>>> protected (remove the word "public" before the method) and if you >>>> can't do >>>> that we might do the following: >>>> >>>> ---- SerialPort.java >>>> package javax.comm >>>> >>>> class SerialPort extends gnu.io.SerialPort { >>>> >>>> public void >>>> rxtxOnlyMethod() { >>>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>>> instead"); >>>> } >>>> ---- end >>> >>> So how about it, Trent? >>> >>> Can we ship those classes with the next release? >> >> Hi Pascal >> >> I'm not going to say what people can or can not ship. I'm going to >> propose removing all of the above extensions from SerialPort.java. I >> think it is the best thing to do after cooling off a bit. >> >> But thats all I've considered at this point. I'm in favor of >> removing the >> extensions and staying in gnu.io which more importantly means >> staying at >> arms length from javax. >> >> I can remove the extensions, put a windows fix in, bump the >> versions and >> tag the releases without changing packages if everyone agrees to that. >> If people want to know why CommAPI has not gone through a JSR which >> makes >> it clear rxtx can be in javax.comm and explains how conformancy is >> determined, I do not think this is the right forum though you can >> freely >> do so. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pascal at quies.net Mon Jul 17 17:54:56 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Tue, 18 Jul 2006 01:54:56 +0200 Subject: [Rxtx] summary of issues In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> Message-ID: <200607180154.56359.pascal@quies.net> Op maandag 17 juli 2006 18:34, schreef Dr. Douglas Lyon: > Hi All, > As I see it, at this stage of the discussion, I think it would be helpful > to summarize the concerns. Let me see if I can get this > straight, and please correct me, if I am wrong: Thank you. :) > 1. Sun is making no progress on improving the CommAPI spec. > 2. We are seeking to reinvigorate a JSR for the CommAPI in order > to keep sun involved. Sun wants a JSR becouse they have other concerns than a almost obsolete piece of hardware. > 3. Meanwhile we are extending the RXTX API, with non- > commAPI improvements. > 4. People are worried that the improvements will be non-portable, > when the commAPI re-activates. > 5. I have asked for feedback on the JSR approach and obtained > zero response. > 6. My limited imagination does not see any drawback to taking > the JSR approach (except, possibly, from the overhead of a committee, or > some license issue that I do not understand). > 7. http://www.jcp.org/en/jsr/detail?id=922 shows the status of the JSR now. > Status: Withdrawn > The sun contact is: vincent.zhang at sun.com > I have written to Vincent at Sun to ask him what would be involved with > reactivation of JSR 922. We don't need to communicate with the employees but we need a plan. We need a working implementation with a free license. They have offered us some ideas like in the 2.0.3 README (see attachment). Is there a plan based on the differences of the various platforms? Is there a API purposal? Is there a plan of the JNI? If not I am willing to help. I can write/represent the POSIX part with special interrest of the free UNIX systems. -------------- next part -------------- DISTRIBUTION NOTES: This distribution contains the comm.jar file original part of the COMMAPI 2.0.3 release. The 2.0.3 release itself is no longer distributed. comm.jar, which contains the comm API java class files (eg. Sun's binary implementation of the interface classes), is being made available, unsupported, with no obligation to fix bugs, at the request of the RXTX project. The RxTx project (http://www.rxtx.org), uses the comm.jar class files, but provides their own native library components to provide support for other platforms. The 2.0.3 comm.jar is being provided in this way because as of COMMAPI 3.x, the java binary implementation forked and became incompatible with the RxTx project's native code. Due to the lack of a clear business case, and to resource constraints, no additional resources are being provided to provide an alternative engineering solution at the time of writing. RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: Ultimately the COMMAPI would be better served if a Java Community Process JSR (http://www.jcp.org) was opened and the COMMAPI was rearchitected to provide a more pluggable framework to improve cross-platform support. Such an architecture would embody a better defined and better documented SPI interface, including a way for comm. ports to be revealed to the client application through the API via platform-aware plugins. Similarly, native code used to access comm port in general could be handled more flexibly using a plugin model, whereby on any platform, multiple native modules could be in use simultaneously. Since there are now various ways serial ports can be implemented and accessed, modular comm. port JNI native libraries would be of benefit insofar as removing the burden of over-generalization from any single native component, or inversely, by relieving the implicit constraint that comm. drivers be accessed only via a monolithic mechanism, such as the UNIX vnode interface. paul.klissner at sun.com 6/10/06 From tjarvi at qbang.org Mon Jul 17 18:24:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 18:24:47 -0600 (MDT) Subject: [Rxtx] summary of issues In-Reply-To: <200607180154.56359.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607180154.56359.pascal@quies.net> Message-ID: On Tue, 18 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 17 juli 2006 18:34, schreef Dr. Douglas Lyon: >> Hi All, >> As I see it, at this stage of the discussion, I think it would be helpful >> to summarize the concerns. Let me see if I can get this >> straight, and please correct me, if I am wrong: > > Thank you. :) > >> 1. Sun is making no progress on improving the CommAPI spec. >> 2. We are seeking to reinvigorate a JSR for the CommAPI in order >> to keep sun involved. > > Sun wants a JSR becouse they have other concerns than a almost obsolete piece > of hardware. > >> 3. Meanwhile we are extending the RXTX API, with non- >> commAPI improvements. >> 4. People are worried that the improvements will be non-portable, >> when the commAPI re-activates. >> 5. I have asked for feedback on the JSR approach and obtained >> zero response. >> 6. My limited imagination does not see any drawback to taking >> the JSR approach (except, possibly, from the overhead of a committee, or >> some license issue that I do not understand). >> 7. http://www.jcp.org/en/jsr/detail?id=922 shows the status of the JSR now. >> Status: Withdrawn >> The sun contact is: vincent.zhang at sun.com >> I have written to Vincent at Sun to ask him what would be involved with >> reactivation of JSR 922. > > We don't need to communicate with the employees but we need a plan. We need a > working implementation with a free license. They have offered us some ideas > like in the 2.0.3 README (see attachment). > > Is there a plan based on the differences of the various platforms? Is there a > API purposal? Is there a plan of the JNI? > > If not I am willing to help. I can write/represent the POSIX part with special > interrest of the free UNIX systems. > Not to put words in your mouth but it sounds like you would rather not be in javax.comm namespace at all and do something like a VFS for serial ports as suggested in the readme? Maybe call it a VCS for character streams. That sounds like a major version change rather than an incremental change. So a vote for cutting the ropes and floating in the current? rxtx 3.0 or whatever abandoning current application requirements and perhaps largely rewriting rxtx.. Thats possible and could happen at the same time. An email to Vincent sounds polite enough at this stage. -- Trent Jarvi tjarvi at qbang.org From phillip at uow.edu.au Mon Jul 17 19:33:19 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Tue, 18 Jul 2006 11:33:19 +1000 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application in Mac OSX" Message-ID: <7DBE5FEB-EA06-45BC-ABBE-A9990281E32D@uow.edu.au> Hi We found a workaround - Problem fixed by creating /var/lock directory - seems that they changed the directory from /var/spool/uucp for the lock file but didn't update the documentation. audfg5:~ phillip$ sudo mkdir /var/lock Password: audfg5:~ phillip$ ls -ld /var/lock drwxr-xr-x 2 root wheel 68 Jul 18 09:51 /var/lock audfg5:~ phillip$ sudo chmod 775 /var/lock audfg5:~ phillip$ ls -ld /var/lock drwxrwxr-x 2 root wheel 68 Jul 18 09:51 /var/lock audfg5:~ phillip$ sudo chgrp uucp /var/lock audfg5:~ phillip$ ls -ld /var/lock drwxrwxr-x 2 root uucp 68 Jul 18 09:51 /var/lock audfg5:~ phillip$ ls -l /var/lock total 8 -r--r--r-- 1 phillip uucp 11 Jul 18 09:58 LK.003.009.002 Now both programs work and we get a warning on the console: RXTX Warning: Removing stale lock file. /var/lock/LK.003.009.002 Do we still need the /var/spool/uucp directory?? thanks Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From tjarvi at qbang.org Mon Jul 17 19:40:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 19:40:26 -0600 (MDT) Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application in Mac OSX" In-Reply-To: <7DBE5FEB-EA06-45BC-ABBE-A9990281E32D@uow.edu.au> References: <7DBE5FEB-EA06-45BC-ABBE-A9990281E32D@uow.edu.au> Message-ID: On Tue, 18 Jul 2006, Phillip McKerrow wrote: > Hi > We found a workaround - Problem fixed by creating /var/lock directory > - seems that they changed the directory from /var/spool/uucp for the > lock file but didn't update the documentation. > > audfg5:~ phillip$ sudo mkdir /var/lock > Password: > audfg5:~ phillip$ ls -ld /var/lock > drwxr-xr-x 2 root wheel 68 Jul 18 09:51 /var/lock > audfg5:~ phillip$ sudo chmod 775 /var/lock > audfg5:~ phillip$ ls -ld /var/lock > drwxrwxr-x 2 root wheel 68 Jul 18 09:51 /var/lock > audfg5:~ phillip$ sudo chgrp uucp /var/lock > audfg5:~ phillip$ ls -ld /var/lock > drwxrwxr-x 2 root uucp 68 Jul 18 09:51 /var/lock > audfg5:~ phillip$ ls -l /var/lock > total 8 > -r--r--r-- 1 phillip uucp 11 Jul 18 09:58 LK.003.009.002 > > Now both programs work and we get a warning on the console: > RXTX Warning: Removing stale lock file. /var/lock/LK.003.009.002 > > Do we still need the /var/spool/uucp directory?? > [The new code in CVS will not use Lockfiles on Mac OS X.] The above can happen if you did not close the port before exiting the program. The warning is harmless. RXTX notes that the old program is not running and removes the stale lockfile. -- Trent Jarvi tjarvi at qbang.org From phillip at uow.edu.au Tue Jul 18 01:07:40 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Tue, 18 Jul 2006 17:07:40 +1000 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX Message-ID: Hi I am trying to run a precompiled Java program (JavaKit for setting up the TINI processor over a serial link from http://www.maxim-ic.com/ products/tini/software/downloads.cfm). It uses javax.comm for serial communication. 1. I downloaded the Sparc Solaris version of comm.jar and placed it in /Library/Java/Extensions with RXTXcomm.jar and librxtxSerial.jnilib. 2. I added a javax.com.properties file to /System/Library/Frameworks/ JavaVM.framework/Versions/CurrentJDK/Home/lib It is a text file with one line Driver=gnu.io.RXTXCommDriver 3. When I execute JavaKit it crashes with the following console output audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver (CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:109) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Exception in thread "main" java.lang.UnsatisfiedLinkError: isSessionActive at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts (Portmapping.java:155) at com.sun.comm.Portmapping.refreshPortDatabase (Portmapping.java:100) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:138) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ Home/lib/ext instead of /Library/Java/Extensions it makes no difference: If I use the generic version of comm,jar file from Sun, JavaKit brings up a gui but can't find the serial ports: The console output is: audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while loading driver gnu.io.RXTXCommDriver Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no SolarisSerialParallel in java.library.path Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while loading driver com.sun.comm.SolarisDriver Am I doing something wrong in my efforts to get this going? Should I have another file loaded somewhere or have I run into a bug in RXTX?? thanks again for your help. Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From joachim at buechse.de Tue Jul 18 02:53:38 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 18 Jul 2006 10:53:38 +0200 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: References: Message-ID: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> 2.1.7 is the gnu.io.* version. You need 2.0.7 ie the javax.comm.* version. --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 18.07.2006, at 09:07, Phillip McKerrow wrote: > Hi > > I am trying to run a precompiled Java program (JavaKit for setting up > the TINI processor over a serial link from http://www.maxim-ic.com/ > products/tini/software/downloads.cfm). It uses javax.comm for serial > communication. > > 1. I downloaded the Sparc Solaris version of comm.jar and placed it > in /Library/Java/Extensions with RXTXcomm.jar and > librxtxSerial.jnilib. > > 2. I added a javax.com.properties file to /System/Library/Frameworks/ > JavaVM.framework/Versions/CurrentJDK/Home/lib > It is a text file with one line > Driver=gnu.io.RXTXCommDriver > > 3. When I execute JavaKit it crashes with the following console output > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver > (CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:109) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > Exception in thread "main" java.lang.UnsatisfiedLinkError: > isSessionActive > at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > at com.sun.comm.Portmapping.registerCommPorts > (Portmapping.java:155) > at com.sun.comm.Portmapping.refreshPortDatabase > (Portmapping.java:100) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:138) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > > If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ > Home/lib/ext > instead of /Library/Java/Extensions it makes no difference: > > If I use the generic version of comm,jar file from Sun, JavaKit > brings up a gui but can't find the serial ports: The console > output is: > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while > loading driver gnu.io.RXTXCommDriver > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no > SolarisSerialParallel in java.library.path > Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while > loading driver com.sun.comm.SolarisDriver > > > Am I doing something wrong in my efforts to get this going? Should I > have another file loaded somewhere or have I run into a bug in RXTX?? > > thanks again for your help. > > Phillip > > > ---------------------------------------------------------------------- > Phillip McKerrow http:// > www.uow.edu.au/~phillip/ > School of Information Technology and Computer Science > University of Wollongong * > Northfields Avenue, * * > Wollongong, NSW, 2522. + > AUSTRALIA * the land of the > southern cross > tel : +61 2 4221 3771 fax : +61 2 4221 > 4170 > > God so loved the world that he gave his one and only Son (Jesus), > that whoever believes in him shall not perish but have eternal life. > John 3:16 > ---------------------------------------------------------------------- > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alex at det.ua.pt Tue Jul 18 03:29:15 2006 From: alex at det.ua.pt (Alexandre Mota) Date: Tue, 18 Jul 2006 10:29:15 +0100 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: Message-ID: Hello Edit the JavaKit.java in order to use the gnu.io and compile everything. If you have the RXTX already installed and working it will work. I am using it on linux and windows with jdk 1.5. Best Regards Alexandre -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Phillip McKerrow Sent: ter?a-feira, 18 de Julho de 2006 8:08 To: rxtx at qbang.org Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX Hi I am trying to run a precompiled Java program (JavaKit for setting up the TINI processor over a serial link from http://www.maxim-ic.com/ products/tini/software/downloads.cfm). It uses javax.comm for serial communication. 1. I downloaded the Sparc Solaris version of comm.jar and placed it in /Library/Java/Extensions with RXTXcomm.jar and librxtxSerial.jnilib. 2. I added a javax.com.properties file to /System/Library/Frameworks/ JavaVM.framework/Versions/CurrentJDK/Home/lib It is a text file with one line Driver=gnu.io.RXTXCommDriver 3. When I execute JavaKit it crashes with the following console output audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver (CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:109) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Exception in thread "main" java.lang.UnsatisfiedLinkError: isSessionActive at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts (Portmapping.java:155) at com.sun.comm.Portmapping.refreshPortDatabase (Portmapping.java:100) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:138) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ Home/lib/ext instead of /Library/Java/Extensions it makes no difference: If I use the generic version of comm,jar file from Sun, JavaKit brings up a gui but can't find the serial ports: The console output is: audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while loading driver gnu.io.RXTXCommDriver Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no SolarisSerialParallel in java.library.path Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while loading driver com.sun.comm.SolarisDriver Am I doing something wrong in my efforts to get this going? Should I have another file loaded somewhere or have I run into a bug in RXTX?? thanks again for your help. Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jul 18 04:52:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 18 Jul 2006 04:52:02 -0600 (MDT) Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: References: Message-ID: On Tue, 18 Jul 2006, Phillip McKerrow wrote: > Hi > > I am trying to run a precompiled Java program (JavaKit for setting up > the TINI processor over a serial link from http://www.maxim-ic.com/ > products/tini/software/downloads.cfm). It uses javax.comm for serial > communication. > > 1. I downloaded the Sparc Solaris version of comm.jar and placed it > in /Library/Java/Extensions with RXTXcomm.jar and > librxtxSerial.jnilib. > > 2. I added a javax.com.properties file to /System/Library/Frameworks/ > JavaVM.framework/Versions/CurrentJDK/Home/lib > It is a text file with one line > Driver=gnu.io.RXTXCommDriver > > 3. When I execute JavaKit it crashes with the following console output > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver > (CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:109) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > Exception in thread "main" java.lang.UnsatisfiedLinkError: > isSessionActive > at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > at com.sun.comm.Portmapping.registerCommPorts > (Portmapping.java:155) > at com.sun.comm.Portmapping.refreshPortDatabase > (Portmapping.java:100) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:138) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > > If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ > Home/lib/ext > instead of /Library/Java/Extensions it makes no difference: > > If I use the generic version of comm,jar file from Sun, JavaKit > brings up a gui but can't find the serial ports: The console output is: > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while > loading driver gnu.io.RXTXCommDriver > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no > SolarisSerialParallel in java.library.path > Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while > loading driver com.sun.comm.SolarisDriver > > > Am I doing something wrong in my efforts to get this going? Should I > have another file loaded somewhere or have I run into a bug in RXTX?? > > thanks again for your help. > RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for that. Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Tue Jul 18 16:14:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 18 Jul 2006 18:14:38 -0400 Subject: [Rxtx] jcp and jsr In-Reply-To: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> References: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> Message-ID: Hi All, I have been in touch with: Paul Klissner Please read what Paul writes below. I am not sure, but this might be a good chance for the RXTX group to take action. As to what we should write for the JSR, I am thinking about something in the javax.comm namespace. What is the collective feeling about that? Thanks! - Doug Paul writes: "I think a JSR should be opened, but I don't see any point in proceeding with 922, which never formed and expert group, or provided a specification or reference implementation. It was a placeholder, and the title wasn't even relevant. I think we should discuss our ideas about what we'd like to accomplish and javax.comm and see if we can reach an agreement. You would submit a JSR through the Java Community Process, and if you do, I'd like to represent Sun on the expert group, and contribute to the effort. We may want to start with a fresh specification, borrowing what we want from the current javax.com, adding what we need, and creating a reference implementation. Paul" From pascal at quies.net Tue Jul 18 18:12:26 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 02:12:26 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> Message-ID: <200607190212.27131.pascal@quies.net> Hi Dr., The namespace is the last thing we need to worry about. Let's start with the common goals. For instance the current API is not very object oriented. It might be a good idea to have a static set of objects available representing every supported port available on the system in realtime. Each object should clearly know its own state and its capabilities. To get a port there could be a method like synchronized void connect(PortUser) where PortUser is a interface which handles the interaction with a input and a output stream and listers like PortStillAvailableListener, PortBufferListener and a DataAvailableListener. What is the collective feeling about that? Op woensdag 19 juli 2006 00:14, schreef Dr. Douglas Lyon: > Hi All, > I have been in touch with: > Paul Klissner > Please read what Paul writes below. > I am not sure, but this might be a good chance for > the RXTX group to take action. > As to what we should write for the JSR, I am thinking > about something in the javax.comm namespace. > What is the collective feeling about that? > Thanks! > - Doug > > Paul writes: > "I think a JSR should be opened, but I don't see any point > in proceeding with 922, which never formed and expert group, > or provided a specification or reference implementation. > It was a placeholder, and the title wasn't even relevant. > > I think we should discuss our ideas about what we'd like > to accomplish and javax.comm and see if we can reach an > agreement. > > You would submit a JSR through the Java Community Process, > and if you do, I'd like to represent Sun on the expert group, > and contribute to the effort. We may want to start with > a fresh specification, borrowing what we want from the > current javax.com, adding what we need, and creating > a reference implementation. From phillip at uow.edu.au Tue Jul 18 23:44:25 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Wed, 19 Jul 2006 15:44:25 +1000 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application in Mac OSX" Message-ID: <7EEF3F56-A406-4532-BB3D-AA642A4818CA@uow.edu.au> > > Do we still need the /var/spool/uucp directory?? > > >> Trent Jarvi wrote >>[The new code in CVS will not use Lockfiles on Mac OS X.] Great, that should make installation easier. When will the next version be released? Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From phillip at uow.edu.au Wed Jul 19 00:14:26 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Wed, 19 Jul 2006 16:14:26 +1000 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: References: Message-ID: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> > > Edit the JavaKit.java in order to use the gnu.io and compile > everything. > > Alexandre > Unfotunately all I have is a .jar that contains it. I haven't found the source on their web site. > From: Joachim Buechse > 2.1.7 is the gnu.io.* version. You need 2.0.7 ie the javax.comm.* > version. > > RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for > that. > > Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. > > Trent Jarv I found the rxtx download page and downloaded rxtx-2.0-7pre1 (source/ Mac) The Install folder in ForPackageMaker has librxtxSerial.jnilib and java.com.properties but instead of RXTXComm.jar it has jcl.jar (I have no idea what is is for - it doesn't seem to be a replacement for RXTXCom.jar) I tried to run the XCode project to build it but there is a syntax error - nativeSetSerialPortParams returns a void not a jboolean. Also, there is no target to make RXTXComm.jar JNIEXPORT void JNICALL Java_gnu_io_RXTXPort_nativeSetSerialPortParams (JNIEnv *, jobject, jint, jint, jint, jint); Can you tell me where to find either a working copy of 2.0 for Mac OSX, or RXTXComm.jar or a working XCode project for Version 2. This is getting very frustrating. thanks Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From joachim at buechse.de Wed Jul 19 01:17:03 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 19 Jul 2006 09:17:03 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607190212.27131.pascal@quies.net> References: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> <200607190212.27131.pascal@quies.net> Message-ID: <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> The static objects will work for Windows and Linux, however for OSX they will create problems: - ports can appear and disappear at any time with VCP drivers for USB - the port names are not known until the usb-port is "plugged in" Please do not forget that tty ports can be opened by several applications concurrently. All of those will "loose" the port if anyone opens the corresponding cu port. As this naming based mechanism does not exist on Windows (maybe it does via an API) it should probably be reflected in the API. In other words there are "two levels of open": - Open for reading status lines (1) - Open for reading/writing data (2) I am not sure if state (1) should also allow the modification of certain status lines (ie to set a modem ready). I am also not sure if the api should unify corresponding cu. and tty. ports into one single port. Regards, Joachim On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: > For instance the current API is not very object oriented. > It might be a good idea to have a static set of objects available > representing > every supported port available on the system in realtime. Each > object should > clearly know its own state and its capabilities. To get a port > there could be > a method like synchronized void connect(PortUser) where PortUser is a > interface which handles the interaction with a input and a output > stream and > listers like PortStillAvailableListener, PortBufferListener and a > DataAvailableListener. > > What is the collective feeling about that? From joachim at buechse.de Wed Jul 19 01:29:53 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 19 Jul 2006 09:29:53 +0200 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> References: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> Message-ID: <2D32167B-3830-41D6-9FDD-462301F0453F@buechse.de> As you have already downloaded the source, just cd into the main folder and do a "cvs up -d" this will remove some outdated files and create a new XCode project which should compile without problems. You may also want to search the mail archive or checkout README.OSX for my suggestion on how to avoid the javax.comm.properties file by creating a class com.sun.comm.SolarisDriver. Regards, Joachim PS: I can feel your pain... it was the same for me. In fact I never understood why there are different native or java implementations for 2.0 and 2.1. The two versions could easily be unified by using the simplest of OO programing (intermediate abstract classes). But I guess at the time of branching the direction was not clear. Also the licences are not the same... On 19.07.2006, at 08:14, Phillip McKerrow wrote: >> RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for >> that. >> >> Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. >> >> Trent Jarv > > I found the rxtx download page and downloaded rxtx-2.0-7pre1 (source/ > Mac) > > The Install folder in ForPackageMaker has librxtxSerial.jnilib and > java.com.properties but instead of RXTXComm.jar it has jcl.jar (I > have no idea what is is for - it doesn't seem to be a replacement for > RXTXCom.jar) > > I tried to run the XCode project to build it but there is a syntax > error - nativeSetSerialPortParams returns a void not a jboolean. > Also, there is no target to make RXTXComm.jar > > JNIEXPORT void JNICALL Java_gnu_io_RXTXPort_nativeSetSerialPortParams > (JNIEnv *, jobject, jint, jint, jint, jint); > > Can you tell me where to find either a working copy of 2.0 for Mac > OSX, or RXTXComm.jar or a working XCode project for Version 2. This > is getting very frustrating. > > thanks > > Phillip > > ---------------------------------------------------------------------- > Phillip McKerrow http:// > www.uow.edu.au/~phillip/ > School of Information Technology and Computer Science > University of Wollongong * > Northfields Avenue, * * > Wollongong, NSW, 2522. + > AUSTRALIA * the land of the > southern cross > tel : +61 2 4221 3771 fax : +61 2 4221 > 4170 > > God so loved the world that he gave his one and only Son (Jesus), > that whoever believes in him shall not perish but have eternal life. > John 3:16 > ---------------------------------------------------------------------- > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alex at det.ua.pt Wed Jul 19 03:02:40 2006 From: alex at det.ua.pt (Alexandre Mota) Date: Wed, 19 Jul 2006 10:02:40 +0100 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> References: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> Message-ID: <44BDF530.5080502@det.ua.pt> Phillip McKerrow wrote: >>Edit the JavaKit.java in order to use the gnu.io and compile >>everything. >> >>Alexandre >> >> >> >Unfotunately all I have is a .jar that contains it. I haven't found >the source on their web site. > > > > Download http://files.dalsemi.com/pub/tini/tini1_17.tgz Decompress it and you will find the JavaKiTSrc.jar in the src dir. Decompress it with jar -xf JavaKitSrc.jar and you will get all the source files you need. Alexandre PS: Remenber that puting JavaKit into work is allways a pain... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060719/f5172a01/attachment-0342.html From lyon at docjava.com Wed Jul 19 05:27:47 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 19 Jul 2006 07:27:47 -0400 Subject: [Rxtx] RXTX binary for mac In-Reply-To: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> References: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> Message-ID: Hi All, I have some older RXTX binaries that are deployed in a webstart application. You can try it with: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp The libs are signed and packed for webstart disto by me. http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/ Shows them. - DL > > >> Edit the JavaKit.java in order to use the gnu.io and compile? >> everything. >> >> Alexandre >> >Unfotunately all I have is a .jar that contains it. I haven't found? >the source on their web site. > > >> From: Joachim Buechse >> 2.1.7 is the gnu.io.* version. You need 2.0.7 ie the javax.comm.* >> version. >> > >> RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for? >> that. >> >> Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. >> >> Trent Jarv > >I found the rxtx download page and downloaded rxtx-2.0-7pre1 (source/ >Mac) > >The Install folder in ForPackageMaker has librxtxSerial.jnilib and? >java.com.properties but instead of RXTXComm.jar it has jcl.jar (I? >have no idea what is is for - it doesn't seem to be a replacement for? >RXTXCom.jar) > >I tried to run the XCode project to build it but there is a syntax? >error - nativeSetSerialPortParams returns a void not a jboolean.?? >Also, there is no target to make RXTXComm.jar > >JNIEXPORT void JNICALL Java_gnu_io_RXTXPort_nativeSetSerialPortParams > (JNIEnv *, jobject, jint, jint, jint, jint); > >Can you tell me where to find either a working copy of 2.0 for Mac? >OSX, or RXTXComm.jar or a working XCode project for Version 2. This? >is getting very frustrating. > >thanks > >Phillip > >---------------------------------------------------------------------- >Phillip McKerrow http:// >www.uow.edu.au/~phillip/ >School of Information Technology and Computer Science >University of Wollongong * >Northfields Avenue, * * >Wollongong, NSW, 2522. + >AUSTRALIA * the land of the? >southern cross >tel : +61 2 4221 3771 fax : +61 2 4221 4170 > >God so loved the world that he gave his one and only Son (Jesus), >that whoever believes in him shall not perish but have eternal life. >John 3:16 >---------------------------------------------------------------------- > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Wed Jul 19 06:11:27 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 14:11:27 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> Message-ID: <200607191411.27566.pascal@quies.net> Hi Joachim, Thanks for the constructive critisism. :) Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: > The static objects will work for Windows and Linux, however for OSX > they will create problems: > - ports can appear and disappear at any time with VCP drivers for USB > - the port names are not known until the usb-port is "plugged in" Ports can appear and disappear on *any* OS with USB support. Some Linux distributions even create and remove devicefiles on the fly. With the current API you fetch a list of all available ports and then you try to cast one. What happens if the port is no longer available at that time? What happens if a port vanishes during the data transfer? Of course you can catch exceptions but that makes the code quite messy. The idea was to get a PortStillAvailableListener interface. In that way the implementation is free to handle a cleanup or wait for return routine in a OO way. The I/O streams should just lock. The word static was not ment as persistent but as Java static available. Considder the following: java.lang.hw.HardwareConfiguration { public enum PortType { RS232, I2C, etc. }; /** Gets the currently available ports of type {@code PortType}. */ public static java.lang.hw.Port[] getPorts(PortType); } com.example.Driver implements PortUser, implements PortStillAvailableListener { public portNoLongerAvailable(PortEvent event) { // cleanup & dismiss. } } com.example.Application { public static void main(String[] args) { Driver someDriver = new Driver(); Port radomPort = HardwareConfiguration.getPorts( HardwareConfiguration.PortType.RS232)[1]; myDevice.addStillAvailableListener(someDriver); myDevice.connect(someDriver); } } > Please do not forget that tty ports can be opened by several > applications concurrently. All of those will "loose" the port if > anyone opens the corresponding cu port. Indeed we need a good overview of the differences between the various platforms. Should we create a document or a Wiki for this purpose? FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: http://www.openbsd.org/cgi-bin/man.cgi?query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html Linux uses /var/lock: http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES Is there absolutely no way to get a lock under Windows? > As this naming based > mechanism does not exist on Windows (maybe it does via an API) it > should probably be reflected in the API. In other words there are > "two levels of open": > > - Open for reading status lines (1) > - Open for reading/writing data (2) > > I am not sure if state (1) should also allow the modification of > certain status lines (ie to set a modem ready). I'm not sure I understand. Do you mean canonical and noncanonical mode? How far is Windows with the canonical mode. Is it comparable to POSIX? > I am also not sure if > the api should unify corresponding cu. and tty. ports into one single > port. I think the API should hide low-level details like devicefiles. Who is participating anyway? Is it just the four of us? Cheers, Pascal > On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: > > For instance the current API is not very object oriented. > > It might be a good idea to have a static set of objects available > > representing > > every supported port available on the system in realtime. Each > > object should > > clearly know its own state and its capabilities. To get a port > > there could be > > a method like synchronized void connect(PortUser) where PortUser is a > > interface which handles the interaction with a input and a output > > stream and > > listers like PortStillAvailableListener, PortBufferListener and a > > DataAvailableListener. > > > > What is the collective feeling about that? From joachim at buechse.de Wed Jul 19 07:09:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 19 Jul 2006 15:09:27 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191411.27566.pascal@quies.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> Message-ID: <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> Pascal, I think that the PortNoLongerAvailableListener creates more problems than it solves. I think that exceptions are much better suited for this case. There might be an additional method "Port.isOpen" or "Port.isAvailable" which interested applications may call at times best suited. Most implementations will only find out, that a port disappeared when trying to read or write. Anything else would require polling with a high frequency or kernel hooks that do not exist (in POSIX). Any kind of call back like portNoLongerAvailable() creates the risk of deadlocks and races which require an involved implementation as the library does not know what it is calling (ie a user might try to call close from the callback which can block a very long time). Callbacks introduce concurrency which unneccessarily increases the complexity. Regards, Joachim On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: > Hi Joachim, > > Thanks for the constructive critisism. :) > > Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >> The static objects will work for Windows and Linux, however for OSX >> they will create problems: >> - ports can appear and disappear at any time with VCP drivers for USB >> - the port names are not known until the usb-port is "plugged in" > > Ports can appear and disappear on *any* OS with USB support. Some > Linux > distributions even create and remove devicefiles on the fly. > > With the current API you fetch a list of all available ports and > then you try > to cast one. What happens if the port is no longer available at > that time? > What happens if a port vanishes during the data transfer? Of course > you can > catch exceptions but that makes the code quite messy. > > The idea was to get a PortStillAvailableListener interface. In that > way the > implementation is free to handle a cleanup or wait for return > routine in a OO > way. The I/O streams should just lock. > > The word static was not ment as persistent but as Java static > available. > Considder the following: > > java.lang.hw.HardwareConfiguration { > public enum PortType { RS232, I2C, etc. }; > > /** Gets the currently available ports of type {@code PortType}. */ > public static java.lang.hw.Port[] getPorts(PortType); > } > > com.example.Driver implements PortUser, implements > PortStillAvailableListener > { > public portNoLongerAvailable(PortEvent event) { > // cleanup & dismiss. > } > } > > com.example.Application { > public static void main(String[] args) { > Driver someDriver = new Driver(); > Port radomPort = HardwareConfiguration.getPorts( > HardwareConfiguration.PortType.RS232)[1]; > myDevice.addStillAvailableListener(someDriver); > myDevice.connect(someDriver); > } > } > >> Please do not forget that tty ports can be opened by several >> applications concurrently. All of those will "loose" the port if >> anyone opens the corresponding cu port. > > Indeed we need a good overview of the differences between the various > platforms. Should we create a document or a Wiki for this purpose? > > FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: > http://www.openbsd.org/cgi-bin/man.cgi? > query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD > +Current&arch=i386&format=html > > Linux uses /var/lock: > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > Is there absolutely no way to get a lock under Windows? > >> As this naming based >> mechanism does not exist on Windows (maybe it does via an API) it >> should probably be reflected in the API. In other words there are >> "two levels of open": >> >> - Open for reading status lines (1) >> - Open for reading/writing data (2) >> >> I am not sure if state (1) should also allow the modification of >> certain status lines (ie to set a modem ready). > > I'm not sure I understand. Do you mean canonical and noncanonical > mode? > > How far is Windows with the canonical mode. Is it comparable to POSIX? > >> I am also not sure if >> the api should unify corresponding cu. and tty. ports into one single >> port. > > I think the API should hide low-level details like devicefiles. > > > Who is participating anyway? Is it just the four of us? > > Cheers, > > Pascal > > >> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>> For instance the current API is not very object oriented. >>> It might be a good idea to have a static set of objects available >>> representing >>> every supported port available on the system in realtime. Each >>> object should >>> clearly know its own state and its capabilities. To get a port >>> there could be >>> a method like synchronized void connect(PortUser) where PortUser >>> is a >>> interface which handles the interaction with a input and a output >>> stream and >>> listers like PortStillAvailableListener, PortBufferListener and a >>> DataAvailableListener. >>> >>> What is the collective feeling about that? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Wed Jul 19 08:33:08 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Wed, 19 Jul 2006 11:33:08 -0300 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191411.27566.pascal@quies.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> Message-ID: <44BE42A4.3030203@gmail.com> > Linux uses /var/lock: > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > Is there absolutely no way to get a lock under Windows? Indeed Windows block ports when someone open ones. Java Comm could manage this feature. > Who is participating anyway? Is it just the four of us? I can help too. Regards, Manuel From pascal at quies.net Wed Jul 19 09:01:17 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 17:01:17 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> References: <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> Message-ID: <200607191701.17607.pascal@quies.net> In the POSIX world things are simple. If any transaction fails with ENOTTY we lock the I/O streams and create a PortNoLongerAvailableEvent. We *might* even go so far as to start a thread which polls the tty say once a second afther a PortNoLongerAvailableEvent and kill it if there is succes with a PortAvailableAgainEvent but there won't be anything like deadlocks and races. I promise. ;) Methods like isOpen and isAvailable require polling which is exactly what we both don't want and they can't be reliable since it is a moment. A clean sepparation of the functional code and Listeners for events makes the code better readable and more flexible. PS If OS X has a notification system for changes in the available ports this OS specific functionality is more simple to implement too. Op woensdag 19 juli 2006 15:09, schreef Joachim Buechse: > Pascal, > > I think that the PortNoLongerAvailableListener creates more problems > than it solves. > > I think that exceptions are much better suited for this case. There > might be an additional method "Port.isOpen" or "Port.isAvailable" > which interested applications may call at times best suited. > > Most implementations will only find out, that a port disappeared when > trying to read or write. Anything else would require polling with a > high frequency or kernel hooks that do not exist (in POSIX). Any kind > of call back like portNoLongerAvailable() creates the risk of > deadlocks and races which require an involved implementation as the > library does not know what it is calling (ie a user might try to call > close from the callback which can block a very long time). Callbacks > introduce concurrency which unneccessarily increases the complexity. > > Regards, > Joachim From jredman at ergotech.com Wed Jul 19 09:20:39 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 09:20:39 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191411.27566.pascal@quies.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> Message-ID: <44BE4DC7.7@ergotech.com> Pascal S. de Kloe wrote: >> I am also not sure if >> the api should unify corresponding cu. and tty. ports into one single >> port. > > I think the API should hide low-level details like devicefiles. Not all ports have device files. It's long been my goal to add support for virtual serial ports, that is, serial ports on Ethernet terminal servers, for example integrating RFC2217. This means that the port name is some combination of an IP address and TCP port number. Nothing in /dev. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From brian at mbari.org Wed Jul 19 10:04:51 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 19 Jul 2006 09:04:51 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BE42A4.3030203@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <44BE42A4.3030203@gmail.com> Message-ID: <5FDA8DB5-FD08-4EAA-81A7-C46A7CF6FA18@mbari.org> >> Who is participating anyway? Is it just the four of us? > I'm not much of a POSIX or C guy. But I do a lot of OO design. I'm happy to throw my 2 cents in too. Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060719/404de230/attachment-0341.html From pascal at quies.net Wed Jul 19 10:16:16 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 18:16:16 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BE4DC7.7@ergotech.com> References: <200607191411.27566.pascal@quies.net> <44BE4DC7.7@ergotech.com> Message-ID: <200607191816.17099.pascal@quies.net> Op woensdag 19 juli 2006 17:20, schreef Jim Redman: > Pascal S. de Kloe wrote: > >> I am also not sure if > >> the api should unify corresponding cu. and tty. ports into one single > >> port. > > > > I think the API should hide low-level details like devicefiles. > > Not all ports have device files. It's long been my goal to add support > for virtual serial ports, that is, serial ports on Ethernet terminal > servers, for example integrating RFC2217. This means that the port name > is some combination of an IP address and TCP port number. Nothing in /dev. > > Jim This idea doesn't need any native calls at all, right? How would you like to realize that? Jini? I'm sure you knew that the server is already there: http://www.viara.cn/en/jts.htm From pascal at quies.net Wed Jul 19 10:17:12 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 18:17:12 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <5FDA8DB5-FD08-4EAA-81A7-C46A7CF6FA18@mbari.org> References: <44BE42A4.3030203@gmail.com> <5FDA8DB5-FD08-4EAA-81A7-C46A7CF6FA18@mbari.org> Message-ID: <200607191817.12769.pascal@quies.net> Op woensdag 19 juli 2006 18:04, schreef Brian Schlining: > >> Who is participating anyway? Is it just the four of us? > > I'm not much of a POSIX or C guy. But I do a lot of OO design. I'm > happy to throw my 2 cents in too. > > Brian Schlining > Software Engineer > http://www.mbari.org Excellent! :) We need a lot of opinions from all kinds of users. From jredman at ergotech.com Wed Jul 19 10:54:18 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 10:54:18 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191816.17099.pascal@quies.net> References: <200607191411.27566.pascal@quies.net> <44BE4DC7.7@ergotech.com> <200607191816.17099.pascal@quies.net> Message-ID: <44BE63BA.9090905@ergotech.com> Pascal, Pascal S. de Kloe wrote: > Op woensdag 19 juli 2006 17:20, schreef Jim Redman: >> Pascal S. de Kloe wrote: >>>> I am also not sure if >>>> the api should unify corresponding cu. and tty. ports into one single >>>> port. >>> I think the API should hide low-level details like devicefiles. >> Not all ports have device files. It's long been my goal to add support >> for virtual serial ports, that is, serial ports on Ethernet terminal >> servers, for example integrating RFC2217. This means that the port name >> is some combination of an IP address and TCP port number. Nothing in /dev. >> >> Jim > > This idea doesn't need any native calls at all, right? No native calls, it's just a Socket link. > > How would you like to realize that? I keep wondering that myself. I had in mind port names that are, for example, "192.168.0.99:3000". These would need to be added to the properties file (or the -D option). I'm open for suggestion. It's conceptually, it's the same as USB. Instead of USB->Serial it's Ethernet->Serial. The difference is that the USB devices create virtual serial ports within the OS. Some Ethernet devices also do this, but since, unlike USB communications, TCP/IP is supported natively within Java such a driver is unnecessary. > Jini? Is that still alive and kicking? > > I'm sure you knew that the server is already there: > > http://www.viara.cn/en/jts.htm Yes, that library is part of the plan. These devices are real serial ports. Somewhere, out in the Ether there's a DB9/DB25 cable with RS232/485 bits flowing over it. Since these are real ports, I'd like the ports to look like real serial ports (SerialPort) and not have to handle them as special cases. We have a bunch of code that deals with serial devices (PLCs, Barcode, Temperature Controllers, RFID, SECS, etc. etc.) and to rewrite each one of those to handle this case doesn't make much sense when the correct place to encapsulate a serial port is in the SerialPort layer. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From pascal at quies.net Wed Jul 19 12:44:01 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 20:44:01 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BE63BA.9090905@ergotech.com> References: <200607191816.17099.pascal@quies.net> <44BE63BA.9090905@ergotech.com> Message-ID: <200607192044.01966.pascal@quies.net> Op woensdag 19 juli 2006 18:54, schreef Jim Redman: > I keep wondering that myself. I had in mind port names that are, for > example, "192.168.0.99:3000". These would need to be added to the > properties file (or the -D option). > > I'm open for suggestion. Jini works very well especialy for ethernets like the one you describe. It's a shame that it never got the attention it deserves. > > Jini? > > Is that still alive and kicking? Not that it does matter becouse Java software doesn't need much maintenance. ;) Have a look at http://www.jini.org/. From Paul.Klissner at Sun.COM Wed Jul 19 15:45:38 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 14:45:38 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> Message-ID: <44BEA802.7060508@sun.com> Joachim Buechse wrote: > Pascal, > > I think that the PortNoLongerAvailableListener creates more problems > than it solves. > > I think that exceptions are much better suited for this case. There > might be an additional method "Port.isOpen" or "Port.isAvailable" > which interested applications may call at times best suited. > > Most implementations will only find out, that a port disappeared when > trying to read or write. Anything else would require polling with a > high frequency or kernel hooks that do not exist (in POSIX). Any kind > of call back like portNoLongerAvailable() creates the risk of > deadlocks and races which require an involved implementation as the > library does not know what it is calling (ie a user might try to call > close from the callback which can block a very long time). Callbacks > introduce concurrency which unneccessarily increases the complexity. I think we should find out what are the minimum requirements to get a JSR open, form an expert group, and get that group discussing these things in the JSR. I'm not pushing for Sun to sponsor it, as I think there is a community interest already and that it deserves an independent life and commitment. ACCESS EXCEPTIONS: ----------------- I agree, exceptions of this sort are the way to go. Exceptions are already simpler than having to err check at each function call, so a big improvement. No need to architect a more trouble prone complexity into the API. PROJECT SCOPE: ------------- Also, we should think carefully about what the scope of this project would be. Should it be javax."comm" which handles both serial and parallel (is parallel going by the wayside). Should it be split into two project: javax.EIA232 (or javax.RS232), and javax.IEEE1284? Should we differentiate between single-ended serial protocols, like EIA232, I2C, 2-WIRE, SPI, vs. quasi-multidrop and full multidrop busses such as EIA422, EIA432 and EIA485? If we really were to add I2C support to the API, we'd have to delve into the semantics more, because there could be some implicit decoding of the bus the API users would want to see. At this point, I'm thinking they're all different, and should be their own projects.. perhaps there could be an umbrella layer that abstracted out some of the generic issues like device ownership and access, perhaps not. javax.eia232 javax.eia485 or (javax.EIX4xx?) javax.i2c, javax.spi (or javax.chipbus?) DRIVER PLUGINS: -------------- Taking javax.eia232 for example, I think we need an architecture that allows for multiple plugins to provide multiple simultaneous drivers/adapters to allow for heterogeneous providers on a single system. For example, not only can there be USB based serial devices but networked serial devices, for example accessing devices on thin clients. PORTMAPPING: ----------- For Sun's javax.comm 3.0, we introduced a portmapping abstraction layer, that creates a mechansim to help administer the view (filtering)of available ports given to the application, and the name of such ports. I hope we can consider the right platform neutral way to accomplish that. In javax.comm as it is now, the API has to know where to go and look to find ports. In 3.x I added the ability to specify where to look for standard ports as properties to make it more flexible, but for our thin client platform, which can represent a very dynamic buffet of ports splayed in the leaf nodes of a tree that isn't good enough. That complicates things for the users (having to specify and manage unique and long path names to ports which can come and go), so there is an option whereby the user can configure something like "com1" such that on a thin client it represents the first port of the first USB/serial dongle connected. Javax.comm knows how to find that in the context of the current thin client, but the administrator doesn't have to worry about it. How to architect the API flexibly enough to allow for this kind of thing needs to be considered. Paul > > Regards, > Joachim > > On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: > >> Hi Joachim, >> >> Thanks for the constructive critisism. :) >> >> Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >>> The static objects will work for Windows and Linux, however for OSX >>> they will create problems: >>> - ports can appear and disappear at any time with VCP drivers for USB >>> - the port names are not known until the usb-port is "plugged in" >> Ports can appear and disappear on *any* OS with USB support. Some >> Linux >> distributions even create and remove devicefiles on the fly. >> >> With the current API you fetch a list of all available ports and >> then you try >> to cast one. What happens if the port is no longer available at >> that time? >> What happens if a port vanishes during the data transfer? Of course >> you can >> catch exceptions but that makes the code quite messy. >> >> The idea was to get a PortStillAvailableListener interface. In that >> way the >> implementation is free to handle a cleanup or wait for return >> routine in a OO >> way. The I/O streams should just lock. >> >> The word static was not ment as persistent but as Java static >> available. >> Considder the following: >> >> java.lang.hw.HardwareConfiguration { >> public enum PortType { RS232, I2C, etc. }; >> >> /** Gets the currently available ports of type {@code PortType}. */ >> public static java.lang.hw.Port[] getPorts(PortType); >> } >> >> com.example.Driver implements PortUser, implements >> PortStillAvailableListener >> { >> public portNoLongerAvailable(PortEvent event) { >> // cleanup & dismiss. >> } >> } >> >> com.example.Application { >> public static void main(String[] args) { >> Driver someDriver = new Driver(); >> Port radomPort = HardwareConfiguration.getPorts( >> HardwareConfiguration.PortType.RS232)[1]; >> myDevice.addStillAvailableListener(someDriver); >> myDevice.connect(someDriver); >> } >> } >> >>> Please do not forget that tty ports can be opened by several >>> applications concurrently. All of those will "loose" the port if >>> anyone opens the corresponding cu port. >> Indeed we need a good overview of the differences between the various >> platforms. Should we create a document or a Wiki for this purpose? >> >> FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: >> http://www.openbsd.org/cgi-bin/man.cgi? >> query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD >> +Current&arch=i386&format=html >> >> Linux uses /var/lock: >> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES >> >> Is there absolutely no way to get a lock under Windows? >> >>> As this naming based >>> mechanism does not exist on Windows (maybe it does via an API) it >>> should probably be reflected in the API. In other words there are >>> "two levels of open": >>> >>> - Open for reading status lines (1) >>> - Open for reading/writing data (2) >>> >>> I am not sure if state (1) should also allow the modification of >>> certain status lines (ie to set a modem ready). >> I'm not sure I understand. Do you mean canonical and noncanonical >> mode? >> >> How far is Windows with the canonical mode. Is it comparable to POSIX? >> >>> I am also not sure if >>> the api should unify corresponding cu. and tty. ports into one single >>> port. >> I think the API should hide low-level details like devicefiles. >> >> >> Who is participating anyway? Is it just the four of us? >> >> Cheers, >> >> Pascal >> >> >>> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>>> For instance the current API is not very object oriented. >>>> It might be a good idea to have a static set of objects available >>>> representing >>>> every supported port available on the system in realtime. Each >>>> object should >>>> clearly know its own state and its capabilities. To get a port >>>> there could be >>>> a method like synchronized void connect(PortUser) where PortUser >>>> is a >>>> interface which handles the interaction with a input and a output >>>> stream and >>>> listers like PortStillAvailableListener, PortBufferListener and a >>>> DataAvailableListener. >>>> >>>> What is the collective feeling about that? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Wed Jul 19 16:32:37 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 16:32:37 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEA802.7060508@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <44BEB305.3030208@ergotech.com> For one, I'd object to the splitting of 232 and 485 and question why it's necessary. Often the only difference between 232 access and 485 access is whether there's a converter attached to the serial port. Put another way, while 485 is multidrop, I think that's an application level issue rather than a driver level issue. If the issue is electrical, I don't think that it's possible to reliably support receiver switching of a 2-wire 485 network within Java, the timing is just too tight, so your stuck with requiring a 485 converter that automatically switches (not an onerous burden for us) or some OS level intervention. Anyway, if we're going to start differentiating at the electrical level we still support some current loop systems (Siemens S5 PLC if you care). Jim Paul Klissner wrote: > Joachim Buechse wrote: >> Pascal, >> >> I think that the PortNoLongerAvailableListener creates more problems >> than it solves. >> >> I think that exceptions are much better suited for this case. There >> might be an additional method "Port.isOpen" or "Port.isAvailable" >> which interested applications may call at times best suited. >> >> Most implementations will only find out, that a port disappeared when >> trying to read or write. Anything else would require polling with a >> high frequency or kernel hooks that do not exist (in POSIX). Any kind >> of call back like portNoLongerAvailable() creates the risk of >> deadlocks and races which require an involved implementation as the >> library does not know what it is calling (ie a user might try to call >> close from the callback which can block a very long time). Callbacks >> introduce concurrency which unneccessarily increases the complexity. > > I think we should find out what are the minimum requirements > to get a JSR open, form an expert group, and get that group > discussing these things in the JSR. I'm not pushing for > Sun to sponsor it, as I think there is a community interest > already and that it deserves an independent life and > commitment. > > ACCESS EXCEPTIONS: > ----------------- > I agree, exceptions of this sort are the way to go. > Exceptions are already simpler than having to err > check at each function call, so a big improvement. > No need to architect a more trouble prone complexity > into the API. > > PROJECT SCOPE: > ------------- > > Also, we should think carefully about what the scope of > this project would be. Should it be javax."comm" which > handles both serial and parallel (is parallel going by the > wayside). Should it be split into two project: > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > > Should we differentiate between single-ended serial > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > quasi-multidrop and full multidrop busses such as > EIA422, EIA432 and EIA485? If we really were to > add I2C support to the API, we'd have to delve into > the semantics more, because there could be some > implicit decoding of the bus the API users would > want to see. > > At this point, I'm thinking they're all different, > and should be their own projects.. perhaps there > could be an umbrella layer that abstracted out > some of the generic issues like device ownership > and access, perhaps not. > > javax.eia232 > javax.eia485 or (javax.EIX4xx?) > javax.i2c, javax.spi (or javax.chipbus?) > > DRIVER PLUGINS: > -------------- > Taking javax.eia232 for example, I think we need an > architecture that allows for multiple plugins to > provide multiple simultaneous drivers/adapters to > allow for heterogeneous providers on a single system. > For example, not only can there be USB based serial > devices but networked serial devices, for example > accessing devices on thin clients. > > PORTMAPPING: > ----------- > For Sun's javax.comm 3.0, we introduced a portmapping > abstraction layer, that creates a mechansim to help > administer the view (filtering)of available ports given > to the application, and the name of such ports. I hope we > can consider the right platform neutral way to > accomplish that. > > In javax.comm as it is now, the API has to know > where to go and look to find ports. In 3.x I added > the ability to specify where to look for standard > ports as properties to make it more flexible, but > for our thin client platform, which can represent > a very dynamic buffet of ports splayed in the > leaf nodes of a tree that isn't good enough. > That complicates things for the users (having > to specify and manage unique and long path names > to ports which can come and go), so there is > an option whereby the user can configure > something like "com1" such that on a thin client > it represents the first port of the first USB/serial > dongle connected. Javax.comm knows how to find > that in the context of the current thin client, > but the administrator doesn't have to worry about it. > > How to architect the API flexibly enough to allow > for this kind of thing needs to be considered. > > Paul > > > >> Regards, >> Joachim >> >> On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: >> >>> Hi Joachim, >>> >>> Thanks for the constructive critisism. :) >>> >>> Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >>>> The static objects will work for Windows and Linux, however for OSX >>>> they will create problems: >>>> - ports can appear and disappear at any time with VCP drivers for USB >>>> - the port names are not known until the usb-port is "plugged in" >>> Ports can appear and disappear on *any* OS with USB support. Some >>> Linux >>> distributions even create and remove devicefiles on the fly. >>> >>> With the current API you fetch a list of all available ports and >>> then you try >>> to cast one. What happens if the port is no longer available at >>> that time? >>> What happens if a port vanishes during the data transfer? Of course >>> you can >>> catch exceptions but that makes the code quite messy. >>> >>> The idea was to get a PortStillAvailableListener interface. In that >>> way the >>> implementation is free to handle a cleanup or wait for return >>> routine in a OO >>> way. The I/O streams should just lock. >>> >>> The word static was not ment as persistent but as Java static >>> available. >>> Considder the following: >>> >>> java.lang.hw.HardwareConfiguration { >>> public enum PortType { RS232, I2C, etc. }; >>> >>> /** Gets the currently available ports of type {@code PortType}. */ >>> public static java.lang.hw.Port[] getPorts(PortType); >>> } >>> >>> com.example.Driver implements PortUser, implements >>> PortStillAvailableListener >>> { >>> public portNoLongerAvailable(PortEvent event) { >>> // cleanup & dismiss. >>> } >>> } >>> >>> com.example.Application { >>> public static void main(String[] args) { >>> Driver someDriver = new Driver(); >>> Port radomPort = HardwareConfiguration.getPorts( >>> HardwareConfiguration.PortType.RS232)[1]; >>> myDevice.addStillAvailableListener(someDriver); >>> myDevice.connect(someDriver); >>> } >>> } >>> >>>> Please do not forget that tty ports can be opened by several >>>> applications concurrently. All of those will "loose" the port if >>>> anyone opens the corresponding cu port. >>> Indeed we need a good overview of the differences between the various >>> platforms. Should we create a document or a Wiki for this purpose? >>> >>> FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: >>> http://www.openbsd.org/cgi-bin/man.cgi? >>> query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD >>> +Current&arch=i386&format=html >>> >>> Linux uses /var/lock: >>> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES >>> >>> Is there absolutely no way to get a lock under Windows? >>> >>>> As this naming based >>>> mechanism does not exist on Windows (maybe it does via an API) it >>>> should probably be reflected in the API. In other words there are >>>> "two levels of open": >>>> >>>> - Open for reading status lines (1) >>>> - Open for reading/writing data (2) >>>> >>>> I am not sure if state (1) should also allow the modification of >>>> certain status lines (ie to set a modem ready). >>> I'm not sure I understand. Do you mean canonical and noncanonical >>> mode? >>> >>> How far is Windows with the canonical mode. Is it comparable to POSIX? >>> >>>> I am also not sure if >>>> the api should unify corresponding cu. and tty. ports into one single >>>> port. >>> I think the API should hide low-level details like devicefiles. >>> >>> >>> Who is participating anyway? Is it just the four of us? >>> >>> Cheers, >>> >>> Pascal >>> >>> >>>> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>>>> For instance the current API is not very object oriented. >>>>> It might be a good idea to have a static set of objects available >>>>> representing >>>>> every supported port available on the system in realtime. Each >>>>> object should >>>>> clearly know its own state and its capabilities. To get a port >>>>> there could be >>>>> a method like synchronized void connect(PortUser) where PortUser >>>>> is a >>>>> interface which handles the interaction with a input and a output >>>>> stream and >>>>> listers like PortStillAvailableListener, PortBufferListener and a >>>>> DataAvailableListener. >>>>> >>>>> What is the collective feeling about that? >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Paul.Klissner at Sun.COM Wed Jul 19 17:31:36 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 16:31:36 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEB305.3030208@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> Message-ID: <44BEC0D8.4050806@sun.com> Jim Redman wrote: > For one, I'd object to the splitting of 232 and 485 and question why > it's necessary. Often the only difference between 232 access and 485 > access is whether there's a converter attached to the serial port. > > Put another way, while 485 is multidrop, I think that's an application > level issue rather than a driver level issue. > > If the issue is electrical, I don't think that it's possible to reliably > support receiver switching of a 2-wire 485 network within Java, the > timing is just too tight, so your stuck with requiring a 485 converter > that automatically switches (not an onerous burden for us) or some OS > level intervention. > > Anyway, if we're going to start differentiating at the electrical level > we still support some current loop systems (Siemens S5 PLC if you care). > > Jim To be honest, I've not done anything with 422, 423 or 485, so I have no objection to keeping them together if there isn't enough of a protocol distinction to make it worth seperating them out. I'd just like to find another suitable name than javax.comm, unless the JSR wants to start with javax.comm 4.0, since all the previous 'major revisions' are accounted for. javax.serialport? Paul > > Paul Klissner wrote: >> Joachim Buechse wrote: >>> Pascal, >>> >>> I think that the PortNoLongerAvailableListener creates more problems >>> than it solves. >>> >>> I think that exceptions are much better suited for this case. There >>> might be an additional method "Port.isOpen" or "Port.isAvailable" >>> which interested applications may call at times best suited. >>> >>> Most implementations will only find out, that a port disappeared when >>> trying to read or write. Anything else would require polling with a >>> high frequency or kernel hooks that do not exist (in POSIX). Any kind >>> of call back like portNoLongerAvailable() creates the risk of >>> deadlocks and races which require an involved implementation as the >>> library does not know what it is calling (ie a user might try to call >>> close from the callback which can block a very long time). Callbacks >>> introduce concurrency which unneccessarily increases the complexity. >> I think we should find out what are the minimum requirements >> to get a JSR open, form an expert group, and get that group >> discussing these things in the JSR. I'm not pushing for >> Sun to sponsor it, as I think there is a community interest >> already and that it deserves an independent life and >> commitment. >> >> ACCESS EXCEPTIONS: >> ----------------- >> I agree, exceptions of this sort are the way to go. >> Exceptions are already simpler than having to err >> check at each function call, so a big improvement. >> No need to architect a more trouble prone complexity >> into the API. >> >> PROJECT SCOPE: >> ------------- >> >> Also, we should think carefully about what the scope of >> this project would be. Should it be javax."comm" which >> handles both serial and parallel (is parallel going by the >> wayside). Should it be split into two project: >> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >> >> Should we differentiate between single-ended serial >> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >> quasi-multidrop and full multidrop busses such as >> EIA422, EIA432 and EIA485? If we really were to >> add I2C support to the API, we'd have to delve into >> the semantics more, because there could be some >> implicit decoding of the bus the API users would >> want to see. >> >> At this point, I'm thinking they're all different, >> and should be their own projects.. perhaps there >> could be an umbrella layer that abstracted out >> some of the generic issues like device ownership >> and access, perhaps not. >> >> javax.eia232 >> javax.eia485 or (javax.EIX4xx?) >> javax.i2c, javax.spi (or javax.chipbus?) >> >> DRIVER PLUGINS: >> -------------- >> Taking javax.eia232 for example, I think we need an >> architecture that allows for multiple plugins to >> provide multiple simultaneous drivers/adapters to >> allow for heterogeneous providers on a single system. >> For example, not only can there be USB based serial >> devices but networked serial devices, for example >> accessing devices on thin clients. >> >> PORTMAPPING: >> ----------- >> For Sun's javax.comm 3.0, we introduced a portmapping >> abstraction layer, that creates a mechansim to help >> administer the view (filtering)of available ports given >> to the application, and the name of such ports. I hope we >> can consider the right platform neutral way to >> accomplish that. >> >> In javax.comm as it is now, the API has to know >> where to go and look to find ports. In 3.x I added >> the ability to specify where to look for standard >> ports as properties to make it more flexible, but >> for our thin client platform, which can represent >> a very dynamic buffet of ports splayed in the >> leaf nodes of a tree that isn't good enough. >> That complicates things for the users (having >> to specify and manage unique and long path names >> to ports which can come and go), so there is >> an option whereby the user can configure >> something like "com1" such that on a thin client >> it represents the first port of the first USB/serial >> dongle connected. Javax.comm knows how to find >> that in the context of the current thin client, >> but the administrator doesn't have to worry about it. >> >> How to architect the API flexibly enough to allow >> for this kind of thing needs to be considered. >> >> Paul >> >> >> >>> Regards, >>> Joachim >>> >>> On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: >>> >>>> Hi Joachim, >>>> >>>> Thanks for the constructive critisism. :) >>>> >>>> Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >>>>> The static objects will work for Windows and Linux, however for OSX >>>>> they will create problems: >>>>> - ports can appear and disappear at any time with VCP drivers for USB >>>>> - the port names are not known until the usb-port is "plugged in" >>>> Ports can appear and disappear on *any* OS with USB support. Some >>>> Linux >>>> distributions even create and remove devicefiles on the fly. >>>> >>>> With the current API you fetch a list of all available ports and >>>> then you try >>>> to cast one. What happens if the port is no longer available at >>>> that time? >>>> What happens if a port vanishes during the data transfer? Of course >>>> you can >>>> catch exceptions but that makes the code quite messy. >>>> >>>> The idea was to get a PortStillAvailableListener interface. In that >>>> way the >>>> implementation is free to handle a cleanup or wait for return >>>> routine in a OO >>>> way. The I/O streams should just lock. >>>> >>>> The word static was not ment as persistent but as Java static >>>> available. >>>> Considder the following: >>>> >>>> java.lang.hw.HardwareConfiguration { >>>> public enum PortType { RS232, I2C, etc. }; >>>> >>>> /** Gets the currently available ports of type {@code PortType}. */ >>>> public static java.lang.hw.Port[] getPorts(PortType); >>>> } >>>> >>>> com.example.Driver implements PortUser, implements >>>> PortStillAvailableListener >>>> { >>>> public portNoLongerAvailable(PortEvent event) { >>>> // cleanup & dismiss. >>>> } >>>> } >>>> >>>> com.example.Application { >>>> public static void main(String[] args) { >>>> Driver someDriver = new Driver(); >>>> Port radomPort = HardwareConfiguration.getPorts( >>>> HardwareConfiguration.PortType.RS232)[1]; >>>> myDevice.addStillAvailableListener(someDriver); >>>> myDevice.connect(someDriver); >>>> } >>>> } >>>> >>>>> Please do not forget that tty ports can be opened by several >>>>> applications concurrently. All of those will "loose" the port if >>>>> anyone opens the corresponding cu port. >>>> Indeed we need a good overview of the differences between the various >>>> platforms. Should we create a document or a Wiki for this purpose? >>>> >>>> FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: >>>> http://www.openbsd.org/cgi-bin/man.cgi? >>>> query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD >>>> +Current&arch=i386&format=html >>>> >>>> Linux uses /var/lock: >>>> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES >>>> >>>> Is there absolutely no way to get a lock under Windows? >>>> >>>>> As this naming based >>>>> mechanism does not exist on Windows (maybe it does via an API) it >>>>> should probably be reflected in the API. In other words there are >>>>> "two levels of open": >>>>> >>>>> - Open for reading status lines (1) >>>>> - Open for reading/writing data (2) >>>>> >>>>> I am not sure if state (1) should also allow the modification of >>>>> certain status lines (ie to set a modem ready). >>>> I'm not sure I understand. Do you mean canonical and noncanonical >>>> mode? >>>> >>>> How far is Windows with the canonical mode. Is it comparable to POSIX? >>>> >>>>> I am also not sure if >>>>> the api should unify corresponding cu. and tty. ports into one single >>>>> port. >>>> I think the API should hide low-level details like devicefiles. >>>> >>>> >>>> Who is participating anyway? Is it just the four of us? >>>> >>>> Cheers, >>>> >>>> Pascal >>>> >>>> >>>>> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>>>>> For instance the current API is not very object oriented. >>>>>> It might be a good idea to have a static set of objects available >>>>>> representing >>>>>> every supported port available on the system in realtime. Each >>>>>> object should >>>>>> clearly know its own state and its capabilities. To get a port >>>>>> there could be >>>>>> a method like synchronized void connect(PortUser) where PortUser >>>>>> is a >>>>>> interface which handles the interaction with a input and a output >>>>>> stream and >>>>>> listers like PortStillAvailableListener, PortBufferListener and a >>>>>> DataAvailableListener. >>>>>> >>>>>> What is the collective feeling about that? >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Wed Jul 19 18:03:40 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 18:03:40 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEC0D8.4050806@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> Message-ID: <44BEC85C.2030809@ergotech.com> Paul Klissner wrote: > I'd just like to find another suitable name than javax.comm, unless > the JSR wants to start with javax.comm 4.0, since all the previous > 'major revisions' are accounted for. javax.serialport? Which perhaps brings us back to what are we trying to fix and how badly. There are a number of 3rd party implementation of Java Comm, at least one from IBM - part of what was J9, now Websphere, or something (presumbly soon to get a name that has eclipse in it sometime soon). Esmertec has one, and there are few others rolling around. If RXTX is the only implementation of the JSR with no backward compatibility, we've just forked Java Serial support and we (for a least one) will be worse off. We won't be able to use the new support because of a lack of support on J2ME platforms that we have no control over and RXTX/current JavaComm will be in maintenance mode or unsupported on all other platforms. So, is there any chance of building a compatibility requirement into this. To pick are really bad example JDBC has support for a DataSource or a Driver. Could we have an ExcellentSerialPort with a fallback to a SerialPort on a class not found exception? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From pascal at quies.net Wed Jul 19 18:22:45 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Thu, 20 Jul 2006 02:22:45 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEC85C.2030809@ergotech.com> References: <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> Message-ID: <200607200222.46023.pascal@quies.net> Op donderdag 20 juli 2006 02:03, schreef Jim Redman: > Which perhaps brings us back to what are we trying to fix and how badly. The initail problem was the license. :) RXTX is sitting in this gnu.comm namespace and is afraid to go to javax.comm. Getting a JSR would solve this problem. And while we're at it we might as well improve the situation with the various platforms. I made some sugestions that where denied as too complex. Cheers, Pascal From Paul.Klissner at Sun.COM Wed Jul 19 19:09:35 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 18:09:35 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607200222.46023.pascal@quies.net> References: <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <200607200222.46023.pascal@quies.net> Message-ID: <44BED7CF.5080405@sun.com> Pascal S. de Kloe wrote: > Op donderdag 20 juli 2006 02:03, schreef Jim Redman: >> Which perhaps brings us back to what are we trying to fix and how badly. > > The initail problem was the license. :) > > RXTX is sitting in this gnu.comm namespace and is afraid to go to javax.comm. > Getting a JSR would solve this problem. > > And while we're at it we might as well improve the situation with the various > platforms. I made some sugestions that where denied as too complex. "Denied" is a bit harsh :) I'll re-examine your e-mails to see if my preferences change. It's not like your proposition has been put up to a formal vote, just discussion. Paul From Paul.Klissner at Sun.COM Wed Jul 19 19:28:47 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 18:28:47 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEC85C.2030809@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> Message-ID: <44BEDC4F.9030403@sun.com> Jim Redman wrote: > Paul Klissner wrote: >> I'd just like to find another suitable name than javax.comm, unless >> the JSR wants to start with javax.comm 4.0, since all the previous >> 'major revisions' are accounted for. javax.serialport? > > Which perhaps brings us back to what are we trying to fix and how badly. The goals I'm most interested in at the moment are: 1. A pluggable platform portmapping scheme wherein each platform can determine which ports to present to the application, and preferably as some configurable logical name. For example on the Sun Ray thin client platform, if an application aquiring a view of serial ports available on the system, it will be informed of Sun Ray serial ports if the application is running in a session currently directed to that particular Sun Ray unit, even though the serial port's device node happens to be server-side deeply nested in a leaf node. If the application is not running on a Sun Ray the port doesn't show up. The Sun Ray plugin would make the decision about when and which ports to present to the application. 2. Pluggable driver-side interface where multiple platform-specific drivers can be utilized simultaneously to introduce more flexibility with the back end. > There are a number of 3rd party implementation of Java Comm, at least > one from IBM - part of what was J9, now Websphere, or something > (presumbly soon to get a name that has eclipse in it sometime soon). > Esmertec has one, and there are few others rolling around. I have not been advocating gutting the API, since much of it is perfectly adequate. I'm not totally opposed to making substantial changes or improvements depending on other people's needs. There's no reason previous versions of javax.comm need to suddenly disappear if products need legacy support. > > If RXTX is the only implementation of the JSR with no backward > compatibility, we've just forked Java Serial support and we (for a least > one) will be worse off. We won't be able to use the new support because > of a lack of support on J2ME platforms that we have no control over and > RXTX/current JavaComm will be in maintenance mode or unsupported on all > other platforms. There can't be *that* many platforms this is ported to. And it will be no javax.usb. Seems like most of the standard platforms will be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, JDBC... > > So, is there any chance of building a compatibility requirement into > this. To pick are really bad example JDBC has support for a DataSource > or a Driver. Could we have an ExcellentSerialPort with a fallback to a > SerialPort on a class not found exception? Maybe, or maybe we just let people know what we are doing and try to figure out how to get their applications ported. Might not be that difficult. From my standpoint anyway, earthshaking changes aren't really necessary. Others might disagree. Paul From rwelty at averillpark.net Wed Jul 19 19:35:54 2006 From: rwelty at averillpark.net (Richard P. Welty) Date: Wed, 19 Jul 2006 21:35:54 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter Message-ID: <44BEDDFA.7020108@averillpark.net> I'm returning to the use of rxtx after 2 years off doing things that don't need serial ports. I'm trying to get my laptop (fedora core 1) talking to a set of portable auto scales through a Keyspan USB adapter (in my past use of rxtx, I had actual serial ports, but those days are long gone.) I have the keyspan kernel module loaded, and lsusb shows the device as correctly identified. I'm missing the bit of magic needed to get rxtx to provide the port in response to CommPortIdentifier.getPortIdentifiers() thanks in advance for any help, richard From jredman at ergotech.com Wed Jul 19 19:43:25 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 19:43:25 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BED7CF.5080405@sun.com> References: <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <200607200222.46023.pascal@quies.net> <44BED7CF.5080405@sun.com> Message-ID: <44BEDFBD.4020404@ergotech.com> Paul Klissner wrote: > Pascal S. de Kloe wrote: >> Op donderdag 20 juli 2006 02:03, schreef Jim Redman: >>> Which perhaps brings us back to what are we trying to fix and how badly. >> The initail problem was the license. :) >> >> RXTX is sitting in this gnu.comm namespace and is afraid to go to javax.comm. >> Getting a JSR would solve this problem. >> >> And while we're at it we might as well improve the situation with the various >> platforms. I made some sugestions that where denied as too complex. > > "Denied" is a bit harsh :) I'll re-examine your e-mails > to see if my preferences change. It's not like your > proposition has been put up to a formal vote, just discussion. OK, I'll officially float backwards compatibility in the form of "It should be possible to use anything that comes out of the JSR in place of an existing java comm implementation". I wonder if "Denied" is too harsh for that one :) Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From ajmas at sympatico.ca Wed Jul 19 19:47:06 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Wed, 19 Jul 2006 21:47:06 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEDDFA.7020108@averillpark.net> References: <44BEDDFA.7020108@averillpark.net> Message-ID: <35101C10-59A5-4F02-AEEE-DB69112F8130@sympatico.ca> Do you see an associated device in /dev ? On 19-Jul-06, at 21:35 , Richard P. Welty wrote: > I'm returning to the use of rxtx after 2 years off doing > things that don't need serial ports. > > I'm trying to get my laptop (fedora core 1) talking to a > set of portable auto scales through a Keyspan USB adapter > (in my past use of rxtx, I had actual serial ports, but those > days are long gone.) I have the keyspan kernel module loaded, > and lsusb shows the device as correctly identified. I'm missing > the bit of magic needed to get rxtx to provide the port > in response to CommPortIdentifier.getPortIdentifiers() > > thanks in advance for any help, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Wed Jul 19 19:54:03 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 19:54:03 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEDC4F.9030403@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> Message-ID: <44BEE23B.30908@ergotech.com> Paul, For the record we're STILL supporting some PersonalJava platforms. We're _almost_ at the point where we can assume that the platforms will have a Collections framework, but routinely compile with a 1.1 check so that we don't make that assumption unnecessarily. Of 50+ non-graphical Factory Automation JavaBeans we have 2 that require Java2 (Reporting and JavaScripting), and we have people asking for a back-port. Embedded platforms don't change in a hurry. Unlike desktop platforms, embedded systems are expected to last 5-10+ years. There are factory automation vendors in the pharmaceutical industry who are buying systems on eBay because that's the FDA validate platform. It must be that make/model, spec'd sometime in the mid-90's. So... If you make an incompatible change TODAY figure we can start using that code _at the earliest_ somewhere around 2012 or the low teens. Are we _really_ the only people on the list supporting embedded/factory automation platforms? Jim Paul Klissner wrote: > Jim Redman wrote: >> Paul Klissner wrote: >>> I'd just like to find another suitable name than javax.comm, unless >>> the JSR wants to start with javax.comm 4.0, since all the previous >>> 'major revisions' are accounted for. javax.serialport? >> Which perhaps brings us back to what are we trying to fix and how badly. > The goals I'm most interested in at the moment are: > > 1. A pluggable platform portmapping scheme wherein each platform > can determine which ports to present to the application, and > preferably as some configurable logical name. > > For example on the Sun Ray thin client platform, if an application > aquiring a view of serial ports available on the system, it will > be informed of Sun Ray serial ports if the application is running > in a session currently directed to that particular Sun Ray unit, > even though the serial port's device node happens to be server-side > deeply nested in a leaf node. If the application is not running on > a Sun Ray the port doesn't show up. The Sun Ray plugin would make > the decision about when and which ports to present to the application. > > 2. Pluggable driver-side interface where multiple platform-specific > drivers can be utilized simultaneously to introduce more flexibility > with the back end. > >> There are a number of 3rd party implementation of Java Comm, at least >> one from IBM - part of what was J9, now Websphere, or something >> (presumbly soon to get a name that has eclipse in it sometime soon). >> Esmertec has one, and there are few others rolling around. > > I have not been advocating gutting the API, since much of it is > perfectly adequate. I'm not totally opposed to making substantial > changes or improvements depending on other people's needs. There's > no reason previous versions of javax.comm need to suddenly disappear > if products need legacy support. > > >> If RXTX is the only implementation of the JSR with no backward >> compatibility, we've just forked Java Serial support and we (for a least >> one) will be worse off. We won't be able to use the new support because >> of a lack of support on J2ME platforms that we have no control over and >> RXTX/current JavaComm will be in maintenance mode or unsupported on all >> other platforms. > > There can't be *that* many platforms this is ported to. And it will > be no javax.usb. Seems like most of the standard platforms will > be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, > JDBC... > >> So, is there any chance of building a compatibility requirement into >> this. To pick are really bad example JDBC has support for a DataSource >> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >> SerialPort on a class not found exception? > > Maybe, or maybe we just let people know what we are doing and > try to figure out how to get their applications ported. Might not > be that difficult. From my standpoint anyway, earthshaking > changes aren't really necessary. Others might disagree. > > Paul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tod at todbot.com Wed Jul 19 19:59:52 2006 From: tod at todbot.com (Tod E. Kurt) Date: Wed, 19 Jul 2006 18:59:52 -0700 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEDDFA.7020108@averillpark.net> References: <44BEDDFA.7020108@averillpark.net> Message-ID: Hi, "lsusb" doesn't show if you have the proper drivers loaded for the specific USB device, just that a USB device is plugged in. The text identifiers sent by the USB device aren't used by the OS except for things like lsusb. Look at the output of "dmesg" or /var/log/messages and see if you have a lines that looks like: keyspan 1-1:1.0: Keyspan 1 port adapter converter detected usb 1-1: Keyspan 1 port adapter converter now attached to ttyUSB0 If you do, then you've got a serial port at "/dev/ttyUSB0", and you can use minicom or whatever (even RXTX!) to play with it. If you get a message like: usb.c: USB device 4 (vend/prod 0x06cd/0x0121) is not claimed by any active driver. Then the USB driver can't find the 'keyspan' driver. If you're sure you have this driver, then hotplug isn't working for some reason. You could try running the command: % sudo modprobe keyspan And see if anything useful happens. You should see the 'keyspan' driver when you type "lsmod" to list the currently loaded kernel modules. -=tod On Jul 19, 2006, at 6:35 PM, Richard P. Welty wrote: > I'm returning to the use of rxtx after 2 years off doing > things that don't need serial ports. > > I'm trying to get my laptop (fedora core 1) talking to a > set of portable auto scales through a Keyspan USB adapter > (in my past use of rxtx, I had actual serial ports, but those > days are long gone.) I have the keyspan kernel module loaded, > and lsusb shows the device as correctly identified. I'm missing > the bit of magic needed to get rxtx to provide the port > in response to CommPortIdentifier.getPortIdentifiers() > > thanks in advance for any help, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From rwelty at suespammers.org Wed Jul 19 20:05:18 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Wed, 19 Jul 2006 22:05:18 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <35101C10-59A5-4F02-AEEE-DB69112F8130@sympatico.ca> References: <44BEDDFA.7020108@averillpark.net> <35101C10-59A5-4F02-AEEE-DB69112F8130@sympatico.ca> Message-ID: <44BEE4DE.9080707@suespammers.org> Andr?-John Mas wrote: > Do you see an associated device in /dev ? Well, there are lots of /dev/ttyUSB devices, there, but nothing jumps out as having been assigned to the keyspan. But then, I'm not that knowledgable about the USB mapping here; this is the first time I've tried to use one this way and I'm on the steep part of the learning curve. richard From rwelty at suespammers.org Wed Jul 19 20:08:20 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Wed, 19 Jul 2006 22:08:20 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: References: <44BEDDFA.7020108@averillpark.net> Message-ID: <44BEE594.50402@suespammers.org> Tod E. Kurt wrote: > Then the USB driver can't find the 'keyspan' driver. If you're sure > you have this driver, then hotplug isn't working for some reason. > You could try running the command: Ok, it looks like the keyspan driver may be the problem; it's having some sort of problem loading it. I'll have to look into this further tomorrow night. thanks, richard From pascal at quies.net Wed Jul 19 20:11:21 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Thu, 20 Jul 2006 04:11:21 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEDFBD.4020404@ergotech.com> References: <44BED7CF.5080405@sun.com> <44BEDFBD.4020404@ergotech.com> Message-ID: <200607200411.22012.pascal@quies.net> Op donderdag 20 juli 2006 03:43, schreef Jim Redman: > Paul Klissner wrote: > > Pascal S. de Kloe wrote: > >> Op donderdag 20 juli 2006 02:03, schreef Jim Redman: > >>> Which perhaps brings us back to what are we trying to fix and how > >>> badly. > >> > >> The initail problem was the license. :) > >> > >> RXTX is sitting in this gnu.comm namespace and is afraid to go to > >> javax.comm. Getting a JSR would solve this problem. > >> > >> And while we're at it we might as well improve the situation with the > >> various platforms. I made some sugestions that where denied as too > >> complex. > > > > "Denied" is a bit harsh :) I'll re-examine your e-mails > > to see if my preferences change. It's not like your > > proposition has been put up to a formal vote, just discussion. > > OK, I'll officially float backwards compatibility in the form of "It > should be possible to use anything that comes out of the JSR in place of > an existing java comm implementation". > > I wonder if "Denied" is too harsh for that one :) > > Jim Hehehe. I don't have any troubles with people voting against my ideas at all so don't worry Paul. :) However, it is exactly the compatibilty thing where Jim is talking about what makes me want to make a *huge* change if any. From jredman at ergotech.com Wed Jul 19 20:25:50 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 20:25:50 -0600 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEE594.50402@suespammers.org> References: <44BEDDFA.7020108@averillpark.net> <44BEE594.50402@suespammers.org> Message-ID: <44BEE9AE.3030200@ergotech.com> Some who remembers this better than me please help. You also need something like: -Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3 When you start the application. This can be put in a properties files (where?). Jim Richard P. Welty wrote: > Tod E. Kurt wrote: > >> Then the USB driver can't find the 'keyspan' driver. If you're sure >> you have this driver, then hotplug isn't working for some reason. >> You could try running the command: > > Ok, it looks like the keyspan driver may be the problem; it's having > some sort of problem loading it. I'll have to look into this further > tomorrow night. > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From ajmas at sympatico.ca Wed Jul 19 20:32:52 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Wed, 19 Jul 2006 22:32:52 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEE9AE.3030200@ergotech.com> References: <44BEDDFA.7020108@averillpark.net> <44BEE594.50402@suespammers.org> <44BEE9AE.3030200@ergotech.com> Message-ID: Are you sure about this? I know on MacOS X no such configuration was needed. If this is indeed true, this is poor design, in this day and age of dynamic devices. On 19-Jul-06, at 22:25 , Jim Redman wrote: > Some who remembers this better than me please help. > > You also need something like: > > -Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyUSB0:/dev/ttyUSB1:/ > dev/ttyUSB2:/dev/ttyUSB3 > > When you start the application. This can be put in a properties files > (where?). > > Jim > > Richard P. Welty wrote: >> Tod E. Kurt wrote: >> >>> Then the USB driver can't find the 'keyspan' driver. If you're sure >>> you have this driver, then hotplug isn't working for some reason. >>> You could try running the command: >> >> Ok, it looks like the keyspan driver may be the problem; it's having >> some sort of problem loading it. I'll have to look into this further >> tomorrow night. >> >> thanks, >> richard >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Wed Jul 19 20:41:01 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Wed, 19 Jul 2006 22:41:01 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEE9AE.3030200@ergotech.com> References: <44BEDDFA.7020108@averillpark.net> <44BEE594.50402@suespammers.org> <44BEE9AE.3030200@ergotech.com> Message-ID: <44BEED3D.5020304@suespammers.org> Jim Redman wrote: > Some who remembers this better than me please help. > > You also need something like: > > -Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3 > > When you start the application. This can be put in a properties files > (where?). Thanks for all the help, guys. Thinking back on how this laptop came to be in its current state, I'm of the opinion a format and complete rebuild with a newer version of Fedora is in order before I waste any more time in diagnosis. The problems I'm seeing clearly have nothing to do with RXTX and everything to do with how many upgrades have been chained together getting this laptop from whereever I started (RH 7.0 or 7.1) to FC1. It could probably be fixed in place, but I shudder to think about the amount of time needed to figure out the proper fix. But the software I'm putting together will need to run on Y2K/XP and Mac OS X, so I'll be following portability and installer discussions on this list rather intently (http://scale-app.sourceforge.net for anyone who cares.) richard From Paul.Klissner at Sun.COM Wed Jul 19 22:53:53 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 21:53:53 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEE23B.30908@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> Message-ID: <44BF0C61.4020900@sun.com> Jim Redman wrote: > Paul, > > For the record we're STILL supporting some PersonalJava platforms. > We're _almost_ at the point where we can assume that the platforms will > have a Collections framework, but routinely compile with a 1.1 check so > that we don't make that assumption unnecessarily. Of 50+ non-graphical > Factory Automation JavaBeans we have 2 that require Java2 (Reporting and > JavaScripting), and we have people asking for a back-port. > > Embedded platforms don't change in a hurry. Unlike desktop platforms, > embedded systems are expected to last 5-10+ years. > > There are factory automation vendors in the pharmaceutical industry who > are buying systems on eBay because that's the FDA validate platform. It > must be that make/model, spec'd sometime in the mid-90's. > > So... If you make an incompatible change TODAY figure we can start using > that code _at the earliest_ somewhere around 2012 or the low teens. > > Are we _really_ the only people on the list supporting embedded/factory > automation platforms? > > Jim Do you provide your own implementation classes? Why can't you just continue to use 2.1 for the embedded platform until 2012 if you're locked down? Are you worried bugs won't get fixed? Sun might consider open sourcing the 2.1 Java source. I can't promise that, but it's been discussed and hasn't met resistance, except from me, because I wasn't super impressed with the code. I can probably be persuaded to champion open sourcing that and going through the process/legal machinations within Sun if it frees us to pursue a JSR for a new generation of javax.comm where we can have a chunk of common code in Open Source and each platform is simply responsible for it's platform specific plugins. I don't have many opinions about this set in stone because there are a lot of technical and pragmatic considerations such as yours the community has that I am probably not aware of or sufficiently sensitive to yet. I don't feel I really have the bird's eye view of all of this yet. The other thing is, I can only offer 10% of my time right now, according to my management, which is why I'm not pushing to be the spec lead for the JSR, and want only to be a participant to represent Sun's interests on the E.G. There is nothing sacred about Sun employees in the JCP as far as a JSR initiated by another entity is concerned. I am not the person everything needs to be cleared through. Ideas I have will pass or fail based on their merit and the community perception just like anyone else's. Paul > > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul Klissner wrote: >>>> I'd just like to find another suitable name than javax.comm, unless >>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>> 'major revisions' are accounted for. javax.serialport? >>> Which perhaps brings us back to what are we trying to fix and how badly. >> The goals I'm most interested in at the moment are: >> >> 1. A pluggable platform portmapping scheme wherein each platform >> can determine which ports to present to the application, and >> preferably as some configurable logical name. >> >> For example on the Sun Ray thin client platform, if an application >> aquiring a view of serial ports available on the system, it will >> be informed of Sun Ray serial ports if the application is running >> in a session currently directed to that particular Sun Ray unit, >> even though the serial port's device node happens to be server-side >> deeply nested in a leaf node. If the application is not running on >> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >> the decision about when and which ports to present to the application. >> >> 2. Pluggable driver-side interface where multiple platform-specific >> drivers can be utilized simultaneously to introduce more flexibility >> with the back end. >> >>> There are a number of 3rd party implementation of Java Comm, at least >>> one from IBM - part of what was J9, now Websphere, or something >>> (presumbly soon to get a name that has eclipse in it sometime soon). >>> Esmertec has one, and there are few others rolling around. >> I have not been advocating gutting the API, since much of it is >> perfectly adequate. I'm not totally opposed to making substantial >> changes or improvements depending on other people's needs. There's >> no reason previous versions of javax.comm need to suddenly disappear >> if products need legacy support. >> >> >>> If RXTX is the only implementation of the JSR with no backward >>> compatibility, we've just forked Java Serial support and we (for a least >>> one) will be worse off. We won't be able to use the new support because >>> of a lack of support on J2ME platforms that we have no control over and >>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>> other platforms. >> There can't be *that* many platforms this is ported to. And it will >> be no javax.usb. Seems like most of the standard platforms will >> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >> JDBC... >> >>> So, is there any chance of building a compatibility requirement into >>> this. To pick are really bad example JDBC has support for a DataSource >>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>> SerialPort on a class not found exception? >> Maybe, or maybe we just let people know what we are doing and >> try to figure out how to get their applications ported. Might not >> be that difficult. From my standpoint anyway, earthshaking >> changes aren't really necessary. Others might disagree. >> >> Paul >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From Paul.Klissner at Sun.COM Thu Jul 20 00:27:41 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 23:27:41 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BF0C61.4020900@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> Message-ID: <44BF225D.80104@sun.com> Paul Klissner wrote: > Jim Redman wrote: >> Paul, >> >> For the record we're STILL supporting some PersonalJava platforms. >> We're _almost_ at the point where we can assume that the platforms will >> have a Collections framework, but routinely compile with a 1.1 check so >> that we don't make that assumption unnecessarily. Of 50+ non-graphical >> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >> JavaScripting), and we have people asking for a back-port. >> >> Embedded platforms don't change in a hurry. Unlike desktop platforms, >> embedded systems are expected to last 5-10+ years. >> >> There are factory automation vendors in the pharmaceutical industry who >> are buying systems on eBay because that's the FDA validate platform. It >> must be that make/model, spec'd sometime in the mid-90's. >> >> So... If you make an incompatible change TODAY figure we can start using >> that code _at the earliest_ somewhere around 2012 or the low teens. >> >> Are we _really_ the only people on the list supporting embedded/factory >> automation platforms? >> >> Jim > > Do you provide your own implementation classes? > > Why can't you just continue to use 2.1 for the embedded platform until > 2012 if you're locked down? Are you worried bugs won't get fixed? > Sun might consider open sourcing the 2.1 Java source. Excuse me, I meant 2.0.3 > I can't promise > that, but it's been discussed and hasn't met resistance, except > from me, because I wasn't super impressed with the code. I can probably > be persuaded to champion open sourcing that and going through the > process/legal machinations within Sun if it frees us to pursue > a JSR for a new generation of javax.comm where we can have a chunk of > common code in Open Source and each platform is simply responsible > for it's platform specific plugins. > > I don't have many opinions about this set in stone because there > are a lot of technical and pragmatic considerations such as yours > the community has that I am probably not aware of or sufficiently > sensitive to yet. I don't feel I really have the bird's eye view > of all of this yet. > > The other thing is, I can only offer 10% of my time right now, > according to my management, which is why I'm not pushing to > be the spec lead for the JSR, and want only to be a participant > to represent Sun's interests on the E.G. There is nothing sacred > about Sun employees in the JCP as far as a JSR initiated by another > entity is concerned. I am not the person everything needs to be > cleared through. Ideas I have will pass or fail based on their > merit and the community perception just like anyone else's. > > Paul > >> Paul Klissner wrote: >>> Jim Redman wrote: >>>> Paul Klissner wrote: >>>>> I'd just like to find another suitable name than javax.comm, unless >>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>> 'major revisions' are accounted for. javax.serialport? >>>> Which perhaps brings us back to what are we trying to fix and how badly. >>> The goals I'm most interested in at the moment are: >>> >>> 1. A pluggable platform portmapping scheme wherein each platform >>> can determine which ports to present to the application, and >>> preferably as some configurable logical name. >>> >>> For example on the Sun Ray thin client platform, if an application >>> aquiring a view of serial ports available on the system, it will >>> be informed of Sun Ray serial ports if the application is running >>> in a session currently directed to that particular Sun Ray unit, >>> even though the serial port's device node happens to be server-side >>> deeply nested in a leaf node. If the application is not running on >>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>> the decision about when and which ports to present to the application. >>> >>> 2. Pluggable driver-side interface where multiple platform-specific >>> drivers can be utilized simultaneously to introduce more flexibility >>> with the back end. >>> >>>> There are a number of 3rd party implementation of Java Comm, at least >>>> one from IBM - part of what was J9, now Websphere, or something >>>> (presumbly soon to get a name that has eclipse in it sometime soon). >>>> Esmertec has one, and there are few others rolling around. >>> I have not been advocating gutting the API, since much of it is >>> perfectly adequate. I'm not totally opposed to making substantial >>> changes or improvements depending on other people's needs. There's >>> no reason previous versions of javax.comm need to suddenly disappear >>> if products need legacy support. >>> >>> >>>> If RXTX is the only implementation of the JSR with no backward >>>> compatibility, we've just forked Java Serial support and we (for a least >>>> one) will be worse off. We won't be able to use the new support because >>>> of a lack of support on J2ME platforms that we have no control over and >>>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>>> other platforms. >>> There can't be *that* many platforms this is ported to. And it will >>> be no javax.usb. Seems like most of the standard platforms will >>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>> JDBC... >>> >>>> So, is there any chance of building a compatibility requirement into >>>> this. To pick are really bad example JDBC has support for a DataSource >>>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>>> SerialPort on a class not found exception? >>> Maybe, or maybe we just let people know what we are doing and >>> try to figure out how to get their applications ported. Might not >>> be that difficult. From my standpoint anyway, earthshaking >>> changes aren't really necessary. Others might disagree. >>> >>> Paul >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Thu Jul 20 00:50:21 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 20 Jul 2006 08:50:21 +0200 Subject: [Rxtx] jcp and jsr Message-ID: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> Hi all, I work with SNIJDER Micro Systems. We're doing embedded Java and just heard about this discussion by way of Ted Kosan from the embedded Java community. We think Jim is right about the compatibility issues for embedded Java platforms. Our own embedded Java platform (see http://www.embedded-web.com ) uses a 3rd party implementation of javax.comm written by the JVM vendor. As Jim says, changes take much longer to propagate in the embedded space. If the 'new' javax.comm is not backwards compatible, embedded JVM vendors (esmertec, IBM, Tao Group, etc.) will probably evaluate whether it makes sense for them to support the new API. Some will eventually adopt it, but that will take time. Some will just stay with the current API, thus increasing the gap between embedded Java developers and desktop Java developers (different APIs to do the same thing) This is a very real problem in our opinion. Also taking into account that many desktop computers nowadays don't even have standard serial ports, I believe that the embedded Java community already gathers a significant share of the potential javax.comm users. I think backwards compatibility should be seriously considered. Best regards, Guillermo Jim Redman wrote: >Paul Klissner wrote: > > I'd just like to find another suitable name than javax.comm, unless > > the JSR wants to start with javax.comm 4.0, since all the previous > > 'major revisions' are accounted for. javax.serialport? > >Which perhaps brings us back to what are we trying to fix and how badly. > >There are a number of 3rd party implementation of Java Comm, at least >one from IBM - part of what was J9, now Websphere, or something >(presumbly soon to get a name that has eclipse in it sometime soon). >Esmertec has one, and there are few others rolling around. > >If RXTX is the only implementation of the JSR with no backward >compatibility, we've just forked Java Serial support and we (for a least >one) will be worse off. We won't be able to use the new support because >of a lack of support on J2ME platforms that we have no control over and >RXTX/current JavaComm will be in maintenance mode or unsupported on all >other platforms. > >So, is there any chance of building a compatibility requirement into >this. To pick are really bad example JDBC has support for a DataSource >or a Driver. Could we have an ExcellentSerialPort with a fallback to a >SerialPort on a class not found exception? > >Jim -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Thu Jul 20 00:57:04 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 20 Jul 2006 08:57:04 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> References: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> Message-ID: <7.0.1.0.0.20060720085221.036d88e8@sms.nl> Paul Klissner wrote: >Jim Redman wrote: > > Paul, > > > > For the record we're STILL supporting some PersonalJava platforms. > > We're _almost_ at the point where we can assume that the platforms will > > have a Collections framework, but routinely compile with a 1.1 check so > > that we don't make that assumption unnecessarily. Of 50+ non-graphical > > Factory Automation JavaBeans we have 2 that require Java2 (Reporting and > > JavaScripting), and we have people asking for a back-port. > > > > Embedded platforms don't change in a hurry. Unlike desktop platforms, > > embedded systems are expected to last 5-10+ years. > > > > There are factory automation vendors in the pharmaceutical industry who > > are buying systems on eBay because that's the FDA validate platform. It > > must be that make/model, spec'd sometime in the mid-90's. > > > > So... If you make an incompatible change TODAY figure we can start using > > that code _at the earliest_ somewhere around 2012 or the low teens. > > > > Are we _really_ the only people on the list supporting embedded/factory > > automation platforms? > > > > Jim > >Do you provide your own implementation classes? > >Why can't you just continue to use 2.1 for the embedded platform until >2012 if you're locked down? Are you worried bugs won't get fixed? If embedded platforms keep using the "old" (current) javax.comm API but the desktop Java world starts to use a new, backwards-incompatible API, then this will result in more trouble for embedded Java application developers as they will no longer be able to use the same API on desktop systems and embedded platforms. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Thu Jul 20 00:59:16 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 20 Jul 2006 08:59:16 +0200 Subject: [Rxtx] jcp and jsr Message-ID: <7.0.1.0.0.20060720085812.036d9c28@sms.nl> Pascal S. de Kloe wrote: >Who is participating anyway? Is it just the four of us? > >Cheers, > >Pascal We would be more than happy to participate if we can be of any help. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From Paul.Klissner at Sun.COM Thu Jul 20 02:23:42 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Thu, 20 Jul 2006 01:23:42 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <7.0.1.0.0.20060720085221.036d88e8@sms.nl> References: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> <7.0.1.0.0.20060720085221.036d88e8@sms.nl> Message-ID: <44BF3D8E.4030705@sun.com> Guillermo Rodriguez Garcia wrote: > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul, >>> >>> For the record we're STILL supporting some PersonalJava platforms. >>> We're _almost_ at the point where we can assume that the platforms will >>> have a Collections framework, but routinely compile with a 1.1 check so >>> that we don't make that assumption unnecessarily. Of 50+ non-graphical >>> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >>> JavaScripting), and we have people asking for a back-port. >>> >>> Embedded platforms don't change in a hurry. Unlike desktop platforms, >>> embedded systems are expected to last 5-10+ years. >>> >>> There are factory automation vendors in the pharmaceutical industry who >>> are buying systems on eBay because that's the FDA validate platform. It >>> must be that make/model, spec'd sometime in the mid-90's. >>> >>> So... If you make an incompatible change TODAY figure we can start using >>> that code _at the earliest_ somewhere around 2012 or the low teens. >>> >>> Are we _really_ the only people on the list supporting embedded/factory >>> automation platforms? >>> >>> Jim >> Do you provide your own implementation classes? >> >> Why can't you just continue to use 2.1 for the embedded platform until >> 2012 if you're locked down? Are you worried bugs won't get fixed? > > If embedded platforms keep using the "old" (current) javax.comm API but > the desktop Java world starts to use a new, backwards-incompatible API, > then this will result in more trouble for embedded Java application > developers as they will no longer be able to use the same API on desktop > systems and embedded platforms. OK, I understand the situation more clearly now. The kinds of changes I'm opting don't seem difficult to design in a backward compatible way. I haven't scrutinized the other requests on the list. I guess it will be interesting to hear what the proponents for other changes have to say. Paul > > Guillermo > > -- > Guillermo Rodriguez Garcia > > Snijder Micro Systems phone +31-493-351020 > G. Rodriguez Garcia fax +31-493-351530 > Visser 25 email guille at sms.nl > NL5751 BL Deurne > The Netherlands http://www.snijder.com > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jul 20 02:46:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 20 Jul 2006 10:46:09 +0200 Subject: [Rxtx] quo vadis API/namespace (Re: jcp and jsr) In-Reply-To: <44BEDC4F.9030403@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> Message-ID: Paul, for the first time in many months, I have the impression, that we have the same agenda;-) If the "driver-level"-api changes however "nobody" will be disappointed. However, regarding the user-level-api I disagree. As fundamental changes to the API have been suggested several times I must be ignoring something. I would be delighted to learn were the current API fails - i.e. what can not be done or is overly complex based on the current API. Of course it is better fun to start something from scratch, but unless there are really substantial gains from completely redesigning an API I don't see the point. The promise of Java is to write once (which I interpret as write against the same API for all platforms). Getting VM providers like esmertec to support a new/replacement API is not a simple task, it requires a business case which for the biggest part simply does not exist. If we keep the javax.comm namespace and keep the "user-level"-api a superset of the current PortIdentifier/Port-api, the same application can work against javax.comm 2.0/3.0/future.x. Of course a factory/wrapping approach can always unify different APIs but this adds more implementation/ testing complexity to every application. So in short: Unless we find a strong argument why javax.comm can't be used I prefer that we keep it. Unless we find a strong feature / use- case that can not be handled with (an extension of) the current CommPort/CommPortIndentifier I'd prefer to keep that as well. Regards, Joachim On 20.07.2006, at 03:28, Paul Klissner wrote: > The goals I'm most interested in at the moment are: > > 1. A pluggable platform portmapping scheme wherein each platform > can determine which ports to present to the application, and > preferably as some configurable logical name. > > For example on the Sun Ray thin client platform, if an application > aquiring a view of serial ports available on the system, it will > be informed of Sun Ray serial ports if the application is running > in a session currently directed to that particular Sun Ray unit, > even though the serial port's device node happens to be server-side > deeply nested in a leaf node. If the application is not running on > a Sun Ray the port doesn't show up. The Sun Ray plugin would make > the decision about when and which ports to present to the application. > > 2. Pluggable driver-side interface where multiple platform-specific > drivers can be utilized simultaneously to introduce more flexibility > with the back end. > >> There are a number of 3rd party implementation of Java Comm, at least >> one from IBM - part of what was J9, now Websphere, or something >> (presumbly soon to get a name that has eclipse in it sometime soon). >> Esmertec has one, and there are few others rolling around. > > I have not been advocating gutting the API, since much of it is > perfectly adequate. I'm not totally opposed to making substantial > changes or improvements depending on other people's needs. There's > no reason previous versions of javax.comm need to suddenly disappear > if products need legacy support. > > >> >> If RXTX is the only implementation of the JSR with no backward >> compatibility, we've just forked Java Serial support and we (for a >> least >> one) will be worse off. We won't be able to use the new support >> because >> of a lack of support on J2ME platforms that we have no control >> over and >> RXTX/current JavaComm will be in maintenance mode or unsupported >> on all >> other platforms. > > There can't be *that* many platforms this is ported to. And it will > be no javax.usb. Seems like most of the standard platforms will > be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, > JDBC... > >> >> So, is there any chance of building a compatibility requirement into >> this. To pick are really bad example JDBC has support for a >> DataSource >> or a Driver. Could we have an ExcellentSerialPort with a fallback >> to a >> SerialPort on a class not found exception? > > Maybe, or maybe we just let people know what we are doing and > try to figure out how to get their applications ported. Might not > be that difficult. From my standpoint anyway, earthshaking > changes aren't really necessary. Others might disagree. > > Paul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Luis.Moreira at jet.uk Thu Jul 20 03:56:38 2006 From: Luis.Moreira at jet.uk (Luis Moreira) Date: Thu, 20 Jul 2006 10:56:38 +0100 Subject: [Rxtx] problems with setting up Rxtx Message-ID: Hi Guys, I have just joined the list and I am very new to JAVA. I am investigating serial communications and I just realised that the JAVAX.COMM package does not support windows anymore. I then looked at alternatives and the RXTX package came up. The problem I have at the moment is not using the classes but, rather how to install RXTX package so that I can use the classes, what do I need to install to support it and how if I write a program using it, do I make it portable. Best regards Luis From lyon at docjava.com Thu Jul 20 07:16:55 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 20 Jul 2006 09:16:55 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> Message-ID: Hi All, There has been some discussion about plugins for serial communications. As I see it, what Java really needs is a NativeLibraryManager. This is a rather much larger charge than "just" RXTX. The RXTX basic mode of operation is that we associate static blocks of code with a "System.load". Failure occurs when the class containing such a block of code is loaded AND the native library is not found. What are some of the options? 1. Do nothing, let the program fail with an exception. 2. try to catch an UnsatisfiedLinkError as a part of making the driver. 3. Search the java.library.path to see if the driver is present (i.e., guard the input). 4. Other?? In the case of either step 2 or 3, we need to fix the lack of a library. What are the options for fixing a library? 1. Do nothing, but give the user an interesting error with instructions on what to do. 2. Attempt to find the library on the file system (perhaps with user help). 3. Attempt to download the library and install it (perhaps with user permission). 4. Attempt to internalize the library as a UUEncoded serialized object and install it (better ask the user, again!). 5. Other?? My attempts at making RXTX more robust on install have led to mixed results. Altering the java.library.path has led to a bit of byte-code engineering (as this is loaded at JVM start time). Internalizing of libraries is attractive, until you realize how many libraries are involved. Dyanmically changing libraries during development is very attractive, for developers, who are changing libraries often. It is also very interesting for those who want to control the version of the libraries in the run-time. For example, something like the following will guard the input to the system load: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getInstance() { if (driver != null) return driver; if (!NativeLibDetect.isLibInPath("rxtxSerial")) fixDriver(); if (NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } At the other extreme, something like: try { System.load("rxtxSerial"); } catch (UnsatisfiedLinkError e) { System.out.println("could not load lib"); } Will at least attempt to handle the missing lib, in a simple way. Perhaps some error handling is better than none. To fix the driver, I can beam it down from a web page, using: private static void fixDriver() { File tmpDir = new File( SystemUtils.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); try { UrlUtils.getUrl(getResourceUrl(), tmpDir); String nativeLib = getNativeLibName(); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(nativeLib); if (b == null) { System.out.println("could not get:" + nativeLib); return; } File f = getRxtxHome(); Futil.writeBytes(getRxtxLibFile(), b); SystemUtils.appendJavaLibraryPath(f); } catch (IOException e) { e.printStackTrace(); } } Where the libraries are stored in the hacky dispatch: private static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isMacOs()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); System.out.println("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } Appending to the library path is tricky, at run-time: public static void appendJavaLibraryPath(File p) { if (p.isFile()) System.out.println("warning: appendJavaLibraryPath:" + "only directories are findable:"+p); System.out.println("appending:"+p+" to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:"+System.getProperty(javaLibraryPa th)); } The key is altering the core visibility of the sys_paths in the class loader: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } No, it isn't simple (nor even easy) but once the API is set we have a kind of NativeLibraryManager that helps us to make libraries, like RXTX more robust. As far as I know, there is nothing quite like it (unless you all know differently). Is there any interest in this? Forgive me if this is too far off the beaten path, but the inability to load a native library remains a source of fragility in the RXTX system, IMHO. Thanks for your thoughts! - Doug From jredman at ergotech.com Thu Jul 20 08:06:41 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 20 Jul 2006 08:06:41 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BF0C61.4020900@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> Message-ID: <44BF8DF1.4040101@ergotech.com> Paul, The issue with a new, incompatible implementation is, as you've identified below, is support for the old API. Open sourcing would be helpful, but then someone (us?) would have to maintain the source through changing versions of Window, and RXTX on Linux platforms. Or we'd have to have to versions of our codebase, which doesn't appeal too much. The maintenance issue is not impossible, but I think that in essence I'm agreeing with a comment you made earlier. IF a huge change is required, then lets get on with it. However, if the changes that are required are just extensions and enhancements, with some low-level re-engineering, then can we keep a compatible high-level API so that people needing the new features can use an extended API and those who need cross-platform compatibility can continue to use the existing features. Jim Paul Klissner wrote: > Jim Redman wrote: >> Paul, >> >> For the record we're STILL supporting some PersonalJava platforms. >> We're _almost_ at the point where we can assume that the platforms will >> have a Collections framework, but routinely compile with a 1.1 check so >> that we don't make that assumption unnecessarily. Of 50+ non-graphical >> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >> JavaScripting), and we have people asking for a back-port. >> >> Embedded platforms don't change in a hurry. Unlike desktop platforms, >> embedded systems are expected to last 5-10+ years. >> >> There are factory automation vendors in the pharmaceutical industry who >> are buying systems on eBay because that's the FDA validate platform. It >> must be that make/model, spec'd sometime in the mid-90's. >> >> So... If you make an incompatible change TODAY figure we can start using >> that code _at the earliest_ somewhere around 2012 or the low teens. >> >> Are we _really_ the only people on the list supporting embedded/factory >> automation platforms? >> >> Jim > > Do you provide your own implementation classes? > > Why can't you just continue to use 2.1 for the embedded platform until > 2012 if you're locked down? Are you worried bugs won't get fixed? > Sun might consider open sourcing the 2.1 Java source. I can't promise > that, but it's been discussed and hasn't met resistance, except > from me, because I wasn't super impressed with the code. I can probably > be persuaded to champion open sourcing that and going through the > process/legal machinations within Sun if it frees us to pursue > a JSR for a new generation of javax.comm where we can have a chunk of > common code in Open Source and each platform is simply responsible > for it's platform specific plugins. > > I don't have many opinions about this set in stone because there > are a lot of technical and pragmatic considerations such as yours > the community has that I am probably not aware of or sufficiently > sensitive to yet. I don't feel I really have the bird's eye view > of all of this yet. > > The other thing is, I can only offer 10% of my time right now, > according to my management, which is why I'm not pushing to > be the spec lead for the JSR, and want only to be a participant > to represent Sun's interests on the E.G. There is nothing sacred > about Sun employees in the JCP as far as a JSR initiated by another > entity is concerned. I am not the person everything needs to be > cleared through. Ideas I have will pass or fail based on their > merit and the community perception just like anyone else's. > > Paul > >> Paul Klissner wrote: >>> Jim Redman wrote: >>>> Paul Klissner wrote: >>>>> I'd just like to find another suitable name than javax.comm, unless >>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>> 'major revisions' are accounted for. javax.serialport? >>>> Which perhaps brings us back to what are we trying to fix and how badly. >>> The goals I'm most interested in at the moment are: >>> >>> 1. A pluggable platform portmapping scheme wherein each platform >>> can determine which ports to present to the application, and >>> preferably as some configurable logical name. >>> >>> For example on the Sun Ray thin client platform, if an application >>> aquiring a view of serial ports available on the system, it will >>> be informed of Sun Ray serial ports if the application is running >>> in a session currently directed to that particular Sun Ray unit, >>> even though the serial port's device node happens to be server-side >>> deeply nested in a leaf node. If the application is not running on >>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>> the decision about when and which ports to present to the application. >>> >>> 2. Pluggable driver-side interface where multiple platform-specific >>> drivers can be utilized simultaneously to introduce more flexibility >>> with the back end. >>> >>>> There are a number of 3rd party implementation of Java Comm, at least >>>> one from IBM - part of what was J9, now Websphere, or something >>>> (presumbly soon to get a name that has eclipse in it sometime soon). >>>> Esmertec has one, and there are few others rolling around. >>> I have not been advocating gutting the API, since much of it is >>> perfectly adequate. I'm not totally opposed to making substantial >>> changes or improvements depending on other people's needs. There's >>> no reason previous versions of javax.comm need to suddenly disappear >>> if products need legacy support. >>> >>> >>>> If RXTX is the only implementation of the JSR with no backward >>>> compatibility, we've just forked Java Serial support and we (for a least >>>> one) will be worse off. We won't be able to use the new support because >>>> of a lack of support on J2ME platforms that we have no control over and >>>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>>> other platforms. >>> There can't be *that* many platforms this is ported to. And it will >>> be no javax.usb. Seems like most of the standard platforms will >>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>> JDBC... >>> >>>> So, is there any chance of building a compatibility requirement into >>>> this. To pick are really bad example JDBC has support for a DataSource >>>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>>> SerialPort on a class not found exception? >>> Maybe, or maybe we just let people know what we are doing and >>> try to figure out how to get their applications ported. Might not >>> be that difficult. From my standpoint anyway, earthshaking >>> changes aren't really necessary. Others might disagree. >>> >>> Paul >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Paul.Klissner at Sun.COM Thu Jul 20 09:31:38 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Thu, 20 Jul 2006 08:31:38 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BF8DF1.4040101@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> <44BF8DF1.4040101@ergotech.com> Message-ID: <44BFA1DA.10301@sun.com> Jim Redman wrote: > Paul, > > The issue with a new, incompatible implementation is, as you've > identified below, is support for the old API. Open sourcing would be > helpful, but then someone (us?) would have to maintain the source > through changing versions of Window, and RXTX on Linux platforms. Or > we'd have to have to versions of our codebase, which doesn't appeal too > much. > > The maintenance issue is not impossible, but I think that in essence I'm > agreeing with a comment you made earlier. > > IF a huge change is required, then lets get on with it. However, if the > changes that are required are just extensions and enhancements, with > some low-level re-engineering, then can we keep a compatible high-level > API so that people needing the new features can use an extended API and > those who need cross-platform compatibility can continue to use the > existing features. > > Jim Guillermo made a crystal clear case and I understand the problem that that will be caused by forking the API in any sense of the word. I only want to uphold Sun's interests and resolve the problems we ran into with the RXTX community when Sun added portmapping to 3.0, which was not easily undone and was implemented as kind of a hack because it wasn't directly supported by the javax.comm architection. As I mentioned previously the changes I want to make have primarily to do with adding platform-specific portmapping via plugins, and supporting multiple javax.comm backend drivers on the same host (some ports would use one driver, others ports might use another). Also I'd like to address some bugfixes that were done in Sun's version 3.0 (including better error reporting, and more robust code for locating configuration files). Besides that, I'm not aware of any deficiences, but I've glanced other e-mails where people have suggested some. It would be good to get a summary of everyone's wishes. I've stated mine. I given much thought to what it would take to properly address EIA-422, EIA-423 and EIA-485 (if any); but those would probably be extensions. Sounds like the differences might be transparent to the API. I'll look into that more. Paul > > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul, >>> >>> For the record we're STILL supporting some PersonalJava platforms. >>> We're _almost_ at the point where we can assume that the platforms will >>> have a Collections framework, but routinely compile with a 1.1 check so >>> that we don't make that assumption unnecessarily. Of 50+ non-graphical >>> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >>> JavaScripting), and we have people asking for a back-port. >>> >>> Embedded platforms don't change in a hurry. Unlike desktop platforms, >>> embedded systems are expected to last 5-10+ years. >>> >>> There are factory automation vendors in the pharmaceutical industry who >>> are buying systems on eBay because that's the FDA validate platform. It >>> must be that make/model, spec'd sometime in the mid-90's. >>> >>> So... If you make an incompatible change TODAY figure we can start using >>> that code _at the earliest_ somewhere around 2012 or the low teens. >>> >>> Are we _really_ the only people on the list supporting embedded/factory >>> automation platforms? >>> >>> Jim >> Do you provide your own implementation classes? >> >> Why can't you just continue to use 2.1 for the embedded platform until >> 2012 if you're locked down? Are you worried bugs won't get fixed? >> Sun might consider open sourcing the 2.1 Java source. I can't promise >> that, but it's been discussed and hasn't met resistance, except >> from me, because I wasn't super impressed with the code. I can probably >> be persuaded to champion open sourcing that and going through the >> process/legal machinations within Sun if it frees us to pursue >> a JSR for a new generation of javax.comm where we can have a chunk of >> common code in Open Source and each platform is simply responsible >> for it's platform specific plugins. >> >> I don't have many opinions about this set in stone because there >> are a lot of technical and pragmatic considerations such as yours >> the community has that I am probably not aware of or sufficiently >> sensitive to yet. I don't feel I really have the bird's eye view >> of all of this yet. >> >> The other thing is, I can only offer 10% of my time right now, >> according to my management, which is why I'm not pushing to >> be the spec lead for the JSR, and want only to be a participant >> to represent Sun's interests on the E.G. There is nothing sacred >> about Sun employees in the JCP as far as a JSR initiated by another >> entity is concerned. I am not the person everything needs to be >> cleared through. Ideas I have will pass or fail based on their >> merit and the community perception just like anyone else's. >> >> Paul >> >>> Paul Klissner wrote: >>>> Jim Redman wrote: >>>>> Paul Klissner wrote: >>>>>> I'd just like to find another suitable name than javax.comm, unless >>>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>>> 'major revisions' are accounted for. javax.serialport? >>>>> Which perhaps brings us back to what are we trying to fix and how badly. >>>> The goals I'm most interested in at the moment are: >>>> >>>> 1. A pluggable platform portmapping scheme wherein each platform >>>> can determine which ports to present to the application, and >>>> preferably as some configurable logical name. >>>> >>>> For example on the Sun Ray thin client platform, if an application >>>> aquiring a view of serial ports available on the system, it will >>>> be informed of Sun Ray serial ports if the application is running >>>> in a session currently directed to that particular Sun Ray unit, >>>> even though the serial port's device node happens to be server-side >>>> deeply nested in a leaf node. If the application is not running on >>>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>>> the decision about when and which ports to present to the application. >>>> >>>> 2. Pluggable driver-side interface where multiple platform-specific >>>> drivers can be utilized simultaneously to introduce more flexibility >>>> with the back end. >>>> >>>>> There are a number of 3rd party implementation of Java Comm, at least >>>>> one from IBM - part of what was J9, now Websphere, or something >>>>> (presumbly soon to get a name that has eclipse in it sometime soon). >>>>> Esmertec has one, and there are few others rolling around. >>>> I have not been advocating gutting the API, since much of it is >>>> perfectly adequate. I'm not totally opposed to making substantial >>>> changes or improvements depending on other people's needs. There's >>>> no reason previous versions of javax.comm need to suddenly disappear >>>> if products need legacy support. >>>> >>>> >>>>> If RXTX is the only implementation of the JSR with no backward >>>>> compatibility, we've just forked Java Serial support and we (for a least >>>>> one) will be worse off. We won't be able to use the new support because >>>>> of a lack of support on J2ME platforms that we have no control over and >>>>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>>>> other platforms. >>>> There can't be *that* many platforms this is ported to. And it will >>>> be no javax.usb. Seems like most of the standard platforms will >>>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>>> JDBC... >>>> >>>>> So, is there any chance of building a compatibility requirement into >>>>> this. To pick are really bad example JDBC has support for a DataSource >>>>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>>>> SerialPort on a class not found exception? >>>> Maybe, or maybe we just let people know what we are doing and >>>> try to figure out how to get their applications ported. Might not >>>> be that difficult. From my standpoint anyway, earthshaking >>>> changes aren't really necessary. Others might disagree. >>>> >>>> Paul >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From Paul.Klissner at Sun.COM Thu Jul 20 09:45:11 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Thu, 20 Jul 2006 08:45:11 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BFA1DA.10301@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> <44BF8DF1.4040101@ergotech.com> <44BFA1DA.10301@sun.com> Message-ID: <44BFA507.3020001@sun.com> Paul Klissner wrote: > Jim Redman wrote: >> Paul, >> >> The issue with a new, incompatible implementation is, as you've >> identified below, is support for the old API. Open sourcing would be >> helpful, but then someone (us?) would have to maintain the source >> through changing versions of Window, and RXTX on Linux platforms. Or >> we'd have to have to versions of our codebase, which doesn't appeal >> too much. >> >> The maintenance issue is not impossible, but I think that in essence >> I'm agreeing with a comment you made earlier. >> >> IF a huge change is required, then lets get on with it. However, if >> the changes that are required are just extensions and enhancements, >> with some low-level re-engineering, then can we keep a compatible >> high-level API so that people needing the new features can use an >> extended API and those who need cross-platform compatibility can >> continue to use the existing features. >> >> Jim > > Guillermo made a crystal clear case and I understand the problem > that that will be caused by forking the API in any sense of the > word. I only want to uphold Sun's interests and resolve the problems > we ran into with the RXTX community when Sun added portmapping > to 3.0, which was not easily undone and was implemented as kind > of a hack because it wasn't directly supported by the javax.comm > architection. ^^^"architecture" > > As I mentioned previously the changes I want to make have primarily > to do with adding platform-specific portmapping via plugins, > and supporting multiple javax.comm backend drivers on the same > host (some ports would use one driver, others ports might use another). > > Also I'd like to address some bugfixes that were done in Sun's > version 3.0 (including better error reporting, and more robust > code for locating configuration files). Besides that, I'm not > aware of any deficiences, but I've glanced other e-mails where > people have suggested some. It would be good to get a summary > of everyone's wishes. I've stated mine. > > I given much thought to what it would take to properly address ^^^haven't > EIA-422, EIA-423 and EIA-485 (if any); but those would > probably be extensions. Sounds like the differences might > be transparent to the API. I'll look into that more. > > Paul > > >> >> Paul Klissner wrote: >>> Jim Redman wrote: >>>> Paul, >>>> >>>> For the record we're STILL supporting some PersonalJava platforms. >>>> We're _almost_ at the point where we can assume that the platforms >>>> will have a Collections framework, but routinely compile with a 1.1 >>>> check so that we don't make that assumption unnecessarily. Of 50+ >>>> non-graphical Factory Automation JavaBeans we have 2 that require >>>> Java2 (Reporting and JavaScripting), and we have people asking for a >>>> back-port. >>>> >>>> Embedded platforms don't change in a hurry. Unlike desktop >>>> platforms, embedded systems are expected to last 5-10+ years. >>>> >>>> There are factory automation vendors in the pharmaceutical industry >>>> who are buying systems on eBay because that's the FDA validate >>>> platform. It must be that make/model, spec'd sometime in the mid-90's. >>>> >>>> So... If you make an incompatible change TODAY figure we can start >>>> using that code _at the earliest_ somewhere around 2012 or the low >>>> teens. >>>> >>>> Are we _really_ the only people on the list supporting >>>> embedded/factory automation platforms? >>>> >>>> Jim >>> Do you provide your own implementation classes? >>> >>> Why can't you just continue to use 2.1 for the embedded platform until >>> 2012 if you're locked down? Are you worried bugs won't get fixed? >>> Sun might consider open sourcing the 2.1 Java source. I can't promise >>> that, but it's been discussed and hasn't met resistance, except >>> from me, because I wasn't super impressed with the code. I can probably >>> be persuaded to champion open sourcing that and going through the >>> process/legal machinations within Sun if it frees us to pursue >>> a JSR for a new generation of javax.comm where we can have a chunk of >>> common code in Open Source and each platform is simply responsible >>> for it's platform specific plugins. >>> >>> I don't have many opinions about this set in stone because there >>> are a lot of technical and pragmatic considerations such as yours >>> the community has that I am probably not aware of or sufficiently >>> sensitive to yet. I don't feel I really have the bird's eye view >>> of all of this yet. >>> >>> The other thing is, I can only offer 10% of my time right now, >>> according to my management, which is why I'm not pushing to >>> be the spec lead for the JSR, and want only to be a participant >>> to represent Sun's interests on the E.G. There is nothing sacred >>> about Sun employees in the JCP as far as a JSR initiated by another >>> entity is concerned. I am not the person everything needs to be >>> cleared through. Ideas I have will pass or fail based on their >>> merit and the community perception just like anyone else's. >>> >>> Paul >>> >>>> Paul Klissner wrote: >>>>> Jim Redman wrote: >>>>>> Paul Klissner wrote: >>>>>>> I'd just like to find another suitable name than javax.comm, unless >>>>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>>>> 'major revisions' are accounted for. javax.serialport? >>>>>> Which perhaps brings us back to what are we trying to fix and how >>>>>> badly. >>>>> The goals I'm most interested in at the moment are: >>>>> >>>>> 1. A pluggable platform portmapping scheme wherein each platform >>>>> can determine which ports to present to the application, and >>>>> preferably as some configurable logical name. >>>>> >>>>> For example on the Sun Ray thin client platform, if an application >>>>> aquiring a view of serial ports available on the system, it will >>>>> be informed of Sun Ray serial ports if the application is running >>>>> in a session currently directed to that particular Sun Ray unit, >>>>> even though the serial port's device node happens to be server-side >>>>> deeply nested in a leaf node. If the application is not running on >>>>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>>>> the decision about when and which ports to present to the application. >>>>> >>>>> 2. Pluggable driver-side interface where multiple platform-specific >>>>> drivers can be utilized simultaneously to introduce more flexibility >>>>> with the back end. >>>>> >>>>>> There are a number of 3rd party implementation of Java Comm, at >>>>>> least one from IBM - part of what was J9, now Websphere, or >>>>>> something (presumbly soon to get a name that has eclipse in it >>>>>> sometime soon). Esmertec has one, and there are few others rolling >>>>>> around. >>>>> I have not been advocating gutting the API, since much of it is >>>>> perfectly adequate. I'm not totally opposed to making substantial >>>>> changes or improvements depending on other people's needs. There's >>>>> no reason previous versions of javax.comm need to suddenly disappear >>>>> if products need legacy support. >>>>> >>>>> >>>>>> If RXTX is the only implementation of the JSR with no backward >>>>>> compatibility, we've just forked Java Serial support and we (for a >>>>>> least one) will be worse off. We won't be able to use the new >>>>>> support because of a lack of support on J2ME platforms that we >>>>>> have no control over and RXTX/current JavaComm will be in >>>>>> maintenance mode or unsupported on all other platforms. >>>>> There can't be *that* many platforms this is ported to. And it will >>>>> be no javax.usb. Seems like most of the standard platforms will >>>>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>>>> JDBC... >>>>> >>>>>> So, is there any chance of building a compatibility requirement >>>>>> into this. To pick are really bad example JDBC has support for a >>>>>> DataSource or a Driver. Could we have an ExcellentSerialPort with >>>>>> a fallback to a SerialPort on a class not found exception? >>>>> Maybe, or maybe we just let people know what we are doing and >>>>> try to figure out how to get their applications ported. Might not >>>>> be that difficult. From my standpoint anyway, earthshaking >>>>> changes aren't really necessary. Others might disagree. >>>>> >>>>> Paul >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From jredman at ergotech.com Thu Jul 20 10:30:01 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 20 Jul 2006 10:30:01 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BFA507.3020001@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> <44BF8DF1.4040101@ergotech.com> <44BFA1DA.10301@sun.com> <44BFA507.3020001@sun.com> Message-ID: <44BFAF89.5010003@ergotech.com> Thast what hapens if you post late at nihgt nad erly in the moning as wel. :) Paul Klissner wrote: > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul, >>> >>> The issue with a new, incompatible implementation is, as you've >>> identified below, is support for the old API. Open sourcing would be >>> helpful, but then someone (us?) would have to maintain the source >>> through changing versions of Window, and RXTX on Linux platforms. Or >>> we'd have to have to versions of our codebase, which doesn't appeal >>> too much. >>> >>> The maintenance issue is not impossible, but I think that in essence >>> I'm agreeing with a comment you made earlier. >>> >>> IF a huge change is required, then lets get on with it. However, if >>> the changes that are required are just extensions and enhancements, >>> with some low-level re-engineering, then can we keep a compatible >>> high-level API so that people needing the new features can use an >>> extended API and those who need cross-platform compatibility can >>> continue to use the existing features. >>> >>> Jim >> Guillermo made a crystal clear case and I understand the problem >> that that will be caused by forking the API in any sense of the >> word. I only want to uphold Sun's interests and resolve the problems >> we ran into with the RXTX community when Sun added portmapping >> to 3.0, which was not easily undone and was implemented as kind >> of a hack because it wasn't directly supported by the javax.comm >> architection. > ^^^"architecture" >> As I mentioned previously the changes I want to make have primarily >> to do with adding platform-specific portmapping via plugins, >> and supporting multiple javax.comm backend drivers on the same >> host (some ports would use one driver, others ports might use another). >> >> Also I'd like to address some bugfixes that were done in Sun's >> version 3.0 (including better error reporting, and more robust >> code for locating configuration files). Besides that, I'm not >> aware of any deficiences, but I've glanced other e-mails where >> people have suggested some. It would be good to get a summary >> of everyone's wishes. I've stated mine. >> >> I given much thought to what it would take to properly address > ^^^haven't >> EIA-422, EIA-423 and EIA-485 (if any); but those would >> probably be extensions. Sounds like the differences might >> be transparent to the API. I'll look into that more. >> >> Paul >> >> >>> Paul Klissner wrote: >>>> Jim Redman wrote: >>>>> Paul, >>>>> >>>>> For the record we're STILL supporting some PersonalJava platforms. >>>>> We're _almost_ at the point where we can assume that the platforms >>>>> will have a Collections framework, but routinely compile with a 1.1 >>>>> check so that we don't make that assumption unnecessarily. Of 50+ >>>>> non-graphical Factory Automation JavaBeans we have 2 that require >>>>> Java2 (Reporting and JavaScripting), and we have people asking for a >>>>> back-port. >>>>> >>>>> Embedded platforms don't change in a hurry. Unlike desktop >>>>> platforms, embedded systems are expected to last 5-10+ years. >>>>> >>>>> There are factory automation vendors in the pharmaceutical industry >>>>> who are buying systems on eBay because that's the FDA validate >>>>> platform. It must be that make/model, spec'd sometime in the mid-90's. >>>>> >>>>> So... If you make an incompatible change TODAY figure we can start >>>>> using that code _at the earliest_ somewhere around 2012 or the low >>>>> teens. >>>>> >>>>> Are we _really_ the only people on the list supporting >>>>> embedded/factory automation platforms? >>>>> >>>>> Jim >>>> Do you provide your own implementation classes? >>>> >>>> Why can't you just continue to use 2.1 for the embedded platform until >>>> 2012 if you're locked down? Are you worried bugs won't get fixed? >>>> Sun might consider open sourcing the 2.1 Java source. I can't promise >>>> that, but it's been discussed and hasn't met resistance, except >>>> from me, because I wasn't super impressed with the code. I can probably >>>> be persuaded to champion open sourcing that and going through the >>>> process/legal machinations within Sun if it frees us to pursue >>>> a JSR for a new generation of javax.comm where we can have a chunk of >>>> common code in Open Source and each platform is simply responsible >>>> for it's platform specific plugins. >>>> >>>> I don't have many opinions about this set in stone because there >>>> are a lot of technical and pragmatic considerations such as yours >>>> the community has that I am probably not aware of or sufficiently >>>> sensitive to yet. I don't feel I really have the bird's eye view >>>> of all of this yet. >>>> >>>> The other thing is, I can only offer 10% of my time right now, >>>> according to my management, which is why I'm not pushing to >>>> be the spec lead for the JSR, and want only to be a participant >>>> to represent Sun's interests on the E.G. There is nothing sacred >>>> about Sun employees in the JCP as far as a JSR initiated by another >>>> entity is concerned. I am not the person everything needs to be >>>> cleared through. Ideas I have will pass or fail based on their >>>> merit and the community perception just like anyone else's. >>>> >>>> Paul >>>> >>>>> Paul Klissner wrote: >>>>>> Jim Redman wrote: >>>>>>> Paul Klissner wrote: >>>>>>>> I'd just like to find another suitable name than javax.comm, unless >>>>>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>>>>> 'major revisions' are accounted for. javax.serialport? >>>>>>> Which perhaps brings us back to what are we trying to fix and how >>>>>>> badly. >>>>>> The goals I'm most interested in at the moment are: >>>>>> >>>>>> 1. A pluggable platform portmapping scheme wherein each platform >>>>>> can determine which ports to present to the application, and >>>>>> preferably as some configurable logical name. >>>>>> >>>>>> For example on the Sun Ray thin client platform, if an application >>>>>> aquiring a view of serial ports available on the system, it will >>>>>> be informed of Sun Ray serial ports if the application is running >>>>>> in a session currently directed to that particular Sun Ray unit, >>>>>> even though the serial port's device node happens to be server-side >>>>>> deeply nested in a leaf node. If the application is not running on >>>>>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>>>>> the decision about when and which ports to present to the application. >>>>>> >>>>>> 2. Pluggable driver-side interface where multiple platform-specific >>>>>> drivers can be utilized simultaneously to introduce more flexibility >>>>>> with the back end. >>>>>> >>>>>>> There are a number of 3rd party implementation of Java Comm, at >>>>>>> least one from IBM - part of what was J9, now Websphere, or >>>>>>> something (presumbly soon to get a name that has eclipse in it >>>>>>> sometime soon). Esmertec has one, and there are few others rolling >>>>>>> around. >>>>>> I have not been advocating gutting the API, since much of it is >>>>>> perfectly adequate. I'm not totally opposed to making substantial >>>>>> changes or improvements depending on other people's needs. There's >>>>>> no reason previous versions of javax.comm need to suddenly disappear >>>>>> if products need legacy support. >>>>>> >>>>>> >>>>>>> If RXTX is the only implementation of the JSR with no backward >>>>>>> compatibility, we've just forked Java Serial support and we (for a >>>>>>> least one) will be worse off. We won't be able to use the new >>>>>>> support because of a lack of support on J2ME platforms that we >>>>>>> have no control over and RXTX/current JavaComm will be in >>>>>>> maintenance mode or unsupported on all other platforms. >>>>>> There can't be *that* many platforms this is ported to. And it will >>>>>> be no javax.usb. Seems like most of the standard platforms will >>>>>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>>>>> JDBC... >>>>>> >>>>>>> So, is there any chance of building a compatibility requirement >>>>>>> into this. To pick are really bad example JDBC has support for a >>>>>>> DataSource or a Driver. Could we have an ExcellentSerialPort with >>>>>>> a fallback to a SerialPort on a class not found exception? >>>>>> Maybe, or maybe we just let people know what we are doing and >>>>>> try to figure out how to get their applications ported. Might not >>>>>> be that difficult. From my standpoint anyway, earthshaking >>>>>> changes aren't really necessary. Others might disagree. >>>>>> >>>>>> Paul >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Thu Jul 20 10:31:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 20 Jul 2006 10:31:57 -0600 (MDT) Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEA802.7060508@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: > PROJECT SCOPE: > ------------- > > Also, we should think carefully about what the scope of > this project would be. Should it be javax."comm" which > handles both serial and parallel (is parallel going by the > wayside). Should it be split into two project: > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > > Should we differentiate between single-ended serial > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > quasi-multidrop and full multidrop busses such as > EIA422, EIA432 and EIA485? If we really were to > add I2C support to the API, we'd have to delve into > the semantics more, because there could be some > implicit decoding of the bus the API users would > want to see. > Hi Paul The way RXTX works, which is a fair representation of the people using the API, is complete support for RIA232, minimal support for IEEE1284. From what I understand, Sun was going along the same lines. If we combined both projects, we would have half a parallel port implementation. I see maybe 4 requests for features not in the parallel support a year. The other protocols should not be limited by a JSR which is going to be focused upon serial port interests. The IEA485 hacks in RXTX along with I2C and Raw should _not_ be considered a strong basis for extending the API to cover these protocols. If people want to do real implementations, they should not face a 'standard' which wasnt really focused upon their interests. I think we understand the parallel port issues fairly well but have not implemented many features and I don't know if we would. So a versatile API is favorable but I do not think we have the proper community to represent much more than Serial. We could provide a framework or maybe just a model for further work with other standards. -- Trent Jarvi tjarvi at qbang.org From naranjo.manuel at gmail.com Thu Jul 20 10:49:33 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Thu, 20 Jul 2006 13:49:33 -0300 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <44BFB41D.4010604@gmail.com> Trent Jarvi wrote: >> PROJECT SCOPE: >> ------------- >> >> Also, we should think carefully about what the scope of >> this project would be. Should it be javax."comm" which >> handles both serial and parallel (is parallel going by the >> wayside). Should it be split into two project: >> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >> >> Should we differentiate between single-ended serial >> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >> quasi-multidrop and full multidrop busses such as >> EIA422, EIA432 and EIA485? If we really were to >> add I2C support to the API, we'd have to delve into >> the semantics more, because there could be some >> implicit decoding of the bus the API users would >> want to see. >> > > Hi Paul > > The way RXTX works, which is a fair representation of the people using the > API, is complete support for RIA232, minimal support for IEEE1284. From > what I understand, Sun was going along the same lines. If we combined > both projects, we would have half a parallel port implementation. I see > maybe 4 requests for features not in the parallel support a year. > > The other protocols should not be limited by a JSR which is going to be > focused upon serial port interests. The IEA485 hacks in RXTX along with > I2C and Raw should _not_ be considered a strong basis for extending the > API to cover these protocols. If people want to do real implementations, > they should not face a 'standard' which wasnt really focused upon their > interests. I think we understand the parallel port issues fairly well but > have not implemented many features and I don't know if we would. > > So a versatile API is favorable but I do not think we have the proper > community to represent much more than Serial. We could provide a > framework or maybe just a model for further work with other standards. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Hi, I agree with Trent, as far as I have seen most projects that were using RXTX and Java Comm where designed to work only with Serial Ports. What is fact is that a Parallel port can not be modeled at all like a Serial Port, except that they both expose and Input Stream and an Output Stream. As I have read there is a huge market of embedded applications using port accessing. We could take two different aproaches with the JSR, one could be define a way to access every kind of port independent of the implementation of the port himself. We could access Serial, Parallel, I2C, USB, etc. But we will have huge problems with it, because we will have to face a lot of low level programming which of course will be platform dependent, and that is were the write one use everywhere of Java could dye. The other approach is to define an Api that only supports Serial Ports, compatible with the one that is defined in javax.comm 2.0, and make some classes that extend that packages, maybe even in another package, like AWT and JSWING do. We then could eventually extend to other kinds of ports but that will require a lot of work more. I'm not a person specialized on Informatical Engineering, so I do not think I can give a hand on Low Level programming, I do can help with the Java part, debugging and testing. Regards, Manuel From brian at mbari.org Thu Jul 20 11:19:33 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 20 Jul 2006 10:19:33 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <8BFCAB48-6302-44CD-ABF0-560BC04AD26E@mbari.org> > The way RXTX works, which is a fair representation of the people > using the > API, is complete support for RIA232, minimal support for IEEE1284. > From > what I understand, Sun was going along the same lines. If we combined > both projects, we would have half a parallel port implementation. > I see > maybe 4 requests for features not in the parallel support a year. > > The other protocols should not be limited by a JSR which is going > to be > focused upon serial port interests. The IEA485 hacks in RXTX along > with > I2C and Raw should _not_ be considered a strong basis for extending > the > API to cover these protocols. If people want to do real > implementations, > they should not face a 'standard' which wasnt really focused upon > their > interests. I think we understand the parallel port issues fairly > well but > have not implemented many features and I don't know if we would. > > So a versatile API is favorable but I do not think we have the proper > community to represent much more than Serial. We could provide a > framework or maybe just a model for further work with other standards. I agree completely. Folks use RXTX for serial ports. In my field (Oceanography), we uses RS232 to talk to nearly all our instruments. So we really need a great implementation of serial port communications in Java that runs on a variety of architectures. I'd prefer if the JSR focused on that. >> I given much thought to what it would take to properly address >> > ^^^haven't > >> EIA-422, EIA-423 and EIA-485 (if any); but those would >> probably be extensions. Sounds like the differences might >> be transparent to the API. I'll look into that more. I've had good luck using the current implementation of RXTX with RS422, although you'll need to use a pin converter. my 2 cents. Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060720/fb956c68/attachment-0340.html From pascal at quies.net Fri Jul 21 15:43:40 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Fri, 21 Jul 2006 23:43:40 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: Message-ID: <200607212343.40882.pascal@quies.net> Op donderdag 20 juli 2006 15:16, schreef Dr. Douglas Lyon: > Hi All, > There has been some discussion about plugins for serial communications. > > As I see it, what Java really needs is a NativeLibraryManager. This is > a rather much larger charge than "just" RXTX. > > The RXTX basic mode of operation is that we associate static > blocks of code with a "System.load". > > Failure occurs when the class containing such a block of code is > loaded AND the native library is not found. > > What are some of the options? > > 1. Do nothing, let the program fail with an exception. > 2. try to catch an UnsatisfiedLinkError as a part of making > the driver. > 3. Search the java.library.path to see if the driver is present > (i.e., guard the input). > 4. Other?? > > In the case of either step 2 or 3, we need to fix the lack of a library. > > What are the options for fixing a library? > 1. Do nothing, but give the user an interesting error with instructions on > what to do. > 2. Attempt to find the library on the file system (perhaps with user help). > 3. Attempt to download the library and install it (perhaps with user > permission). > 4. Attempt to internalize the library as a UUEncoded serialized object and > install it (better ask the user, again!). > 5. Other?? 5. Put the binaries together with the attached classes in a jar. Joachim told me that and it works! I forgot to publish the results. :$ ---- begin example import org.rxtx.CommunicationAPI; ... CommunicationAPI commExtension = new CommunicationAPI(); try { commExtenios.loadNativeLibraries(); } catch (Exception e) { // We *need* javax.comm } // Now we have the extension available. ... ---- end example Do you like it? Commens anyone? The path to the libraries is in the form of /native/rxtx/-/{libserial,libparallel} so /native/rxtx/windows-i386/libserial would do. I asked for binaries but only Joachim offered me help with OS X on the next release. Does anyone have javax.comm warper classes? -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 6781 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060721/b39a5592/CommunicationAPI-0339.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: PlatformNotSupportedException.java Type: text/x-java Size: 1621 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060721/b39a5592/PlatformNotSupportedException-0339.bin From pascal at quies.net Fri Jul 21 15:45:30 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Fri, 21 Jul 2006 23:45:30 +0200 Subject: [Rxtx] quo vadis API/namespace (Re: jcp and jsr) In-Reply-To: References: <44BEDC4F.9030403@sun.com> Message-ID: <200607212345.30495.pascal@quies.net> Op donderdag 20 juli 2006 10:46, schreef Joachim Buechse: > So in short: Unless we find a strong argument why javax.comm can't be > used I prefer that we keep it. Unless we find a strong feature / use- > case that can not be handled with (an extension of) the current > CommPort/CommPortIndentifier I'd prefer to keep that as well. I seem to be the only one who sees failures in the API so lets keep it that way. Now how do we get a JSR/lisence if we don't want any changes? :P From lyon at docjava.com Sat Jul 22 06:07:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 22 Jul 2006 08:07:03 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607212343.40882.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> Message-ID: Hi All, I like the idea of the native lib in a jar with other classes. An alternative I did not know would work. Now, if you place the rxtx classes and native library in the same jar, do they both have to be in any specific place in order to be found? In my approach, you can locate the native library at run-time, and you need not alter any environmental variables nor mangle the JDK home. Thus, each user can have a different native library, one for development and one for release, for example. Regards, - Doug >Op donderdag 20 juli 2006 15:16, schreef Dr. Douglas Lyon: >> Hi All, >> There has been some discussion about plugins for serial communications. >> >> As I see it, what Java really needs is a NativeLibraryManager. This is >> a rather much larger charge than "just" RXTX. >> >> The RXTX basic mode of operation is that we associate static >> blocks of code with a "System.load". >> >> Failure occurs when the class containing such a block of code is >> loaded AND the native library is not found. >> >> What are some of the options? >> >> 1. Do nothing, let the program fail with an exception. >> 2. try to catch an UnsatisfiedLinkError as a part of making >> the driver. >> 3. Search the java.library.path to see if the driver is present >> (i.e., guard the input). >> 4. Other?? >> >> In the case of either step 2 or 3, we need to fix the lack of a library. >> >> What are the options for fixing a library? >> 1. Do nothing, but give the user an interesting error with instructions on >> what to do. >> 2. Attempt to find the library on the file system (perhaps with user help). >> 3. Attempt to download the library and install it (perhaps with user >> permission). >> 4. Attempt to internalize the library as a UUEncoded serialized object and >> install it (better ask the user, again!). >> 5. Other?? > >5. Put the binaries together with the attached classes in a jar. > >Joachim told me that and it works! I forgot to publish the results. :$ > > >---- begin example >import org.rxtx.CommunicationAPI; > >... >CommunicationAPI commExtension = new CommunicationAPI(); >try { > commExtenios.loadNativeLibraries(); >} catch (Exception e) { > // We *need* javax.comm >} > >// Now we have the extension available. >... >---- end example > > >Do you like it? Commens anyone? > > >The path to the libraries is in the form >of /native/rxtx/-/{libserial,libparallel} >so /native/rxtx/windows-i386/libserial would do. > >I asked for binaries but only Joachim offered me help with OS X on the next >release. > >Does anyone have javax.comm warper classes? > >Attachment converted: PowerBookHd:CommunicationAPI.java (TEXT/ttxt) (001C1686) >Attachment converted: PowerBookHd:PlatformNotSupporte#1C1687.java >(TEXT/ttxt) (001C1687) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 22 07:06:06 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 15:06:06 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607212343.40882.pascal@quies.net> Message-ID: <200607221506.07140.pascal@quies.net> > Now, if you place the rxtx classes and native library in the same > jar, do they both have to be in any specific place in order to be found? Answer: > >The path to the libraries is in the form > >of /native/rxtx/-/{libserial,libparallel} > >so /native/rxtx/windows-i386/libserial would do. I'me looking for the various os.name and os.arch values right now. From lyon at docjava.com Sat Jul 22 08:06:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 22 Jul 2006 10:06:26 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607221506.07140.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> <200607221506.07140.pascal@quies.net> Message-ID: Hi All, Here is how I have arranged my signed versions of the native binaries: http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/windows/native.jar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/native.jar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/linux/native.jar Then I do: public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isMacOs()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); System.out.println("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } My new-age NativeLibraryManger concept-thang allows you to write stuff like: /** * This method fixes the driver by beaming over * to the tmp directory a native.jar file. * The native.jar file is signed and its * native libs are beamed over to the user home directory * ~/.rxtx/
* Finally, the java.library.path is altered to include
* ~/.rxtx/ */ private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), NativeLibraryManager.mapLibraryName("rxtxSerial")); } catch (IOException e) { e.printStackTrace(); } } I do a lazy singleton design pattern: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getInstance() { if (driver != null) return driver; if (!NativeLibraryManager.isLibInPath("rxtxSerial")) fixDriver(); if (NativeLibraryManager.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } I am at a cross-roads here, since a file-based distro might be preferable to a URL based distro. To make this really general, and to "remember" where the last version of a native library came from, I serialize a bean into user preferences The user can then store native libraries anywhere, remembering the location in the preferences. What is the general feeling about this? Thanks! - Doug > > Now, if you place the rxtx classes and native library in the same >> jar, do they both have to be in any specific place in order to be found? > >Answer: > >> >The path to the libraries is in the form >> >of /native/rxtx/-/{libserial,libparallel} >> >so /native/rxtx/windows-i386/libserial would do. > >I'me looking for the various os.name and os.arch values right now. >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Sat Jul 22 10:30:55 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 22 Jul 2006 11:30:55 -0500 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607212343.40882.pascal@quies.net> Message-ID: <44C252BF.6040404@cox.net> Dr. Douglas Lyon wrote: > Hi All, > I like the idea of the native lib in a jar with other classes. > An alternative I did not know would work. I have several applications that run with a security policy. In these applications, native library loading will require an appropriate FilePermission that should be known about ahead of time. The current native library implementation will require the native library to be extracted from the jar and written to disk, requiring a FilePermission("...","write") for that file, and then will also require read access to load the library. I personally don't want to give write access to a JVM for a shared library which can provide a point of abuse by errant code. Gregg Wonderly From gergg at cox.net Sat Jul 22 10:33:52 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 22 Jul 2006 11:33:52 -0500 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607212343.40882.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> Message-ID: <44C25370.9070506@cox.net> >Pascal S. de Kloe wrote: >>> I am also not sure if >>> the api should unify corresponding cu. and tty. ports into one single >>> port. >> >> I think the API should hide low-level details like devicefiles. > >Not all ports have device files. It's long been my goal to add support >for virtual serial ports, that is, serial ports on Ethernet terminal >servers, for example integrating RFC2217. This means that the port name >is some combination of an IP address and TCP port number. Nothing in /dev. What I think would make the most sense is a simple "device" enumeration Server Provider Interface that would bring port objects into the JVM based on the platform JVM providers knowledge of how to enumerate those ports. Application writers would provide a plugin using the SPI that would codify those devices into named entities that they are interested in. public interface HardwarePort { public String getName(); public String getHardwareID(); public String getManufacturer(); public List getCapabilities(); public Object getImplementation(); } public interface PortCapability { public String getDescription(); public CapabilityId getIdentifier(); } public enum CapabilityId { INPUT, // Can receive input OUTPUT, // Can send output ASYNCHRONOUS, // Can send and receive at the same time SYNCHRONOUS, // No synchronous I/O ADDRESSABLE // Port has an address associated } Then, you might imagine that the enumerated capabilities had a standardized/specified interface that you'd find implemented on ports that had such capabilities. The getImplementation() method would return the implementation class provided by the JVM provider that had all of the interfaces tied to it. These are just some quick thoughts, pick away at them. I am very interested in getting a new comm api in place which can provide the ability for all USB connected devices to have drivers provided as 100% java for all non-timing critical types of device interfaces. The JVM provider should have an SPI to write to which will enable them to abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into something that we can talk 100% java to. That's my big desire. Starting with something simple which gives a good start in that direction would be great! Gregg Wonderly From pascal at quies.net Sat Jul 22 10:43:27 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 18:43:27 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <44C252BF.6040404@cox.net> References: <44C252BF.6040404@cox.net> Message-ID: <200607221843.27765.pascal@quies.net> Op zaterdag 22 juli 2006 18:30, schreef Gregg Wonderly: > Dr. Douglas Lyon wrote: > > Hi All, > > I like the idea of the native lib in a jar with other classes. > > An alternative I did not know would work. > > I have several applications that run with a security policy. In these > applications, native library loading will require an appropriate > FilePermission that should be known about ahead of time. The current > native library implementation will require the native library to be > extracted from the jar and written to disk, requiring a > FilePermission("...","write") for that file, and then will also require > read access to load the library. I personally don't want to give write > access to a JVM for a shared library which can provide a point of abuse by > errant code. > > Gregg Wonderly That's indeed a pitty limitation. It creates a lot of possible exceptions too. On the other hand, any native lib passes the securiy model. Applications who can access hardware ports can be expected to create files, right? From pascal at quies.net Sat Jul 22 10:54:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 18:54:13 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607221506.07140.pascal@quies.net> Message-ID: <200607221854.13467.pascal@quies.net> Hi Dr., We're both trying to do the same thing. The CommunicationAPI does not only look at the OS but it also indexes the available hardware architectures and does not need OsUtils. Any Java 2 runtime will do. The plan was to make a single JAR with the binaries for all supported platforms, the RXTX gnu.io package and the javax.comm wrapers. A signed version would be nice. A few questions remain tough. Does anybody know how Sun uses the SunOS and Solaris identifiers for the Java property os.name? Op zaterdag 22 juli 2006 16:06, schreef Dr. Douglas Lyon: > Hi All, > Here is how I have arranged my signed versions of the native > binaries: > http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/windows/native.j >ar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/native.jar > http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/linux/native.jar > > Then I do: > public static URL getResourceUrl() throws MalformedURLException { > String rxtxUrl = "http://show.docjava.com:8086/" + > "book/cgij/code/jnlp/libs/rxtx/"; > if (OsUtils.isLinux()) > return new URL(rxtxUrl + "linux/native.jar"); > if (OsUtils.isMacOs()) > return new URL(rxtxUrl + "mac/native.jar"); > if (OsUtils.isWindows()) > return new URL(rxtxUrl + "windows/native.jar"); > System.out.println("no automatic install supported for this > platform. " + > "Please e-mail lyon at docjava.com with a bug report"); > return null; > } > > My new-age NativeLibraryManger concept-thang allows you to > write stuff like: > > /** > * This method fixes the driver by beaming over > * to the tmp directory a native.jar file. > * The native.jar file is signed and its > * native libs are beamed over to the user home directory > * ~/.rxtx/
> * Finally, the java.library.path is altered to include
> * ~/.rxtx/ > */ > private static void fixDriver() { > > try { > NativeLibraryManager.fixDriver(getResourceUrl(), > NativeLibraryManager.mapLibraryName("rxtxSerial")); > } catch (IOException e) { > e.printStackTrace(); > } > } > > I do a lazy singleton design pattern: > > public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public synchronized static RXTXCommDriver getInstance() { > if (driver != null) return driver; > if (!NativeLibraryManager.isLibInPath("rxtxSerial")) > fixDriver(); > if (NativeLibraryManager.isLibInPath("rxtxSerial")) { > driver = new RXTXCommDriver(); > driver.initialize(); > } > return driver; > } > > I am at a cross-roads here, since a file-based distro might be preferable > to a URL based distro. To make this really general, and to "remember" where > the last version of a native library came from, I serialize a bean into > user preferences > The user can then store native libraries anywhere, remembering the location > in the preferences. > > What is the general feeling about this? > > Thanks! > - Doug > > > > Now, if you place the rxtx classes and native library in the same > >> > >> jar, do they both have to be in any specific place in order to be > >> found? > > > >Answer: > >> >The path to the libraries is in the form > >> >of /native/rxtx/-/{libserial,libparallel} > >> >so /native/rxtx/windows-i386/libserial would do. > > > >I'me looking for the various os.name and os.arch values right now. > >_______________________________________________ > >Rxtx mailing list > >Rxtx at qbang.org > >http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Sat Jul 22 11:17:51 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 22 Jul 2006 19:17:51 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <44C252BF.6040404@cox.net> References: <200607212343.40882.pascal@quies.net> <44C252BF.6040404@cox.net> Message-ID: <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> We could easily have a stub method / flag that allows you to explicitly load the native library (via System.loadLibrary ie from the java.library.path). In this case the "auto-extraction" would not take place. On 22.07.2006, at 18:30, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> Hi All, >> I like the idea of the native lib in a jar with other classes. >> An alternative I did not know would work. > > I have several applications that run with a security policy. In these > applications, native library loading will require an appropriate > FilePermission > that should be known about ahead of time. The current native library > implementation will require the native library to be extracted from > the jar and > written to disk, requiring a FilePermission("...","write") for that > file, and > then will also require read access to load the library. I > personally don't want > to give write access to a JVM for a shared library which can > provide a point of > abuse by errant code. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 22 11:20:19 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 19:20:19 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607221506.07140.pascal@quies.net> Message-ID: <200607221920.20096.pascal@quies.net> The attachment setup.zip contains a very small update of CommunicationAPI and a good start with the various platforms. All we need to do is fill those directories with binaries. Various binaries are missing the pararlel library. Why is that? -------------- next part -------------- A non-text attachment was scrubbed... Name: setup.zip Type: application/x-zip Size: 8459 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060722/12770623/setup-0338.bin From gregg at cytetech.com Thu Jul 20 21:32:55 2006 From: gregg at cytetech.com (Gregg Wonderly) Date: Thu, 20 Jul 2006 22:32:55 -0500 Subject: [Rxtx] jcp and jsr Message-ID: <44C04AE7.9050800@cytetech.com> >Pascal S. de Kloe wrote: >>> I am also not sure if >>> the api should unify corresponding cu. and tty. ports into one single >>> port. >> >> I think the API should hide low-level details like devicefiles. > >Not all ports have device files. It's long been my goal to add support >for virtual serial ports, that is, serial ports on Ethernet terminal >servers, for example integrating RFC2217. This means that the port name >is some combination of an IP address and TCP port number. Nothing in /dev. What I think would make the most sense is a simple "device" enumeration Server Provider Interface that would bring port objects into the JVM based on the platform JVM providers knowledge of how to enumerate those ports. Application writers would provide a plugin using the SPI that would codify those devices into named entities that they are interested in. public interface HardwarePort { public String getName(); public String getHardwareID(); public String getManufacturer(); public List getCapabilities(); public Object getImplementation(); } public interface PortCapability { public String getDescription(); public CapabilityId getIdentifier(); } public enum CapabilityId { INPUT, // Can receive input OUTPUT, // Can send output ASYNCHRONOUS, // Can send and receive at the same time SYNCHRONOUS, // No synchronous I/O ADDRESSABLE // Port has an address associated } Then, you might imagine that the enumerated capabilities had a standardized/specified interface that you'd find implemented on ports that had such capabilities. The getImplementation() method would return the implementation class provided by the JVM provider that had all of the interfaces tied to it. These are just some quick thoughts, pick away at them. I am very interested in getting a new comm api in place which can provide the ability for all USB connected devices to have drivers provided as 100% java for all non-timing critical types of device interfaces. The JVM provider should have an SPI to write to which will enable them to abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into something that we can talk 100% java to. That's my big desire. Starting with something simple which gives a good start in that direction would be great! Gregg Wonderly From pascal at quies.net Sat Jul 22 11:32:03 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 19:32:03 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44C25370.9070506@cox.net> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> Message-ID: <200607221932.04194.pascal@quies.net> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: > >Pascal S. de Kloe wrote: > >>> I am also not sure if > >>> the api should unify corresponding cu. and tty. ports into one single > >>> port. > >> > >> I think the API should hide low-level details like devicefiles. > > > >Not all ports have device files. It's long been my goal to add support > >for virtual serial ports, that is, serial ports on Ethernet terminal > >servers, for example integrating RFC2217. This means that the port name > >is some combination of an IP address and TCP port number. Nothing in > > /dev. > > What I think would make the most sense is a simple "device" enumeration > Server Provider Interface that would bring port objects into the JVM based > on the platform JVM providers knowledge of how to enumerate those ports. > Application writers would provide a plugin using the SPI that would codify > those devices into named entities that they are interested in. > > public interface HardwarePort { > public String getName(); > public String getHardwareID(); > public String getManufacturer(); > public List getCapabilities(); > public Object getImplementation(); > } > > public interface PortCapability { > public String getDescription(); > public CapabilityId getIdentifier(); > } > > public enum CapabilityId { > INPUT, // Can receive input > OUTPUT, // Can send output > ASYNCHRONOUS, // Can send and receive at the same time > SYNCHRONOUS, // No synchronous I/O > ADDRESSABLE // Port has an address associated > } > > Then, you might imagine that the enumerated capabilities had a > standardized/specified interface that you'd find implemented on ports that > had such capabilities. > > The getImplementation() method would return the implementation class > provided by the JVM provider that had all of the interfaces tied to it. > > These are just some quick thoughts, pick away at them. > > I am very interested in getting a new comm api in place which can provide > the ability for all USB connected devices to have drivers provided as 100% > java for all non-timing critical types of device interfaces. > > The JVM provider should have an SPI to write to which will enable them to > abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into something > that we can talk 100% java to. > > That's my big desire. Starting with something simple which gives a good > start in that direction would be great! That was exactly my wish too. The point people brought up was: 1) It's too complex. 2) What does it solve? In both facts they are right. It'll take a *long* time to plan such a thing right but if it works you have a product. Anyway, I'd like to join. ;) From joachim at buechse.de Sat Jul 22 11:37:11 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 22 Jul 2006 19:37:11 +0200 Subject: [Rxtx] Strange error (show stopper) Message-ID: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> I just discovered a strange error in RXTX on OSX. SerialDemo.java manages to corrupt the event_info_structure by a simple OpenPort,ClosePort - this could be in relation to the deadlock problem that was reported recently. Could anyone try to reproduce this on Solaris or some other system which is neither WIN32 nor Linux (ie which uses a drain thread). In SerialImp.c : RXTXPort(interruptEventLoop) Apparently the event_info_structure gets corrupted shortly after pthread_kill(index->drain_tid, SIGABRT); In particular, the index->closing flag gets overwritten by a pointer value. **** Adding the following debugging code: pthread_kill(index->drain_tid, SIGABRT); sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i \n", index->fd, index, index->closing ); report( message ); /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ usleep(50 * 1000); sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i \n", index->fd, index, index->closing ); report( message ); **** gives me: 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 drain_loop: received EINTR------------------ drain_loop exiting --------------------- entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 eventLoop: got interrupt 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 **** Modifying SerialImp.h : event_info_struct by moving the prev*, next* pointers jmethodID checkMonitorThread; struct event_info_struct *dummy, *dummy2; fd_set rfds; struct timeval tv_sleep; int closing; struct event_info_struct *next, *prev; *** (ie replacing their original position with dummys and moving them *** behind the closing flag) results in this: 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 drain_loop: received EINTR------------------ drain_loop exiting --------------------- entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 eventLoop: got interrupt 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 *** I was not able to track down the problem. If anyone could check wether this happens on other platforms as well, we may get closer to a fix. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich From joachim at buechse.de Sat Jul 22 11:46:35 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 22 Jul 2006 19:46:35 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607221932.04194.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> Message-ID: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> It seems that Gregg's suggestion could be implemented without changing the existing "user-level" API of javax.comm. Most of the information suggested for HardwarePort is not accessible from within the POSSIX-API but this is a different story. It is clear that javax.comm can never provide a way to talk to all USB devices, simply because some USB devices have several endpoints. But it could provide a means of talking to devices that function as a bidirectional-pipe (ie any USB to serial bridge). Regards, Joachim On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>> Pascal S. de Kloe wrote: >>>>> I am also not sure if >>>>> the api should unify corresponding cu. and tty. ports into one >>>>> single >>>>> port. >>>> >>>> I think the API should hide low-level details like devicefiles. >>> >>> Not all ports have device files. It's long been my goal to add >>> support >>> for virtual serial ports, that is, serial ports on Ethernet terminal >>> servers, for example integrating RFC2217. This means that the >>> port name >>> is some combination of an IP address and TCP port number. >>> Nothing in >>> /dev. >> >> What I think would make the most sense is a simple "device" >> enumeration >> Server Provider Interface that would bring port objects into the >> JVM based >> on the platform JVM providers knowledge of how to enumerate those >> ports. >> Application writers would provide a plugin using the SPI that >> would codify >> those devices into named entities that they are interested in. >> >> public interface HardwarePort { >> public String getName(); >> public String getHardwareID(); >> public String getManufacturer(); >> public List getCapabilities(); >> public Object getImplementation(); >> } >> >> public interface PortCapability { >> public String getDescription(); >> public CapabilityId getIdentifier(); >> } >> >> public enum CapabilityId { >> INPUT, // Can receive input >> OUTPUT, // Can send output >> ASYNCHRONOUS, // Can send and receive at the same time >> SYNCHRONOUS, // No synchronous I/O >> ADDRESSABLE // Port has an address associated >> } >> >> Then, you might imagine that the enumerated capabilities had a >> standardized/specified interface that you'd find implemented on >> ports that >> had such capabilities. >> >> The getImplementation() method would return the implementation class >> provided by the JVM provider that had all of the interfaces tied >> to it. >> >> These are just some quick thoughts, pick away at them. >> >> I am very interested in getting a new comm api in place which can >> provide >> the ability for all USB connected devices to have drivers provided >> as 100% >> java for all non-timing critical types of device interfaces. >> >> The JVM provider should have an SPI to write to which will enable >> them to >> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >> something >> that we can talk 100% java to. >> >> That's my big desire. Starting with something simple which gives >> a good >> start in that direction would be great! > > That was exactly my wish too. > > The point people brought up was: > 1) It's too complex. > 2) What does it solve? > > In both facts they are right. It'll take a *long* time to plan such > a thing > right but if it works you have a product. Anyway, I'd like to join. ;) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Jul 22 11:55:23 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 22 Jul 2006 14:55:23 -0300 Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: <44C2668B.5080703@gmail.com> Joachim Buechse escribi?: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. > > It is clear that javax.comm can never provide a way to talk to all > USB devices, simply because some USB devices have several endpoints. > But it could provide a means of talking to devices that function as a > bidirectional-pipe (ie any USB to serial bridge). > > Regards, > Joachim Hi, About USB, why do not we contact the guys that make a library to support USB under Java from Linux? I think there is all ready an JSR for USB access, what we could do to this JSR is help to implement Usb access from other OSes. Regards, Manuel > > On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > >> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>> Pascal S. de Kloe wrote: >>>>>> I am also not sure if >>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>> single >>>>>> port. >>>>> I think the API should hide low-level details like devicefiles. >>>> Not all ports have device files. It's long been my goal to add >>>> support >>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>> servers, for example integrating RFC2217. This means that the >>>> port name >>>> is some combination of an IP address and TCP port number. >>>> Nothing in >>>> /dev. >>> What I think would make the most sense is a simple "device" >>> enumeration >>> Server Provider Interface that would bring port objects into the >>> JVM based >>> on the platform JVM providers knowledge of how to enumerate those >>> ports. >>> Application writers would provide a plugin using the SPI that >>> would codify >>> those devices into named entities that they are interested in. >>> >>> public interface HardwarePort { >>> public String getName(); >>> public String getHardwareID(); >>> public String getManufacturer(); >>> public List getCapabilities(); >>> public Object getImplementation(); >>> } >>> >>> public interface PortCapability { >>> public String getDescription(); >>> public CapabilityId getIdentifier(); >>> } >>> >>> public enum CapabilityId { >>> INPUT, // Can receive input >>> OUTPUT, // Can send output >>> ASYNCHRONOUS, // Can send and receive at the same time >>> SYNCHRONOUS, // No synchronous I/O >>> ADDRESSABLE // Port has an address associated >>> } >>> >>> Then, you might imagine that the enumerated capabilities had a >>> standardized/specified interface that you'd find implemented on >>> ports that >>> had such capabilities. >>> >>> The getImplementation() method would return the implementation class >>> provided by the JVM provider that had all of the interfaces tied >>> to it. >>> >>> These are just some quick thoughts, pick away at them. >>> >>> I am very interested in getting a new comm api in place which can >>> provide >>> the ability for all USB connected devices to have drivers provided >>> as 100% >>> java for all non-timing critical types of device interfaces. >>> >>> The JVM provider should have an SPI to write to which will enable >>> them to >>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>> something >>> that we can talk 100% java to. >>> >>> That's my big desire. Starting with something simple which gives >>> a good >>> start in that direction would be great! >> That was exactly my wish too. >> >> The point people brought up was: >> 1) It's too complex. >> 2) What does it solve? >> >> In both facts they are right. It'll take a *long* time to plan such >> a thing >> right but if it works you have a product. Anyway, I'd like to join. ;) >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Sat Jul 22 11:58:00 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Sat, 22 Jul 2006 13:58:00 -0400 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> Message-ID: <41E45C85-4A22-4C5B-915F-62ED36BACCF2@sympatico.ca> A couple of questions: - what version are you using? - does this happen with the version in cvs? Andre On 22-Jul-06, at 13:37 , Joachim Buechse wrote: > I just discovered a strange error in RXTX on OSX. SerialDemo.java > manages to corrupt the event_info_structure by a simple > OpenPort,ClosePort - this could be in relation to the deadlock > problem that was reported recently. > > Could anyone try to reproduce this on Solaris or some other system > which is neither WIN32 nor Linux (ie which uses a drain thread). > > In SerialImp.c : RXTXPort(interruptEventLoop) > > Apparently the event_info_structure gets corrupted shortly after > > pthread_kill(index->drain_tid, SIGABRT); > > In particular, the index->closing flag gets overwritten by a pointer > value. > > > **** Adding the following debugging code: > > pthread_kill(index->drain_tid, SIGABRT); > sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ > usleep(50 * 1000); > sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > > **** gives me: > > 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 > > **** Modifying SerialImp.h : event_info_struct by moving the > prev*, next* pointers > > jmethodID checkMonitorThread; > struct event_info_struct *dummy, *dummy2; > fd_set rfds; > struct timeval tv_sleep; > int closing; > struct event_info_struct *next, *prev; > > *** (ie replacing their original position with dummys and moving them > *** behind the closing flag) results in this: > > 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 > > > *** I was not able to track down the problem. If anyone could check > wether this happens on other platforms as well, we may get closer to > a fix. > > Regards, > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Paul.Klissner at Sun.COM Sat Jul 22 12:19:41 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Sat, 22 Jul 2006 11:19:41 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: <44C26C3D.8020501@sun.com> Joachim Buechse wrote: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. > > It is clear that javax.comm can never provide a way to talk to all > USB devices, simply because some USB devices have several endpoints. > But it could provide a means of talking to devices that function as a > bidirectional-pipe (ie any USB to serial bridge). If the 'back end' driver could be java as well an .so then driver's could be written using javax.usb, which is available currently for Linux. Paul > > Regards, > Joachim > > On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > >> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>> Pascal S. de Kloe wrote: >>>>>> I am also not sure if >>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>> single >>>>>> port. >>>>> I think the API should hide low-level details like devicefiles. >>>> Not all ports have device files. It's long been my goal to add >>>> support >>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>> servers, for example integrating RFC2217. This means that the >>>> port name >>>> is some combination of an IP address and TCP port number. >>>> Nothing in >>>> /dev. >>> What I think would make the most sense is a simple "device" >>> enumeration >>> Server Provider Interface that would bring port objects into the >>> JVM based >>> on the platform JVM providers knowledge of how to enumerate those >>> ports. >>> Application writers would provide a plugin using the SPI that >>> would codify >>> those devices into named entities that they are interested in. >>> >>> public interface HardwarePort { >>> public String getName(); >>> public String getHardwareID(); >>> public String getManufacturer(); >>> public List getCapabilities(); >>> public Object getImplementation(); >>> } >>> >>> public interface PortCapability { >>> public String getDescription(); >>> public CapabilityId getIdentifier(); >>> } >>> >>> public enum CapabilityId { >>> INPUT, // Can receive input >>> OUTPUT, // Can send output >>> ASYNCHRONOUS, // Can send and receive at the same time >>> SYNCHRONOUS, // No synchronous I/O >>> ADDRESSABLE // Port has an address associated >>> } >>> >>> Then, you might imagine that the enumerated capabilities had a >>> standardized/specified interface that you'd find implemented on >>> ports that >>> had such capabilities. >>> >>> The getImplementation() method would return the implementation class >>> provided by the JVM provider that had all of the interfaces tied >>> to it. >>> >>> These are just some quick thoughts, pick away at them. >>> >>> I am very interested in getting a new comm api in place which can >>> provide >>> the ability for all USB connected devices to have drivers provided >>> as 100% >>> java for all non-timing critical types of device interfaces. >>> >>> The JVM provider should have an SPI to write to which will enable >>> them to >>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>> something >>> that we can talk 100% java to. >>> >>> That's my big desire. Starting with something simple which gives >>> a good >>> start in that direction would be great! >> That was exactly my wish too. >> >> The point people brought up was: >> 1) It's too complex. >> 2) What does it solve? >> >> In both facts they are right. It'll take a *long* time to plan such >> a thing >> right but if it works you have a product. Anyway, I'd like to join. ;) >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 22 12:48:15 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 20:48:15 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607221920.20096.pascal@quies.net> References: <200607221920.20096.pascal@quies.net> Message-ID: <200607222048.16215.pascal@quies.net> http://quies.net/communicationapi.jar Fixed a few typo's and it works on Linux i386. It should also work on Windows i386. The rest is missing libParallel or more... -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 6664 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060722/5fd7c1ce/CommunicationAPI-0338.bin From Paul.Klissner at Sun.COM Sat Jul 22 12:53:12 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Sat, 22 Jul 2006 11:53:12 -0700 Subject: [Rxtx] jcp and jsr (libusb, javax.usb) In-Reply-To: <44C2668B.5080703@gmail.com> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> <44C2668B.5080703@gmail.com> Message-ID: <44C27418.1090309@sun.com> Manuel Naranjo wrote: > Joachim Buechse escribi?: >> It seems that Gregg's suggestion could be implemented without >> changing the existing "user-level" API of javax.comm. Most of the >> information suggested for HardwarePort is not accessible from within >> the POSSIX-API but this is a different story. >> >> It is clear that javax.comm can never provide a way to talk to all >> USB devices, simply because some USB devices have several endpoints. >> But it could provide a means of talking to devices that function as a >> bidirectional-pipe (ie any USB to serial bridge). >> >> Regards, >> Joachim > > Hi, > About USB, why do not we contact the guys that make a library to support > USB under Java from Linux? > I think there is all ready an JSR for USB access, what we could do to this > JSR is help to implement Usb access from other OSes. JAVAX.USB --------- javax.usb already a SourceForge project. I was Sun's rep on the expert group for JSR-80, javax.usb. I lived and breathed it for a 1.5 yrs working with spec lead from IBM on it. It's for real and the linux implementation works (not sure about the Win32 port on sourceforge). IBM even created a porting layer to simplify porting it to other platforms by implementing in Java all of the numerous 'clerical' functions of the API in Java so that the porting layer is absolutely minimal. The hardest part is managing the hotpluggable device tree topology as objects, and depending on one's platform or coding skills probably wouldn't take more than a week or two to get right. LIBUSB 1.0 (*NOT* libusb 0.1.8) ---------- There is also the native C library libusb. libusb 0.1.8 is weak, but libusb 1.0 under development holds the promise of being an extrordinarily robust C API to access USB devices through, and could definitely use some help getting people to port it to other platforms. I've attached the proposed libusb 1.0 API header which Sun worked with Johannes on for months before he went off into oblivion. The API has stalled and a fire might need to be lit under Johannes or it might need to be forked to get it moving again, but the spec for 1.0 is awesome, and this puppy is ready to turn into something sweet with some fresh blood on it. And it is a really good technology to become aquainted with... hint hint. Both of those APIs are really excellent and hold great promise for the community and use of USB technology in general. One of my goals, now which competes for my time with other higher priority projects was to layer an implementation of javax.usb over libusb 1.0, so that javax.usb would follow libusb to any platform and only one port would be required. But since libusb 1.0 is moving slowly, largely because the current sourceforge gatekeeper for the project, Johannes Erdfelt's lack of energy and sparse communication, it might be faster to simply port javax.usb to Mac OS, Win, Solaris and BSD if some people could get behind those, unless someone want's to get behind making libusb happen. >>>> >>>> public enum CapabilityId { >>>> INPUT, // Can receive input >>>> OUTPUT, // Can send output >>>> ASYNCHRONOUS, // Can send and receive at the same time >>>> SYNCHRONOUS, // No synchronous I/O >>>> ADDRESSABLE // Port has an address associated >>>> } My understanding is that synchronous/asynchronous refers to the way the data is clocked. I think FULLDUPLEX/HALFDUPLEX is what the author meant, or needs to be added. Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: libusb.h Type: text/x-sun-h-file Size: 26696 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060722/4a43e034/libusb-0338.bin From pascal at quies.net Sat Jul 22 17:53:31 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 01:53:31 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> References: <44C252BF.6040404@cox.net> <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> Message-ID: <200607230153.32328.pascal@quies.net> Hi Joachim, I'm not getting it. How do you easily get a "stub method / flag"? Op zaterdag 22 juli 2006 19:17, schreef Joachim Buechse: > We could easily have a stub method / flag that allows you to > explicitly load the native library (via System.loadLibrary ie from > the java.library.path). In this case the "auto-extraction" would not > take place. > > On 22.07.2006, at 18:30, Gregg Wonderly wrote: > > Dr. Douglas Lyon wrote: > >> Hi All, > >> I like the idea of the native lib in a jar with other classes. > >> An alternative I did not know would work. > > > > I have several applications that run with a security policy. In these > > applications, native library loading will require an appropriate > > FilePermission > > that should be known about ahead of time. The current native library > > implementation will require the native library to be extracted from > > the jar and > > written to disk, requiring a FilePermission("...","write") for that > > file, and > > then will also require read access to load the library. I > > personally don't want > > to give write access to a JVM for a shared library which can > > provide a point of > > abuse by errant code. > > > > Gregg Wonderly > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat Jul 22 18:46:33 2006 From: jredman at ergotech.com (Jim Redman) Date: Sat, 22 Jul 2006 18:46:33 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44C26C3D.8020501@sun.com> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> <44C26C3D.8020501@sun.com> Message-ID: <44C2C6E9.8020408@ergotech.com> Paul, I think that you've already proposed a "pluggable" underlying architecture and I think that this might be better implemented there. If you need some more examples, I'd like to have a Bluetooth interface (with dynamic discovery). Jim Paul Klissner wrote: > Joachim Buechse wrote: >> It seems that Gregg's suggestion could be implemented without >> changing the existing "user-level" API of javax.comm. Most of the >> information suggested for HardwarePort is not accessible from within >> the POSSIX-API but this is a different story. >> >> It is clear that javax.comm can never provide a way to talk to all >> USB devices, simply because some USB devices have several endpoints. >> But it could provide a means of talking to devices that function as a >> bidirectional-pipe (ie any USB to serial bridge). > > If the 'back end' driver could be java as well an .so > then driver's could be written using javax.usb, which > is available currently for Linux. > > Paul > > > >> Regards, >> Joachim >> >> On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: >> >>> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>>> Pascal S. de Kloe wrote: >>>>>>> I am also not sure if >>>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>>> single >>>>>>> port. >>>>>> I think the API should hide low-level details like devicefiles. >>>>> Not all ports have device files. It's long been my goal to add >>>>> support >>>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>>> servers, for example integrating RFC2217. This means that the >>>>> port name >>>>> is some combination of an IP address and TCP port number. >>>>> Nothing in >>>>> /dev. >>>> What I think would make the most sense is a simple "device" >>>> enumeration >>>> Server Provider Interface that would bring port objects into the >>>> JVM based >>>> on the platform JVM providers knowledge of how to enumerate those >>>> ports. >>>> Application writers would provide a plugin using the SPI that >>>> would codify >>>> those devices into named entities that they are interested in. >>>> >>>> public interface HardwarePort { >>>> public String getName(); >>>> public String getHardwareID(); >>>> public String getManufacturer(); >>>> public List getCapabilities(); >>>> public Object getImplementation(); >>>> } >>>> >>>> public interface PortCapability { >>>> public String getDescription(); >>>> public CapabilityId getIdentifier(); >>>> } >>>> >>>> public enum CapabilityId { >>>> INPUT, // Can receive input >>>> OUTPUT, // Can send output >>>> ASYNCHRONOUS, // Can send and receive at the same time >>>> SYNCHRONOUS, // No synchronous I/O >>>> ADDRESSABLE // Port has an address associated >>>> } >>>> >>>> Then, you might imagine that the enumerated capabilities had a >>>> standardized/specified interface that you'd find implemented on >>>> ports that >>>> had such capabilities. >>>> >>>> The getImplementation() method would return the implementation class >>>> provided by the JVM provider that had all of the interfaces tied >>>> to it. >>>> >>>> These are just some quick thoughts, pick away at them. >>>> >>>> I am very interested in getting a new comm api in place which can >>>> provide >>>> the ability for all USB connected devices to have drivers provided >>>> as 100% >>>> java for all non-timing critical types of device interfaces. >>>> >>>> The JVM provider should have an SPI to write to which will enable >>>> them to >>>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>>> something >>>> that we can talk 100% java to. >>>> >>>> That's my big desire. Starting with something simple which gives >>>> a good >>>> start in that direction would be great! >>> That was exactly my wish too. >>> >>> The point people brought up was: >>> 1) It's too complex. >>> 2) What does it solve? >>> >>> In both facts they are right. It'll take a *long* time to plan such >>> a thing >>> right but if it works you have a product. Anyway, I'd like to join. ;) >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From lyon at docjava.com Sun Jul 23 04:27:22 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 06:27:22 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607222048.16215.pascal@quies.net> References: <200607221920.20096.pascal@quies.net> <200607222048.16215.pascal@quies.net> Message-ID: The Class.forName is a static method. Therefore myClass.forName Should be Class.forName and myClass becomes an unused parameter. - DL >http://quies.net/communicationapi.jar > >Fixed a few typo's and it works on Linux i386. It should also work on Windows >i386. The rest is missing libParallel or more... > > >Attachment converted: PowerBookHd:CommunicationAPI 1.java >(TEXT/ttxt) (001C1A15) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Jul 23 04:32:45 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 06:32:45 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607222048.16215.pascal@quies.net> References: <200607221920.20096.pascal@quies.net> <200607222048.16215.pascal@quies.net> Message-ID: Also, the is Java2 check does not check if you are running under jdk1.5 - DL >http://quies.net/communicationapi.jar > >Fixed a few typo's and it works on Linux i386. It should also work on Windows >i386. The rest is missing libParallel or more... > > >Attachment converted: PowerBookHd:CommunicationAPI 1.java >(TEXT/ttxt) (001C1A15) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Jul 23 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 06:54:12 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607221843.27765.pascal@quies.net> References: <44C252BF.6040404@cox.net> <200607221843.27765.pascal@quies.net> Message-ID: Hi All, Perhaps Java web start can address Gregg's concerns. The native libs are placed into a signed jar for distribution. As to the assertion that serial-port based programs need file io abilities, that seems true, to me. Particularly for /dev/ttyN type native libs or libs that use lock files. The question of how to obtain a signed application that is given file-io authority may be settled by using a signing technology. Even applets can be signed, to enable improved access to the file system. What else can we try? Any ideas? Thanks! - Doug >Op zaterdag 22 juli 2006 18:30, schreef Gregg Wonderly: >> Dr. Douglas Lyon wrote: >> > Hi All, >> > I like the idea of the native lib in a jar with other classes. >> > An alternative I did not know would work. >> >> I have several applications that run with a security policy. In these >> applications, native library loading will require an appropriate >> FilePermission that should be known about ahead of time. The current >> native library implementation will require the native library to be >> extracted from the jar and written to disk, requiring a >> FilePermission("...","write") for that file, and then will also require >> read access to load the library. I personally don't want to give write >> access to a JVM for a shared library which can provide a point of abuse by >> errant code. >> >> Gregg Wonderly > >That's indeed a pitty limitation. It creates a lot of possible exceptions too. > >On the other hand, any native lib passes the securiy model. Applications who >can access hardware ports can be expected to create files, right? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 04:57:33 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 12:57:33 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607222048.16215.pascal@quies.net> Message-ID: <200607231257.34284.pascal@quies.net> Op zondag 23 juli 2006 12:27, schreef Dr. Douglas Lyon: > The Class.forName is a static method. Therefore > myClass.forName Should be Class.forName and > myClass becomes an unused parameter. > - DL Thank you. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 6625 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060723/00f3b627/CommunicationAPI-0338.bin From pascal at quies.net Sun Jul 23 05:02:59 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 13:02:59 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607222048.16215.pascal@quies.net> Message-ID: <200607231302.59252.pascal@quies.net> Op zondag 23 juli 2006 12:32, schreef Dr. Douglas Lyon: > Also, the is Java2 check does not check if you are running under > jdk1.5 > - DL Could you please explain? The JDK 1.5 will pass the check just fine. From lyon at docjava.com Sun Jul 23 05:34:10 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 07:34:10 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607221854.13467.pascal@quies.net> References: <200607221506.07140.pascal@quies.net> <200607221854.13467.pascal@quies.net> Message-ID: Hi All, Please call me Doug (the Dr. is for the classroom). Thanks! - Doug >Hi Dr., > >We're both trying to do the same thing. > >The CommunicationAPI does not only look at the OS but it also indexes the >available hardware architectures and does not need OsUtils. Any Java 2 >runtime will do. > >The plan was to make a single JAR with the binaries for all supported >platforms, the RXTX gnu.io package and the javax.comm wrapers. > >A signed version would be nice. > >A few questions remain tough. Does anybody know how Sun uses the SunOS and >Solaris identifiers for the Java property os.name? > > > >Op zaterdag 22 juli 2006 16:06, schreef Dr. Douglas Lyon: >> Hi All, >> Here is how I have arranged my signed versions of the native >> binaries: >> http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/windows/native.j >>ar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/native.jar >> http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/linux/native.jar >> >> Then I do: >> public static URL getResourceUrl() throws MalformedURLException { >> String rxtxUrl = "http://show.docjava.com:8086/" + >> "book/cgij/code/jnlp/libs/rxtx/"; >> if (OsUtils.isLinux()) >> return new URL(rxtxUrl + "linux/native.jar"); >> if (OsUtils.isMacOs()) >> return new URL(rxtxUrl + "mac/native.jar"); >> if (OsUtils.isWindows()) >> return new URL(rxtxUrl + "windows/native.jar"); >> System.out.println("no automatic install supported for this >> platform. " + >> "Please e-mail lyon at docjava.com with a bug report"); >> return null; >> } >> >> My new-age NativeLibraryManger concept-thang allows you to >> write stuff like: >> >> /** >> * This method fixes the driver by beaming over >> * to the tmp directory a native.jar file. >> * The native.jar file is signed and its >> * native libs are beamed over to the user home directory >> * ~/.rxtx/
>> * Finally, the java.library.path is altered to include
>> * ~/.rxtx/ >> */ >> private static void fixDriver() { >> >> try { >> NativeLibraryManager.fixDriver(getResourceUrl(), >> NativeLibraryManager.mapLibraryName("rxtxSerial")); >> } catch (IOException e) { >> e.printStackTrace(); >> } >> } >> >> I do a lazy singleton design pattern: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public synchronized static RXTXCommDriver getInstance() { >> if (driver != null) return driver; >> if (!NativeLibraryManager.isLibInPath("rxtxSerial")) >> fixDriver(); >> if (NativeLibraryManager.isLibInPath("rxtxSerial")) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> } >> return driver; >> } >> >> I am at a cross-roads here, since a file-based distro might be preferable >> to a URL based distro. To make this really general, and to "remember" where >> the last version of a native library came from, I serialize a bean into >> user preferences >> The user can then store native libraries anywhere, remembering the location >> in the preferences. >> >> What is the general feeling about this? >> >> Thanks! >> - Doug >> >> > > Now, if you place the rxtx classes and native library in the same >> >> >> >> jar, do they both have to be in any specific place in order to be >> >> found? >> > >> >Answer: >> >> >The path to the libraries is in the form >> >> >of /native/rxtx/-/{libserial,libparallel} >> >> >so /native/rxtx/windows-i386/libserial would do. >> > >> >I'me looking for the various os.name and os.arch values right now. >> >_______________________________________________ >> >Rxtx mailing list >> >Rxtx at qbang.org >> >http://mailman.qbang.org/mailman/listinfo/rxtx > > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 06:12:33 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 14:12:33 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607221843.27765.pascal@quies.net> Message-ID: <200607231412.34078.pascal@quies.net> Op zondag 23 juli 2006 12:54, schreef Dr. Douglas Lyon: > Hi All, > Perhaps Java web start can address Gregg's concerns. > The native libs are placed into a signed jar for distribution. > As to the assertion that serial-port based programs need file io > abilities, that seems true, to me. Particularly for /dev/ttyN type > native libs or libs that use lock files. > The question of how to obtain a signed application that is given > file-io authority may be settled by using a signing technology. > > Even applets can be signed, to enable improved access to the file > system. > > What else can we try? Any ideas? It might be a good idea to use a more optimized version for youre networked applications. These native libraries are huge for some reason. Can you build a "downloader"? From lyon at docjava.com Sun Jul 23 06:46:43 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 08:46:43 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607231302.59252.pascal@quies.net> References: <200607222048.16215.pascal@quies.net> <200607231302.59252.pascal@quies.net> Message-ID: public static void main(String[] args) { System.out.println("isJava2="+System.getProperty("java.version")); } Prints out 1.5_06 on my system, but you seem to need the "1.2" to be present on the system...right? RXTX does work under 1.5, at least on my system. - DL >Op zondag 23 juli 2006 12:32, schreef Dr. Douglas Lyon: >> Also, the is Java2 check does not check if you are running under >> jdk1.5 >> - DL > >Could you please explain? >The JDK 1.5 will pass the check just fine. >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Jul 23 06:58:02 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 08:58:02 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607231412.34078.pascal@quies.net> References: <200607221843.27765.pascal@quies.net> <200607231412.34078.pascal@quies.net> Message-ID: Hi All, Yes, I do have a download, as to the question of "huge": ls -al native.jar -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar 28kbytes is not really huge, right? In fact, if you uncompress the jar, you get: -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so Which is almost 80kbytes, so the jar is 40% of the native libs size, and it is signed. At least on the Linux version, it is smaller. I did not check the other versions. And with java web start, the JNLP only downloads the native jar if it is new or changed. And it only downloads the native jar used for the target platform. Here is how the jnlp looks, FYI... addbk.JAddressBook.Main DocJava, Inc. I have been playing around with "eager" and "lazy" directives, but I can't really tell the difference. Cheers! - Doug >Op zondag 23 juli 2006 12:54, schreef Dr. Douglas Lyon: >> Hi All, >> Perhaps Java web start can address Gregg's concerns. >> The native libs are placed into a signed jar for distribution. >> As to the assertion that serial-port based programs need file io >> abilities, that seems true, to me. Particularly for /dev/ttyN type >> native libs or libs that use lock files. >> The question of how to obtain a signed application that is given >> file-io authority may be settled by using a signing technology. >> >> Even applets can be signed, to enable improved access to the file >> system. >> >> What else can we try? Any ideas? > >It might be a good idea to use a more optimized version for youre networked >applications. These native libraries are huge for some reason. >Can you build a "downloader"? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 07:53:54 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 15:53:54 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607231302.59252.pascal@quies.net> Message-ID: <200607231553.55088.pascal@quies.net> Op zondag 23 juli 2006 14:46, schreef Dr. Douglas Lyon: > public static void main(String[] args) { > System.out.println("isJava2="+System.getProperty("java.version")); > > } > Prints out 1.5_06 on my system, but you seem to need the "1.2" to be > present on the system...right? if (System.getProperty("java.version").compareTo("1.2") < 0) throw new Error("RXTX requires a Java 2 platform."); The line requires a version string of "1.2" or higher. Sun decided to name all versions since 1.2 as Java 2. (That is why there is this 2 in J2SE.) The error should never happen anyway if you compile the code with the -target 1.2 flag. From pascal at quies.net Sun Jul 23 07:55:52 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 15:55:52 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607231412.34078.pascal@quies.net> Message-ID: <200607231555.52419.pascal@quies.net> Op zondag 23 juli 2006 14:58, schreef Dr. Douglas Lyon: > Hi All, > Yes, I do have a download, as to the question of "huge": > ls -al native.jar > -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar > 28kbytes is not really huge, right? > In fact, if you uncompress the jar, you get: > -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so > -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so > Which is almost 80kbytes, so the jar is 40% of the native libs size, and > it is signed. > At least on the Linux version, it is smaller. I did not check the > other versions. > > And with java web start, the JNLP only downloads the native jar if it is > new or changed. > And it only downloads the native jar used for the target platform. > > Here is how the jnlp looks, FYI... > codebase="http://show.docjava.com:8086/book/cgij/code/jnlp/"> > > addbk.JAddressBook.Main > DocJava, Inc. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have been playing around with "eager" and "lazy" directives, > but I can't really tell the difference. > > Cheers! > - Doug That is a nice sollution. Is there a tag for the architecture too becouse now you assume i386 and that is of course not necesairy true. From joachim at buechse.de Sun Jul 23 11:17:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 23 Jul 2006 19:17:29 +0200 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <41E45C85-4A22-4C5B-915F-62ED36BACCF2@sympatico.ca> References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> <41E45C85-4A22-4C5B-915F-62ED36BACCF2@sympatico.ca> Message-ID: <0B7FC525-4C71-49E8-B652-CCF6C67B4A58@buechse.de> This happens with the versions in CVS (2.07+ and 2.17+). On 22.07.2006, at 19:58, Andr?-John Mas wrote: > A couple of questions: > - what version are you using? > - does this happen with the version in cvs? > > Andre > > On 22-Jul-06, at 13:37 , Joachim Buechse wrote: > >> I just discovered a strange error in RXTX on OSX. SerialDemo.java >> manages to corrupt the event_info_structure by a simple >> OpenPort,ClosePort - this could be in relation to the deadlock >> problem that was reported recently. >> >> Could anyone try to reproduce this on Solaris or some other system >> which is neither WIN32 nor Linux (ie which uses a drain thread). >> >> In SerialImp.c : RXTXPort(interruptEventLoop) >> >> Apparently the event_info_structure gets corrupted shortly after >> >> pthread_kill(index->drain_tid, SIGABRT); >> >> In particular, the index->closing flag gets overwritten by a pointer >> value. >> >> >> **** Adding the following debugging code: >> >> pthread_kill(index->drain_tid, SIGABRT); >> sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i >> \n", index->fd, index, index->closing ); >> report( message ); >> /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ >> usleep(50 * 1000); >> sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i >> \n", index->fd, index, index->closing ); >> report( message ); >> >> **** gives me: >> >> 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 >> drain_loop: received EINTR------------------ drain_loop exiting >> --------------------- >> entering check_tiocmget_changes >> leaving check_tiocmget_changes >> port_has_changed_fionread: change is 0 >> eventLoop: got interrupt >> 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 >> >> **** Modifying SerialImp.h : event_info_struct by moving the >> prev*, next* pointers >> >> jmethodID checkMonitorThread; >> struct event_info_struct *dummy, *dummy2; >> fd_set rfds; >> struct timeval tv_sleep; >> int closing; >> struct event_info_struct *next, *prev; >> >> *** (ie replacing their original position with dummys and moving them >> *** behind the closing flag) results in this: >> >> 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 >> drain_loop: received EINTR------------------ drain_loop exiting >> --------------------- >> entering check_tiocmget_changes >> leaving check_tiocmget_changes >> port_has_changed_fionread: change is 0 >> eventLoop: got interrupt >> 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 >> >> >> *** I was not able to track down the problem. If anyone could check >> wether this happens on other platforms as well, we may get closer to >> a fix. >> >> Regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Sun Jul 23 11:44:48 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 23 Jul 2006 19:44:48 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607230153.32328.pascal@quies.net> References: <44C252BF.6040404@cox.net> <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> <200607230153.32328.pascal@quies.net> Message-ID: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> Gregg's concern was, that extracting the library from the jar and loading it via System.load needs file access privileges. To solve this concern, all that's required is a static method/flag that triggers loading via System.loadLibrary instead (of course, then he needs to make sure, that the library is on the java.library.path). This could also be handled via a system property of course. Regards, Joachim On 23.07.2006, at 01:53, Pascal S. de Kloe wrote: > Hi Joachim, > > I'm not getting it. > How do you easily get a "stub method / flag"? > > > Op zaterdag 22 juli 2006 19:17, schreef Joachim Buechse: >> We could easily have a stub method / flag that allows you to >> explicitly load the native library (via System.loadLibrary ie from >> the java.library.path). In this case the "auto-extraction" would not >> take place. >> >> On 22.07.2006, at 18:30, Gregg Wonderly wrote: >>> Dr. Douglas Lyon wrote: >>>> Hi All, >>>> I like the idea of the native lib in a jar with other classes. >>>> An alternative I did not know would work. >>> >>> I have several applications that run with a security policy. In >>> these >>> applications, native library loading will require an appropriate >>> FilePermission >>> that should be known about ahead of time. The current native >>> library >>> implementation will require the native library to be extracted from >>> the jar and >>> written to disk, requiring a FilePermission("...","write") for that >>> file, and >>> then will also require read access to load the library. I >>> personally don't want >>> to give write access to a JVM for a shared library which can >>> provide a point of >>> abuse by errant code. >>> >>> Gregg Wonderly >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 13:34:17 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 21:34:17 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> References: <200607230153.32328.pascal@quies.net> <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> Message-ID: <200607232134.17451.pascal@quies.net> Aaah, the penny drops. I was reading it as the stub method _root_ flag like using the root of a jar as a context for java.library.path. Thanks for explaining. :) I'll build it right away. Op zondag 23 juli 2006 19:44, schreef Joachim Buechse: > Gregg's concern was, that extracting the library from the jar and > loading it via System.load needs file access privileges. To solve > this concern, all that's required is a static method/flag that > triggers loading via System.loadLibrary instead (of course, then he > needs to make sure, that the library is on the java.library.path). > This could also be handled via a system property of course. > > Regards, > Joachim > > On 23.07.2006, at 01:53, Pascal S. de Kloe wrote: > > Hi Joachim, > > > > I'm not getting it. > > How do you easily get a "stub method / flag"? > > > > Op zaterdag 22 juli 2006 19:17, schreef Joachim Buechse: > >> We could easily have a stub method / flag that allows you to > >> explicitly load the native library (via System.loadLibrary ie from > >> the java.library.path). In this case the "auto-extraction" would not > >> take place. > >> > >> On 22.07.2006, at 18:30, Gregg Wonderly wrote: > >>> Dr. Douglas Lyon wrote: > >>>> Hi All, > >>>> I like the idea of the native lib in a jar with other classes. > >>>> An alternative I did not know would work. > >>> > >>> I have several applications that run with a security policy. In > >>> these > >>> applications, native library loading will require an appropriate > >>> FilePermission > >>> that should be known about ahead of time. The current native > >>> library > >>> implementation will require the native library to be extracted from > >>> the jar and > >>> written to disk, requiring a FilePermission("...","write") for that > >>> file, and > >>> then will also require read access to load the library. I > >>> personally don't want > >>> to give write access to a JVM for a shared library which can > >>> provide a point of > >>> abuse by errant code. > >>> > >>> Gregg Wonderly > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 18:10:45 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 02:10:45 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607232134.17451.pascal@quies.net> References: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> <200607232134.17451.pascal@quies.net> Message-ID: <200607240210.45992.pascal@quies.net> Hello gentleman, The CommunicationAPI class / utility is almost ready. Could you please have a final look and give your opinion? Does anybody know how the SunOS and the Solaris os.name is used? Sun uses just sparc as the description for os.arch. Is it safe to use the 32-bit binaries? @Gregg You can extract the necessary libraries during the installation with the extractNativeLibraries method to the application directory so they get loaded automatically. Is that good enough? @Trent Would you include this class afther any possible comments in the distribution? -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 10884 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060723/d2e99122/CommunicationAPI-0337.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: PlatformNotSupportedException.java Type: text/x-java Size: 1621 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060723/d2e99122/PlatformNotSupportedException-0337.bin From lyon at docjava.com Sun Jul 23 18:14:08 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 20:14:08 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607231555.52419.pascal@quies.net> References: <200607231412.34078.pascal@quies.net> <200607231555.52419.pascal@quies.net> Message-ID: Hi All, The present JNLP distro that I use: > > >> >> > Works for Macs using G3 and G4's. I have not tested this with an i386 mac, as I do not have one. And it only works with i386 based linux... As far as architecture goes: Allows for a chip arch, and this might address your question. The real bottleneck is that you need one of everything to test a deployment, or you have to know a bunch of people (like on this list!) to do a proper test. Cheers! - Doug >Op zondag 23 juli 2006 14:58, schreef Dr. Douglas Lyon: >> Hi All, >> Yes, I do have a download, as to the question of "huge": >> ls -al native.jar >> -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar >> 28kbytes is not really huge, right? >> In fact, if you uncompress the jar, you get: >> -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so >> -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so >> Which is almost 80kbytes, so the jar is 40% of the native libs size, and >> it is signed. >> At least on the Linux version, it is smaller. I did not check the >> other versions. >> >> And with java web start, the JNLP only downloads the native jar if it is >> new or changed. >> And it only downloads the native jar used for the target platform. >> >> Here is how the jnlp looks, FYI... >> > codebase="http://show.docjava.com:8086/book/cgij/code/jnlp/"> >> >> addbk.JAddressBook.Main >> DocJava, Inc. >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > >> >> > > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> I have been playing around with "eager" and "lazy" directives, >> but I can't really tell the difference. >> >> Cheers! >> - Doug > >That is a nice sollution. > >Is there a tag for the architecture too becouse now you assume i386 and that >is of course not necesairy true. >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Sun Jul 23 10:38:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 23 Jul 2006 11:38:50 -0500 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607221843.27765.pascal@quies.net> References: <44C252BF.6040404@cox.net> <200607221843.27765.pascal@quies.net> Message-ID: <44C3A61A.3060706@cox.net> Pascal S. de Kloe wrote: > Op zaterdag 22 juli 2006 18:30, schreef Gregg Wonderly: >>I have several applications that run with a security policy. In these >>applications, native library loading will require an appropriate >>FilePermission that should be known about ahead of time. The current >>native library implementation will require the native library to be >>extracted from the jar and written to disk, requiring a >>FilePermission("...","write") for that file, and then will also require >>read access to load the library. I personally don't want to give write >>access to a JVM for a shared library which can provide a point of abuse by >>errant code. > That's indeed a pitty limitation. It creates a lot of possible exceptions too. > > On the other hand, any native lib passes the securiy model. Applications who > can access hardware ports can be expected to create files, right? The use of an appropriate security policy is a deployment time configuration. There needs to be appropriate limits that confine the software to its intended tasks. Gregg Wonderly From gergg at cox.net Sun Jul 23 10:56:39 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 23 Jul 2006 11:56:39 -0500 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607221920.20096.pascal@quies.net> <200607222048.16215.pascal@quies.net> Message-ID: <44C3AA47.4060003@cox.net> Dr. Douglas Lyon wrote: > The Class.forName is a static method. Therefore > myClass.forName Should be Class.forName and > myClass becomes an unused parameter. Or better yet, make that parameter a context classloader and call Class.forName( classname, classloader); so that the location of the codebase for loading classes can be separate from the applications classpath. Gregg Wonderly From tjarvi at qbang.org Sun Jul 23 20:26:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 20:26:04 -0600 (MDT) Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: I do not see a point of having CommAPI do much more than basic termios interfaces and possibly parallel ports. The kernels can deliver that interface just fine for USB and other types. One problem with the current implementation for USB and IrDA is hotplug. There is a HAL daemon that can send connect and disconnect events which should probably be added to a new API. Sun is also working on a HAL port for Solaris. It is hackish but I saw at the Linux symposium that it will be getting attention and improving. The point being that these events could be included not that HAL is the end of all problems. It would appear to me that anything further in USB space should be done with the/a USB API to avoid duplication of efforts. USB is only one of many low level options for termios interfaces. On Sat, 22 Jul 2006, Joachim Buechse wrote: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. > > It is clear that javax.comm can never provide a way to talk to all > USB devices, simply because some USB devices have several endpoints. > But it could provide a means of talking to devices that function as a > bidirectional-pipe (ie any USB to serial bridge). > > Regards, > Joachim > > On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > >> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>> Pascal S. de Kloe wrote: >>>>>> I am also not sure if >>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>> single >>>>>> port. >>>>> >>>>> I think the API should hide low-level details like devicefiles. >>>> >>>> Not all ports have device files. It's long been my goal to add >>>> support >>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>> servers, for example integrating RFC2217. This means that the >>>> port name >>>> is some combination of an IP address and TCP port number. >>>> Nothing in >>>> /dev. >>> >>> What I think would make the most sense is a simple "device" >>> enumeration >>> Server Provider Interface that would bring port objects into the >>> JVM based >>> on the platform JVM providers knowledge of how to enumerate those >>> ports. >>> Application writers would provide a plugin using the SPI that >>> would codify >>> those devices into named entities that they are interested in. >>> >>> public interface HardwarePort { >>> public String getName(); >>> public String getHardwareID(); >>> public String getManufacturer(); >>> public List getCapabilities(); >>> public Object getImplementation(); >>> } >>> >>> public interface PortCapability { >>> public String getDescription(); >>> public CapabilityId getIdentifier(); >>> } >>> >>> public enum CapabilityId { >>> INPUT, // Can receive input >>> OUTPUT, // Can send output >>> ASYNCHRONOUS, // Can send and receive at the same time >>> SYNCHRONOUS, // No synchronous I/O >>> ADDRESSABLE // Port has an address associated >>> } >>> >>> Then, you might imagine that the enumerated capabilities had a >>> standardized/specified interface that you'd find implemented on >>> ports that >>> had such capabilities. >>> >>> The getImplementation() method would return the implementation class >>> provided by the JVM provider that had all of the interfaces tied >>> to it. >>> >>> These are just some quick thoughts, pick away at them. >>> >>> I am very interested in getting a new comm api in place which can >>> provide >>> the ability for all USB connected devices to have drivers provided >>> as 100% >>> java for all non-timing critical types of device interfaces. >>> >>> The JVM provider should have an SPI to write to which will enable >>> them to >>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>> something >>> that we can talk 100% java to. >>> >>> That's my big desire. Starting with something simple which gives >>> a good >>> start in that direction would be great! >> >> That was exactly my wish too. >> >> The point people brought up was: >> 1) It's too complex. >> 2) What does it solve? >> >> In both facts they are right. It'll take a *long* time to plan such >> a thing >> right but if it works you have a product. Anyway, I'd like to join. ;) >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jul 23 20:31:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 20:31:45 -0600 (MDT) Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607231412.34078.pascal@quies.net> References: <200607221843.27765.pascal@quies.net> <200607231412.34078.pascal@quies.net> Message-ID: On Sun, 23 Jul 2006, Pascal S. de Kloe wrote: > Op zondag 23 juli 2006 12:54, schreef Dr. Douglas Lyon: >> Hi All, >> Perhaps Java web start can address Gregg's concerns. >> The native libs are placed into a signed jar for distribution. >> As to the assertion that serial-port based programs need file io >> abilities, that seems true, to me. Particularly for /dev/ttyN type >> native libs or libs that use lock files. >> The question of how to obtain a signed application that is given >> file-io authority may be settled by using a signing technology. >> >> Even applets can be signed, to enable improved access to the file >> system. >> >> What else can we try? Any ideas? > > It might be a good idea to use a more optimized version for youre networked > applications. These native libraries are huge for some reason. > Can you build a "downloader"? It may be that the binaries are not stripped. "strip librtxserial.so" for instance. That will remove the symbols which are not usually needed in production. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jul 23 20:49:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 20:49:16 -0600 (MDT) Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607240210.45992.pascal@quies.net> References: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> <200607232134.17451.pascal@quies.net> <200607240210.45992.pascal@quies.net> Message-ID: On Mon, 24 Jul 2006, Pascal S. de Kloe wrote: > Hello gentleman, > > The CommunicationAPI class / utility is almost ready. > Could you please have a final look and give your opinion? > > > Does anybody know how the SunOS and the Solaris os.name is used? > > Sun uses just sparc as the description for os.arch. Is it safe to use the > 32-bit binaries? > > > > @Gregg > You can extract the necessary libraries during the installation with the > extractNativeLibraries method to the application directory so they get loaded > automatically. Is that good enough? > > @Trent > Would you include this class afther any possible comments in the distribution? > Hi Pascal, It would appear to me that this is a tool for using the API, not an API. So perhaps the classname is not the best choice. The class also has a main which would not make a great deal of sense to include in the library to me. It would make a nice example for the contrib directory or a new utility directory though. Documentation of its availability in the main document could make it stand out from the other contrib files. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jul 23 21:27:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 21:27:48 -0600 (MDT) Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> Message-ID: On Sat, 22 Jul 2006, Joachim Buechse wrote: > I just discovered a strange error in RXTX on OSX. SerialDemo.java > manages to corrupt the event_info_structure by a simple > OpenPort,ClosePort - this could be in relation to the deadlock > problem that was reported recently. > > Could anyone try to reproduce this on Solaris or some other system > which is neither WIN32 nor Linux (ie which uses a drain thread). > > In SerialImp.c : RXTXPort(interruptEventLoop) > > Apparently the event_info_structure gets corrupted shortly after > > pthread_kill(index->drain_tid, SIGABRT); > > In particular, the index->closing flag gets overwritten by a pointer > value. > > > **** Adding the following debugging code: > > pthread_kill(index->drain_tid, SIGABRT); > sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ > usleep(50 * 1000); > sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > > **** gives me: > > 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 > > **** Modifying SerialImp.h : event_info_struct by moving the > prev*, next* pointers > > jmethodID checkMonitorThread; > struct event_info_struct *dummy, *dummy2; > fd_set rfds; > struct timeval tv_sleep; > int closing; > struct event_info_struct *next, *prev; > > *** (ie replacing their original position with dummys and moving them > *** behind the closing flag) results in this: > > 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 > > > *** I was not able to track down the problem. If anyone could check > wether this happens on other platforms as well, we may get closer to > a fix. > Hi Joachim Interesting. I did run many tests with that code on may OSs. To be fair, the tests are just starting to get into good shape again. I'm still tagging releases with a bit of feel and not enough process. I'll look at this some more tomorrow night. The SIGABRT was added recently as part of the close speedups. Thats from memory. I can provide the exact patch that introduced that tomorrow. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jul 23 22:22:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 22:22:26 -0600 (MDT) Subject: [Rxtx] clarification Message-ID: It should be clear that doug is the maintainer of rxtx.org now. I'll be running around very fast trying to make that easier for him but if you want something in rxtx, it is doug that does that. There are some things doug isnt very good at. He needs some help there. If he asks others for their opinion, thats his call. If he asks others for help, thats his call. This was setup to help the community. I hope everyone makes good use of it as they are now. I'm very happy with what I see but I want to make it clear that nobody should be asking me to be in rxtx. I have interests but they may not always be yours. -- Trent Jarvi tjarvi at qbang.org From guille at sms.nl Mon Jul 24 00:32:26 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Mon, 24 Jul 2006 08:32:26 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <7.0.1.0.0.20060724082455.038aa518@sms.nl> At 18:31 20/07/2006, Trent Jarvi wrote: > > PROJECT SCOPE: > > ------------- > > > > Also, we should think carefully about what the scope of > > this project would be. Should it be javax."comm" which > > handles both serial and parallel (is parallel going by the > > wayside). Should it be split into two project: > > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > > > > Should we differentiate between single-ended serial > > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > > quasi-multidrop and full multidrop busses such as > > EIA422, EIA432 and EIA485? If we really were to > > add I2C support to the API, we'd have to delve into > > the semantics more, because there could be some > > implicit decoding of the bus the API users would > > want to see. > > > >Hi Paul > >The way RXTX works, which is a fair representation of the people using the >API, is complete support for RIA232, minimal support for IEEE1284. From >what I understand, Sun was going along the same lines. If we combined >both projects, we would have half a parallel port implementation. I see >maybe 4 requests for features not in the parallel support a year. > >The other protocols should not be limited by a JSR which is going to be >focused upon serial port interests. The IEA485 hacks in RXTX along with >I2C and Raw should _not_ be considered a strong basis for extending the >API to cover these protocols. If people want to do real implementations, >they should not face a 'standard' which wasnt really focused upon their >interests. I think we understand the parallel port issues fairly well but >have not implemented many features and I don't know if we would. I agree with all of this. API requirements for I2C, SPI, etc. are very different from those for RS232/485/422. Our embedded Java platform has APIs for all of these and more and they don't share a lot apart from the fact that they all use Input/OutputStreams (and in the case of SPI you still need to cater with the fact that every time you want to read you must also write to the device.) If I was to design javax.comm from scratch, I think I would focus on serial ports exclusively (== whatever the underlying OS represents as serial ports). Even parallel is a bit out of place IMHO, although I understand it needs to stay for backwards compatibility. >So a versatile API is favorable but I do not think we have the proper >community to represent much more than Serial. Yes, I think the same. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From joachim at buechse.de Mon Jul 24 01:33:14 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 24 Jul 2006 09:33:14 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607231412.34078.pascal@quies.net> <200607231555.52419.pascal@quies.net> Message-ID: <106C7BEC-EC26-4A05-8E94-61E2C9F2A54E@buechse.de> Or you put your project on Sourceforge and use this: http://sourceforge.net/docs/compile_farm#hosts On 24.07.2006, at 02:14, Dr. Douglas Lyon wrote: > Hi All, > The present JNLP distro that I use: >>> >>> >> download="eager" /> >>> >> > > Works for Macs using G3 and G4's. I have not tested > this with an i386 mac, as I do not have one. And it only works > with i386 based linux... > > As far as architecture goes: > > > > Allows for a chip arch, and this might address your question. > > The real bottleneck is that you need one of everything to test a > deployment, > or you have to know a bunch of people (like on this list!) to do a > proper test. > > Cheers! > - Doug > > >> Op zondag 23 juli 2006 14:58, schreef Dr. Douglas Lyon: >>> Hi All, >>> Yes, I do have a download, as to the question of "huge": >>> ls -al native.jar >>> -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar >>> 28kbytes is not really huge, right? >>> In fact, if you uncompress the jar, you get: >>> -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so >>> -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so >>> Which is almost 80kbytes, so the jar is 40% of the native libs >>> size, and >>> it is signed. >>> At least on the Linux version, it is smaller. I did not check the >>> other versions. >>> >>> And with java web start, the JNLP only downloads the native jar >>> if it is >>> new or changed. >>> And it only downloads the native jar used for the target platform. >>> >>> Here is how the jnlp looks, FYI... >>> >> codebase="http://show.docjava.com:8086/book/cgij/code/ >>> jnlp/"> >>> >>> addbk.JAddressBook.Main >>> DocJava, Inc. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> download="eager" /> >>> >>> >>> >>> >>> >> download="lazy" /> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I have been playing around with "eager" and "lazy" directives, >>> but I can't really tell the difference. >>> >>> Cheers! >>> - Doug >> >> That is a nice sollution. >> >> Is there a tag for the architecture too becouse now you assume >> i386 and that >> is of course not necesairy true. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jul 24 02:13:15 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 24 Jul 2006 10:13:15 +0200 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> Message-ID: <939306BB-2AEE-4D20-906E-9A9B40C76125@buechse.de> The pthread_kill is followed by a sleep. When the sleep returns the structure is damaged. I did not find the source that overwrites the closing field - it is correctly set by the exiting drain thread. But something overwrites it afterwards. I currently believe that this existed for some time but was never seen because the previous versions did not rely on the structure to be in good shape when tearing down connections. However I may be completely wrong and it is an OSX problem. To help me find the source, it would be nice to get some indications what the 2 debug lines I suggested return on other platforms. Joachim On 24.07.2006, at 05:27, Trent Jarvi wrote: > On Sat, 22 Jul 2006, Joachim Buechse wrote: > >> I just discovered a strange error in RXTX on OSX. SerialDemo.java >> manages to corrupt the event_info_structure by a simple >> OpenPort,ClosePort - this could be in relation to the deadlock >> problem that was reported recently. >> >> Could anyone try to reproduce this on Solaris or some other system >> which is neither WIN32 nor Linux (ie which uses a drain thread). >> >> In SerialImp.c : RXTXPort(interruptEventLoop) >> >> Apparently the event_info_structure gets corrupted shortly after >> >> pthread_kill(index->drain_tid, SIGABRT); >> >> In particular, the index->closing flag gets overwritten by a pointer >> value. > > Hi Joachim > > Interesting. I did run many tests with that code on may OSs. To > be fair, > the tests are just starting to get into good shape again. I'm still > tagging releases with a bit of feel and not enough process. I'll > look at > this some more tomorrow night. > > The SIGABRT was added recently as part of the close speedups. > Thats from > memory. I can provide the exact patch that introduced that tomorrow. > > -- > Trent Jarvi > tjarvi at qbang.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Mon Jul 24 05:58:21 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 13:58:21 +0200 Subject: [Rxtx] =?iso-8859-1?q?NativeLibraryManager_-_A_general_solution_a?= =?iso-8859-1?q?n_to_old=09problem=2E?= In-Reply-To: <44C3AA47.4060003@cox.net> References: <44C3AA47.4060003@cox.net> Message-ID: <200607241358.21366.pascal@quies.net> Op zondag 23 juli 2006 18:56, schreef Gregg Wonderly: > Dr. Douglas Lyon wrote: > > The Class.forName is a static method. Therefore > > myClass.forName Should be Class.forName and > > myClass becomes an unused parameter. > > Or better yet, make that parameter a context classloader and call > > Class.forName( classname, classloader); > > so that the location of the codebase for loading classes can be separate > from the applications classpath. I agree. -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 10719 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060724/693f269d/CommunicationAPI-0337.bin From pascal at quies.net Mon Jul 24 06:05:53 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 14:05:53 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607240210.45992.pascal@quies.net> Message-ID: <200607241405.53456.pascal@quies.net> Op maandag 24 juli 2006 04:49, schreef Trent Jarvi: > > @Trent > > Would you include this class afther any possible comments in the > > distribution? > > Hi Pascal, > > It would appear to me that this is a tool for using the API, not an API. > So perhaps the classname is not the best choice. > > The class also has a main which would not make a great deal of sense to > include in the library to me. It would make a nice example for the > contrib directory or a new utility directory though. Documentation of its > availability in the main document could make it stand out from the other > contrib files. The name-change and the removal of main() would ofcourse be no problem. You really don't want to distribute binaries, huh? How can the developers of RXTX know whether it works on a machine they don't have? Anyway, I don't see anotherway to get a version of the extension "that just works" than to build my own distribution. :@ I also can't believe that nobody on this list has binaries for official supported platforms like Windows IA64 and Windows x86_64 unless the build fails on these platforms (which would be nice to know). http://java.sun.com/j2se/1.4.2/system-configurations.html http://java.sun.com/j2se/1.5.0/system-configurations.html From pascal at quies.net Mon Jul 24 06:08:45 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 14:08:45 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <106C7BEC-EC26-4A05-8E94-61E2C9F2A54E@buechse.de> References: <106C7BEC-EC26-4A05-8E94-61E2C9F2A54E@buechse.de> Message-ID: <200607241408.45956.pascal@quies.net> Op maandag 24 juli 2006 09:33, schreef Joachim Buechse: > Or you put your project on Sourceforge and use this: > > http://sourceforge.net/docs/compile_farm#hosts That's nice. :) I'll host a distribution on Sourceforge real soon. HP also has a such a facility for PA-RISC and IA64 architectures at http://www.testdrive.hp.com/ The other day I was thinking about building a big bittorrent with Qemu images for developers. The number of platforms seems impressive: http://qemu.org/status.html With each image compressed with bzip2 a clean installation of OpenBSD and FreeBSD and a Debian Woody + gmake + gcc for each Qemu platform will take about 1.5GB. From lyon at docjava.com Mon Jul 24 07:07:02 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 24 Jul 2006 09:07:02 -0400 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060724082455.038aa518@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: Hi All, There has been a lot of discussion regarding RS485. Let me see if I can summarize this, please correct me if I am wrong; I am deliberately ignoring connector and electrical issues, focusing, instead, on protocol and software issues. Also, I have never used RS485, and I don't know much about it. 1. Serial ports that claim RS232 are typically used in the data link layer of the OSI model of networking. Basically, this means that they work with a point-to-point protocol and are meant to connect two devices. 2. Within the RS232 standard there are framing bits (start and stop bits) and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. Thats' it. 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) you do it in software, not in the RS232 standard. 4. RS485 is different from RS232 in that it is in the Network Layer of the OSI model of networking. 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in a factory). RS-485 is similar to RS-422, but RS-422 allows just one driver with multiple receivers whereas RS-485 supports multiple drivers and receivers. 6. RS-485 is a serial bus with multiple nodes and thus must handle network link layer protocols. By using high-impedance receivers, you can have as many as 256 nodes. 7. The RS-485 can be implemented with RXTX in the core and a layer of software on top to handle media access control (MAC sublayer). There are also hardware converters. http://www.rs485.com/pconverters.html for example. However, some of these require software control. There is some support in the form of the Rs485.java class, in RXTX. 8. The RS-485 specification will add to the size of the JSR 9. Javax.comm specification, version 2.0 (the Real OLD version) says: This version of the Java communications API contains support for RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not mentioned. 10. DO people want to add RS485 to a new JSR? Would it make sense for the RS-485 people to speak up now? Please let me know if you think my summary is wrong. Thanks! - Doug >At 18:31 20/07/2006, Trent Jarvi wrote: >> > PROJECT SCOPE: >> > ------------- >> > >> > Also, we should think carefully about what the scope of >> > this project would be. Should it be javax."comm" which >> > handles both serial and parallel (is parallel going by the >> > wayside). Should it be split into two project: >> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >> > >> > Should we differentiate between single-ended serial >> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >> > quasi-multidrop and full multidrop busses such as >> > EIA422, EIA432 and EIA485? If we really were to >> > add I2C support to the API, we'd have to delve into >> > the semantics more, because there could be some >> > implicit decoding of the bus the API users would >> > want to see. >> > >> >>Hi Paul >> >>The way RXTX works, which is a fair representation of the people using the >>API, is complete support for RIA232, minimal support for IEEE1284. From >>what I understand, Sun was going along the same lines. If we combined >>both projects, we would have half a parallel port implementation. I see >>maybe 4 requests for features not in the parallel support a year. >> >>The other protocols should not be limited by a JSR which is going to be >>focused upon serial port interests. The IEA485 hacks in RXTX along with >>I2C and Raw should _not_ be considered a strong basis for extending the >>API to cover these protocols. If people want to do real implementations, >>they should not face a 'standard' which wasnt really focused upon their >>interests. I think we understand the parallel port issues fairly well but >>have not implemented many features and I don't know if we would. > >I agree with all of this. API requirements for I2C, SPI, etc. are very >different from those for RS232/485/422. Our embedded Java platform has >APIs for all of these and more and they don't share a lot apart from the >fact that they all use Input/OutputStreams (and in the case of SPI you >still need to cater with the fact that every time you want to read you >must also write to the device.) > >If I was to design javax.comm from scratch, I think I would focus on >serial ports exclusively (== whatever the underlying OS represents as >serial ports). Even parallel is a bit out of place IMHO, although I >understand it needs to stay for backwards compatibility. > > >>So a versatile API is favorable but I do not think we have the proper >>community to represent much more than Serial. > >Yes, I think the same. > >Guillermo >-- >Guillermo Rodriguez Garcia > >Snijder Micro Systems phone +31-493-351020 >G. Rodriguez Garcia fax +31-493-351530 >Visser 25 email guille at sms.nl >NL5751 BL Deurne >The Netherlands http://www.snijder.com > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Mon Jul 24 07:46:55 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Mon, 24 Jul 2006 10:46:55 -0300 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: <44C4CF4F.1080706@gmail.com> Doug: I do not think that RS485 is a must by now. I do think we must make a JSR to standarize a bit Serial Ports accessing. Maybe we can make a JSR just for serial ports, and then start trying with other kind of ports and make others JSR. Or try to expand our first JSR, but I trully do not know if that can be made. About other ports besides RS485, the others I2C, SPI, etc, run at a very low level, maybe too close to the processor for Java. I do not know if Java is fast enough to access this ports, even more as this ports depends directly from the architecture, the write once run every way of Java is somekind useless at this level, so I do not think this is suitable for us. Regards, Manuel > Hi All, > There has been a lot of discussion regarding RS485. > > Let me see if I can summarize this, please correct me if I am wrong; > I am deliberately ignoring connector and electrical issues, focusing, > instead, on protocol and software issues. Also, I have never used > RS485, and I don't know much about it. > > 1. Serial ports that claim RS232 are typically used in > the data link layer of the OSI model of networking. Basically, this means > that they work with a point-to-point protocol and are meant to connect two > devices. > > 2. Within the RS232 standard there are framing bits (start and stop bits) > and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. > Thats' it. > > 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) > you do it in software, not in the RS232 standard. > > 4. RS485 is different from RS232 in that it is in the Network Layer of > the OSI model of networking. > > 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > a factory). > RS-485 is similar to RS-422, but RS-422 allows just one driver with > multiple receivers whereas RS-485 supports multiple drivers and > receivers. > > 6. RS-485 is a serial bus with multiple nodes and thus must handle network > link layer protocols. By using high-impedance receivers, you can have > as many as 256 nodes. > > 7. The RS-485 can be implemented with RXTX in the core and a layer of software > on top to handle media access control (MAC sublayer). There are also > hardware converters. > http://www.rs485.com/pconverters.html for example. However, some of > these require software control. There is some support in the form of > the Rs485.java class, > in RXTX. > > 8. The RS-485 specification will add to the size of the JSR > > 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > This version of the Java communications API contains support for > RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > mentioned. > > 10. DO people want to add RS485 to a new JSR? > > Would it make sense for the RS-485 people to speak up now? > Please let me know if you think my summary is wrong. > > Thanks! > - Doug > > > > > > >> At 18:31 20/07/2006, Trent Jarvi wrote: >> >>> > PROJECT SCOPE: >>> > ------------- >>> > >>> > Also, we should think carefully about what the scope of >>> > this project would be. Should it be javax."comm" which >>> > handles both serial and parallel (is parallel going by the >>> > wayside). Should it be split into two project: >>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>> > >>> > Should we differentiate between single-ended serial >>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>> > quasi-multidrop and full multidrop busses such as >>> > EIA422, EIA432 and EIA485? If we really were to >>> > add I2C support to the API, we'd have to delve into >>> > the semantics more, because there could be some >>> > implicit decoding of the bus the API users would >>> > want to see. >>> > >>> >>> Hi Paul >>> >>> The way RXTX works, which is a fair representation of the people using the >>> API, is complete support for RIA232, minimal support for IEEE1284. From >>> what I understand, Sun was going along the same lines. If we combined >>> both projects, we would have half a parallel port implementation. I see >>> maybe 4 requests for features not in the parallel support a year. >>> >>> The other protocols should not be limited by a JSR which is going to be >>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>> I2C and Raw should _not_ be considered a strong basis for extending the >>> API to cover these protocols. If people want to do real implementations, >>> they should not face a 'standard' which wasnt really focused upon their >>> interests. I think we understand the parallel port issues fairly well but >>> have not implemented many features and I don't know if we would. >>> >> I agree with all of this. API requirements for I2C, SPI, etc. are very >> different from those for RS232/485/422. Our embedded Java platform has >> APIs for all of these and more and they don't share a lot apart from the >> fact that they all use Input/OutputStreams (and in the case of SPI you >> still need to cater with the fact that every time you want to read you >> must also write to the device.) >> >> If I was to design javax.comm from scratch, I think I would focus on >> serial ports exclusively (== whatever the underlying OS represents as >> serial ports). Even parallel is a bit out of place IMHO, although I >> understand it needs to stay for backwards compatibility. >> >> >> >>> So a versatile API is favorable but I do not think we have the proper >>> community to represent much more than Serial. >>> >> Yes, I think the same. >> >> Guillermo >> -- >> Guillermo Rodriguez Garcia >> >> Snijder Micro Systems phone +31-493-351020 >> G. Rodriguez Garcia fax +31-493-351530 >> Visser 25 email guille at sms.nl >> NL5751 BL Deurne >> The Netherlands http://www.snijder.com >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From gergg at cox.net Mon Jul 24 07:51:53 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 08:51:53 -0500 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607240210.45992.pascal@quies.net> References: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> <200607232134.17451.pascal@quies.net> <200607240210.45992.pascal@quies.net> Message-ID: <44C4D079.80609@cox.net> Pascal S. de Kloe wrote: > @Gregg > You can extract the necessary libraries during the installation with the > extractNativeLibraries method to the application directory so they get loaded > automatically. Is that good enough? If you start the JVM with -Djava.security.manager what permissions are required? Can you send me a policy that is applicable so that I can review what permissions are being required? Gregg Wonderly From gergg at cox.net Mon Jul 24 07:54:22 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 08:54:22 -0500 Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: <44C4D10E.50604@cox.net> Joachim Buechse wrote: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. Sorry for the late reply here. My intent was this. That there could be a low level port/device SPI that could be put in place once, and then overtime we could layer other APIs, including an updated javax.comm which would make use of this SPI. Gregg Wonderly From cmalan at lhar.co.za Mon Jul 24 08:04:01 2006 From: cmalan at lhar.co.za (Christo Malan) Date: Mon, 24 Jul 2006 16:04:01 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: <44C4D351.603@lhar.co.za> Hi I don't think RS-485 belong in rxtx, the scope of the spec is not wide enough as it only specify the electrical layer. Their is no data protocol recommended or defined. This mean that we have no idea when to sample for a bit, how long is a bit and how many bits before we can say new data is available. Christo Dr. Douglas Lyon wrote: > Hi All, > There has been a lot of discussion regarding RS485. > > Let me see if I can summarize this, please correct me if I am wrong; > I am deliberately ignoring connector and electrical issues, focusing, > instead, on protocol and software issues. Also, I have never used > RS485, and I don't know much about it. > > 1. Serial ports that claim RS232 are typically used in > the data link layer of the OSI model of networking. Basically, this means > that they work with a point-to-point protocol and are meant to connect two > devices. > > 2. Within the RS232 standard there are framing bits (start and stop bits) > and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. > Thats' it. > > 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) > you do it in software, not in the RS232 standard. > > 4. RS485 is different from RS232 in that it is in the Network Layer of > the OSI model of networking. > > 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > a factory). > RS-485 is similar to RS-422, but RS-422 allows just one driver with > multiple receivers whereas RS-485 supports multiple drivers and > receivers. > > 6. RS-485 is a serial bus with multiple nodes and thus must handle network > link layer protocols. By using high-impedance receivers, you can have > as many as 256 nodes. > > 7. The RS-485 can be implemented with RXTX in the core and a layer of software > on top to handle media access control (MAC sublayer). There are also > hardware converters. > http://www.rs485.com/pconverters.html for example. However, some of > these require software control. There is some support in the form of > the Rs485.java class, > in RXTX. > > 8. The RS-485 specification will add to the size of the JSR > > 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > This version of the Java communications API contains support for > RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > mentioned. > > 10. DO people want to add RS485 to a new JSR? > > Would it make sense for the RS-485 people to speak up now? > Please let me know if you think my summary is wrong. > > Thanks! > - Doug > > > > > > >> At 18:31 20/07/2006, Trent Jarvi wrote: >> >>> > PROJECT SCOPE: >>> > ------------- >>> > >>> > Also, we should think carefully about what the scope of >>> > this project would be. Should it be javax."comm" which >>> > handles both serial and parallel (is parallel going by the >>> > wayside). Should it be split into two project: >>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>> > >>> > Should we differentiate between single-ended serial >>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>> > quasi-multidrop and full multidrop busses such as >>> > EIA422, EIA432 and EIA485? If we really were to >>> > add I2C support to the API, we'd have to delve into >>> > the semantics more, because there could be some >>> > implicit decoding of the bus the API users would >>> > want to see. >>> > >>> >>> Hi Paul >>> >>> The way RXTX works, which is a fair representation of the people using the >>> API, is complete support for RIA232, minimal support for IEEE1284. From >>> what I understand, Sun was going along the same lines. If we combined >>> both projects, we would have half a parallel port implementation. I see >>> maybe 4 requests for features not in the parallel support a year. >>> >>> The other protocols should not be limited by a JSR which is going to be >>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>> I2C and Raw should _not_ be considered a strong basis for extending the >>> API to cover these protocols. If people want to do real implementations, >>> they should not face a 'standard' which wasnt really focused upon their >>> interests. I think we understand the parallel port issues fairly well but >>> have not implemented many features and I don't know if we would. >>> >> I agree with all of this. API requirements for I2C, SPI, etc. are very >> different from those for RS232/485/422. Our embedded Java platform has >> APIs for all of these and more and they don't share a lot apart from the >> fact that they all use Input/OutputStreams (and in the case of SPI you >> still need to cater with the fact that every time you want to read you >> must also write to the device.) >> >> If I was to design javax.comm from scratch, I think I would focus on >> serial ports exclusively (== whatever the underlying OS represents as >> serial ports). Even parallel is a bit out of place IMHO, although I >> understand it needs to stay for backwards compatibility. >> >> >> >>> So a versatile API is favorable but I do not think we have the proper >>> community to represent much more than Serial. >>> >> Yes, I think the same. >> >> Guillermo >> -- >> Guillermo Rodriguez Garcia >> >> Snijder Micro Systems phone +31-493-351020 >> G. Rodriguez Garcia fax +31-493-351530 >> Visser 25 email guille at sms.nl >> NL5751 BL Deurne >> The Netherlands http://www.snijder.com >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > From pascal at quies.net Mon Jul 24 08:19:03 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 16:19:03 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <44C4D079.80609@cox.net> References: <200607240210.45992.pascal@quies.net> <44C4D079.80609@cox.net> Message-ID: <200607241619.04053.pascal@quies.net> Op maandag 24 juli 2006 15:51, schreef Gregg Wonderly: > Pascal S. de Kloe wrote: > > @Gregg > > You can extract the necessary libraries during the installation with the > > extractNativeLibraries method to the application directory so they get > > loaded automatically. Is that good enough? > > If you start the JVM with -Djava.security.manager what permissions are > required? Can you send me a policy that is applicable so that I can review > what permissions are being required? Just look at the javadoc in CommunicationAPI.java for SecurityExceptions. ;) From gergg at cox.net Mon Jul 24 08:21:49 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 09:21:49 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4CF4F.1080706@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> Message-ID: <44C4D77D.5080200@cox.net> Manuel Francisco Naranjo wrote: > Doug: > I do not think that RS485 is a must by now. I do think we must make a > JSR to standarize a bit Serial Ports accessing. Maybe we can make a JSR > just for serial ports, and then start trying with other kind of ports > and make others JSR. Or try to expand our first JSR, but I trully do > not know if that can be made. I think that anyone aimed at the javax.comm space should be interested in creating a hardware access SPI first. This is the predominate stumbling block for java having access to various hardware devices. The more we can promote as a standard, the more we can expect consistency and availability! > About other ports besides RS485, the others I2C, SPI, etc, run at a very > low level, maybe too close to the processor for Java. SPI (not service provider interface) is a great protocol for disparet systems because the clocking is synchronous based on the fastest speed available at each end. This means that you can do SPI, today, in java by connecting serial port signal lines, or parallel port data lines to an SPI device, and bit banging the protocol. It won't be lightening fast, but it will be very much functional. What would make the most since is the ability for applications to designate various signalling line sources such as serial signaling lines and parallel port data lines as SPI data, slave select and clock signals, and plug those into an existing API. public class SPISlaveSelectLine { public SPISlaveSelectLine( int slave, SignalPort sp ) { ... } } public class SPIClockLine { public SPIClockLine( SignalPort sp ) { ... } } public class SPIDataLine { public SPIDataLine( SignalPort sp ) { ... } } I'd really like to see the embedded systems community take up this task and push these kinds of things forward. Having standard APIs would make it possible to run your software on aJile's AJ processors, the Muvium PIC environment, javacard, J2ME, etc. Imagine being able to plug a cellphone into the wall, attach a cable which has signalling lines and presto a remote terminal for monitoring and control. Data collection is a very needed capability as the next wave of technology evolution. The Java platform is not enabled with APIs to do this trivially yet. So, it doesn't look viable to many... Gregg Wonderly From guille at sms.nl Mon Jul 24 08:37:21 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 16:37:21 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: <1153751841.44c4db21de4bb@webmail.eatserver.nl> Hi Doug, Some comments below. Quoting "Dr. Douglas Lyon" : > Hi All, > There has been a lot of discussion regarding RS485. > > Let me see if I can summarize this, please correct me if I am wrong; > I am deliberately ignoring connector and electrical issues, focusing, > instead, on protocol and software issues. Also, I have never used > RS485, and I don't know much about it. > > 1. Serial ports that claim RS232 are typically used in > the data link layer of the OSI model of networking. Basically, this means > that they work with a point-to-point protocol and are meant to connect two > devices. It is actually physical + link (layers 1 and 2 of the OSI model), but yes, this is essentially right. > > 2. Within the RS232 standard there are framing bits (start and stop bits) > and error control bits (parity). The flow control is xon-xoff or DTR, CTS, > RTS. Thats' it. I'm not even sure that the RS232 standard talks about xon-xoff and such, I think it does not do much more than defining the electrical signals. Also note that RS232 was originally defined for the DTE-DCE interface (e.g. a device such as a modem connected to a computer). The current use of RS232 as a "general purpose" point to point link is a generalization of the RS232 standard. > > 3. If you want more than that from RS232 (forward error correction, ARQ, > etc.) > you do it in software, not in the RS232 standard. > > 4. RS485 is different from RS232 in that it is in the Network Layer of > the OSI model of networking. I would not put it that way. RS485 is very similar to RS232 with three main differences: - Only tx/rx, no extra signals such as DTR, RTS, CTS, etc (but then many "RS232" serial ports don't have them either) - Different electrical specs (which do not concern us here) - Multidrop and only one node talks at a given time (half duplex) But it does not define addresses (many RS485-based protocol use addresses for the nodes but that's not part of the RS485 standard), routing, etc. For software developers it still looks like a serial port (which it is!) except for the half-duplex part. More on this below. So RS485 is still about layers 1 and 2, same as RS232. I think all of this could be easier if we talk about UARTs instead of "RS232/RS485/RS422". All of these three are typically UARTs with some sort of buffer to get the electrical levels right: RS232 interface == UART + RS232 buffer/transceiver RS485 interface == UART + RS485 buffer/transceiver RS422 interface == UART + RS422 buffer/transceiver > > 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > a factory). > RS-485 is similar to RS-422, but RS-422 allows just one driver with > multiple receivers whereas RS-485 supports multiple drivers and > receivers. RS422 is exactly the same as RS485 except that it uses 4 wires instead of 2 wires so it can be full duplex again (but again this depends on the protocol you layer on top) > > 6. RS-485 is a serial bus with multiple nodes and thus must handle network > link layer protocols. By using high-impedance receivers, you can have > as many as 256 nodes. > > 7. The RS-485 can be implemented with RXTX in the core and a layer of > software > on top to handle media access control (MAC sublayer). There are also > hardware converters. > http://www.rs485.com/pconverters.html for example. However, some of > these require software control. There is some support in the form of > the Rs485.java class, > in RXTX. > > 8. The RS-485 specification will add to the size of the JSR > > 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > This version of the Java communications API contains support for > RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > mentioned. > > 10. DO people want to add RS485 to a new JSR? > > Would it make sense for the RS-485 people to speak up now? > Please let me know if you think my summary is wrong. Basically, for a software developer the only difference between RS485 and RS232 is the half-duplex nature of RS485, which means that you cannot receive and send at the same time. This has some implications depending on how RS485 is implemented in hardware, and on the (application) protocol defined on top of RS485. As I said, a RS485 interface is normally implemented using a standard UART plus a RS485 buffer/transceiver. RS485 buffers/transceivers can be in transmit mode or in receive mode. In a given RS485 bus, only one node should be in transmit mode at any given time, with the rest of the nodes 'listening' until it is their turn to transmit (and it is the application level protocol the one defines who should transmit next.) The RS485 chips used as buffers/transceivers normally have a control pin that is used to switch them into transmit or receive mode. There are typically three ways to handle this: 1. One of the control signals from the UART, such as RTS, DTR, etc. is connected to this control pin. The software must explicitly toggle this signal in order to switch the RS485 buffer/transceiver into transmit or receive mode. This puts a lot of burden on the software side and is sometimes unreliable because of complex timing issues as well as issues with buffering at the device driver level, but it is still a popular solution. 2. The UART itself knows about RS485 and can be configured to control the RS485 buffer/transceiver automatically, without any sort of software intervention. This is a very good solution since it is transparent to the software. However most UARTs don't know about RS485. 3. Standard UART + some custom hardware to control the direction pin. This is also transparent to the software. RS232/RS485 converters are an example of this approach. Implications for the software: For 3/ the software does not need to do anything special. For 2/ all you need is some sort of mechanism to tell the UART to enter RS485-mode (typically a ioctlex). For 1/ there is no simple solution. The timing issues make it difficult to implement this sort of mechanism in user space so it is often done at the device driver level. If this is the case, then all one needs is a mechanism to tell the driver to enter RS485-mode (again, a ioctlex). If this is NOT the case, then the application will need to take care. To do this more or less reliably, you would probably need a couple of things: - Some way to disable software buffering (and FIFOs if possible) - Some way to poll the UART's serial transmit register so that you can determine exactly when all data has been sent (many UARTs don't even support this) and switch to receive mode. - High resolution timers. - Real-time capabilities. Pretty strict requirements as you can see, which is why this approach never works very well except for very specific applications. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From naranjo.manuel at gmail.com Mon Jul 24 08:39:15 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Mon, 24 Jul 2006 11:39:15 -0300 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D77D.5080200@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> Message-ID: <44C4DB93.8080008@gmail.com> Gregg: Thanks for taking me out of the dark ;). Trully I did not know that SPI was an underlaying level of Serial ports, and Parallel ports. I give back what I said. I also would like to see my cell phone plug to every were, and be able to program it with java, is just that I do not know if we are going to get ourselves in a very almost unfinishable task. Regards, Manuel > Manuel Francisco Naranjo wrote: > >> Doug: >> I do not think that RS485 is a must by now. I do think we must make a >> JSR to standarize a bit Serial Ports accessing. Maybe we can make a JSR >> > > just for serial ports, and then start trying with other kind of ports > > and make others JSR. Or try to expand our first JSR, but I trully do > > not know if that can be made. > > I think that anyone aimed at the javax.comm space should be interested in > creating a hardware access SPI first. This is the predominate stumbling > block for java having access to various hardware devices. The more we can > promote as a standard, the more we can expect consistency and availability! > > >> About other ports besides RS485, the others I2C, SPI, etc, run at a very >> low level, maybe too close to the processor for Java. >> > > SPI (not service provider interface) is a great protocol for disparet systems > because the clocking is synchronous based on the fastest speed available at each > end. This means that you can do SPI, today, in java by connecting serial port > signal lines, or parallel port data lines to an SPI device, and bit banging the > protocol. It won't be lightening fast, but it will be very much functional. > What would make the most since is the ability for applications to designate > various signalling line sources such as serial signaling lines and parallel port > data lines as SPI data, slave select and clock signals, and plug those into an > existing API. > > public class SPISlaveSelectLine { > public SPISlaveSelectLine( int slave, SignalPort sp ) { > ... > } > } > > public class SPIClockLine { > public SPIClockLine( SignalPort sp ) { > ... > } > } > > public class SPIDataLine { > public SPIDataLine( SignalPort sp ) { > ... > } > } > > I'd really like to see the embedded systems community take up this task and push > these kinds of things forward. Having standard APIs would make it possible to > run your software on aJile's AJ processors, the Muvium PIC environment, > javacard, J2ME, etc. Imagine being able to plug a cellphone into the wall, > attach a cable which has signalling lines and presto a remote terminal for > monitoring and control. > > Data collection is a very needed capability as the next wave of technology > evolution. The Java platform is not enabled with APIs to do this trivially yet. > So, it doesn't look viable to many... > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From guille at sms.nl Mon Jul 24 08:41:21 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 16:41:21 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D351.603@lhar.co.za> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: <1153752081.44c4dc11eedf3@webmail.eatserver.nl> Quoting Christo Malan : > Hi > > I don't think RS-485 belong in rxtx, the scope of the spec is not wide > enough as it only specify the electrical layer. Their is no data > protocol recommended or defined. RS485 is exactly at the same level as RS232, no more and no less. > This mean that we have no idea when to > sample for a bit, how long is a bit and how many bits before we can say > new data is available. A "RS485 serial port" is just a UART whose output complies with the RS485 electrical spec, just as a "RS232 serial port" is just a UART whose output complies with the RS232 electrical spec. Bit times, sampling intervals, character structure etc. are the same for both protocols... Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From tjarvi at qbang.org Mon Jul 24 08:44:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 24 Jul 2006 08:44:53 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D351.603@lhar.co.za> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: A JSR/JCP would not just involve RXTX. In fact it would be very nice to have others with expertise in various areas like I2C, IrDA, RS485, RS422, ... involved. Within the RXTX community, I do not think we have enough depth to tackle RS485 alone. I'm aware of some of the low level issues but to be honest, I've never actually used it. The RS485 classes in RXTX are more like notes to myself about the issues involved without hardware solutions. In operating systems like Linux, this may be much less of an issue in the future. Linux is putting realtime patches now in the kernels which could make RS485 over EIA232 possible. This is probably the last chance RS485 has to get into a published spec for a long time though. Right now, I do not think its reasonable to include it in the process. Others could make that less of a problem. On Mon, 24 Jul 2006, Christo Malan wrote: > Hi > > I don't think RS-485 belong in rxtx, the scope of the spec is not wide > enough as it only specify the electrical layer. Their is no data > protocol recommended or defined. This mean that we have no idea when to > sample for a bit, how long is a bit and how many bits before we can say > new data is available. > > Christo > > Dr. Douglas Lyon wrote: >> Hi All, >> There has been a lot of discussion regarding RS485. >> >> Let me see if I can summarize this, please correct me if I am wrong; >> I am deliberately ignoring connector and electrical issues, focusing, >> instead, on protocol and software issues. Also, I have never used >> RS485, and I don't know much about it. >> >> 1. Serial ports that claim RS232 are typically used in >> the data link layer of the OSI model of networking. Basically, this means >> that they work with a point-to-point protocol and are meant to connect two >> devices. >> >> 2. Within the RS232 standard there are framing bits (start and stop bits) >> and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. >> Thats' it. >> >> 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) >> you do it in software, not in the RS232 standard. >> >> 4. RS485 is different from RS232 in that it is in the Network Layer of >> the OSI model of networking. >> >> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in >> a factory). >> RS-485 is similar to RS-422, but RS-422 allows just one driver with >> multiple receivers whereas RS-485 supports multiple drivers and >> receivers. >> >> 6. RS-485 is a serial bus with multiple nodes and thus must handle network >> link layer protocols. By using high-impedance receivers, you can have >> as many as 256 nodes. >> >> 7. The RS-485 can be implemented with RXTX in the core and a layer of software >> on top to handle media access control (MAC sublayer). There are also >> hardware converters. >> http://www.rs485.com/pconverters.html for example. However, some of >> these require software control. There is some support in the form of >> the Rs485.java class, >> in RXTX. >> >> 8. The RS-485 specification will add to the size of the JSR >> >> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: >> This version of the Java communications API contains support for >> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not >> mentioned. >> >> 10. DO people want to add RS485 to a new JSR? >> >> Would it make sense for the RS-485 people to speak up now? >> Please let me know if you think my summary is wrong. >> >> Thanks! >> - Doug >> >> >> >> >> >> >>> At 18:31 20/07/2006, Trent Jarvi wrote: >>> >>>> > PROJECT SCOPE: >>>> > ------------- >>>> > >>>> > Also, we should think carefully about what the scope of >>>> > this project would be. Should it be javax."comm" which >>>> > handles both serial and parallel (is parallel going by the >>>> > wayside). Should it be split into two project: >>>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>>> > >>>> > Should we differentiate between single-ended serial >>>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>>> > quasi-multidrop and full multidrop busses such as >>>> > EIA422, EIA432 and EIA485? If we really were to >>>> > add I2C support to the API, we'd have to delve into >>>> > the semantics more, because there could be some >>>> > implicit decoding of the bus the API users would >>>> > want to see. >>>> > >>>> >>>> Hi Paul >>>> >>>> The way RXTX works, which is a fair representation of the people using the >>>> API, is complete support for RIA232, minimal support for IEEE1284. From >>>> what I understand, Sun was going along the same lines. If we combined >>>> both projects, we would have half a parallel port implementation. I see >>>> maybe 4 requests for features not in the parallel support a year. >>>> >>>> The other protocols should not be limited by a JSR which is going to be >>>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>>> I2C and Raw should _not_ be considered a strong basis for extending the >>>> API to cover these protocols. If people want to do real implementations, >>>> they should not face a 'standard' which wasnt really focused upon their >>>> interests. I think we understand the parallel port issues fairly well but >>>> have not implemented many features and I don't know if we would. >>>> >>> I agree with all of this. API requirements for I2C, SPI, etc. are very >>> different from those for RS232/485/422. Our embedded Java platform has >>> APIs for all of these and more and they don't share a lot apart from the >>> fact that they all use Input/OutputStreams (and in the case of SPI you >>> still need to cater with the fact that every time you want to read you >>> must also write to the device.) >>> >>> If I was to design javax.comm from scratch, I think I would focus on >>> serial ports exclusively (== whatever the underlying OS represents as >>> serial ports). Even parallel is a bit out of place IMHO, although I >>> understand it needs to stay for backwards compatibility. >>> >>> >>> >>>> So a versatile API is favorable but I do not think we have the proper >>>> community to represent much more than Serial. >>>> >>> Yes, I think the same. >>> >>> Guillermo >>> -- >>> Guillermo Rodriguez Garcia >>> >>> Snijder Micro Systems phone +31-493-351020 >>> G. Rodriguez Garcia fax +31-493-351530 >>> Visser 25 email guille at sms.nl >>> NL5751 BL Deurne >>> The Netherlands http://www.snijder.com >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From guille at sms.nl Mon Jul 24 08:47:47 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 16:47:47 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D77D.5080200@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> Message-ID: <1153752467.44c4dd93c08f7@webmail.eatserver.nl> Hi Gregg, Quoting Gregg Wonderly : > SPI (not service provider interface) is a great protocol for disparet systems > > because the clocking is synchronous based on the fastest speed available at > each > end. This means that you can do SPI, today, in java by connecting serial > port > signal lines, or parallel port data lines to an SPI device, and bit banging > the > protocol. It won't be lightening fast, but it will be very much functional. [...] > I'd really like to see the embedded systems community take up this task and > push > these kinds of things forward. Having standard APIs would make it possible > to > run your software on aJile's AJ processors, the Muvium PIC environment, > javacard, J2ME, etc. Imagine being able to plug a cellphone into the wall, > attach a cable which has signalling lines and presto a remote terminal for > monitoring and control. As an embedded Java vendor, SNIJDER Micro Systems certainly sees the value of standardized APIs to talk to different types of communication buses including SPI, I2C, 1-Wire, etc., for embedded applications. However we think this has nothing to do with javax.comm. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From guille at sms.nl Mon Jul 24 09:05:22 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 17:05:22 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4DB93.8080008@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <44C4DB93.8080008@gmail.com> Message-ID: <1153753522.44c4e1b24f2e1@webmail.eatserver.nl> Quoting Manuel Francisco Naranjo : > Gregg: > Thanks for taking me out of the dark ;). Trully I did not know that SPI > was an underlaying level of Serial ports, and Parallel ports. In fact it isn't; it is just another serial protocol, just like I2C. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From jredman at ergotech.com Mon Jul 24 09:29:10 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 09:29:10 -0600 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: <44C4E746.8070808@ergotech.com> Folks, The RS232/485/422/etc. etc. is a complete red herring (http://en.wikipedia.org/wiki/Red_herring in case you don't know the expression). The differences between the two are at the electrical level, not at the RXTX level. I'll provide a concrete example and see if we can get away from this issue. There's an industrial serial communications standard - Modbus. Modbus capable devices are very common and can be purchased, generally, with an RS232 or a 485 or a 422 - you decide when you buy it. Some actually provide both 232 and 485 on the same connector. Now, within our environment you configure a Modbus JavaBean. One of the parameters is the "Station Number". The station number is required for both RS232 and RS485 devices - the protocol doesn't change based on the electrical requirements of the device. Now I can configure an application talking to, say, station 2 and station 7. I can add an RS485 converter to the computer serial port and put two physical devices there, configured as station 2 and station 7 and everything works fine. HOWEVER, over RS232 some devices will respond to both station 2 and station 7. So THE SAME APPLICATION will work with both 232 and 485. The only changes are hardware related. This same behavior is true of a number of 485 "networks" and many industrial devices that have 485 interfaces have 232 as an option using the same protocol. Jim Trent Jarvi wrote: > A JSR/JCP would not just involve RXTX. In fact it would be very nice to > have others with expertise in various areas like I2C, IrDA, RS485, RS422, > ... involved. > > Within the RXTX community, I do not think we have enough depth to tackle > RS485 alone. I'm aware of some of the low level issues but to be honest, > I've never actually used it. The RS485 classes in RXTX are more like > notes to myself about the issues involved without hardware solutions. In > operating systems like Linux, this may be much less of an issue in the > future. Linux is putting realtime patches now in the kernels which could > make RS485 over EIA232 possible. > > This is probably the last chance RS485 has to get into a published spec > for a long time though. Right now, I do not think its reasonable to > include it in the process. Others could make that less of a problem. > > On Mon, 24 Jul 2006, Christo Malan wrote: > >> Hi >> >> I don't think RS-485 belong in rxtx, the scope of the spec is not wide >> enough as it only specify the electrical layer. Their is no data >> protocol recommended or defined. This mean that we have no idea when to >> sample for a bit, how long is a bit and how many bits before we can say >> new data is available. >> >> Christo >> >> Dr. Douglas Lyon wrote: >>> Hi All, >>> There has been a lot of discussion regarding RS485. >>> >>> Let me see if I can summarize this, please correct me if I am wrong; >>> I am deliberately ignoring connector and electrical issues, focusing, >>> instead, on protocol and software issues. Also, I have never used >>> RS485, and I don't know much about it. >>> >>> 1. Serial ports that claim RS232 are typically used in >>> the data link layer of the OSI model of networking. Basically, this means >>> that they work with a point-to-point protocol and are meant to connect two >>> devices. >>> >>> 2. Within the RS232 standard there are framing bits (start and stop bits) >>> and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. >>> Thats' it. >>> >>> 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) >>> you do it in software, not in the RS232 standard. >>> >>> 4. RS485 is different from RS232 in that it is in the Network Layer of >>> the OSI model of networking. >>> >>> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in >>> a factory). >>> RS-485 is similar to RS-422, but RS-422 allows just one driver with >>> multiple receivers whereas RS-485 supports multiple drivers and >>> receivers. >>> >>> 6. RS-485 is a serial bus with multiple nodes and thus must handle network >>> link layer protocols. By using high-impedance receivers, you can have >>> as many as 256 nodes. >>> >>> 7. The RS-485 can be implemented with RXTX in the core and a layer of software >>> on top to handle media access control (MAC sublayer). There are also >>> hardware converters. >>> http://www.rs485.com/pconverters.html for example. However, some of >>> these require software control. There is some support in the form of >>> the Rs485.java class, >>> in RXTX. >>> >>> 8. The RS-485 specification will add to the size of the JSR >>> >>> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: >>> This version of the Java communications API contains support for >>> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not >>> mentioned. >>> >>> 10. DO people want to add RS485 to a new JSR? >>> >>> Would it make sense for the RS-485 people to speak up now? >>> Please let me know if you think my summary is wrong. >>> >>> Thanks! >>> - Doug >>> >>> >>> >>> >>> >>> >>>> At 18:31 20/07/2006, Trent Jarvi wrote: >>>> >>>>>> PROJECT SCOPE: >>>>>> ------------- >>>>>> >>>>>> Also, we should think carefully about what the scope of >>>>>> this project would be. Should it be javax."comm" which >>>>>> handles both serial and parallel (is parallel going by the >>>>>> wayside). Should it be split into two project: >>>>>> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>>>>> >>>>>> Should we differentiate between single-ended serial >>>>>> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>>>>> quasi-multidrop and full multidrop busses such as >>>>>> EIA422, EIA432 and EIA485? If we really were to >>>>>> add I2C support to the API, we'd have to delve into >>>>>> the semantics more, because there could be some >>>>>> implicit decoding of the bus the API users would >>>>>> want to see. >>>>>> >>>>> Hi Paul >>>>> >>>>> The way RXTX works, which is a fair representation of the people using the >>>>> API, is complete support for RIA232, minimal support for IEEE1284. From >>>>> what I understand, Sun was going along the same lines. If we combined >>>>> both projects, we would have half a parallel port implementation. I see >>>>> maybe 4 requests for features not in the parallel support a year. >>>>> >>>>> The other protocols should not be limited by a JSR which is going to be >>>>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>>>> I2C and Raw should _not_ be considered a strong basis for extending the >>>>> API to cover these protocols. If people want to do real implementations, >>>>> they should not face a 'standard' which wasnt really focused upon their >>>>> interests. I think we understand the parallel port issues fairly well but >>>>> have not implemented many features and I don't know if we would. >>>>> >>>> I agree with all of this. API requirements for I2C, SPI, etc. are very >>>> different from those for RS232/485/422. Our embedded Java platform has >>>> APIs for all of these and more and they don't share a lot apart from the >>>> fact that they all use Input/OutputStreams (and in the case of SPI you >>>> still need to cater with the fact that every time you want to read you >>>> must also write to the device.) >>>> >>>> If I was to design javax.comm from scratch, I think I would focus on >>>> serial ports exclusively (== whatever the underlying OS represents as >>>> serial ports). Even parallel is a bit out of place IMHO, although I >>>> understand it needs to stay for backwards compatibility. >>>> >>>> >>>> >>>>> So a versatile API is favorable but I do not think we have the proper >>>>> community to represent much more than Serial. >>>>> >>>> Yes, I think the same. >>>> >>>> Guillermo >>>> -- >>>> Guillermo Rodriguez Garcia >>>> >>>> Snijder Micro Systems phone +31-493-351020 >>>> G. Rodriguez Garcia fax +31-493-351530 >>>> Visser 25 email guille at sms.nl >>>> NL5751 BL Deurne >>>> The Netherlands http://www.snijder.com >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From jredman at ergotech.com Mon Jul 24 09:50:21 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 09:50:21 -0600 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D77D.5080200@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> Message-ID: <44C4EC3D.6010204@ergotech.com> Jim, How about we go back to basics and define a serial port. Under Java, I can open /dev/ttyS0, COM1:, etc and read/write a serial port. So what does RXTX bring to the table? If we can define what we need from the product at a high level (functional spec.) then we can look at what's wrong underneath (design requirements). I can do this fairly easily. Functionally, I want support for SerialPort - a superset of that would be fine. SerialPort provides an abstraction that provides everything I need for accessing serial devices. At the design level, I'd like a "pluggable" architecture. That is, I'd like to able to accommodate anything that it makes sense to implement in terms of the SerialPort interface. An obvious plugin is one that supports the current RXTX serial port access - through device files. But _I'd_ like a plugin for serial ports over Ethernet, serial ports over BlueTooth (including discovery), etc. I'm sure others could think of modules they'd like i2c, SPI, etc. etc. I'm not sure that ANY of these should be part of the spec. although perhaps the device file based version could be part of a reference implementation. I don't know that this is really much different from the existing architecture. I doubt that much code could be shared between, for example, a BlueTooth serial port and a /dev/ttyS0 serial port, but perhaps those more familiar with the code could comment. I suspect some cleanup of registration, etc. would be needed to formalize plugins, but I doubt it's too great. Some time ago I learnt the definition of a "Goal". It should be concrete, winnable and build unity. So, I have laid out a concrete goal, build to a superset of the SerialPort interface, it's winnable because it's not a complete rewrite of RXTX and it builds unity because anyone's pet electrical specification can be added. A simplistic view, tell me where I went wrong. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From lyon at docjava.com Mon Jul 24 10:06:40 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 24 Jul 2006 12:06:40 -0400 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4E746.8070808@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> Message-ID: >Hi All, Wow, what an informed and interesting debate from my most innocent and well-intentioned of e-mails. I must say that I am learning a great deal from this list! When I speak about RS232 I wanted to focus on the protocol, not the connector shape or pin-out or electrical issues. Issues like that are addressed by the rs232c standard. The RS232 is a really loaded term! The C revision of the standard was issued in 1969 in part to accommodate electrical characteristics. Revision D was issued in 1986. The current revision is TIA-232-F Interface Between Data Terminal Equipment and Data Circuit-Terminating Equipment Employing Serial Binary Data Interchange, issued in 1997. None of this is of any particular relevance to the basic underlying question: Should the next JSR attempt to address the multi-drop abilities of RS-485? Thanks! - Doug >Folks, > >The RS232/485/422/etc. etc. is a complete red herring >(http://en.wikipedia.org/wiki/Red_herring in case you don't know the >expression). The differences between the two are at the electrical >level, not at the RXTX level. I'll provide a concrete example and see >if we can get away from this issue. > >There's an industrial serial communications standard - Modbus. Modbus >capable devices are very common and can be purchased, generally, with an >RS232 or a 485 or a 422 - you decide when you buy it. Some actually >provide both 232 and 485 on the same connector. Now, within our >environment you configure a Modbus JavaBean. One of the parameters is >the "Station Number". The station number is required for both RS232 and >RS485 devices - the protocol doesn't change based on the electrical >requirements of the device. Now I can configure an application talking >to, say, station 2 and station 7. I can add an RS485 converter to the >computer serial port and put two physical devices there, configured as >station 2 and station 7 and everything works fine. HOWEVER, over RS232 >some devices will respond to both station 2 and station 7. So THE SAME >APPLICATION will work with both 232 and 485. The only changes are >hardware related. This same behavior is true of a number of 485 >"networks" and many industrial devices that have 485 interfaces have 232 >as an option using the same protocol. > >Jim > > >Trent Jarvi wrote: >> A JSR/JCP would not just involve RXTX. In fact it would be very nice to >> have others with expertise in various areas like I2C, IrDA, RS485, RS422, >> ... involved. >> >> Within the RXTX community, I do not think we have enough depth to tackle >> RS485 alone. I'm aware of some of the low level issues but to be honest, >> I've never actually used it. The RS485 classes in RXTX are more like >> notes to myself about the issues involved without hardware solutions. In >> operating systems like Linux, this may be much less of an issue in the >> future. Linux is putting realtime patches now in the kernels which could >> make RS485 over EIA232 possible. >> >> This is probably the last chance RS485 has to get into a published spec >> for a long time though. Right now, I do not think its reasonable to >> include it in the process. Others could make that less of a problem. >> >> On Mon, 24 Jul 2006, Christo Malan wrote: >> >>> Hi >>> >>> I don't think RS-485 belong in rxtx, the scope of the spec is not wide >>> enough as it only specify the electrical layer. Their is no data >>> protocol recommended or defined. This mean that we have no idea when to >>> sample for a bit, how long is a bit and how many bits before we can say >>> new data is available. >>> >>> Christo >>> >>> Dr. Douglas Lyon wrote: >>>> Hi All, >>>> There has been a lot of discussion regarding RS485. >>>> >>>> Let me see if I can summarize this, please correct me if I am wrong; >>>> I am deliberately ignoring connector and electrical issues, focusing, >>>> instead, on protocol and software issues. Also, I have never used >>>> RS485, and I don't know much about it. > >>> >>>> 1. Serial ports that claim RS232 are typically used in >>>> the data link layer of the OSI model of networking. Basically, this means >>>> that they work with a point-to-point protocol and are meant to connect two > >>> devices. >>>> >>>> 2. Within the RS232 standard there are framing bits (start and stop bits) >>>> and error control bits (parity). The flow control is xon-xoff or >>>>DTR, CTS, RTS. >>>> Thats' it. >>>> >>>> 3. If you want more than that from RS232 (forward error >>>>correction, ARQ, etc.) >>>> you do it in software, not in the RS232 standard. >>>> >>>> 4. RS485 is different from RS232 in that it is in the Network Layer of >>>> the OSI model of networking. >>>> >>>> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in >>>> a factory). >>>> RS-485 is similar to RS-422, but RS-422 allows just one driver with >>>> multiple receivers whereas RS-485 supports multiple drivers and >>>> receivers. >>>> >>>> 6. RS-485 is a serial bus with multiple nodes and thus must handle network >>>> link layer protocols. By using high-impedance receivers, you can have >>>> as many as 256 nodes. >>>> >>>> 7. The RS-485 can be implemented with RXTX in the core and a >>>>layer of software >>>> on top to handle media access control (MAC sublayer). There are also >>>> hardware converters. >>>> http://www.rs485.com/pconverters.html for example. However, some of >>>> these require software control. There is some support in the form of >>>> the Rs485.java class, >>>> in RXTX. >>>> >>>> 8. The RS-485 specification will add to the size of the JSR >>>> >>>> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: >>>> This version of the Java communications API contains support for >>>> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not >>>> mentioned. >>>> >>>> 10. DO people want to add RS485 to a new JSR? >>>> >>>> Would it make sense for the RS-485 people to speak up now? >>>> Please let me know if you think my summary is wrong. >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>> >>>> >>>> >>>> >>>>> At 18:31 20/07/2006, Trent Jarvi wrote: >>>>> >>>>>>> PROJECT SCOPE: >>>>>>> ------------- >>>>>>> >>>>>>> Also, we should think carefully about what the scope of >>>>>>> this project would be. Should it be javax."comm" which >>>>>>> handles both serial and parallel (is parallel going by the >>>>>>> wayside). Should it be split into two project: >>>>>>> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>>>>>> >>>>>>> Should we differentiate between single-ended serial >>>>>>> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>>>>>> quasi-multidrop and full multidrop busses such as >>>>>>> EIA422, EIA432 and EIA485? If we really were to >>>>>>> add I2C support to the API, we'd have to delve into >>>>>>> the semantics more, because there could be some >>>>>>> implicit decoding of the bus the API users would >>>>>>> want to see. >>>>>>> >>>>>> Hi Paul >>>>>> >>>>>> The way RXTX works, which is a fair representation of the >>>>>>people using the >>>>>> API, is complete support for RIA232, minimal support for IEEE1284. From >>>>>> what I understand, Sun was going along the same lines. If we combined >>>>>> both projects, we would have half a parallel port implementation. I see >>>>>> maybe 4 requests for features not in the parallel support a year. >>>>>> >>>>>> The other protocols should not be limited by a JSR which is going to be >>>>>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>>>>> I2C and Raw should _not_ be considered a strong basis for extending the >>>>>> API to cover these protocols. If people want to do real >>>>>>implementations, >>>>>> they should not face a 'standard' which wasnt really focused upon their >>>>>> interests. I think we understand the parallel port issues >>>>>>fairly well but >>>>>> have not implemented many features and I don't know if we would. >>>>>> >>>>> I agree with all of this. API requirements for I2C, SPI, etc. are very >>>>> different from those for RS232/485/422. Our embedded Java platform has >>>>> APIs for all of these and more and they don't share a lot apart from the >>>>> fact that they all use Input/OutputStreams (and in the case of SPI you > >>>> still need to cater with the fact that every time you want to read you >>>>> must also write to the device.) >>>>> >>>>> If I was to design javax.comm from scratch, I think I would focus on >>>>> serial ports exclusively (== whatever the underlying OS represents as > >>>> serial ports). Even parallel is a bit out of place IMHO, although I >>>>> understand it needs to stay for backwards compatibility. >>>>> >>>>> >>>>> >>>>>> So a versatile API is favorable but I do not think we have the proper >>>>>> community to represent much more than Serial. >>>>>> >>>>> Yes, I think the same. >>>>> >>>>> Guillermo >>>>> -- >>>>> Guillermo Rodriguez Garcia >>>>> >>>>> Snijder Micro Systems phone +31-493-351020 >>>>> G. Rodriguez Garcia fax +31-493-351530 >>>>> Visser 25 email guille at sms.nl >>>>> NL5751 BL Deurne >>>>> The Netherlands http://www.snijder.com >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >-- >Jim Redman >(505) 662 5156 x85 >http://www.ergotech.com >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Mon Jul 24 10:16:44 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 18:16:44 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> Message-ID: <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> Hi Doug, Quoting "Dr. Douglas Lyon" : > >Hi All, > > > Wow, what an informed and interesting debate from my most > innocent and well-intentioned of e-mails. > > I must say that I am learning a great deal from this list! > > When I speak about > RS232 I wanted to focus on the protocol, not the connector shape or > pin-out or electrical issues. Issues like that are addressed by the > rs232c standard. > The RS232 is a really loaded term! Right. Maybe we should be talking about "serial ports" instead. At the functional level it does not make any difference whether it is RS232, RS485, or RS422... except maybe for the direction control in the case of RS485 ports. [...] > > None of this is of any particular relevance to the basic underlying > question: > > Should the next JSR attempt to address the multi-drop abilities of RS-485? What I would suggest is to just add a new 'ioctlex'-like method to the SerialPort API: A method that you'd use to pass platform- or implementation-specific info to the underlying driver or OS to do things such as "enabling RS485 mode" or "disable FIFOs" or "poll the TSR register". No need to define any function codes. This is for stuff that is platform- or implementation-specific and as such cannot be easily abstracted anyway. The goal is to accomodate hat those systems that have serial ports with special, non-standard capabilities without forcing developers to leave javax.comm. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From Paul.Klissner at Sun.COM Mon Jul 24 10:45:33 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Mon, 24 Jul 2006 09:45:33 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> Message-ID: <44C4F92D.6090807@sun.com> >> None of this is of any particular relevance to the basic underlying >> question: >> >> Should the next JSR attempt to address the multi-drop abilities of RS-485? > > What I would suggest is to just add a new 'ioctlex'-like method > to the SerialPort API: A method that you'd use to pass platform- > or implementation-specific info to the underlying driver or OS > to do things such as "enabling RS485 mode" or "disable FIFOs" or > "poll the TSR register". > > No need to define any function codes. This is for stuff that is > platform- or implementation-specific and as such cannot be easily > abstracted anyway. Detrimental to platform independence. Paul From berkland at spamcop.net Mon Jul 24 11:07:58 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 24 Jul 2006 13:07:58 -0400 Subject: [Rxtx] jcp and jsr In-Reply-To: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> Message-ID: <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> Gregg Wonderly wrote: > That there could be a low level port/device SPI > that could be put in place once, and then overtime > we could layer other APIs, including an updated > javax.comm which would make use of this SPI. I think there is great merit in this suggestion. I would like to see the ability to register a new "port" along with a custom handler in the Java client code before attempting to access the port. e.g . CommManager.getInstance().registerPortImpl("USB1:", new HidPortAdapter(/*vendorId=*/ "1234", /*deviceId=*/ "4321"); CommManager.getInstance().registerPortImpl("Ether1:", new InetPortAdapter(/*ipAndPort=*/ "192.168.1.101:8088"); It would allow other protocols that this group doesn't have depth in to be developed by someone who does on an "as needed" basis. Additionally, the value of this would be with some devices that implement basically the same protocol that was initially used over RS232 for a USB (via an HID) or Ethernet interface. There are a number of these in POS hardware. The existing JavaPOS driver written against JavaCOMM 2.0 could be reused by plugging in an HID or IP adapter before attempting to access the device. It might also be valuable to use something like an extended version of the portmapping file found in JavaCOMM 3.0. A configuration file could allow this definition to take place outside of any Java client code. Such a mapping file wouldn't even need to be part of the JSR API or reference implementation. It could be handled in a specific implementation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060724/7f51342e/attachment-0336.html From guille at sms.nl Mon Jul 24 11:14:54 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 19:14:54 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4F92D.6090807@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> Message-ID: <1153761294.44c5000ec1360@webmail.eatserver.nl> Quoting Paul Klissner : > >> None of this is of any particular relevance to the basic underlying > >> question: > >> > >> Should the next JSR attempt to address the multi-drop abilities of > RS-485? > > > > What I would suggest is to just add a new 'ioctlex'-like method > > to the SerialPort API: A method that you'd use to pass platform- > > or implementation-specific info to the underlying driver or OS > > to do things such as "enabling RS485 mode" or "disable FIFOs" or > > "poll the TSR register". > > > > No need to define any function codes. This is for stuff that is > > platform- or implementation-specific and as such cannot be easily > > abstracted anyway. > > Detrimental to platform independence. Yes, it is. But as you go closer and closer to the hardware level some things are by nature platform-dependent, and sometimes just cannot be solved in a platform-independent way. In these cases, is it better to have no solution at all than having one that is less than perfect? Put it another way, would you prefer having people say "I just cannot do this in Java; I'll go somewhere else" rather than "I can do this in Java -- only not in a platform-independent way" ? Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From gergg at cox.net Mon Jul 24 11:34:00 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 12:34:00 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153752467.44c4dd93c08f7@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> Message-ID: <44C50488.1040508@cox.net> Guillermo Rodriguez wrote: > As an embedded Java vendor, SNIJDER Micro Systems certainly sees the > value of standardized APIs to talk to different types of communication > buses including SPI, I2C, 1-Wire, etc., for embedded applications. > However we think this has nothing to do with javax.comm. I don't think this is only about javax.comm. Certainly that's important. I'm just wading into this conversation mainstream and trying to say: If you are going to do anything about "fixing" javax.comm to work on all platforms, please, please, please start with a hardware port SPI definition that lets you get to serial ports, and then provide the existing javax.com API and whatever new API you think is necessary (I don't have any really issues with the existing API directly). Then, there will be a place for others interesting in SPI, i2C, USB and other things to get started with providing access to devices that are also interesting in Java applications, and directly, in embedded Java applications. Gregg Wonderly From Paul.Klissner at Sun.COM Mon Jul 24 11:41:51 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Mon, 24 Jul 2006 10:41:51 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153761294.44c5000ec1360@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> Message-ID: <44C5065F.3060802@sun.com> Guillermo Rodriguez wrote: > Quoting Paul Klissner : > >>>> None of this is of any particular relevance to the basic underlying >>>> question: >>>> >>>> Should the next JSR attempt to address the multi-drop abilities of >> RS-485? >>> What I would suggest is to just add a new 'ioctlex'-like method >>> to the SerialPort API: A method that you'd use to pass platform- >>> or implementation-specific info to the underlying driver or OS >>> to do things such as "enabling RS485 mode" or "disable FIFOs" or >>> "poll the TSR register". >>> >>> No need to define any function codes. This is for stuff that is >>> platform- or implementation-specific and as such cannot be easily >>> abstracted anyway. >> Detrimental to platform independence. > > Yes, it is. But as you go closer and closer to the hardware level some > things are by nature platform-dependent, and sometimes just cannot be > solved in a platform-independent way. In these cases, is it better to > have no solution at all than having one that is less than perfect? > > Put it another way, would you prefer having people say "I just cannot > do this in Java; I'll go somewhere else" rather than "I can do this > in Java -- only not in a platform-independent way" ? If there isn't a reasonable way to abstract it out, then why use Java? The whole idea is platform neutrality, otherwise, what is the huge advantage of adopting a standardized Java API? I think it is wrong to subvert the API. I think we have to arrive at some sort of consensus about the scope of the API and do our best to engineer a robust API in terms of that scope using abstraction. There may be outliers, but the outliers probably aren't portable, and probably would do just as well to not use java for that particular application. If this was a JSR, if we found some compelling problem that kept cropping up the API could be reved so as not to just orphan cases with legitimate requests. If someone really needs to do funky things with the hardware, why wouldn't that be put in the native back end? Couldn't some of this be addressed by the multiple SPI layer that I recommended as one of the two changes I'd like to see made to javax.comm (the other being a port mapping plugin layer)? Paul From jredman at ergotech.com Mon Jul 24 11:49:46 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 11:49:46 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> Message-ID: <44C5083A.6090902@ergotech.com> A thought for later since we haven't really reached this level of detail, but since this type of approach seems likely... If a configuration file is mandatory, can we specify what the file is called and what the format of the options are (mandatory?, and optional) without limiting extensions. This just adds consistency across platforms/implementations. Jim Doug Berkland wrote: > Gregg Wonderly wrote: > > That there could be a low level port/device SPI > > that could be put in place once, and then overtime > > we could layer other APIs, including an updated > > javax.comm which would make use of this SPI. > > I think there is great merit in this suggestion. I would like to see > the ability to register a new "port" along with a custom handler in the > Java client code before attempting to access the port. > e.g . > CommManager.getInstance().registerPortImpl("USB1:", new > HidPortAdapter(/*vendorId=*/ "1234", /*deviceId=*/ "4321"); > CommManager.getInstance().registerPortImpl("Ether1:", new > InetPortAdapter(/*ipAndPort=*/ " 192.168.1.101:8088 > "); > > It would allow other protocols that this group doesn't have depth in to > be developed by someone who does on an "as needed" basis. > > Additionally, the value of this would be with some devices that > implement basically the same protocol that was initially used over RS232 > for a USB (via an HID) or Ethernet interface. There are a number of > these in POS hardware. The existing JavaPOS driver written against > JavaCOMM 2.0 could be reused by plugging in an HID or IP adapter before > attempting to access the device. > > It might also be valuable to use something like an extended version of > the portmapping file found in JavaCOMM 3.0. A configuration file could > allow this definition to take place outside of any Java client code. > Such a mapping file wouldn't even need to be part of the JSR API or > reference implementation. It could be handled in a specific > implementation. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From mtnvega at yahoo.com.br Mon Jul 24 11:51:40 2006 From: mtnvega at yahoo.com.br (mtnvega) Date: Mon, 24 Jul 2006 14:51:40 -0300 Subject: [Rxtx] Serial Read/Write Details Message-ID: <44C508AC.7060103@yahoo.com.br> Hello, I'm have being flirting with RXTX for a while since I'm working on a college project where I will need to communicate with a microcontroller using USART. Now is the time to start using it! But I have some doubts and I hope you can help-me. I will need to both send and receive data from the serial port. First I will need to send some command bytes then wait for some data that will be returned from the microcontroller. And I would like to know which is the best way to do that. I'm mean, of course send and receive data is the purpose of the serial port and RXTX but I'm looking for some details since there will be no package control but just a fixed command format and confirmation messages from the microcontroller side. I would like to know if I should open and close the port or if I can just open it once. I read that upon writing to output the input buffer are filled with the same data, is it right? If yes, isn't it a problem since I'm waiting for data back in a very small time? Thank you, Luiz _______________________________________________________ Voc? quer respostas para suas perguntas? Ou voc? sabe muito e quer compartilhar seu conhecimento? Experimente o Yahoo! Respostas ! http://br.answers.yahoo.com/ From jredman at ergotech.com Mon Jul 24 12:45:50 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 12:45:50 -0600 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C50488.1040508@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> Message-ID: <44C5155E.7080105@ergotech.com> Gregg, Is SPI applicable to a SerialPort interface over Ethernet (or Bluetooth)? I've assumed that it's specific to directly-connected-UART-based serial ports - something similar to I2C. I'm starting to think that I'm opposed to having hardware definitions (transport layer?) in the JavaComm spec., but then what's left? Jim Gregg Wonderly wrote: > Guillermo Rodriguez wrote: >> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the >> value of standardized APIs to talk to different types of communication >> buses including SPI, I2C, 1-Wire, etc., for embedded applications. >> However we think this has nothing to do with javax.comm. > > I don't think this is only about javax.comm. Certainly that's important. I'm > just wading into this conversation mainstream and trying to say: > > If you are going to do anything about "fixing" javax.comm to work on all > platforms, please, please, please start with a hardware port SPI definition that > lets you get to serial ports, and then provide the existing javax.com API and > whatever new API you think is necessary (I don't have any really issues with the > existing API directly). > > Then, there will be a place for others interesting in SPI, i2C, USB and other > things to get started with providing access to devices that are also interesting > in Java applications, and directly, in embedded Java applications. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Mon Jul 24 13:15:19 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 14:15:19 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C5155E.7080105@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <44C5155E.7080105@ergotech.com> Message-ID: <44C51C47.90409@cox.net> Jim Redman wrote: > Is SPI applicable to a SerialPort interface over Ethernet (or > Bluetooth)? I've assumed that it's specific to > directly-connected-UART-based serial ports - something similar to I2C. SPI is a simple 2 line (clock and data) plus slave select bi-directional, full duplex data transfer mechanism. It has nothing to do, directly with serial ports, but could be implemented using serial port signalling lines. > I'm starting to think that I'm opposed to having hardware definitions > (transport layer?) in the JavaComm spec., but then what's left? Jim, there are multiple conversations going on, on the list. There is a group of people that just want a standard serial port mechanism in Java, apparently NOW! They are going back and forth about that. There is another conversation about doing a JSR to make the serial port interfaces a standard, since Sun's original implementation was never a Java standard. There is a small group saying if you're going to do a JSR for serial ports, why not provide a nice foundation for serial ports which might also support other kinds of "ports" and associated protocols. And there are a couple of other conversations about Pascal's stuff. It's this last group that I am the most interested in. I think that it is possible to create a simple Service Provider Interface for 'hardware interfacing' that covers serial ports and also includes expandability to cover other types of hardware. We want to find the level of abstraction that the most number of OSes provide in their user level APIs, and create a matching SPI at that level which will allow a JVM vendor to provide access to the types of hardware that is common on their OSes/hardware. Then, third parties might add some value by providing some good abstrations for particular types of protocols or particular vendors' hardware (ports which can be switched between RS232 and RS485 for example). Finally, we can create an implementation of the javax.comm API which uses this SPI to provide exactly the same API as today, but with an approved foundation for hardware access from java using 100% java code. Gregg Wonderly From mark at mdsh.com Mon Jul 24 16:03:38 2006 From: mark at mdsh.com (Mark Himsley) Date: Mon, 24 Jul 2006 23:03:38 +0100 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: I don't see how any Java app is going to know the difference between an RS232, RS422, or RS485 port. I regularly use RXTX controlling RS422 devices (controlling VTRs) and I can use an RS232 port with bodged wiring (for short distances) or RS232 port with a media converted - either of which may be built into the PC or may be a USB device - or an RS422 USB device. They are just 'serial port' devices. Please don't get hung up on higher layer stuff - that's for application developers to add on top of a rock-solid multi platform 'serial port' driver implementations. On 24 July 2006 08:44 -0600 Trent Jarvi wrote: > > A JSR/JCP would not just involve RXTX. In fact it would be very nice to > have others with expertise in various areas like I2C, IrDA, RS485, RS422, > ... involved. > > Within the RXTX community, I do not think we have enough depth to tackle > RS485 alone. I'm aware of some of the low level issues but to be honest, > I've never actually used it. The RS485 classes in RXTX are more like > notes to myself about the issues involved without hardware solutions. In > operating systems like Linux, this may be much less of an issue in the > future. Linux is putting realtime patches now in the kernels which could > make RS485 over EIA232 possible. > > This is probably the last chance RS485 has to get into a published spec > for a long time though. Right now, I do not think its reasonable to > include it in the process. Others could make that less of a problem. > > On Mon, 24 Jul 2006, Christo Malan wrote: > > > Hi > > > > I don't think RS-485 belong in rxtx, the scope of the spec is not wide > > enough as it only specify the electrical layer. Their is no data > > protocol recommended or defined. This mean that we have no idea when to > > sample for a bit, how long is a bit and how many bits before we can say > > new data is available. > > > > Christo > > > > Dr. Douglas Lyon wrote: > >> Hi All, > >> There has been a lot of discussion regarding RS485. > >> > >> Let me see if I can summarize this, please correct me if I am wrong; > >> I am deliberately ignoring connector and electrical issues, focusing, > >> instead, on protocol and software issues. Also, I have never used > >> RS485, and I don't know much about it. > >> > >> 1. Serial ports that claim RS232 are typically used in > >> the data link layer of the OSI model of networking. Basically, this > >> means that they work with a point-to-point protocol and are meant to > >> connect two devices. > >> > >> 2. Within the RS232 standard there are framing bits (start and stop > >> bits) and error control bits (parity). The flow control is xon-xoff or > >> DTR, CTS, RTS. Thats' it. > >> > >> 3. If you want more than that from RS232 (forward error correction, > >> ARQ, etc.) you do it in software, not in the RS232 standard. > >> > >> 4. RS485 is different from RS232 in that it is in the Network Layer of > >> the OSI model of networking. > >> > >> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > >> a factory). > >> RS-485 is similar to RS-422, but RS-422 allows just one driver with > >> multiple receivers whereas RS-485 supports multiple drivers and > >> receivers. > >> > >> 6. RS-485 is a serial bus with multiple nodes and thus must handle > >> network link layer protocols. By using high-impedance receivers, you > >> can have as many as 256 nodes. > >> > >> 7. The RS-485 can be implemented with RXTX in the core and a layer of > >> software on top to handle media access control (MAC sublayer). There > >> are also hardware converters. > >> http://www.rs485.com/pconverters.html for example. However, some of > >> these require software control. There is some support in the form of > >> the Rs485.java class, > >> in RXTX. > >> > >> 8. The RS-485 specification will add to the size of the JSR > >> > >> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > >> This version of the Java communications API contains support for > >> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > >> mentioned. > >> > >> 10. DO people want to add RS485 to a new JSR? > >> > >> Would it make sense for the RS-485 people to speak up now? > >> Please let me know if you think my summary is wrong. > >> > >> Thanks! > >> - Doug > >> > >> > >> > >> > >> > >> > >>> At 18:31 20/07/2006, Trent Jarvi wrote: > >>> > >>>> > PROJECT SCOPE: > >>>> > ------------- > >>>> > > >>>> > Also, we should think carefully about what the scope of > >>>> > this project would be. Should it be javax."comm" which > >>>> > handles both serial and parallel (is parallel going by the > >>>> > wayside). Should it be split into two project: > >>>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > >>>> > > >>>> > Should we differentiate between single-ended serial > >>>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > >>>> > quasi-multidrop and full multidrop busses such as > >>>> > EIA422, EIA432 and EIA485? If we really were to > >>>> > add I2C support to the API, we'd have to delve into > >>>> > the semantics more, because there could be some > >>>> > implicit decoding of the bus the API users would > >>>> > want to see. > >>>> > > >>>> > >>>> Hi Paul > >>>> > >>>> The way RXTX works, which is a fair representation of the people > >>>> using the API, is complete support for RIA232, minimal support for > >>>> IEEE1284. From what I understand, Sun was going along the same > >>>> lines. If we combined both projects, we would have half a parallel > >>>> port implementation. I see maybe 4 requests for features not in the > >>>> parallel support a year. > >>>> > >>>> The other protocols should not be limited by a JSR which is going to > >>>> be focused upon serial port interests. The IEA485 hacks in RXTX > >>>> along with I2C and Raw should _not_ be considered a strong basis for > >>>> extending the API to cover these protocols. If people want to do > >>>> real implementations, they should not face a 'standard' which wasnt > >>>> really focused upon their interests. I think we understand the > >>>> parallel port issues fairly well but have not implemented many > >>>> features and I don't know if we would. > >>>> > >>> I agree with all of this. API requirements for I2C, SPI, etc. are very > >>> different from those for RS232/485/422. Our embedded Java platform has > >>> APIs for all of these and more and they don't share a lot apart from > >>> the fact that they all use Input/OutputStreams (and in the case of > >>> SPI you still need to cater with the fact that every time you want to > >>> read you must also write to the device.) > >>> > >>> If I was to design javax.comm from scratch, I think I would focus on > >>> serial ports exclusively (== whatever the underlying OS represents as > >>> serial ports). Even parallel is a bit out of place IMHO, although I > >>> understand it needs to stay for backwards compatibility. > >>> > >>> > >>> > >>>> So a versatile API is favorable but I do not think we have the proper > >>>> community to represent much more than Serial. > >>>> > >>> Yes, I think the same. > >>> > >>> Guillermo > >>> -- > >>> Guillermo Rodriguez Garcia > >>> > >>> Snijder Micro Systems phone +31-493-351020 > >>> G. Rodriguez Garcia fax +31-493-351530 > >>> Visser 25 email guille at sms.nl > >>> NL5751 BL Deurne > >>> The Netherlands http://www.snijder.com > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> > >> > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Mark Himsley From berkland at spamcop.net Mon Jul 24 16:55:18 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 24 Jul 2006 18:55:18 -0400 Subject: [Rxtx] jcp and jsr In-Reply-To: <44C5083A.6090902@ergotech.com> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> <44C5083A.6090902@ergotech.com> Message-ID: <269e40090607241555g281c7f24s5577b86e35d27eab@mail.gmail.com> I'm sorry, I keep reading SPI as "Service Provider Interface" instead of "Serial Peripheral Interface". (See http://en.wikipedia.org/wiki/Serial_Peripheral_Interface.) What I thought was being suggested was a pluggable implementation like that found in javax.security. (The SPI there actually stands for "Security Provider Interface" not "Service Provider Interface" like I had thought.) I guess that might be a CPI (Comm Provider Interface) or PPI (Port Provider Interface.) At any rate what I would like to see is a JSR with (in order of priority) - compatible API for code written against current javax.comm 2.0 classes - ability to register or "force" a port by providing a name and implementation (not have to rely completely on the "auto-discovery") - nothing precluding the use of a portmapping in a given implementation - ability to register port implementations On 7/24/06, Jim Redman wrote: > > A thought for later since we haven't really reached this level of > detail, but since this type of approach seems likely... > > If a configuration file is mandatory, can we specify what the file is > called and what the format of the options are (mandatory?, and optional) > without limiting extensions. > > This just adds consistency across platforms/implementations. > > Jim > > Doug Berkland wrote: > > Gregg Wonderly wrote: > > > That there could be a low level port/device SPI > > > that could be put in place once, and then overtime > > > we could layer other APIs, including an updated > > > javax.comm which would make use of this SPI. > > > > I think there is great merit in this suggestion. I would like to see > > the ability to register a new "port" along with a custom handler in the > > Java client code before attempting to access the port. > > e.g . > > CommManager.getInstance().registerPortImpl("USB1:", new > > HidPortAdapter(/*vendorId=*/ "1234", /*deviceId=*/ "4321"); > > CommManager.getInstance().registerPortImpl("Ether1:", new > > InetPortAdapter(/*ipAndPort=*/ " 192.168.1.101:8088 > > "); > > > > It would allow other protocols that this group doesn't have depth in to > > be developed by someone who does on an "as needed" basis. > > > > Additionally, the value of this would be with some devices that > > implement basically the same protocol that was initially used over RS232 > > for a USB (via an HID) or Ethernet interface. There are a number of > > these in POS hardware. The existing JavaPOS driver written against > > JavaCOMM 2.0 could be reused by plugging in an HID or IP adapter before > > attempting to access the device. > > > > It might also be valuable to use something like an extended version of > > the portmapping file found in JavaCOMM 3.0. A configuration file could > > allow this definition to take place outside of any Java client code. > > Such a mapping file wouldn't even need to be part of the JSR API or > > reference implementation. It could be handled in a specific > > implementation. > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060724/02c50e6a/attachment-0336.html From tjarvi at qbang.org Mon Jul 24 18:44:54 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 24 Jul 2006 18:44:54 -0600 (MDT) Subject: [Rxtx] Serial Read/Write Details In-Reply-To: <44C508AC.7060103@yahoo.com.br> References: <44C508AC.7060103@yahoo.com.br> Message-ID: On Mon, 24 Jul 2006, mtnvega wrote: > Hello, > > I'm have being flirting with RXTX for a while since I'm working on a > college project where I will > need to communicate with a microcontroller using USART. > > Now is the time to start using it! But I have some doubts and I hope you > can help-me. > > I will need to both send and receive data from the serial port. First I > will need to send some command > bytes then wait for some data that will be returned from the > microcontroller. And I would like > to know which is the best way to do that. I'm mean, of course send and > receive data is the purpose > of the serial port and RXTX but I'm looking for some details since there > will be no package control > but just a fixed command format and confirmation messages from the > microcontroller side. > > I would like to know if I should open and close the port or if I can > just open it once. > I read that upon writing to output the input buffer are filled with the > same data, is it right? > If yes, isn't it a problem since I'm waiting for data back in a very > small time? > Hi Luiz Unless you want to use the port with a second application, just open the port once and close it when you exit the application. The input will not be filled with the data you write. The API has events to let you know when data is available and when your data has gone out the port. You can look in the contrib directory that comes with the source for crude examples of event notification. I think there is an example on the wiki too. I don't think you will have any problems. -- Trent Jarvi tjarvi at qbang.org From guille at sms.nl Tue Jul 25 00:26:12 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 08:26:12 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C50488.1040508@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> Message-ID: <7.0.1.0.0.20060725082124.036309e0@sms.nl> At 19:34 24/07/2006, Gregg Wonderly wrote: >Guillermo Rodriguez wrote: > > As an embedded Java vendor, SNIJDER Micro Systems certainly sees the > > value of standardized APIs to talk to different types of communication > > buses including SPI, I2C, 1-Wire, etc., for embedded applications. > > However we think this has nothing to do with javax.comm. > >I don't think this is only about javax.comm. Certainly that's >important. I'm >just wading into this conversation mainstream and trying to say: > >If you are going to do anything about "fixing" javax.comm to work on all >platforms, please, please, please start with a hardware port SPI >definition that >lets you get to serial ports, and then provide the existing javax.com API and >whatever new API you think is necessary (I don't have any really >issues with the >existing API directly). > >Then, there will be a place for others interesting in SPI, i2C, USB and other >things to get started with providing access to devices that are also >interesting >in Java applications, and directly, in embedded Java applications. I do agree that the best a hardware port SPI definition (where SPI = Service Provider Interface, not the SPI protocol) is a good thing to have to support serial ports layered over other transports. However these are still serial ports at the end. I still don't think the javax.comm API is well suited to "any" serial bus such as I2C, SPI, etc. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 00:41:46 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 08:41:46 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C5065F.3060802@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> Message-ID: <7.0.1.0.0.20060725082630.036d2d10@sms.nl> At 19:41 24/07/2006, Paul Klissner wrote: >Guillermo Rodriguez wrote: >>Quoting Paul Klissner : >> >>>>>None of this is of any particular relevance to the basic underlying >>>>>question: >>>>> >>>>>Should the next JSR attempt to address the multi-drop abilities of >>>RS-485? >>>>What I would suggest is to just add a new 'ioctlex'-like method >>>>to the SerialPort API: A method that you'd use to pass platform- >>>>or implementation-specific info to the underlying driver or OS >>>>to do things such as "enabling RS485 mode" or "disable FIFOs" or >>>>"poll the TSR register". >>>> >>>>No need to define any function codes. This is for stuff that is >>>>platform- or implementation-specific and as such cannot be easily >>>>abstracted anyway. >>>Detrimental to platform independence. >>Yes, it is. But as you go closer and closer to the hardware level some >>things are by nature platform-dependent, and sometimes just cannot be >>solved in a platform-independent way. In these cases, is it better to >>have no solution at all than having one that is less than perfect? >>Put it another way, would you prefer having people say "I just cannot >>do this in Java; I'll go somewhere else" rather than "I can do this >>in Java -- only not in a platform-independent way" ? > >If there isn't a reasonable way to abstract it out, then >why use Java? If an application can be 99% platform independent with small bits being not portable, why *not* use Java? I'd prefer to see people using Java to write non-portable applications than having them use C instead. I believe that Java should promote platform neutrality, but that does not necessarily mean precluding the use of anything that is NOT platform independent. And let's face it, if you are using javax.comm to talk to some serial device directly, then chances are you are already tied to some specific hardware anyway. Also, some people (myself included) think that Java can also be used as a systems programming language, not only for applications. For many embedded platforms this is certainly the case. In our platform we even write device drivers directly in Java. I would imagine the Sun SPOT team (www.sunspotworld.com) supports a similar view. If people needs to do non-portable stuff and wants to do it in Java I'd rather have them do it in Java than tell them to do it in C instead. >The whole idea is platform neutrality, otherwise, what is the >huge advantage of adopting a standardized Java API? I think >it is wrong to subvert the API. I think we have to arrive at >some sort of consensus about the scope of the API and do our >best to engineer a robust API in terms of that scope using >abstraction. > >There may be outliers, but the outliers probably aren't portable, >and probably would do just as well to not use java for that >particular application. The cases I have in mind is more like portable applications with very small bits of non portable code. I can imagine lots of portable applications that need access to RS485, specially in the industrial process control and factory automation fields. As I said in an earlier mail RS485 is half- duplex, but there is standard way to do RS485 direction control from software. Does it mean that the whole application should not be written in Java, only because some small bits of code related to RS485 direction control are not completely portable? > If this was a JSR, if we found some >compelling problem that kept cropping up the API could be >reved so as not to just orphan cases with legitimate requests. > >If someone really needs to do funky things with the hardware, >why wouldn't that be put in the native back end? But nobody said the functionality can't be implemented in the native back end. However you still need an application level API to enable/disable it. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 00:44:43 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 08:44:43 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <269e40090607241555g281c7f24s5577b86e35d27eab@mail.gmail.co m> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> <44C5083A.6090902@ergotech.com> <269e40090607241555g281c7f24s5577b86e35d27eab@mail.gmail.com> Message-ID: <7.0.1.0.0.20060725084431.036d0700@sms.nl> At 00:55 25/07/2006, Doug Berkland wrote: >I'm sorry, I keep reading SPI as "Service Provider Interface" >instead of "Serial Peripheral Interface". (See >http://en.wikipedia.org/wiki/Serial_Peripheral_Interface. >) > >What I thought was being suggested was a pluggable implementation >like that found in javax.security. (The SPI there actually stands >for "Security Provider Interface" not "Service Provider Interface" >like I had thought.) I guess that might be a CPI (Comm Provider >Interface) or PPI (Port Provider Interface.) > >At any rate what I would like to see is a JSR with (in order of priority) >- compatible API for code written against current javax.comm 2.0 classes >- ability to register or "force" a port by providing a name and >implementation (not have to rely completely on the "auto-discovery") >- nothing precluding the use of a portmapping in a given implementation >- ability to register port implementations That sounds very good to me. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From tjarvi at qbang.org Tue Jul 25 01:21:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 01:21:53 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725082124.036309e0@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> Message-ID: On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: > At 19:34 24/07/2006, Gregg Wonderly wrote: >> Guillermo Rodriguez wrote: >>> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the >>> value of standardized APIs to talk to different types of communication >>> buses including SPI, I2C, 1-Wire, etc., for embedded applications. >>> However we think this has nothing to do with javax.comm. >> >> I don't think this is only about javax.comm. Certainly that's >> important. I'm >> just wading into this conversation mainstream and trying to say: >> >> If you are going to do anything about "fixing" javax.comm to work on all >> platforms, please, please, please start with a hardware port SPI >> definition that >> lets you get to serial ports, and then provide the existing javax.com API and >> whatever new API you think is necessary (I don't have any really >> issues with the >> existing API directly). >> >> Then, there will be a place for others interesting in SPI, i2C, USB and other >> things to get started with providing access to devices that are also >> interesting >> in Java applications, and directly, in embedded Java applications. > > I do agree that the best a hardware port SPI definition (where SPI = Service > Provider Interface, not the SPI protocol) is a good thing to have to support > serial ports layered over other transports. However these are still serial > ports at the end. I still don't think the javax.comm API is well suited to > "any" serial bus such as I2C, SPI, etc. > Perhaps the javax.com namespace is just wrong. I think thats a larger issue we are not well prepared to answer. We do have a larger group participating so there is interest beyond our current solution. My concern is getting into blue sky efforts that never materialize. We have a very concrete solution that just needs a few modifications to make current java users happy. This solution is more or less supporting POSIX termios on all platforms including windows. This solution does not ask deep questions like is it USB or RS485 or IrDA. Smart kernel people worry about that. Thats what works. When the fun goes away and I'm fixing spam on slow mail-lists, thats what will continue to work. Thats what will be tested on hundreds of machines every six months. I don't want to remind people of JSR80 windows support but you should keep that in mind while getting too far from the crusty roman roads. I'd love to move off to the side in the namespace and leave javax.com for a great effort unifying the time space continuum to be announced at a later date. Beyond that, we would need serious commitment from people in the community to get more working. Both rxtx.org and Sun are about maxed out right now. -- Trent Jarvi tjarvi at qbang.org From martin at jopdesign.com Tue Jul 25 01:32:22 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 09:32:22 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> Message-ID: <005b01c6afbc$794fc060$0202a8c0@luna> >>> None of this is of any particular relevance to the basic underlying >>> question: >>> >>> Should the next JSR attempt to address the multi-drop abilities of RS-485? I would vote for a strong yes. >> >> What I would suggest is to just add a new 'ioctlex'-like method >> to the SerialPort API: A method that you'd use to pass platform- >> or implementation-specific info to the underlying driver or OS >> to do things such as "enabling RS485 mode" or "disable FIFOs" or >> "poll the TSR register". >> >> No need to define any function codes. This is for stuff that is >> platform- or implementation-specific and as such cannot be easily >> abstracted anyway. > > Detrimental to platform independence. We can model it platform independent with two methods: enterTransmit() and extiTransmit() to do whatever is necessary on the underlying platform to switch to RS485 transmit mode and back. Martin From guille at sms.nl Tue Jul 25 01:45:53 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 09:45:53 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <005b01c6afbc$794fc060$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> Message-ID: <7.0.1.0.0.20060725094317.0363b390@sms.nl> Hi Martin, At 09:32 25/07/2006, Martin Schoeberl wrote: > >>> None of this is of any particular relevance to the basic underlying > >>> question: > >>> > >>> Should the next JSR attempt to address the multi-drop abilities > of RS-485? > >I would vote for a strong yes. > > >> > >> What I would suggest is to just add a new 'ioctlex'-like method > >> to the SerialPort API: A method that you'd use to pass platform- > >> or implementation-specific info to the underlying driver or OS > >> to do things such as "enabling RS485 mode" or "disable FIFOs" or > >> "poll the TSR register". > >> > >> No need to define any function codes. This is for stuff that is > >> platform- or implementation-specific and as such cannot be easily > >> abstracted anyway. > > > > Detrimental to platform independence. > >We can model it platform independent with two methods: > >enterTransmit() and extiTransmit() to do whatever is necessary >on the underlying platform to switch to RS485 transmit mode and >back. Tempting as it is, I don't think this covers all cases. For example, in those cases where RS485 direction control must be done 100% in software, the software needs to have a way to flush (sync) software buffers, poll the hardware FIFOs and TSR (not THR), etc. Or, for example, for those UARTs that do automatic RS485 direction control with a configurable turnaround delay, how would you configure this turnaround delay from the application? Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 01:48:10 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 09:48:10 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> Message-ID: <7.0.1.0.0.20060725094602.036cec00@sms.nl> Hi Trent, At 09:21 25/07/2006, Trent Jarvi wrote: >On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: > > > At 19:34 24/07/2006, Gregg Wonderly wrote: > >> Guillermo Rodriguez wrote: > >>> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the > >>> value of standardized APIs to talk to different types of communication > >>> buses including SPI, I2C, 1-Wire, etc., for embedded applications. > >>> However we think this has nothing to do with javax.comm. > >> > >> I don't think this is only about javax.comm. Certainly that's > >> important. I'm > >> just wading into this conversation mainstream and trying to say: > >> > >> If you are going to do anything about "fixing" javax.comm to work on all > >> platforms, please, please, please start with a hardware port SPI > >> definition that > >> lets you get to serial ports, and then provide the existing > javax.com API and > >> whatever new API you think is necessary (I don't have any really > >> issues with the > >> existing API directly). > >> > >> Then, there will be a place for others interesting in SPI, i2C, > USB and other > >> things to get started with providing access to devices that are also > >> interesting > >> in Java applications, and directly, in embedded Java applications. > > > > I do agree that the best a hardware port SPI definition (where > SPI = Service > > Provider Interface, not the SPI protocol) is a good thing to have > to support > > serial ports layered over other transports. However these are still serial > > ports at the end. I still don't think the javax.comm API is well suited to > > "any" serial bus such as I2C, SPI, etc. > > > >Perhaps the javax.com namespace is just wrong. I think thats a larger >issue we are not well prepared to answer. We do have a larger group >participating so there is interest beyond our current solution. My concern was not about the name specifically, but about the idea that a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, IrDA, etc. Looking from a distance all of these may look similar but the fact is, they have little to do with each other (apart from being 'communication protocols' or 'buses') Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From Paul.Klissner at Sun.COM Tue Jul 25 01:51:26 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Tue, 25 Jul 2006 00:51:26 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725082630.036d2d10@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> Message-ID: <44C5CD7E.9030903@sun.com> Guillermo Rodriguez Garcia wrote: > At 19:41 24/07/2006, Paul Klissner wrote: >> Guillermo Rodriguez wrote: >>> Quoting Paul Klissner : >>> >>>>>> None of this is of any particular relevance to the basic underlying >>>>>> question: >>>>>> >>>>>> Should the next JSR attempt to address the multi-drop abilities of >>>> RS-485? >>>>> What I would suggest is to just add a new 'ioctlex'-like method >>>>> to the SerialPort API: A method that you'd use to pass platform- >>>>> or implementation-specific info to the underlying driver or OS >>>>> to do things such as "enabling RS485 mode" or "disable FIFOs" or >>>>> "poll the TSR register". >>>>> >>>>> No need to define any function codes. This is for stuff that is >>>>> platform- or implementation-specific and as such cannot be easily >>>>> abstracted anyway. >>>> Detrimental to platform independence. >>> Yes, it is. But as you go closer and closer to the hardware level some >>> things are by nature platform-dependent, and sometimes just cannot be >>> solved in a platform-independent way. In these cases, is it better to >>> have no solution at all than having one that is less than perfect? >>> Put it another way, would you prefer having people say "I just cannot >>> do this in Java; I'll go somewhere else" rather than "I can do this >>> in Java -- only not in a platform-independent way" ? >> If there isn't a reasonable way to abstract it out, then >> why use Java? > > If an application can be 99% platform independent with small bits > being not portable, why *not* use Java? I'd prefer to see people > using Java to write non-portable applications than having them > use C instead. > > I believe that Java should promote platform neutrality, but that > does not necessarily mean precluding the use of anything that is > NOT platform independent. And let's face it, if you are using > javax.comm to talk to some serial device directly, then chances > are you are already tied to some specific hardware anyway. > > Also, some people (myself included) think that Java can also be > used as a systems programming language, not only for applications. > For many embedded platforms this is certainly the case. In our > platform we even write device drivers directly in Java. I would > imagine the Sun SPOT team (www.sunspotworld.com) supports a > similar view. > > If people needs to do non-portable stuff and wants to do it in > Java I'd rather have them do it in Java than tell them to do it > in C instead. That sounds a bit evangelizing. I think C is perfectly viable for some jobs, and might even be preferable in some cases, for example in some cases where performance or space is a factor. I feel it isn't right to corrupt an API with hacks for the goal of enticing users to Java, even for all the 'right' reasons. >> If someone really needs to do funky things with the hardware, >> why wouldn't that be put in the native back end? > > But nobody said the functionality can't be implemented in the > native back end. However you still need an application level API > to enable/disable it. Sure, but the functions, if really along the lines of the defined standard, can be abstracted, rather than cheat with a general purpose hack-all ioctl-like interface that just begs to be abused, lending itself to a litany of non-portable applications. I maintain we should scope the project appropriately, then take our best shot at a reasonably complete set of abstract functions, and improve it if necessary over time (alpha and beta, release candidates? And then update the API in a backward-compatible way based on feedback after FCS if necessary), rather than add an everything-but-the-kitchen-sink escape clause method. A determined programmer facing a corner case can figure out a way to accomplish the goal in most cases. Even if the API doesn't provide an ioctl call, it is possible to create implementation classes that mak methods visible outsidethe scope of the API-defined methods. For example, if I am implementing class Foo in FooImpl.java, And Foo.java defines interface methods a(), b() and c(), FooImpl.java can also have public methods d(), e() and f(), which can be accessed from the application by casting a Foo object into a FooImpl object. This is one way to provide a back door without compromising the core API itself to do it. This puts the responsibility of breaking platform independence on the developers and not on the designers. Paul From tjarvi at qbang.org Tue Jul 25 02:57:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 02:57:28 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725094602.036cec00@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> Message-ID: On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: > Hi Trent, > > At 09:21 25/07/2006, Trent Jarvi wrote: >> On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: >> >>> At 19:34 24/07/2006, Gregg Wonderly wrote: >>>> Guillermo Rodriguez wrote: >>>>> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the >>>>> value of standardized APIs to talk to different types of communication >>>>> buses including SPI, I2C, 1-Wire, etc., for embedded applications. >>>>> However we think this has nothing to do with javax.comm. >>>> >>>> I don't think this is only about javax.comm. Certainly that's >>>> important. I'm >>>> just wading into this conversation mainstream and trying to say: >>>> >>>> If you are going to do anything about "fixing" javax.comm to work on all >>>> platforms, please, please, please start with a hardware port SPI >>>> definition that >>>> lets you get to serial ports, and then provide the existing >> javax.com API and >>>> whatever new API you think is necessary (I don't have any really >>>> issues with the >>>> existing API directly). >>>> >>>> Then, there will be a place for others interesting in SPI, i2C, >> USB and other >>>> things to get started with providing access to devices that are also >>>> interesting >>>> in Java applications, and directly, in embedded Java applications. >>> >>> I do agree that the best a hardware port SPI definition (where >> SPI = Service >>> Provider Interface, not the SPI protocol) is a good thing to have >> to support >>> serial ports layered over other transports. However these are still serial >>> ports at the end. I still don't think the javax.comm API is well suited to >>> "any" serial bus such as I2C, SPI, etc. >>> >> >> Perhaps the javax.com namespace is just wrong. I think thats a larger >> issue we are not well prepared to answer. We do have a larger group >> participating so there is interest beyond our current solution. > > My concern was not about the name specifically, but about the idea that > a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, > IrDA, etc. Looking from a distance all of these may look similar but > the fact is, they have little to do with each other (apart from being > 'communication protocols' or 'buses') > Hi Guillermo Interesting name. Fair enough. My thoughts are that if it can't be unified in the kernel we are out of our skulls trying to do it in user space. Hacks trying to do such will sure to be in open solaris or linux symposiums about why user space sucks. But there is a minimal bit that overlapps that is what most users want. If we limit the scope, it isnt that hard of a problem. By limiting the scope we also limit our deliverables. If you have an interest in a specific area it will probably not be enough. -- Trent Jarvi tjarvi at qbang.org From martin at jopdesign.com Tue Jul 25 03:25:38 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 11:25:38 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> Message-ID: <001901c6afcc$4bcf64f0$0c28a8c0@luna> >> >> >> >> What I would suggest is to just add a new 'ioctlex'-like method >> >> to the SerialPort API: A method that you'd use to pass platform- >> >> or implementation-specific info to the underlying driver or OS >> >> to do things such as "enabling RS485 mode" or "disable FIFOs" or >> >> "poll the TSR register". >> >> >> >> No need to define any function codes. This is for stuff that is >> >> platform- or implementation-specific and as such cannot be easily >> >> abstracted anyway. >> > >> > Detrimental to platform independence. >> >>We can model it platform independent with two methods: >> >>enterTransmit() and extiTransmit() to do whatever is necessary >>on the underlying platform to switch to RS485 transmit mode and >>back. > > Tempting as it is, I don't think this covers all cases. For example, > in those cases where RS485 direction control must be done 100% in > software, the software needs to have a way to flush (sync) software > buffers, poll the hardware FIFOs and TSR (not THR), etc. I just meant to hide those low-level issues you mention in the enter/exitTransmit modes. > > Or, for example, for those UARTs that do automatic RS485 direction > control with a configurable turnaround delay, how would you configure > this turnaround delay from the application? Mmh, perhaps in a similar way as you configure timeouts? Isn't this 'just' a timeout value? Martin From guille at sms.nl Tue Jul 25 04:05:29 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 12:05:29 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <001901c6afcc$4bcf64f0$0c28a8c0@luna> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> Message-ID: <7.0.1.0.0.20060725115736.03706a38@sms.nl> At 11:25 25/07/2006, Martin Schoeberl wrote: > >> >> > >> >> What I would suggest is to just add a new 'ioctlex'-like method > >> >> to the SerialPort API: A method that you'd use to pass platform- > >> >> or implementation-specific info to the underlying driver or OS > >> >> to do things such as "enabling RS485 mode" or "disable FIFOs" or > >> >> "poll the TSR register". > >> >> > >> >> No need to define any function codes. This is for stuff that is > >> >> platform- or implementation-specific and as such cannot be easily > >> >> abstracted anyway. > >> > > >> > Detrimental to platform independence. > >> > >>We can model it platform independent with two methods: > >> > >>enterTransmit() and extiTransmit() to do whatever is necessary > >>on the underlying platform to switch to RS485 transmit mode and > >>back. > > > > Tempting as it is, I don't think this covers all cases. For example, > > in those cases where RS485 direction control must be done 100% in > > software, the software needs to have a way to flush (sync) software > > buffers, poll the hardware FIFOs and TSR (not THR), etc. > >I just meant to hide those low-level issues you mention in the >enter/exitTransmit modes. If the system has dedicated RS485 hardware then the underlying kernel or device driver may know about it and all of the hassle can be conveniently encapsulated in some enter/exitTransmit methods -- but in this case you can also skip these and just have the driver enable transmit mode as long as it has data to transmit, and stay in receive mode otherwise. If the system has a UART that can be configured as RS232 or RS485 then you may need to tell the kernel or device driver to enter RS485 mode explicitly. Your approach may work there as well. If the system does not have dedicated RS485 hardware and you are using an external RS232-RS485 protocol converter (a very common case) then the driver and kernel probably don't know about that and you have to take care at the application level (javax.comm doesn't even need to know this converter exists), and in order to that you may need to do different things depending on the specific converter you're using. > > > > Or, for example, for those UARTs that do automatic RS485 direction > > control with a configurable turnaround delay, how would you configure > > this turnaround delay from the application? > >Mmh, perhaps in a similar way as you configure timeouts? >Isn't this 'just' a timeout value? Yes, but this is just a specific parameter that you can configure in a specific type of UART (an EXAR UART). Other UARTs might be different. The point I'm trying to make is that there are just too many parameters to have an API for each specific case. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 04:12:31 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 12:12:31 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C5CD7E.9030903@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> <44C5CD7E.9030903@sun.com> Message-ID: <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> At 09:51 25/07/2006, Paul Klissner wrote: >Guillermo Rodriguez Garcia wrote: > > At 19:41 24/07/2006, Paul Klissner wrote: > >> Guillermo Rodriguez wrote: > >>> Quoting Paul Klissner : > >>> > >>>>>> None of this is of any particular relevance to the basic underlying > >>>>>> question: > >>>>>> > >>>>>> Should the next JSR attempt to address the multi-drop abilities of > >>>> RS-485? > >>>>> What I would suggest is to just add a new 'ioctlex'-like method > >>>>> to the SerialPort API: A method that you'd use to pass platform- > >>>>> or implementation-specific info to the underlying driver or OS > >>>>> to do things such as "enabling RS485 mode" or "disable FIFOs" or > >>>>> "poll the TSR register". > >>>>> > >>>>> No need to define any function codes. This is for stuff that is > >>>>> platform- or implementation-specific and as such cannot be easily > >>>>> abstracted anyway. > >>>> Detrimental to platform independence. > >>> Yes, it is. But as you go closer and closer to the hardware level some > >>> things are by nature platform-dependent, and sometimes just cannot be > >>> solved in a platform-independent way. In these cases, is it better to > >>> have no solution at all than having one that is less than perfect? > >>> Put it another way, would you prefer having people say "I just cannot > >>> do this in Java; I'll go somewhere else" rather than "I can do this > >>> in Java -- only not in a platform-independent way" ? > >> If there isn't a reasonable way to abstract it out, then > >> why use Java? > > > > If an application can be 99% platform independent with small bits > > being not portable, why *not* use Java? I'd prefer to see people > > using Java to write non-portable applications than having them > > use C instead. > > > > I believe that Java should promote platform neutrality, but that > > does not necessarily mean precluding the use of anything that is > > NOT platform independent. And let's face it, if you are using > > javax.comm to talk to some serial device directly, then chances > > are you are already tied to some specific hardware anyway. > > > > Also, some people (myself included) think that Java can also be > > used as a systems programming language, not only for applications. > > For many embedded platforms this is certainly the case. In our > > platform we even write device drivers directly in Java. I would > > imagine the Sun SPOT team (www.sunspotworld.com) supports a > > similar view. > > > > If people needs to do non-portable stuff and wants to do it in > > Java I'd rather have them do it in Java than tell them to do it > > in C instead. > >That sounds a bit evangelizing. Could be, but then what's wrong with that? As I said there is people that thinks that Java can be perfectly adequate for system level programming -- especially for embedded platforms. I guess the whole issue is whether it is better to have no solution at all for a specific problem than a solution that is not perfect (in this context a "perfect" solution is one that is portable and platform-independent). I think a solution that is not perfect is better than no solution. If I understand correctly you say that you prefer to have no Java solution (and have people use C) rather than one that is not portable. >I think C is perfectly viable >for some jobs, and might even be preferable in some cases, for example >in some cases where performance or space is a factor. I feel it isn't >right to corrupt an API with hacks for the goal of enticing users >to Java, even for all the 'right' reasons. > > >> If someone really needs to do funky things with the hardware, > >> why wouldn't that be put in the native back end? > > > > But nobody said the functionality can't be implemented in the > > native back end. However you still need an application level API > > to enable/disable it. > >Sure, but the functions, if really along the lines of the defined >standard, can be abstracted, rather than cheat with a general >purpose hack-all ioctl-like interface that just begs to be abused, >lending itself to a litany of non-portable applications. Well, I didn't specifically say there's no way to abstract these functions. I only said that it is not easy, and that I don't know of any reasonable way to do it. But if others can find a way, that is fine of course. >I maintain we should scope the project appropriately, then take >our best shot at a reasonably complete set of abstract functions, >and improve it if necessary over time (alpha and beta, release >candidates? And then update the API in a backward-compatible way >based on feedback after FCS if necessary), rather than add an >everything-but-the-kitchen-sink escape clause method. > >A determined programmer facing a corner case can figure out a way >to accomplish the goal in most cases. Even if the API doesn't provide >an ioctl call, it is possible to create implementation classes that >mak methods visible outsidethe scope of the API-defined methods. > >For example, if I am implementing class Foo in FooImpl.java, >And Foo.java defines interface methods a(), b() and c(), >FooImpl.java can also have public methods d(), e() and f(), which can >be accessed from the application by casting a Foo object into >a FooImpl object. This is one way to provide a back door without >compromising the core API itself to do it. This puts the >responsibility of breaking platform independence on the developers >and not on the designers. Yes, that may be a good way to do it. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 04:21:31 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 12:21:31 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> Message-ID: <7.0.1.0.0.20060725121958.03714668@sms.nl> Hi Trent, At 10:57 25/07/2006, Trent Jarvi wrote: > >> Perhaps the javax.com namespace is just wrong. I think thats a larger > >> issue we are not well prepared to answer. We do have a larger group > >> participating so there is interest beyond our current solution. > > > > My concern was not about the name specifically, but about the idea that > > a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, > > IrDA, etc. Looking from a distance all of these may look similar but > > the fact is, they have little to do with each other (apart from being > > 'communication protocols' or 'buses') > > > >Hi Guillermo > >Interesting name. > >Fair enough. My thoughts are that if it can't be unified in the kernel we >are out of our skulls trying to do it in user space. Hacks trying to do >such will sure to be in open solaris or linux symposiums about why user >space sucks. > >But there is a minimal bit that overlapps that is what most users want. >If we limit the scope, it isnt that hard of a problem. By limiting the >scope we also limit our deliverables. If you have an interest in a >specific area it will probably not be enough. Yes, you are right. But isn't this 'minimal bit that overlaps' what we have already? (basically support for UART-based serial ports plus minimal support for parallel ports) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From lyon at docjava.com Tue Jul 25 05:44:43 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 25 Jul 2006 07:44:43 -0400 Subject: [Rxtx] 7 RS485 questions... In-Reply-To: <7.0.1.0.0.20060725115736.03706a38@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: Hi All, 1. Does anyone have a sense for how much larger the JSR would be if it embraced a multi-drop protocol, like RS485? 2. Do we address collision detection and addressing in RS485? 3. How would collision detection and addressing impact the size of the specification? 4. Would JSR80 (and, perhaps a RS485-USB converter) be the more appropriate place for RS485 support? 5. Is RS485 Transmission controlled by RTS, and the TxD line? 6. How tight is the windows timing on control of the RTS line? 7. Does an RTS controlled RS485 converter work well at high baud rates under windows? Thanks! - Doug From naranjo.manuel at gmail.com Tue Jul 25 06:29:45 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Tue, 25 Jul 2006 09:29:45 -0300 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725094602.036cec00@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> Message-ID: <44C60EB9.5000803@gmail.com> Guillermo Rodriguez Garcia escribi?: > My concern was not about the name specifically, but about the idea that > a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, > IrDA, etc. Looking from a distance all of these may look similar but > the fact is, they have little to do with each other (apart from being > 'communication protocols' or 'buses') > I think Guillermo is right, all ports has in common that they are buses. A stupid idea but why don't declarate the package javax.bus and make javax.comm a dedicated namespace to rs232 and parallell to mantain backward compatibility, obviously the classes at javax.comm should extend classes from javax.bus. Regards, Manuel From j.a.horsmeier at wanadoo.nl Tue Jul 25 07:00:17 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Tue, 25 Jul 2006 15:00:17 +0200 Subject: [Rxtx] 7 RS485 questions... In-Reply-To: Message-ID: <05a701c6afea$47002e00$0a01a8c0@CALVIN> Douglas Lyon wrote: > 1. Does anyone have a sense for how much larger the JSR would > be if it embraced a multi-drop protocol, like RS485? The RS485 multidrop capability all resides on top of the communication layer, i.e. all transmitters but one are disabled (all devices are just listening). When the message has been sent at most one device answers (see 2) > 2. Do we address collision detection and addressing in RS485? Addressing a device is also implemented on top of the communication layer. If/when two devices happen to have the same address it would be disastrous. An address is defined by the protocol, e.g. modbus allows for 250 or so different addresses but another protocol might allow for 2^32 different devices hooked up on one two wire cable. > 3. How would collision detection and addressing impact the size of > the specification? IMHO it's none of rxtx's business, it's a configuration error on the devices if that happens. > 4. Would JSR80 (and, perhaps a RS485-USB converter) be the > more appropriate place for RS485 support? Don't know. > 5. Is RS485 Transmission controlled by RTS, and the TxD line? Two wire RS485 doesn't have a RTS line. It's all in the timing. The half duplex protocol is extremely simple: one master sends, all devices listen, after that at most one device enables its transmitter and sends something back. > 6. How tight is the windows timing on control of the RTS line? Before a device enables its transmitter it should wait a bit because of cable lengths and the other device that must *disable* its transmitter. It's all up to the devices and rxtx can do nothing about it. > 7. Does an RTS controlled RS485 converter work well at high baud > rates under windows? Baud rates aren't the problem; cable lengths are the problem, sensitivity for distortion are the problem. The wait time between en/disabling transmitters can be configured in the devices and can be software controlled on the pc. kind regards, Jos From tjarvi at qbang.org Tue Jul 25 07:08:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 07:08:53 -0600 (MDT) Subject: [Rxtx] 7 RS485 questions... In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: > 5. Is RS485 Transmission controlled by RTS, and the TxD line? This is done when using EIA232 to drive RS485 with no adaptor. This is the RS485 hack that is in RXTX 2.1 that never went anyplace. I discovered no typical kernel will openly support this line of thought. It is not maintainable. There are hardware solutions. Off the top of my head it required < 10 ms responses and typical kernels + java do 10 ms responses. Realtime kernels or special kernel drivers are required. It is possible but not supportable. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Tue Jul 25 07:46:52 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 08:46:52 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <005b01c6afbc$794fc060$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> Message-ID: <44C620CC.6090901@cox.net> Martin Schoeberl wrote: > We can model it platform independent with two methods: > > enterTransmit() and extiTransmit() to do whatever is necessary > on the underlying platform to switch to RS485 transmit mode and > back. Or, do what is typically done, and use a single write operation as the indication of a 'packet' that will let the underlying RS-485/422 driver assert the appropriate signalling. Gregg Wonderly From guille at sms.nl Tue Jul 25 07:48:04 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 15:48:04 +0200 Subject: [Rxtx] 7 RS485 questions... In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: <7.0.1.0.0.20060725154329.036deb18@sms.nl> Hi Doug, Some answers below. At 13:44 25/07/2006, Dr. Douglas Lyon wrote: >Hi All, > >1. Does anyone have a sense for how much larger the JSR would be >if it embraced a multi-drop protocol, like RS485? As I've said in other mails RS485 is in essence just a UART-based serial port interface just like RS232. The only functional difference is that it is multi-drop and half-duplex so there must be a way for nodes to switch between transmit and receive modes but then the RS485 standard does not tell you when or how you should do that -- this depends on the upper layer protocols (for example Modbus) >2. Do we address collision detection and addressing in RS485? Collision detection and addressing are not defined by the RS485 standard. Upper layer protocols such as Modbus take care of that. >3. How would collision detection and addressing impact the size of >the specification? See above. >4. Would JSR80 (and, perhaps a RS485-USB converter) be the more appropriate >place for RS485 support? I don't think so. As I said RS485 is just a serial port like RS232 is. >5. Is RS485 Transmission controlled by RTS, and the TxD line? Some RS232-RS485 protocol converters use the RTS line as a control signal to switch between transmit and receive modes. Others use DTR. Others do not use any of them. >6. How tight is the windows timing on control of the RTS line? Depends on the upper layer protocols, e.g. Modbus. Not defined by RS485. >7. Does an RTS controlled RS485 converter work well at high baud >rates under windows? Depends on how tight the timing is. For some applications it may work well but for many probably won't. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 09:22:09 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Tue, 25 Jul 2006 17:22:09 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C620CC.6090901@cox.net> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> Message-ID: <1153840929.44c6372186f67@webmail.eatserver.nl> Hi Gregg, Quoting Gregg Wonderly : > Martin Schoeberl wrote: > > We can model it platform independent with two methods: > > > > enterTransmit() and extiTransmit() to do whatever is necessary > > on the underlying platform to switch to RS485 transmit mode and > > back. > > Or, do what is typically done, and use a single write operation as the > indication of a 'packet' that will let the underlying RS-485/422 driver > assert > the appropriate signalling. The problem with this is that there is no guarantee that a single call to the write method of the OutputStream associated with a javax.comm SerialPort will translate to a single write to the underlying device driver -- this depends on the javax.comm implementation. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From Paul.Klissner at Sun.COM Tue Jul 25 09:35:19 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Tue, 25 Jul 2006 08:35:19 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C60EB9.5000803@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> <44C60EB9.5000803@gmail.com> Message-ID: <44C63A37.8080406@sun.com> Manuel Francisco Naranjo wrote: > Guillermo Rodriguez Garcia escribi?: >> My concern was not about the name specifically, but about the idea that >> a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, >> IrDA, etc. Looking from a distance all of these may look similar but >> the fact is, they have little to do with each other (apart from being >> 'communication protocols' or 'buses') >> > I think Guillermo is right, all ports has in common that they are buses. > A stupid idea but why don't declarate the package javax.bus and make > javax.comm a dedicated namespace to rs232 and parallell to mantain > backward compatibility, obviously the classes at javax.comm should > extend classes from javax.bus. I like the initial sound of that idea too and was starting to think along those lines myself. But what would be the points of commonality to extend? Device mapping, ownership? Read, write, type, status? Too late for javax.usb (JSR80) very complex Bus and for the most part cast in stone. And 'bus' has such a wide scope. Also that would imply two downloads to install any given bus support, which might not be the end of the world. And maybe two JSRs? Paul From martin at jopdesign.com Tue Jul 25 09:37:12 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 17:37:12 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> Message-ID: <00c801c6b000$33a68f00$0c28a8c0@luna> >> Martin Schoeberl wrote: >> > We can model it platform independent with two methods: >> > >> > enterTransmit() and extiTransmit() to do whatever is necessary >> > on the underlying platform to switch to RS485 transmit mode and >> > back. >> >> Or, do what is typically done, and use a single write operation as the >> indication of a 'packet' that will let the underlying RS-485/422 driver >> assert >> the appropriate signalling. > > The problem with this is that there is no guarantee that a single call > to the write method of the OutputStream associated with a javax.comm > SerialPort will translate to a single write to the underlying device > driver -- this depends on the javax.comm implementation. > I completely agree - it's still a stream and not a packet. This is similar to a single write to a TCP/IP socket. There is no guarantee that you get this data as a single packet/single read on the other side. However, I've seen a lot of programs assuming that this happens ;-) Martin From gergg at cox.net Tue Jul 25 10:15:41 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 11:15:41 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725082124.036309e0@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> Message-ID: <44C643AD.6020604@cox.net> Guillermo Rodriguez Garcia wrote: > At 19:34 24/07/2006, Gregg Wonderly wrote: >>Then, there will be a place for others interesting in SPI, i2C, USB and other >>things to get started with providing access to devices that are also >>interesting >>in Java applications, and directly, in embedded Java applications. > > I do agree that the best a hardware port SPI definition (where SPI = Service > Provider Interface, not the SPI protocol) is a good thing to have to support > serial ports layered over other transports. However these are still serial > ports at the end. I still don't think the javax.comm API is well suited to > "any" serial bus such as I2C, SPI, etc. Yes, absolutely these other wire protocols are different. As I tried to say before, I think that the javax.comm API works fine for my needs. I think that we need to keep it around, no matter what else happens. So, for me, there are a few choices. 1. Create a new JSR to formalize the existing API and include some hardwired JNI code to provide port enumeration and access. 2. Create a new JSR to create a port abstraction SPI to allow JVM providers to enumerate all kinds of port/circuit based hardware to the JVM. Create an implementation of the existing javax.comm API that uses this SPI. 3. Just implement some JNI and Java libraries post them on sourceforge/java.net and let people have at them. For 1 and 2, you'll have to get the JCP to approve that the JSR is worth making a standard. Option 3 doesn't really solve a problem as much as it creates a new way to deal with an existing problem. I think 2 is the most desireable way to go. It really will open the door for more access to hardware from Java! Gregg Wonderly From joachim at buechse.de Tue Jul 25 10:17:07 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 25 Jul 2006 18:17:07 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <00c801c6b000$33a68f00$0c28a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: Just trigger writing on flush(). It is perfectly legal for an Outputstream implementation to do do nothing until flush is called and the documentation of OutputStream.flush reads: "Flushes this output stream and forces any buffered output bytes to be written out. The general contract of flush is that calling it is an indication that, if any bytes previously written have been buffered by the implementation of the output stream, such bytes should immediately be written to their intended destination." As RS485 is a "dont speak up unless requested" protocol, a mandatory flush after write seems like the way to go to me No client can prevent another client from writing, so there is no point in keeping the output-drivers enabled after all data currently buffered has been written. So flush() should trigger "enterTransmit, writePacket[s], exitTransmit". If the service provider (ie concrete implementation of the flush method) decides that the write is inapropriate at the moment (ie because of a higher level arbitration protocol that might be implemented by the service provider) it will simply block the flush or throw an IOException (preferably after some sort of timeout). Regards, Joachim PS: It is great to see all the motivation that is brought forward on this list regarding the future. It would be great if only 10% of that motivation could be transformed into a cleanup and extension of the existing code. The current code access model seems rather inappropriate for the prototyping of the ideas beeing presented. Trent can we get a "contributions" branch with "free" access. On 25.07.2006, at 17:37, Martin Schoeberl wrote: >>> Martin Schoeberl wrote: >>>> We can model it platform independent with two methods: >>>> >>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>> on the underlying platform to switch to RS485 transmit mode and >>>> back. >>> >>> Or, do what is typically done, and use a single write operation >>> as the >>> indication of a 'packet' that will let the underlying RS-485/422 >>> driver >>> assert >>> the appropriate signalling. >> >> The problem with this is that there is no guarantee that a single >> call >> to the write method of the OutputStream associated with a javax.comm >> SerialPort will translate to a single write to the underlying device >> driver -- this depends on the javax.comm implementation. >> > I completely agree - it's still a stream and not a packet. > > This is similar to a single write to a TCP/IP socket. There > is no guarantee that you get this data as a single packet/single > read on the other side. However, I've seen a lot of programs > assuming that this happens ;-) > > Martin > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Tue Jul 25 10:34:59 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Tue, 25 Jul 2006 18:34:59 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <1153845299.44c64833920bd@webmail.eatserver.nl> Hi Joachim, That is a very nice approach which I think would work well as far as the underlying device driver knows about RS485. However it still does not solve the problem with external protocol converters where the device driver only knows about regular UARTs and RTS or DTR must be used to toggle direction of the converter. Guillermo Quoting Joachim Buechse : > Just trigger writing on flush(). It is perfectly legal for an > Outputstream implementation to do do nothing until flush is called > and the documentation of OutputStream.flush reads: > > "Flushes this output stream and forces any buffered output bytes to > be written out. The general contract of flush is that calling it is > an indication that, if any bytes previously written have been > buffered by the implementation of the output stream, such bytes > should immediately be written to their intended destination." > > As RS485 is a "dont speak up unless requested" protocol, a mandatory > flush after write seems like the way to go to me > > No client can prevent another client from writing, so there is no > point in keeping the output-drivers enabled after all data currently > buffered has been written. So flush() should trigger "enterTransmit, > writePacket[s], exitTransmit". If the service provider (ie concrete > implementation of the flush method) decides that the write is > inapropriate at the moment (ie because of a higher level arbitration > protocol that might be implemented by the service provider) it will > simply block the flush or throw an IOException (preferably after some > sort of timeout). > > Regards, > Joachim > > PS: It is great to see all the motivation that is brought forward on > this list regarding the future. It would be great if only 10% of that > motivation could be transformed into a cleanup and extension of the > existing code. The current code access model seems rather > inappropriate for the prototyping of the ideas beeing presented. > Trent can we get a "contributions" branch with "free" access. > > > On 25.07.2006, at 17:37, Martin Schoeberl wrote: > > >>> Martin Schoeberl wrote: > >>>> We can model it platform independent with two methods: > >>>> > >>>> enterTransmit() and extiTransmit() to do whatever is necessary > >>>> on the underlying platform to switch to RS485 transmit mode and > >>>> back. > >>> > >>> Or, do what is typically done, and use a single write operation > >>> as the > >>> indication of a 'packet' that will let the underlying RS-485/422 > >>> driver > >>> assert > >>> the appropriate signalling. > >> > >> The problem with this is that there is no guarantee that a single > >> call > >> to the write method of the OutputStream associated with a javax.comm > >> SerialPort will translate to a single write to the underlying device > >> driver -- this depends on the javax.comm implementation. > >> > > I completely agree - it's still a stream and not a packet. > > > > This is similar to a single write to a TCP/IP socket. There > > is no guarantee that you get this data as a single packet/single > > read on the other side. However, I've seen a lot of programs > > assuming that this happens ;-) > > > > Martin > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- http://www.snijder.com/ SNIJDER Micro Systems From guille at sms.nl Tue Jul 25 10:44:56 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Tue, 25 Jul 2006 18:44:56 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C643AD.6020604@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <44C643AD.6020604@cox.net> Message-ID: <1153845896.44c64a8890968@webmail.eatserver.nl> Hi Gregg, Quoting Gregg Wonderly : > Guillermo Rodriguez Garcia wrote: > > At 19:34 24/07/2006, Gregg Wonderly wrote: > >>Then, there will be a place for others interesting in SPI, i2C, USB and > other > >>things to get started with providing access to devices that are also > >>interesting > >>in Java applications, and directly, in embedded Java applications. > > > > I do agree that the best a hardware port SPI definition (where SPI = > Service > > Provider Interface, not the SPI protocol) is a good thing to have to > support > > serial ports layered over other transports. However these are still serial > > ports at the end. I still don't think the javax.comm API is well suited to > > "any" serial bus such as I2C, SPI, etc. > > Yes, absolutely these other wire protocols are different. As I tried to say > > before, I think that the javax.comm API works fine for my needs. I think > that > we need to keep it around, no matter what else happens. So, for me, there > are a > few choices. > > 1. Create a new JSR to formalize the existing API and include some hardwired > JNI > code to provide port enumeration and access. > > 2. Create a new JSR to create a port abstraction SPI to allow JVM providers > to > enumerate all kinds of port/circuit based hardware to the JVM. Create an > implementation of the existing javax.comm API that uses this SPI. As an embedded Java vendor we work very close to the hardware level and have to deal daily with dozens of different types of ports and communication buses and protocols. Based on our experience I think that a SPI for "all kinds of port/circuit based hardware" is just too generic and not really practical. I think having a Service Provider Interface within javax.comm so that custom serial port implementations can be plugged in is a very good idea. However I don't think it is convenient to have it as a separate JSR and then with such a broad scope. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From joachim at buechse.de Tue Jul 25 10:56:12 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 25 Jul 2006 18:56:12 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <1153845299.44c64833920bd@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> <1153845299.44c64833920bd@webmail.eatserver.nl> Message-ID: In this case you need to configure your port with a different device driver. You may optionally take an existing port, wrap it up in a "wrapping device driver" implemented in Java and add it to the list of ports as a new port... In any case the core application should not care. On 25.07.2006, at 18:34, Guillermo Rodriguez wrote: > Hi Joachim, > > That is a very nice approach which I think would work well as far > as the underlying device driver knows about RS485. > > However it still does not solve the problem with external protocol > converters where the device driver only knows about regular UARTs > and RTS or DTR must be used to toggle direction of the converter. > > Guillermo > > Quoting Joachim Buechse : > >> Just trigger writing on flush(). It is perfectly legal for an >> Outputstream implementation to do do nothing until flush is called >> and the documentation of OutputStream.flush reads: >> >> "Flushes this output stream and forces any buffered output bytes to >> be written out. The general contract of flush is that calling it is >> an indication that, if any bytes previously written have been >> buffered by the implementation of the output stream, such bytes >> should immediately be written to their intended destination." >> >> As RS485 is a "dont speak up unless requested" protocol, a mandatory >> flush after write seems like the way to go to me >> >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). >> >> Regards, >> Joachim >> >> PS: It is great to see all the motivation that is brought forward on >> this list regarding the future. It would be great if only 10% of that >> motivation could be transformed into a cleanup and extension of the >> existing code. The current code access model seems rather >> inappropriate for the prototyping of the ideas beeing presented. >> Trent can we get a "contributions" branch with "free" access. >> >> >> On 25.07.2006, at 17:37, Martin Schoeberl wrote: >> >>>>> Martin Schoeberl wrote: >>>>>> We can model it platform independent with two methods: >>>>>> >>>>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>>>> on the underlying platform to switch to RS485 transmit mode and >>>>>> back. >>>>> >>>>> Or, do what is typically done, and use a single write operation >>>>> as the >>>>> indication of a 'packet' that will let the underlying RS-485/422 >>>>> driver >>>>> assert >>>>> the appropriate signalling. >>>> >>>> The problem with this is that there is no guarantee that a single >>>> call >>>> to the write method of the OutputStream associated with a >>>> javax.comm >>>> SerialPort will translate to a single write to the underlying >>>> device >>>> driver -- this depends on the javax.comm implementation. >>>> >>> I completely agree - it's still a stream and not a packet. >>> >>> This is similar to a single write to a TCP/IP socket. There >>> is no guarantee that you get this data as a single packet/single >>> read on the other side. However, I've seen a lot of programs >>> assuming that this happens ;-) >>> >>> Martin >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > > -- > http://www.snijder.com/ > SNIJDER Micro Systems > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From martin at jopdesign.com Tue Jul 25 11:13:10 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 19:13:10 +0200 Subject: [Rxtx] JSR Direction; packetizing writes References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com><005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net><1153840929.44c6372186f67@webmail.eatserver.nl><00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <000f01c6b00d$9bcc51c0$0202a8c0@luna> > No client can prevent another client from writing, so there is no > point in keeping the output-drivers enabled after all data currently > buffered has been written. So flush() should trigger "enterTransmit, > writePacket[s], exitTransmit". If the service provider (ie concrete > implementation of the flush method) decides that the write is > inapropriate at the moment (ie because of a higher level arbitration > protocol that might be implemented by the service provider) it will > simply block the flush or throw an IOException (preferably after some > sort of timeout). Not only flush() would mean enterTransmit(). With your idea each write should enable the driver, but only flush() can disable the driver after the last byte is written. RS485 is a beast. E.g. some driver chips need a few us (100us for a Maxim 1480B!) from output enable till output low/high. On a different application we had to wait a little bit before disabling the output driver to have a clear '1' on the bus as it took too long for the termination resistors to force the bus to 1. I can imagine that this is not really funny with general RS232/RS485 converters. Martin From joachim at buechse.de Tue Jul 25 11:42:18 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 25 Jul 2006 19:42:18 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <000f01c6b00d$9bcc51c0$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com><005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net><1153840929.44c6372186f67@webmail.eatserver.nl><00c801c6b000$33a68f00$0c28a8c0@luna> <000f01c6b00d$9bcc51c0$0202a8c0@luna> Message-ID: Simple answer: NO. You can not control the timing of the Java VM (especially not on ME) and hence you do not want to enable the outputs before you have all data collected. The timings you mention are all in the implementation space of the device driver. The core application should not care, neither should the javax.comm api in my opinion. Should I happen to be the pour soul that tries to implement an RS485 device driver reference implementation I will try to remember your email and add appropriate properties. Regards, Joachim On 25.07.2006, at 19:13, Martin Schoeberl wrote: >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). > > Not only flush() would mean enterTransmit(). With your idea each > write should enable the driver, but only flush() can disable > the driver after the last byte is written. > > RS485 is a beast. E.g. some driver chips need a few us (100us > for a Maxim 1480B!) from output enable till output low/high. > > On a different application we had to wait a little bit before > disabling the output driver to have a clear '1' on the bus as it took > too long for the termination resistors to force the bus to 1. > > I can imagine that this is not really funny with general > RS232/RS485 converters. > > Martin > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Tue Jul 25 12:50:20 2006 From: jredman at ergotech.com (Jim Redman) Date: Tue, 25 Jul 2006 12:50:20 -0600 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <44C667EC.2070602@ergotech.com> The horror! This would be terribly inefficient. Especially in serial protocols you need to start getting bits on the wire as soon as possible. It could also have some timeout implications. Jim Joachim Buechse wrote: > Just trigger writing on flush(). It is perfectly legal for an > Outputstream implementation to do do nothing until flush is called > and the documentation of OutputStream.flush reads: > > "Flushes this output stream and forces any buffered output bytes to > be written out. The general contract of flush is that calling it is > an indication that, if any bytes previously written have been > buffered by the implementation of the output stream, such bytes > should immediately be written to their intended destination." > > As RS485 is a "dont speak up unless requested" protocol, a mandatory > flush after write seems like the way to go to me > > No client can prevent another client from writing, so there is no > point in keeping the output-drivers enabled after all data currently > buffered has been written. So flush() should trigger "enterTransmit, > writePacket[s], exitTransmit". If the service provider (ie concrete > implementation of the flush method) decides that the write is > inapropriate at the moment (ie because of a higher level arbitration > protocol that might be implemented by the service provider) it will > simply block the flush or throw an IOException (preferably after some > sort of timeout). > > Regards, > Joachim > > PS: It is great to see all the motivation that is brought forward on > this list regarding the future. It would be great if only 10% of that > motivation could be transformed into a cleanup and extension of the > existing code. The current code access model seems rather > inappropriate for the prototyping of the ideas beeing presented. > Trent can we get a "contributions" branch with "free" access. > > > On 25.07.2006, at 17:37, Martin Schoeberl wrote: > >>>> Martin Schoeberl wrote: >>>>> We can model it platform independent with two methods: >>>>> >>>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>>> on the underlying platform to switch to RS485 transmit mode and >>>>> back. >>>> Or, do what is typically done, and use a single write operation >>>> as the >>>> indication of a 'packet' that will let the underlying RS-485/422 >>>> driver >>>> assert >>>> the appropriate signalling. >>> The problem with this is that there is no guarantee that a single >>> call >>> to the write method of the OutputStream associated with a javax.comm >>> SerialPort will translate to a single write to the underlying device >>> driver -- this depends on the javax.comm implementation. >>> >> I completely agree - it's still a stream and not a packet. >> >> This is similar to a single write to a TCP/IP socket. There >> is no guarantee that you get this data as a single packet/single >> read on the other side. However, I've seen a lot of programs >> assuming that this happens ;-) >> >> Martin >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From jredman at ergotech.com Tue Jul 25 12:53:02 2006 From: jredman at ergotech.com (Jim Redman) Date: Tue, 25 Jul 2006 12:53:02 -0600 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <000f01c6b00d$9bcc51c0$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com><005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net><1153840929.44c6372186f67@webmail.eatserver.nl><00c801c6b000$33a68f00$0c28a8c0@luna> <000f01c6b00d$9bcc51c0$0202a8c0@luna> Message-ID: <44C6688E.8040202@ergotech.com> Since we now seem to have entered a discussion of how to switch receive/transmit on 485 lines, I can tell you from experience that you cannot reliably do this from Java. Java just is not fast enough. I spend some time trying to get this to work with RXTX and it would work _most_ of the time, but you need to be able to guarantee ms level response which you can't do in any system that doesn't have real-time capabilities. Jim Martin Schoeberl wrote: >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). > > Not only flush() would mean enterTransmit(). With your idea each > write should enable the driver, but only flush() can disable > the driver after the last byte is written. > > RS485 is a beast. E.g. some driver chips need a few us (100us > for a Maxim 1480B!) from output enable till output low/high. > > On a different application we had to wait a little bit before > disabling the output driver to have a clear '1' on the bus as it took > too long for the termination resistors to force the bus to 1. > > I can imagine that this is not really funny with general > RS232/RS485 converters. > > Martin > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Tue Jul 25 13:37:14 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 14:37:14 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725115736.03706a38@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: <44C672EA.1080604@cox.net> Guillermo Rodriguez Garcia wrote: > At 11:25 25/07/2006, Martin Schoeberl wrote: >>Mmh, perhaps in a similar way as you configure timeouts? >>Isn't this 'just' a timeout value? > > Yes, but this is just a specific parameter that you can configure in a > specific type of UART (an EXAR UART). Other UARTs might be different. The > point I'm trying to make is that there are just too many parameters to > have an API for each specific case. In my earlier example/proposal, I included the ability for attributes of a port to be expressed as a collection of enumeration values for standard things. That would be fine for simple things like Input, Output, Sync, Async etc. When there are specific attributes of specific hardware, the vendor is going to have to provide a way to configure those attributes. One of the primary mechanisms in Java to do this is the JavaBean pattern that can be manifested in a Map type object when an API needs to preexist. So, we can provide an mechanism for propagating random attributes using a Map argument to a method such as public void setConfig( Map params ) throws IOException; public Map getConfig() throws IOException; Then, there is a conduit in and out of the driver that the user can use without needing more standards/spec'd code/API. This isn't much different than an ioctl(2) like mechanism, but it feels more Java like. A URL like mechanism, such as that which JDBC drivers use, could also be attractive. I've also wanted to replace java.net with the J2ME connection based mechanism as well. We might consider looking at the J2ME connector architecture to see if there is any gain in using some of that experience. Gregg Wonderly From gergg at cox.net Tue Jul 25 13:38:42 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 14:38:42 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> <44C5CD7E.9030903@sun.com> <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> Message-ID: <44C67342.9020402@cox.net> Guillermo Rodriguez Garcia wrote: > At 09:51 25/07/2006, Paul Klissner wrote: >>For example, if I am implementing class Foo in FooImpl.java, >>And Foo.java defines interface methods a(), b() and c(), >>FooImpl.java can also have public methods d(), e() and f(), which can >>be accessed from the application by casting a Foo object into >>a FooImpl object. This is one way to provide a back door without >>compromising the core API itself to do it. This puts the >>responsibility of breaking platform independence on the developers >>and not on the designers. > > Yes, that may be a good way to do it. The J2ME connector architecture is an example of a place where this is done. Gregg Wonderly From Paul.Klissner at Sun.COM Tue Jul 25 14:02:40 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Tue, 25 Jul 2006 13:02:40 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C67342.9020402@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> <44C5CD7E.9030903@sun.com> <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> <44C67342.9020402@cox.net> Message-ID: <44C678E0.90209@sun.com> Gregg Wonderly wrote: > Guillermo Rodriguez Garcia wrote: >> At 09:51 25/07/2006, Paul Klissner wrote: >>> For example, if I am implementing class Foo in FooImpl.java, >>> And Foo.java defines interface methods a(), b() and c(), >>> FooImpl.java can also have public methods d(), e() and f(), which can >>> be accessed from the application by casting a Foo object into >>> a FooImpl object. This is one way to provide a back door without >>> compromising the core API itself to do it. This puts the >>> responsibility of breaking platform independence on the developers >>> and not on the designers. >> Yes, that may be a good way to do it. > > The J2ME connector architecture is an example of a place where this is done. It's how I debugged my javax.usb implementations. Paul From Pawan.Kharbanda at dot.state.co.us Tue Jul 25 14:02:53 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 25 Jul 2006 14:02:53 -0600 Subject: [Rxtx] Strange error (show stopper) Message-ID: <939A619A756047469C41EE9BA51890FB0429DFA4@hqexchange3.dot.state.co.us> Joachim, I believe it's the same problem that I reported earlier (Thread deadlocks/Locked Ports), I am not a C person so don't know exactly whatz going in the native code but was able to find a workaround for right now by synchronizing the "interruptEventLoop" and "eventLoop" methods in the RXTXPort class. It helped but is not the right solution, I still find the deadlocks but not as often as I used too. A fix for this will be highly appreciated. I have some Test Classes that I have posted earlier to simulate the problem. ~pk -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Joachim Buechse Sent: Monday, July 24, 2006 2:13 AM To: RXTX Developers and Users Subject: Re: [Rxtx] Strange error (show stopper) The pthread_kill is followed by a sleep. When the sleep returns the structure is damaged. I did not find the source that overwrites the closing field - it is correctly set by the exiting drain thread. But something overwrites it afterwards. I currently believe that this existed for some time but was never seen because the previous versions did not rely on the structure to be in good shape when tearing down connections. However I may be completely wrong and it is an OSX problem. To help me find the source, it would be nice to get some indications what the 2 debug lines I suggested return on other platforms. Joachim On 24.07.2006, at 05:27, Trent Jarvi wrote: > On Sat, 22 Jul 2006, Joachim Buechse wrote: > >> I just discovered a strange error in RXTX on OSX. SerialDemo.java >> manages to corrupt the event_info_structure by a simple >> OpenPort,ClosePort - this could be in relation to the deadlock >> problem that was reported recently. >> >> Could anyone try to reproduce this on Solaris or some other system >> which is neither WIN32 nor Linux (ie which uses a drain thread). >> >> In SerialImp.c : RXTXPort(interruptEventLoop) >> >> Apparently the event_info_structure gets corrupted shortly after >> >> pthread_kill(index->drain_tid, SIGABRT); >> >> In particular, the index->closing flag gets overwritten by a pointer >> value. > > Hi Joachim > > Interesting. I did run many tests with that code on may OSs. To be > fair, the tests are just starting to get into good shape again. I'm > still tagging releases with a bit of feel and not enough process. > I'll look at this some more tomorrow night. > > The SIGABRT was added recently as part of the close speedups. > Thats from > memory. I can provide the exact patch that introduced that tomorrow. > > -- > Trent Jarvi > tjarvi at qbang.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Jul 25 17:42:23 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 18:42:23 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153840929.44c6372186f67@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> Message-ID: <44C6AC5F.3060107@cox.net> Guillermo Rodriguez wrote: > The problem with this is that there is no guarantee that a single call > to the write method of the OutputStream associated with a javax.comm > SerialPort will translate to a single write to the underlying device > driver -- this depends on the javax.comm implementation. More specifically, it depends on a software layer that would targeted specifically at solving this problem for RS-485 and other transports which have blocking or packetizing issues. There are many. In amatuer radio, we have TNCs (radio modems) which will block things using newline separators in some modes, and 0xc0 in others. Gregg Wonderly From gergg at cox.net Tue Jul 25 17:46:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 18:46:11 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C63A37.8080406@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> <44C60EB9.5000803@gmail.com> <44C63A37.8080406@sun.com> Message-ID: <44C6AD43.1090302@cox.net> Paul Klissner wrote: > Also that would imply two downloads to install any given > bus support, which might not be the end of the world. > And maybe two JSRs? Why are we hovering around this "downloads" issue? If we create a JSR that covers everything needed for javax.comm compatibility, does that still imply that it would be an unincluded, optional part of the JVM? If that is still something that people will tolerate, I'm a little lost for words. Still today, I can use the old javax.comm support. If we're just going to recreate the same concerns, issues and limitations, then what's the point? Gregg Wonderly From gergg at cox.net Tue Jul 25 17:48:42 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 18:48:42 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <00c801c6b000$33a68f00$0c28a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <44C6ADDA.5040208@cox.net> Martin Schoeberl wrote: > I completely agree - it's still a stream and not a packet. > > This is similar to a single write to a TCP/IP socket. There > is no guarantee that you get this data as a single packet/single > read on the other side. However, I've seen a lot of programs > assuming that this happens ;-) For nearly forever, serialport drivers have operated in the mode that they send either everything up to the divider char, or a single char. This was specifically done for protocols such as modbus which have 1 1/2 bit time delays indicating end of packet. This kind of thing is something that needs to be maintained for serial protocols to work. A user has to have a way to send a single "packet" of data and make sure that it flows out of the uart uninterrupted. Gregg Wonderly From gergg at cox.net Tue Jul 25 18:03:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 19:03:11 -0500 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <939A619A756047469C41EE9BA51890FB0429DFA4@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB0429DFA4@hqexchange3.dot.state.co.us> Message-ID: <44C6B13F.1000306@cox.net> Kharbanda, Pawan wrote: > Joachim, > I believe it's the same problem that I reported earlier (Thread > deadlocks/Locked Ports), I am not a C person so don't know exactly whatz > going in the native code but was able to find a workaround for right now > by synchronizing the "interruptEventLoop" and "eventLoop" methods in the > RXTXPort class. It helped but is not the right solution, I still find > the deadlocks but not as often as I used too. > > A fix for this will be highly appreciated. I have some Test Classes that > I have posted earlier to simulate the problem. You can send SIGQUIT (signal #3) to unix JVMs to get a stacktrace of where all the threads are at and who owns what locks. Also, on windows, you can run the JVM in a DOS window and use CTRL-BREAK to get the stack trace. This won't go beyond the native level, but it might expose what you need to know. Gregg Wonderly From tjarvi at qbang.org Tue Jul 25 22:21:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 22:21:22 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6AC5F.3060107@cox.net> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: On Tue, 25 Jul 2006, Gregg Wonderly wrote: > Guillermo Rodriguez wrote: >> The problem with this is that there is no guarantee that a single call >> to the write method of the OutputStream associated with a javax.comm >> SerialPort will translate to a single write to the underlying device >> driver -- this depends on the javax.comm implementation. > > More specifically, it depends on a software layer that would targeted > specifically at solving this problem for RS-485 and other transports which have > blocking or packetizing issues. There are many. In amatuer radio, we have TNCs > (radio modems) which will block things using newline separators in some modes, > and 0xc0 in others. > I had looked into RS-485 some. It is daunting without proper hardware. One option is to do a native local tcpip/udp server to remove most of the the 'java issues.' Realtime patches comming down the pipe make it tempting to jump into the tarpit of failures. Beyond that, we should be very explicit about what type of RS-485 hardware we do support and it should not involve things that we have to control DTR/RTS in almost realtime (<20 ms). There are going to be people wanting < $5/EURO winmodem type solutions that will be nothing but problems. Thats doable by hacking kernel drivers but it will never get into mainstream kernels. I do not think thats reasonable from java and is even questionable in typical C. It will work fine until you start oracle... It would be nice to get RS-485 support in. Things like controlling low cost devices in houses, ... But cutting out the hardware isn't a viable solution in java. -- Trent Jarvi tjarvi From tjarvi at qbang.org Tue Jul 25 22:40:36 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 22:40:36 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6AD43.1090302@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> <44C60EB9.5000803@gmail.com> <44C63A37.8080406@sun.com> <44C6AD43.1090302@cox.net> Message-ID: On Tue, 25 Jul 2006, Gregg Wonderly wrote: > Paul Klissner wrote: >> Also that would imply two downloads to install any given >> bus support, which might not be the end of the world. >> And maybe two JSRs? > > Why are we hovering around this "downloads" issue? If we create a JSR that > covers everything needed for javax.comm compatibility, does that still imply > that it would be an unincluded, optional part of the JVM? If that is still > something that people will tolerate, I'm a little lost for words. Still today, > I can use the old javax.comm support. If we're just going to recreate the same > concerns, issues and limitations, then what's the point? > I don't have a problem with Sun shipping rxtx or whatever it becomes. They may have some legacy issues :) Just poking fun. The current state does not work for java users. Not having w32 support means about 80+% of the users do not have support. The rxtx w32 support is heavily influenced by cygwin so it wont change license out of respect for that project. If you really hate life and the LGPL, you can do a w32 port and the rest will just fall into place while you chase windows bugs for 5 years. Anything that dances around w32 support is just an academic waste of time. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Tue Jul 25 22:41:21 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 23:41:21 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: <44C6F271.2020604@cox.net> Trent Jarvi wrote: > I had looked into RS-485 some. It is daunting without proper hardware. > One option is to do a native local tcpip/udp server to remove most of the > the 'java issues.' Realtime patches comming down the pipe make it tempting > to jump into the tarpit of failures. Trent, there is not a way for a non-realtime OS to drive 485 hardware without the hardware taking care of the timing issues. But, a non-realtime OS can support software APIs which let the developer express in an API the types of things that a piece of hardware is capable of. Then we can have an API, and the hardware people and the OS people will provide the solutions where possible. > It would be nice to get RS-485 support in. Things like controlling > low cost devices in houses, ... But cutting out the hardware isn't a > viable solution in java. The 485 hardware devices will have to have non-realtime requirements associated with the controlling mechanisms. There are some of those. I'm mostly interested in having a 485 API for realtime java and/or the aJile and other uC environments which can provide realtime environments. Gregg Wonderly From tjarvi at qbang.org Tue Jul 25 22:54:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 22:54:44 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6F271.2020604@cox.net> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <44C6F271.2020604@cox.net> Message-ID: On Tue, 25 Jul 2006, Gregg Wonderly wrote: > Trent Jarvi wrote: >> I had looked into RS-485 some. It is daunting without proper hardware. >> One option is to do a native local tcpip/udp server to remove most of the >> the 'java issues.' Realtime patches comming down the pipe make it tempting >> to jump into the tarpit of failures. > > Trent, there is not a way for a non-realtime OS to drive 485 hardware without > the hardware taking care of the timing issues. But, a non-realtime OS can > support software APIs which let the developer express in an API the types of > things that a piece of hardware is capable of. Then we can have an API, and the > hardware people and the OS people will provide the solutions where possible. > >> It would be nice to get RS-485 support in. Things like controlling >> low cost devices in houses, ... But cutting out the hardware isn't a >> viable solution in java. > > The 485 hardware devices will have to have non-realtime requirements associated > with the controlling mechanisms. There are some of those. I'm mostly > interested in having a 485 API for realtime java and/or the aJile and other uC > environments which can provide realtime environments. > Hi Gregg I do not disagree with you but I have a problem with this (realtime java and/or the aJile and other Uc environements) being something I may be hearing bugs about 5 years from now. Is this really something that should be in the API or is it something that would make a nice niche market for support and services? Do the two really go together? If you like that market and I think there is a niche market there, great. This is a good area for SPI type interfaces where you could support it but it was not provided by default. -- Trent Jarvi tjarvi at qbang.org From guille at sms.nl Wed Jul 26 00:39:47 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 08:39:47 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C672EA.1080604@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> Message-ID: <7.0.1.0.0.20060726083751.03633188@sms.nl> At 21:37 25/07/2006, Gregg Wonderly wrote: >Guillermo Rodriguez Garcia wrote: > > At 11:25 25/07/2006, Martin Schoeberl wrote: > >>Mmh, perhaps in a similar way as you configure timeouts? > >>Isn't this 'just' a timeout value? > > > > Yes, but this is just a specific parameter that you can configure in a > > specific type of UART (an EXAR UART). Other UARTs might be different. The > > point I'm trying to make is that there are just too many parameters to > > have an API for each specific case. > >In my earlier example/proposal, I included the ability for >attributes of a port >to be expressed as a collection of enumeration values for standard >things. That >would be fine for simple things like Input, Output, Sync, Async >etc. When there >are specific attributes of specific hardware, the vendor is going to have to >provide a way to configure those attributes. One of the primary >mechanisms in >Java to do this is the JavaBean pattern that can be manifested in a Map type >object when an API needs to preexist. So, we can provide an mechanism for >propagating random attributes using a Map argument to a method such as > >public void setConfig( Map params ) throws IOException; >public Map getConfig() throws IOException; > >Then, there is a conduit in and out of the driver that the user can >use without >needing more standards/spec'd code/API. > >This isn't much different than an ioctl(2) like mechanism, This is exactly what I was thinking while reading your mail :) >but it feels more Java like. It would do the job as well and I would be happy with that. However Paul's proposal where implementation classes extend the core API as necessary might be more elegant (for the same reason that it is more elegant than ioctl) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Wed Jul 26 00:41:40 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 08:41:40 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6AC5F.3060107@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: <7.0.1.0.0.20060726084016.03633040@sms.nl> At 01:42 26/07/2006, Gregg Wonderly wrote: >Guillermo Rodriguez wrote: > > The problem with this is that there is no guarantee that a single call > > to the write method of the OutputStream associated with a javax.comm > > SerialPort will translate to a single write to the underlying device > > driver -- this depends on the javax.comm implementation. > >More specifically, it depends on a software layer that would targeted >specifically at solving this problem for RS-485 and other transports >which have >blocking or packetizing issues. There are many. In amatuer radio, >we have TNCs >(radio modems) which will block things using newline separators in >some modes, >and 0xc0 in others. Right. I meant that in general one cannot assume that writes to a stream will translate 1:1 to writes in every layer of the protocol stack (this is most often not the case.) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Wed Jul 26 00:44:57 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 08:44:57 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6ADDA.5040208@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> <44C6ADDA.5040208@cox.net> Message-ID: <7.0.1.0.0.20060726084203.036cd2b8@sms.nl> At 01:48 26/07/2006, Gregg Wonderly wrote: >Martin Schoeberl wrote: > > I completely agree - it's still a stream and not a packet. > > > > This is similar to a single write to a TCP/IP socket. There > > is no guarantee that you get this data as a single packet/single > > read on the other side. However, I've seen a lot of programs > > assuming that this happens ;-) > >For nearly forever, serialport drivers have operated in the mode >that they send >either everything up to the divider char, or a single char. This was >specifically done for protocols such as modbus which have 1 1/2 bit >time delays >indicating end of packet. This kind of thing is something that needs to be >maintained for serial protocols to work. A user has to have a way to send a >single "packet" of data and make sure that it flows out of the uart >uninterrupted. Even that is sometimes difficult to achieve. If the whole packet does not fit in the UART FIFOs, then the driver may have a hard time making sure that all of the data flows out uninterrupted, unless 1/ you have a RTOS with a response time that is fast enough to refill the FIFO before it empties, and/or 2/ you can tolerate a 'stop the world' approach where ints are globally disabled while the packet is being sent (not nice) (just a side comment) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From tjarvi at qbang.org Wed Jul 26 00:48:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 26 Jul 2006 00:48:29 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060726084016.03633040@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <7.0.1.0.0.20060726084016.03633040@sms.nl> Message-ID: On Wed, 26 Jul 2006, Guillermo Rodriguez Garcia wrote: > At 01:42 26/07/2006, Gregg Wonderly wrote: >> Guillermo Rodriguez wrote: >>> The problem with this is that there is no guarantee that a single call >>> to the write method of the OutputStream associated with a javax.comm >>> SerialPort will translate to a single write to the underlying device >>> driver -- this depends on the javax.comm implementation. >> >> More specifically, it depends on a software layer that would targeted >> specifically at solving this problem for RS-485 and other transports >> which have >> blocking or packetizing issues. There are many. In amatuer radio, >> we have TNCs >> (radio modems) which will block things using newline separators in >> some modes, >> and 0xc0 in others. > > Right. I meant that in general one cannot assume that writes to a stream > will translate 1:1 to writes in every layer of the protocol stack (this is > most often not the case.) > Hi Guillermo This sounds like a dead end to me. People using commapi want a a write, an interrupt and data. The kernel being a big problem these days. There are _much_ better ways to do things like protocol stacks. This is not how EIA232 works in the real world. -- Trent Jarvi tjarvi From guille at sms.nl Wed Jul 26 01:02:09 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 09:02:09 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <7.0.1.0.0.20060726084016.03633040@sms.nl> Message-ID: <7.0.1.0.0.20060726090154.036dd708@sms.nl> At 08:48 26/07/2006, Trent Jarvi wrote: >On Wed, 26 Jul 2006, Guillermo Rodriguez Garcia wrote: > > > At 01:42 26/07/2006, Gregg Wonderly wrote: > >> Guillermo Rodriguez wrote: > >>> The problem with this is that there is no guarantee that a single call > >>> to the write method of the OutputStream associated with a javax.comm > >>> SerialPort will translate to a single write to the underlying device > >>> driver -- this depends on the javax.comm implementation. > >> > >> More specifically, it depends on a software layer that would targeted > >> specifically at solving this problem for RS-485 and other transports > >> which have > >> blocking or packetizing issues. There are many. In amatuer radio, > >> we have TNCs > >> (radio modems) which will block things using newline separators in > >> some modes, > >> and 0xc0 in others. > > > > Right. I meant that in general one cannot assume that writes to a stream > > will translate 1:1 to writes in every layer of the protocol stack (this is > > most often not the case.) > > > >Hi Guillermo > >This sounds like a dead end to me. People using commapi want a a write, >an interrupt and data. The kernel being a big problem these days. > >There are _much_ better ways to do things like protocol stacks. This is >not how EIA232 works in the real world. Yes, this is exactly what I'm saying. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From Luis.Moreira at jet.uk Wed Jul 26 01:34:42 2006 From: Luis.Moreira at jet.uk (Luis Moreira) Date: Wed, 26 Jul 2006 08:34:42 +0100 Subject: [Rxtx] Portability Message-ID: Hi Guys, I managed to get the RXTX package to work on my PC, but the question is, if I need to distribute my program to someone that does not know much about java how do I get the program to work on their System? Best regards Luis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/3e3c2058/attachment-0335.html From joachim at buechse.de Wed Jul 26 02:18:19 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 26 Jul 2006 10:18:19 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <44C667EC.2070602@ergotech.com> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> <44C667EC.2070602@ergotech.com> Message-ID: I may not have been very clear with my suggestion: The "mandatory" flush after write was only regarding RS485. If an application does not use flush after write (today), it is damned to fail anyway. The Outputstream interface makes no guarentee what so ever, that any data will be writen before you call flush. So in fact flush is already mandatory unless you dont care if your data is ever transmitted. I don't see how sending on flush for RS485 would be less efficient. If you are concerned about the additional function call you may want to specify on which platform/VM you are working. A function call in java even on slow PCs is in the microsecond range. So if your concern is, that writes should be forwarded as soon as possible, well then follow any write by a flush. I haven't done any JavaME serial programming, but from my experience with implementing Ymodem over RS232+USB, all I can say is this: Either you have your data ready when it is demanded and you can write it with a single write(+flush) or your application will be slow. So yes, you need to get data on the wire as quick as possible, the solutions are manyfold but an additional (flush) function call will hardly make your application slower. Regards, Joachim On 25.07.2006, at 20:50, Jim Redman wrote: > The horror! This would be terribly inefficient. Especially in serial > protocols you need to start getting bits on the wire as soon as > possible. It could also have some timeout implications. > > Jim > > Joachim Buechse wrote: >> Just trigger writing on flush(). It is perfectly legal for an >> Outputstream implementation to do do nothing until flush is called >> and the documentation of OutputStream.flush reads: >> >> "Flushes this output stream and forces any buffered output bytes to >> be written out. The general contract of flush is that calling it is >> an indication that, if any bytes previously written have been >> buffered by the implementation of the output stream, such bytes >> should immediately be written to their intended destination." >> >> As RS485 is a "dont speak up unless requested" protocol, a mandatory >> flush after write seems like the way to go to me >> >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). >> >> Regards, >> Joachim >> >> PS: It is great to see all the motivation that is brought forward on >> this list regarding the future. It would be great if only 10% of that >> motivation could be transformed into a cleanup and extension of the >> existing code. The current code access model seems rather >> inappropriate for the prototyping of the ideas beeing presented. >> Trent can we get a "contributions" branch with "free" access. >> >> >> On 25.07.2006, at 17:37, Martin Schoeberl wrote: >> >>>>> Martin Schoeberl wrote: >>>>>> We can model it platform independent with two methods: >>>>>> >>>>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>>>> on the underlying platform to switch to RS485 transmit mode and >>>>>> back. >>>>> Or, do what is typically done, and use a single write operation >>>>> as the >>>>> indication of a 'packet' that will let the underlying RS-485/422 >>>>> driver >>>>> assert >>>>> the appropriate signalling. >>>> The problem with this is that there is no guarantee that a single >>>> call >>>> to the write method of the OutputStream associated with a >>>> javax.comm >>>> SerialPort will translate to a single write to the underlying >>>> device >>>> driver -- this depends on the javax.comm implementation. >>>> >>> I completely agree - it's still a stream and not a packet. >>> >>> This is similar to a single write to a TCP/IP socket. There >>> is no guarantee that you get this data as a single packet/single >>> read on the other side. However, I've seen a lot of programs >>> assuming that this happens ;-) >>> >>> Martin >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Jul 26 04:28:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 26 Jul 2006 06:28:33 -0400 Subject: [Rxtx] Should we defer JSR support of RS485? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: Hi All, Would it make sense to focus the JSR on rock solid serial and parallel port support? Can the RS485 people live with unofficial support, at least until we get the JSR accepted and the implementation rock solid? Thanks! - Doug From gergg at cox.net Wed Jul 26 08:49:21 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 26 Jul 2006 09:49:21 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <44C6F271.2020604@cox.net> Message-ID: <44C780F1.8020506@cox.net> Trent Jarvi wrote: > I do not disagree with you but I have a problem with this (realtime java > and/or the aJile and other Uc environements) being something I may be > hearing bugs about 5 years from now. Is this really something that should > be in the API or is it something that would make a nice niche market for > support and services? Do the two really go together? The question is whether there needs to be two, three or five ways to do the same thing, or can we distill it down to one so that software working in one environment can work in all. > If you like that market and I think there is a niche market there, great. > This is a good area for SPI type interfaces where you could support it but > it was not provided by default. SPI is supported natively on the aJile processors. Systronix provides an API for using the SPI lines defined for that use. Adding extra slave selects is not part of their API. There are plenty of places where this stuff is getting used. In the C world of uC, there are 500 ways to do the same thing because everyone wants to be as close to the hardware as possible. The trumpet of the Java platform proclaims write once, run anywhere. Thats been a powerful impetus to me and others to use the language. I really do appreciate that I don't have to think about non-application related programming tasks as much as I did in C and C++. It's possible to pick a reasonable level of abstraction that provide opportunity to expand in the future while accounting for the small in the present. But, we have to all get together with a desire to accomplish this, have good constructive conversation and feedback, and get it done. Gregg Wonderly From gergg at cox.net Wed Jul 26 08:56:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 26 Jul 2006 09:56:11 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060726083751.03633188@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> Message-ID: <44C7828B.7040904@cox.net> Guillermo Rodriguez Garcia wrote: > It would do the job as well and I would be happy with that. However > Paul's proposal where implementation classes extend the core API as > necessary might be more elegant (for the same reason that it is more > elegant than ioctl) Right, but my argument was that this demanded that the classes preexist at the time I am writing the software. I have to be able to compile against them. The Map mechanism would allow me to write software that worked with any hardware. The person deploying my software into their environment with their hardware would then just provide a set of configuration values that my software would pass into the API. That's the point I'm trying to make. I'm on the fence about a Map vs a subclass with methods. I can see it both ways. But, as a JDBC user, I've learned to appreciate a single API with Properties passed in. As a Jini user I've learned to appreciate the Configuration mechanisms that Jini 2.x has. I can write code in my configuration file to instantiate and configure the system at deployment time! Gregg Wonderly From joachim at buechse.de Wed Jul 26 09:37:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 26 Jul 2006 17:37:27 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C7828B.7040904@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> <44C7828B.7040904@cox.net> Message-ID: <08E356DB-AC3F-46FC-952B-82D5ABB15926@buechse.de> Unless you are working with J2ME, you can just as well do what you describe using reflection (ie a JavaBean strategy). A Map can change at runtime, an interface can not. Regards, Joachim On 26.07.2006, at 16:56, Gregg Wonderly wrote: > Guillermo Rodriguez Garcia wrote: >> It would do the job as well and I would be happy with that. However >> Paul's proposal where implementation classes extend the core API as >> necessary might be more elegant (for the same reason that it is more >> elegant than ioctl) > > Right, but my argument was that this demanded that the classes > preexist at the > time I am writing the software. I have to be able to compile > against them. > > The Map mechanism would allow me to write software that worked with > any > hardware. The person deploying my software into their environment > with their > hardware would then just provide a set of configuration values that > my software > would pass into the API. > > That's the point I'm trying to make. I'm on the fence about a Map > vs a subclass > with methods. I can see it both ways. But, as a JDBC user, I've > learned to > appreciate a single API with Properties passed in. As a Jini user > I've learned > to appreciate the Configuration mechanisms that Jini 2.x has. I > can write code > in my configuration file to instantiate and configure the system at > deployment > time! > > config/ConfigurationFile.html> > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Paul.Klissner at Sun.COM Wed Jul 26 12:11:37 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 26 Jul 2006 11:11:37 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C780F1.8020506@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <44C6F271.2020604@cox.net> <44C780F1.8020506@cox.net> Message-ID: <44C7B059.1060302@sun.com> Gregg Wonderly wrote: > Trent Jarvi wrote: >> I do not disagree with you but I have a problem with this (realtime java >> and/or the aJile and other Uc environements) being something I may be >> hearing bugs about 5 years from now. Is this really something that should >> be in the API or is it something that would make a nice niche market for >> support and services? Do the two really go together? > > The question is whether there needs to be two, three or five ways to do the same > thing, or can we distill it down to one so that software working in one > environment can work in all. > >> If you like that market and I think there is a niche market there, great. >> This is a good area for SPI type interfaces where you could support it but >> it was not provided by default. > > SPI is supported natively on the aJile processors. Systronix provides an API > for using the SPI lines defined for that use. Adding extra slave selects is not > part of their API. > > There are plenty of places where this stuff is getting used. In the C world of > uC, there are 500 ways to do the same thing because everyone wants to be as > close to the hardware as possible. > > The trumpet of the Java platform proclaims write once, run anywhere. Thats been > a powerful impetus to me and others to use the language. I really do appreciate > that I don't have to think about non-application related programming tasks as > much as I did in C and C++. > > It's possible to pick a reasonable level of abstraction that provide opportunity > to expand in the future while accounting for the small in the present. > > But, we have to all get together with a desire to accomplish this, have good > constructive conversation and feedback, and get it done. I agree that whatever approach we take should involve settling on the scope and then seeking to create a reasonably complete set of abstractions to generalize and make platform independent, and then refine that list as corner cases appear. For whichever bus(ses) we support, it will be standards-based functionality we're trying to support, with device-specific functionality hidden in the driver and not passed through as direct driver-oriented commands via the API. Paul > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Paul.Klissner at Sun.COM Wed Jul 26 12:23:56 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 26 Jul 2006 11:23:56 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C7828B.7040904@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> <44C7828B.7040904@cox.net> Message-ID: <44C7B33C.8090005@sun.com> Gregg Wonderly wrote: > Guillermo Rodriguez Garcia wrote: >> It would do the job as well and I would be happy with that. However >> Paul's proposal where implementation classes extend the core API as >> necessary might be more elegant (for the same reason that it is more >> elegant than ioctl) > > Right, but my argument was that this demanded that the classes preexist at the > time I am writing the software. I have to be able to compile against them. > > The Map mechanism would allow me to write software that worked with any > hardware. The person deploying my software into their environment with their > hardware would then just provide a set of configuration values that my software > would pass into the API. > > That's the point I'm trying to make. I'm on the fence about a Map vs a subclass > with methods. I can see it both ways. But, as a JDBC user, I've learned to > appreciate a single API with Properties passed in. As a Jini user I've learned > to appreciate the Configuration mechanisms that Jini 2.x has. I can write code > in my configuration file to instantiate and configure the system at deployment > time! I don't think this is a problem as long as the implementation specific stuff is handled by controlling through vehicles outside the API. The application code layered over the API should be written such that it can run on any platform and with any generic device of the class the API claims to support. The problem with the ioctl is it's proneness for abuse and invitation to proliferate the space with non-portable applications. If the implementation requires a configuration file to be passed through the API then the application can run on platform A, B and C, which all have the same type of device, fine, and then with a different configuration file, could run on D, E and F with other hardware, that seems reasonable. What if there are multiple devices on a system of different types? There needs to be a way to get the right configuration file to associate with the right device, and the application should seamlessly work with either. The application code layered over the API should not have to be aware of the configuration file or the programmatic peculiarities of the underlying hardware. Paul From joachim at buechse.de Wed Jul 26 12:59:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 26 Jul 2006 20:59:06 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C7B33C.8090005@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> <44C7828B.7040904@cox.net> <44C7B33C.8090005@sun.com> Message-ID: <1A34B6D0-43B2-4F73-A39F-004B3D100CE9@buechse.de> Paul honestly I think you are to extreme - Often enough a USER is very well capable of indentifying which "config file" needs to be choosen to set up the device he owns. This file can be accepted from the application as a "configuration parameter" and passed on to the driver. One very typical example are AT-command sequences. Terminal programs know nothing about their meaning - still they happily pass them on to do their magic. Best regards, Joachim On 26.07.2006, at 20:23, Paul Klissner wrote: > Gregg Wonderly wrote: >> Guillermo Rodriguez Garcia wrote: >>> It would do the job as well and I would be happy with that. However >>> Paul's proposal where implementation classes extend the core API as >>> necessary might be more elegant (for the same reason that it is more >>> elegant than ioctl) >> >> Right, but my argument was that this demanded that the classes >> preexist at the >> time I am writing the software. I have to be able to compile >> against them. >> >> The Map mechanism would allow me to write software that worked >> with any >> hardware. The person deploying my software into their environment >> with their >> hardware would then just provide a set of configuration values >> that my software >> would pass into the API. >> >> That's the point I'm trying to make. I'm on the fence about a Map >> vs a subclass >> with methods. I can see it both ways. But, as a JDBC user, I've >> learned to >> appreciate a single API with Properties passed in. As a Jini user >> I've learned >> to appreciate the Configuration mechanisms that Jini 2.x has. I >> can write code >> in my configuration file to instantiate and configure the system >> at deployment >> time! > > I don't think this is a problem as long as the implementation specific > stuff is handled by controlling through vehicles outside the API. > The application code layered over the API should be written such that > it can run on any platform and with any generic device of the class > the API claims to support. > > The problem with the ioctl is it's proneness for abuse and invitation > to proliferate the space with non-portable applications. > > If the implementation requires a configuration file to be passed > through > the API then the application can run on platform A, B and C, which all > have the same type of device, fine, and then with a different > configuration > file, could run on D, E and F with other hardware, that seems > reasonable. > > What if there are multiple devices on a system of different types? > There needs to be a way to get the right configuration file to > associate > with the right device, and the application should seamlessly work > with either. > The application code layered over the API should not have to be aware > of the configuration file or the programmatic peculiarities of the > underlying hardware. > > Paul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From savagobr at yahoo.com Wed Jul 26 13:15:13 2006 From: savagobr at yahoo.com (Adenilson Cavalcanti) Date: Wed, 26 Jul 2006 12:15:13 -0700 (PDT) Subject: [Rxtx] Strange error (show stopper) - Fedora Core 5 is ok! Message-ID: <20060726191513.28407.qmail@web53802.mail.yahoo.com> Dear Joachim Buechse I'm pretty new to this list (actually, first post) but got curious about the issue that you reported. If a undertood the code correctly, SerialImp.c -> interruptEventLoop only calls pthread_kill when compiled for MacOSX. Anyway, I changed the code to print field values of structure object 'index' and got this results: 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 CLOSING=0 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 CLOSING=1 Which I think seems to be o.k. (I must also comment that I'm running FC5, kernel 2.6.15, gcc 4.1.1, jdk 1.5.0_06). Bellow you will find where in source code I printed the debug information. I was wondering why in Linux is not necessary to call pthread_kill (of course I did read the comments about "output buffer empty" but don't get it...). Any comments? Best regards Savago //---------------------------------------------------------------------------------------------- Changed code. //---------------------------------------------------------------------------------------------- /** XXX: DEBUG INFO*/ snprintf(message, sizeof(message), "1 interrupted thread for FD=%i PTR=%i CLOSING=%i\n", index->fd, index, index->closing ); report(message); #ifdef TIOCSERGETLSR index->closing=1; #endif /* TIOCSERGETLSR */ #ifdef WIN32 termios_interrupt_event_loop( index->fd, 1 ); #endif /* WIN32 */ #if !defined(TIOCSERGETLSR) && !defined(WIN32) . . . #endif /** XXX: DEBUG INFO*/ snprintf(message, sizeof(message), "2 interrupted thread for FD=%i PTR=%i CLOSING=%i\n", index->fd, index, index->closing ); report(message); report("interruptEventLoop: interrupted\n"); //---------------------------------------------------------------------------------------------- OUTPUT: 15:00:24:******* report_serial_events: sending DATA_AVAILABLE 15:00:24:******* reporting data available 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 CLOSING=0 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 CLOSING=1 15:00:24:******* interruptEventLoop: interrupted 15:00:24:******* eventLoop: got interrupt 15:00:24:******* setDTR( 0 ) 15:00:24:******* setDSR( 0 ) 15:00:24:******* >nativeClose pid 15:00:24:******* nativeClose: pid 15:00:24:******* nativeClose: discarding remaining datai (tcflush) 15:00:24:******* nativeClose: calling close 15:00:24:******* fhs_unlock: Removing LockFile 15:00:24:******* nativeClose: Delete jclazz 15:00:24:******* nativeClose: release filename 15:00:24:******* fhs_unlock: Removing LockFile //---------------------------------------------------------------------------------------------- --------------------------------- How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone call rates. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/ad116f14/attachment-0334.html From savagobr at yahoo.com Wed Jul 26 13:23:05 2006 From: savagobr at yahoo.com (Adenilson Cavalcanti) Date: Wed, 26 Jul 2006 12:23:05 -0700 (PDT) Subject: [Rxtx] Locked ports - to Kharbanda Message-ID: <20060726192305.23957.qmail@web53807.mail.yahoo.com> Dear Kharbanda I'm trying to reproduce the bug that you reported (the deadlock one) but dont get it. What I did was write a java app that continuously open/close a port (/dev/ttyS0) within 1 second for this operation. The program keeps running fine, no lock until now. I'm wondering if you could send me a sample app that could help me to reproduce this bug? Best regards Savago --------------------------------- Yahoo! Music Unlimited - Access over 1 million songs.Try it free. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/c56bc64a/attachment-0334.html From Pawan.Kharbanda at dot.state.co.us Wed Jul 26 13:41:13 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Wed, 26 Jul 2006 13:41:13 -0600 Subject: [Rxtx] Locked ports - to Kharbanda Message-ID: <939A619A756047469C41EE9BA51890FB0429E08B@hqexchange3.dot.state.co.us> Savago, I have attached the Test class that i wrote to replicate the locking/threading problem with RXTX in Redhat Linux. Please follow the following instructions to replicate the problem. I don't know if you will be able to replicate using one Serial port or not, i was able to reproduced it using 3 or 4 ports constantly. Instructions: In the TestOpenClosePort.java please change the Serial Ports names(Add the ports installed on your machine). Then compile your java file and run as "java TestOpenClosePort 100" (100 is the no of times you want to open and close the port in one single thread). I have tested this with the Digi Boxes and able to replicate this over and over in Single JVM. Thanks ~pk ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Adenilson Cavalcanti Sent: Wednesday, July 26, 2006 1:23 PM To: rxtx at qbang.org Subject: [Rxtx] Locked ports - to Kharbanda Dear Kharbanda I'm trying to reproduce the bug that you reported (the deadlock one) but dont get it. What I did was write a java app that continuously open/close a port (/dev/ttyS0) within 1 second for this operation. The program keeps running fine, no lock until now. I'm wondering if you could send me a sample app that could help me to reproduce this bug? Best regards Savago ________________________________ Yahoo! Music Unlimited - Access over 1 million songs. Try it free. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/c581de54/attachment-0334.html -------------- next part -------------- A non-text attachment was scrubbed... Name: TestOpenClosePort.java Type: application/octet-stream Size: 6038 bytes Desc: TestOpenClosePort.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/c581de54/TestOpenClosePort-0334.obj From joachim at buechse.de Wed Jul 26 16:01:31 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 27 Jul 2006 00:01:31 +0200 Subject: [Rxtx] Strange error (show stopper) - Fedora Core 5 is ok! In-Reply-To: <20060726191513.28407.qmail@web53802.mail.yahoo.com> References: <20060726191513.28407.qmail@web53802.mail.yahoo.com> Message-ID: Linux offers a feature (TIOCSERGETLSR) that allows to check if all data has been sent. This feature does not exist on OSX, BSD, Solaris and probably some other systems. For these systems RXTX uses a separate thread that calls tc_drain() - on return of this call all data has been written. The pthread_kill is used to guarantee that the drain thread has been canceled. On Linux there is no forced "wait" between the setting of the "closing" flag and the end of the procedure. The test should to be done on a BSD or Solaris system. But maybe you could add a usleep (50000) just before the second sprintf. This might in fact be helpful to see if the problem exists on Linux as well. Thanks, Joachim On 26.07.2006, at 21:15, Adenilson Cavalcanti wrote: > Dear Joachim Buechse > > I'm pretty new to this list (actually, first post) but got curious > about the issue that you reported. > > If a undertood the code correctly, SerialImp.c -> > interruptEventLoop only calls pthread_kill when compiled for MacOSX. > > Anyway, I changed the code to print field values of structure > object 'index' and got this results: > > 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 > CLOSING=0 > 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 > CLOSING=1 > > Which I think seems to be o.k. (I must also comment that I'm > running FC5, kernel 2.6.15, gcc 4.1.1, jdk 1.5.0_06). > > Bellow you will find where in source code I printed the debug > information. > > I was wondering why in Linux is not necessary to call pthread_kill > (of course I did read the comments about "output buffer empty" but > don't get it...). Any comments? > > Best regards > > Savago > > //-------------------------------------------------------------------- > -------------------------- > Changed code. > //-------------------------------------------------------------------- > -------------------------- > /** XXX: DEBUG INFO*/ > snprintf(message, sizeof(message), "1 interrupted thread for FD= > %i PTR=%i CLOSING=%i\n", > index->fd, index, index->closing ); > report(message); > > #ifdef TIOCSERGETLSR > index->closing=1; > #endif /* TIOCSERGETLSR */ > #ifdef WIN32 > termios_interrupt_event_loop( index->fd, 1 ); > #endif /* WIN32 */ > #if !defined(TIOCSERGETLSR) && !defined(WIN32) > . > . > . > #endif > /** XXX: DEBUG INFO*/ > snprintf(message, sizeof(message), "2 interrupted thread for FD= > %i PTR=%i CLOSING=%i\n", > index->fd, index, index->closing ); > report(message); > > report("interruptEventLoop: interrupted\n"); > > //-------------------------------------------------------------------- > -------------------------- > OUTPUT: > > 15:00:24:******* report_serial_events: sending DATA_AVAILABLE > 15:00:24:******* reporting data available > 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 > CLOSING=0 > 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 > CLOSING=1 > 15:00:24:******* interruptEventLoop: interrupted > 15:00:24:******* eventLoop: got interrupt > 15:00:24:******* setDTR( 0 ) > 15:00:24:******* setDSR( 0 ) > 15:00:24:******* >nativeClose pid > 15:00:24:******* nativeClose: pid > 15:00:24:******* nativeClose: discarding remaining datai (tcflush) > 15:00:24:******* nativeClose: calling close > 15:00:24:******* fhs_unlock: Removing LockFile > 15:00:24:******* nativeClose: Delete jclazz > 15:00:24:******* nativeClose: release filename > 15:00:24:******* fhs_unlock: Removing LockFile > //-------------------------------------------------------------------- > -------------------------- > > How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone > call rates. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jul 26 19:34:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 26 Jul 2006 19:34:11 -0600 (MDT) Subject: [Rxtx] Strange error (show stopper) - Fedora Core 5 is ok! In-Reply-To: References: <20060726191513.28407.qmail@web53802.mail.yahoo.com> Message-ID: It is also possible to undefine TIOCSERGETLSR on Linux. It would be nice if BSD and Solaris made the line status register available but it isn't really a standard. On Thu, 27 Jul 2006, Joachim Buechse wrote: > Linux offers a feature (TIOCSERGETLSR) that allows to check if all > data has been sent. This feature does not exist on OSX, BSD, Solaris > and probably some other systems. For these systems RXTX uses a > separate thread that calls tc_drain() - on return of this call all > data has been written. The pthread_kill is used to guarantee that the > drain thread has been canceled. > > On Linux there is no forced "wait" between the setting of the > "closing" flag and the end of the procedure. The test should to be > done on a BSD or Solaris system. But maybe you could add a usleep > (50000) just before the second sprintf. This might in fact be helpful > to see if the problem exists on Linux as well. > > Thanks, > Joachim > > > On 26.07.2006, at 21:15, Adenilson Cavalcanti wrote: > >> Dear Joachim Buechse >> >> I'm pretty new to this list (actually, first post) but got curious >> about the issue that you reported. >> >> If a undertood the code correctly, SerialImp.c -> >> interruptEventLoop only calls pthread_kill when compiled for MacOSX. >> >> Anyway, I changed the code to print field values of structure >> object 'index' and got this results: >> >> 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 >> CLOSING=0 >> 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 >> CLOSING=1 >> >> Which I think seems to be o.k. (I must also comment that I'm >> running FC5, kernel 2.6.15, gcc 4.1.1, jdk 1.5.0_06). >> >> Bellow you will find where in source code I printed the debug >> information. >> >> I was wondering why in Linux is not necessary to call pthread_kill >> (of course I did read the comments about "output buffer empty" but >> don't get it...). Any comments? >> >> Best regards >> >> Savago >> >> //-------------------------------------------------------------------- >> -------------------------- >> Changed code. >> //-------------------------------------------------------------------- >> -------------------------- >> /** XXX: DEBUG INFO*/ >> snprintf(message, sizeof(message), "1 interrupted thread for FD= >> %i PTR=%i CLOSING=%i\n", >> index->fd, index, index->closing ); >> report(message); >> >> #ifdef TIOCSERGETLSR >> index->closing=1; >> #endif /* TIOCSERGETLSR */ >> #ifdef WIN32 >> termios_interrupt_event_loop( index->fd, 1 ); >> #endif /* WIN32 */ >> #if !defined(TIOCSERGETLSR) && !defined(WIN32) >> . >> . >> . >> #endif >> /** XXX: DEBUG INFO*/ >> snprintf(message, sizeof(message), "2 interrupted thread for FD= >> %i PTR=%i CLOSING=%i\n", >> index->fd, index, index->closing ); >> report(message); >> >> report("interruptEventLoop: interrupted\n"); >> >> //-------------------------------------------------------------------- >> -------------------------- >> OUTPUT: >> >> 15:00:24:******* report_serial_events: sending DATA_AVAILABLE >> 15:00:24:******* reporting data available >> 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 >> CLOSING=0 >> 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 >> CLOSING=1 >> 15:00:24:******* interruptEventLoop: interrupted >> 15:00:24:******* eventLoop: got interrupt >> 15:00:24:******* setDTR( 0 ) >> 15:00:24:******* setDSR( 0 ) >> 15:00:24:******* >nativeClose pid >> 15:00:24:******* nativeClose: pid >> 15:00:24:******* nativeClose: discarding remaining datai (tcflush) >> 15:00:24:******* nativeClose: calling close >> 15:00:24:******* fhs_unlock: Removing LockFile >> 15:00:24:******* nativeClose: Delete jclazz >> 15:00:24:******* nativeClose: release filename >> 15:00:24:******* fhs_unlock: Removing LockFile >> //-------------------------------------------------------------------- >> -------------------------- >> >> How low will we go? Check out Yahoo! Messengers low PC-to-Phone >> call rates. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From guille at sms.nl Thu Jul 27 00:30:47 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 27 Jul 2006 08:30:47 +0200 Subject: [Rxtx] more RS485 (was: Strange error (show stopper) - Fedora Core 5 is ok!) In-Reply-To: References: <20060726191513.28407.qmail@web53802.mail.yahoo.com> Message-ID: <7.0.1.0.0.20060727082321.036f10d0@sms.nl> At 00:01 27/07/2006, Joachim Buechse wrote: >Linux offers a feature (TIOCSERGETLSR) that allows to check if all >data has been sent. Just a side note: This is one of the things that is useful when one needs to control external RS232 to RS485 converters with the RTS or DTR lines. The above lets you look at the transmit shift register to know if/when the last character has been completely shifted out ('transmit shift register empty' is a different thing than 'output FIFO empty' and than 'software output buffer empty'). This is something you currently cannot do from your application using rxtx. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From gergg at cox.net Thu Jul 27 11:08:32 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 27 Jul 2006 12:08:32 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C7B33C.8090005@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> <44C7828B.7040904@cox.net> <44C7B33C.8090005@sun.com> Message-ID: <44C8F310.2040107@cox.net> Paul Klissner wrote: > What if there are multiple devices on a system of different types? > There needs to be a way to get the right configuration file to associate > with the right device, and the application should seamlessly work with either. > The application code layered over the API should not have to be aware > of the configuration file or the programmatic peculiarities of the > underlying hardware. If the configuration mechanism is the standard and must be supported, then every device will have to have such a configuration object. The configuration object would be the per device mechanism with a real API on that object. I'll use the Jini ConfigurationFile syntax here as an example: com2 { driver = "name.of.device.driver.class"; config = new com.deviceco.rs485.Parameters( ... arguments to parameter construction ... ); } then the API would ask for the driver and configuration for device com2, and have all the things needed to make the correct device used with the correct configuration. Gregg Wonderly From fredm at alum.mit.edu Fri Jul 28 04:32:56 2006 From: fredm at alum.mit.edu (Fred G. Martin) Date: Fri, 28 Jul 2006 06:32:56 -0400 Subject: [Rxtx] precompiled for Intel Mac? Message-ID: Dear RXTX'ers, Would there be a precompiled binary of the older 2.0-7pre1 version (javax.comm namespace) rxtx for the Intel Mac platform? Would I just need the libSerial.jnilib file? Thank you, Fred From savagobr at yahoo.com Fri Jul 28 09:34:35 2006 From: savagobr at yahoo.com (Adenilson Cavalcanti) Date: Fri, 28 Jul 2006 08:34:35 -0700 (PDT) Subject: [Rxtx] Strange error (show stopper) - FC5 still ok! Message-ID: <20060728153435.41645.qmail@web53815.mail.yahoo.com> Friends I repeated the test, both undefining TIOCSERGETLSR in SerialImp.h as also adding a sleep in function 'interruptEventLoop' and it still is working fine. Later I can test it in pcbsd (based on FreeBSD 6) on my notebook. So far, I think that we can say that in Linux this error doesn't happen. Best regards Savago //------------------------------------------------------------------------ Result with #undef TIOCSERGETLSR 11:08:11:******* 1 interrupted thread for FD=51 PTR=-1321354040 CLOSING=0 11:08:11:******* 2 interrupted thread for FD=51 PTR=-1321354040 CLOSING=1 Result with usleep(50000) 11:14:57:******* 1 interrupted thread for FD=51 PTR=-1322914604 CLOSING=0 11:14:57:******* 2 interrupted thread for FD=51 PTR=-1322914604 CLOSING=1 --------------------------------- How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone call rates. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060728/acd6aec1/attachment-0332.html From joachim at buechse.de Fri Jul 28 12:48:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 28 Jul 2006 20:48:33 +0200 Subject: [Rxtx] precompiled for Intel Mac? In-Reply-To: References: Message-ID: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> There will be. However not before we have figured out some remaining issues. Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 28.07.2006, at 12:32, Fred G. Martin wrote: > Dear RXTX'ers, > > Would there be a precompiled binary of the older 2.0-7pre1 version > (javax.comm namespace) rxtx for the Intel Mac platform? > > Would I just need the libSerial.jnilib file? > > Thank you, > Fred > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From fredm at alum.mit.edu Fri Jul 28 15:30:38 2006 From: fredm at alum.mit.edu (Fred G. Martin) Date: Fri, 28 Jul 2006 17:30:38 -0400 Subject: [Rxtx] precompiled for Intel Mac? In-Reply-To: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> References: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> Message-ID: <4616ED35-24BC-4FD3-90FB-81CAA851FB08@alum.mit.edu> May I ask another way--- can it [easily] be built from the 2.0-7pre1 sources? Fred On Jul 28, 2006, at 2:48 PM, Joachim Buechse wrote: > There will be. However not before we have figured out some remaining > issues. > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 28.07.2006, at 12:32, Fred G. Martin wrote: > >> Dear RXTX'ers, >> >> Would there be a precompiled binary of the older 2.0-7pre1 version >> (javax.comm namespace) rxtx for the Intel Mac platform? >> >> Would I just need the libSerial.jnilib file? >> >> Thank you, >> Fred >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Fri Jul 28 21:04:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 28 Jul 2006 21:04:45 -0600 (MDT) Subject: [Rxtx] precompiled for Intel Mac? In-Reply-To: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> References: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> Message-ID: On Fri, 28 Jul 2006, Joachim Buechse wrote: > There will be. However not before we have figured out some remaining > issues. > Joachim > Joachim and I are trying to get together to work out the remaining issues. I'll be looking at some w32 issues this weekend - a lovely job everyone should do exactly once. There are a few details that need attention. The summer vacation schedual is keeping things at a slow pace. This will be the first free weekend I've had in a while. I'm also gathering a list of things to do on Linux and Solaris which so far isn't too big but there are some that can be problems depending upon your use. Bugzilla is also your friend for bugs that are not getting attention right away. All bugs are interesting but sometimes forgotten on the mail list. I do go through all the bugs in bugzilla one by one now and then. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jul 29 05:18:25 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 29 Jul 2006 07:18:25 -0400 Subject: [Rxtx] The new JSR and RS485 - Moderator Ruling In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: Hi All, It has been several days since I asked the below question. There has not been much in the way of response. Therefore, I am using my new-age radioactive mutant moderator super-powers to make a (non-final) decision that: 1. We can live with unofficial RS485 support for a while, 2. The JSR specification that we embark upon will focus on serial and parallel ports and 3. We may revisit the RS485 question, in the future. Thanks! - Doug Date: Wed, 26 Jul 2006 06:28:33 -0400 From: "Dr. Douglas Lyon" Subject: Should we defer JSR support of RS485? To: RXTX Developers and Users , lyon at docjava.com Original-recipient: rfc822;dlyon at optonline.net Hi All, Would it make sense to focus the JSR on rock solid serial and parallel port support? Can the RS485 people live with unofficial support, at least until we get the JSR accepted and the implementation rock solid? Thanks! - Doug From naranjo.manuel at gmail.com Sat Jul 29 07:59:10 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Sat, 29 Jul 2006 10:59:10 -0300 Subject: [Rxtx] The new JSR and RS485 - Moderator Ruling In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: <44CB69AE.8030104@gmail.com> +1 Totally agree, Manuel > Hi All, > > It has been several days since I asked the below question. > There has not been much in the way of response. > Therefore, I am using my new-age radioactive > mutant moderator super-powers to > make a (non-final) decision that: > 1. We can live with unofficial RS485 support for a while, > 2. The JSR specification that we embark upon will focus on > serial and parallel ports and > 3. We may revisit the RS485 question, in the future. > > Thanks! > - Doug > > > Date: Wed, 26 Jul 2006 06:28:33 -0400 > From: "Dr. Douglas Lyon" > Subject: Should we defer JSR support of RS485? > To: RXTX Developers and Users , lyon at docjava.com > Original-recipient: rfc822;dlyon at optonline.net > > Hi All, > > Would it make sense to focus the JSR on rock solid > serial and parallel port support? > > Can the RS485 people live with unofficial support, at least until > we get the JSR accepted and the implementation rock solid? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Sat Jul 29 14:21:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 29 Jul 2006 14:21:32 -0600 (MDT) Subject: [Rxtx] The new JSR and RS485 - Moderator Ruling In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: Hi Doug At this time, I agree. RS485 is interesting and I would be intested in participating in future discussions/plans with RS485. On Sat, 29 Jul 2006, Dr. Douglas Lyon wrote: > Hi All, > > It has been several days since I asked the below question. > There has not been much in the way of response. > Therefore, I am using my new-age radioactive > mutant moderator super-powers to > make a (non-final) decision that: > 1. We can live with unofficial RS485 support for a while, > 2. The JSR specification that we embark upon will focus on > serial and parallel ports and > 3. We may revisit the RS485 question, in the future. > > Thanks! > - Doug > > > Date: Wed, 26 Jul 2006 06:28:33 -0400 > From: "Dr. Douglas Lyon" > Subject: Should we defer JSR support of RS485? > To: RXTX Developers and Users , lyon at docjava.com > Original-recipient: rfc822;dlyon at optonline.net > > Hi All, > > Would it make sense to focus the JSR on rock solid > serial and parallel port support? > > Can the RS485 people live with unofficial support, at least until > we get the JSR accepted and the implementation rock solid? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Sun Jul 30 04:28:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 30 Jul 2006 06:28:49 -0400 Subject: [Rxtx] interfaces vs. abstract classes Message-ID: Hi All, I was thinking that the new JSR might be more interface oriented and less abstract class oriented. For example, instead of subclassing CommPort, perhaps we should implement a CommPortInterface. How would this look? I don't know. But, perhaps, it would look something like this: package gnu.io; import java.io.InputStream; import java.io.IOException; import java.io.OutputStream; /** * User: lyon * Date: Jul 30, 2006 * Time: 5:19:55 AM * Copyright DocJava, Inc. 2005. */ public interface CommPortInterface { void enableReceiveFraming(int f) throws UnsupportedCommOperationException; void disableReceiveFraming(); boolean isReceiveFramingEnabled(); int getReceiveFramingByte(); void disableReceiveTimeout(); void enableReceiveTimeout(int time) throws UnsupportedCommOperationException; boolean isReceiveTimeoutEnabled(); int getReceiveTimeout(); void enableReceiveThreshold(int thresh) throws UnsupportedCommOperationException; void disableReceiveThreshold(); int getReceiveThreshold(); boolean isReceiveThresholdEnabled(); void setInputBufferSize(int size); int getInputBufferSize(); void setOutputBufferSize(int size); int getOutputBufferSize(); void close(); InputStream getInputStream() throws IOException; OutputStream getOutputStream() throws IOException; String getName(); } Then, we can use: /** * CommPort */ public abstract class CommPort implements CommPortInterface And replace uses of CommPort with uses of CommPortInterface.... package gnu.io; import java.io.FileDescriptor; /** * User: lyon * Date: Jul 30, 2006 * Time: 5:40:20 AM * Copyright DocJava, Inc. 2005. */ public interface CommPortIdentifierInterface { int PORT_SERIAL = 1; int PORT_PARALLEL = 2; int PORT_I2C = 3; int PORT_RS485 = 4; int PORT_RAW = 5; void addPortOwnershipListener(CommPortOwnershipListener c); String getCurrentOwner(); String getName(); int getPortType(); boolean isCurrentlyOwned(); CommPortInterface open(FileDescriptor f) throws UnsupportedCommOperationExce ption; CommPortInterface open(String TheOwner, int i) throws PortInUseException; void removePortOwnershipListener(CommPortOwnershipListener c); } If we continue in this vain, the SerialPort should have an interface that it implements, called (due to my lack of imagination) the SerialPortInterface package gnu.io; import java.util.TooManyListenersException; /** * User: lyon * Date: Jul 30, 2006 * Time: 5:56:35 AM * Copyright DocJava, Inc. 2005. */ public interface SerialPortInterface extends CommPortInterface { int DATABITS_5 = 5; int DATABITS_6 = 6; int DATABITS_7 = 7; int DATABITS_8 = 8; int PARITY_NONE = 0; int PARITY_ODD = 1; int PARITY_EVEN = 2; int PARITY_MARK = 3; int PARITY_SPACE = 4; int STOPBITS_1 = 1; int STOPBITS_2 = 2; int STOPBITS_1_5 = 3; int FLOWCONTROL_NONE = 0; int FLOWCONTROL_RTSCTS_IN = 1; int FLOWCONTROL_RTSCTS_OUT = 2; int FLOWCONTROL_XONXOFF_IN = 4; int FLOWCONTROL_XONXOFF_OUT = 8; void setSerialPortParams(int b, int d, int s, int p) throws UnsupportedCommOperationException; int getBaudRate(); int getDataBits(); int getStopBits(); int getParity(); void setFlowControlMode(int flowcontrol) throws UnsupportedCommOperationException; int getFlowControlMode(); boolean isDTR(); void setDTR(boolean state); void setRTS(boolean state); boolean isCTS(); boolean isDSR(); boolean isCD(); boolean isRI(); boolean isRTS(); void sendBreak(int duration); void addEventListener(SerialPortEventListener lsnr) throws TooManyListenersException; void removeEventListener(); void notifyOnDataAvailable(boolean enable); void notifyOnOutputEmpty(boolean enable); void notifyOnCTS(boolean enable); void notifyOnDSR(boolean enable); void notifyOnRingIndicator(boolean enable); void notifyOnCarrierDetect(boolean enable); void notifyOnOverrunError(boolean enable); void notifyOnParityError(boolean enable); void notifyOnFramingError(boolean enable); void notifyOnBreakInterrupt(boolean enable); byte getParityErrorChar() throws UnsupportedCommOperationException; boolean setParityErrorChar(byte b) throws UnsupportedCommOperationException; byte getEndOfInputChar() throws UnsupportedCommOperationException; boolean setEndOfInputChar(byte b) throws UnsupportedCommOperationException; boolean setUARTType(String type, boolean test) throws UnsupportedCommOperationException; String getUARTType() throws UnsupportedCommOperationException; boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException; int getBaudBase() throws UnsupportedCommOperationException; boolean setDivisor(int Divisor) throws UnsupportedCommOperationException; int getDivisor() throws UnsupportedCommOperationException; boolean setLowLatency() throws UnsupportedCommOperationException; boolean getLowLatency() throws UnsupportedCommOperationException; boolean setCallOutHangup(boolean NoHup) throws UnsupportedCommOperationException; boolean getCallOutHangup() throws UnsupportedCommOperationException; } And, of course, you need a parallel port: package gnu.io; import java.util.TooManyListenersException; /** * User: lyon * Date: Jul 30, 2006 * Time: 6:14:02 AM * Copyright DocJava, Inc. 2005. */ public interface ParallelPortInterface extends CommPortInterface { int LPT_MODE_ANY = 0; int LPT_MODE_SPP = 1; int LPT_MODE_PS2 = 2; int LPT_MODE_EPP = 3; int LPT_MODE_ECP = 4; int LPT_MODE_NIBBLE = 5; int getMode(); int setMode(int mode) throws UnsupportedCommOperationException; void restart(); void suspend(); boolean isPaperOut(); boolean isPrinterBusy(); boolean isPrinterError(); boolean isPrinterSelected(); boolean isPrinterTimedOut(); int getOutputBufferFree(); void addEventListener(ParallelPortEventListener lsnr) throws TooManyListenersException; void removeEventListener(); void notifyOnError(boolean enable); void notifyOnBuffer(boolean enable); } Now, I have refactored my code to take advantage of these interfaces. And have done very limited testing. The problem is that we have some static methods in classes like CommPortIdentifier that don't refactor into interfaces cleanly. I don't know what to do about that... What do people think about the idea of using interfaces rather than abstract classes for making the system a little more component oriented? Thanks! - Doug From tjarvi at qbang.org Sun Jul 30 10:13:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 30 Jul 2006 10:13:06 -0600 (MDT) Subject: [Rxtx] interfaces vs. abstract classes In-Reply-To: References: Message-ID: Hi Doug, I don't see a big advantage one way or another for the interfaces. One thing that should be added but not supported initially on all platforms is event notification of devices becomming physically available and vanishing. This is not the same as digging into USB. If the OS can provide a clean event driven method and provides a proper interface, it is of great use to people dealing with USB and Serial and Parallel Dongles. On Sun, 30 Jul 2006, Dr. Douglas Lyon wrote: > Hi All, > I was thinking that the new JSR might be more > interface oriented and less abstract class oriented. > > For example, instead of subclassing CommPort, perhaps > we should implement a CommPortInterface. > > How would this look? > > I don't know. But, perhaps, it would look something like this: > package gnu.io; > > import java.io.InputStream; > import java.io.IOException; > import java.io.OutputStream; > > /** > * User: lyon > * Date: Jul 30, 2006 > * Time: 5:19:55 AM > * Copyright DocJava, Inc. 2005. > */ > public interface CommPortInterface { > void enableReceiveFraming(int f) > throws UnsupportedCommOperationException; > > void disableReceiveFraming(); > > boolean isReceiveFramingEnabled(); > > int getReceiveFramingByte(); > > void disableReceiveTimeout(); > > void enableReceiveTimeout(int time) > throws UnsupportedCommOperationException; > > boolean isReceiveTimeoutEnabled(); > > int getReceiveTimeout(); > > void enableReceiveThreshold(int thresh) > throws UnsupportedCommOperationException; > > void disableReceiveThreshold(); > > int getReceiveThreshold(); > > boolean isReceiveThresholdEnabled(); > > void setInputBufferSize(int size); > > int getInputBufferSize(); > > void setOutputBufferSize(int size); > > int getOutputBufferSize(); > > void close(); > > InputStream getInputStream() throws IOException; > > OutputStream getOutputStream() throws IOException; > > String getName(); > } > > Then, we can use: > /** > * CommPort > */ > public abstract class CommPort implements CommPortInterface > > And replace uses of CommPort with uses of CommPortInterface.... > package gnu.io; > > import java.io.FileDescriptor; > > /** > * User: lyon > * Date: Jul 30, 2006 > * Time: 5:40:20 AM > * Copyright DocJava, Inc. 2005. > */ > public interface CommPortIdentifierInterface { > int PORT_SERIAL = 1; > int PORT_PARALLEL = 2; > int PORT_I2C = 3; > int PORT_RS485 = 4; > int PORT_RAW = 5; > > void addPortOwnershipListener(CommPortOwnershipListener c); > > String getCurrentOwner(); > > String getName(); > > int getPortType(); > > boolean isCurrentlyOwned(); > > CommPortInterface open(FileDescriptor f) throws > UnsupportedCommOperationExce > ption; > > CommPortInterface open(String TheOwner, int i) > throws PortInUseException; > > void removePortOwnershipListener(CommPortOwnershipListener c); > } > > If we continue in this vain, the SerialPort should have an interface that > it implements, called (due to my lack of imagination) the SerialPortInterface > > package gnu.io; > > import java.util.TooManyListenersException; > > /** > * User: lyon > * Date: Jul 30, 2006 > * Time: 5:56:35 AM > * Copyright DocJava, Inc. 2005. > */ > public interface SerialPortInterface extends CommPortInterface { > int DATABITS_5 = 5; > int DATABITS_6 = 6; > int DATABITS_7 = 7; > int DATABITS_8 = 8; > int PARITY_NONE = 0; > int PARITY_ODD = 1; > int PARITY_EVEN = 2; > int PARITY_MARK = 3; > int PARITY_SPACE = 4; > int STOPBITS_1 = 1; > int STOPBITS_2 = 2; > int STOPBITS_1_5 = 3; > int FLOWCONTROL_NONE = 0; > int FLOWCONTROL_RTSCTS_IN = 1; > int FLOWCONTROL_RTSCTS_OUT = 2; > int FLOWCONTROL_XONXOFF_IN = 4; > int FLOWCONTROL_XONXOFF_OUT = 8; > > void setSerialPortParams(int b, int d, int s, int p) > throws UnsupportedCommOperationException; > > int getBaudRate(); > > int getDataBits(); > > int getStopBits(); > > int getParity(); > > void setFlowControlMode(int flowcontrol) > throws UnsupportedCommOperationException; > > int getFlowControlMode(); > > boolean isDTR(); > > void setDTR(boolean state); > > void setRTS(boolean state); > > boolean isCTS(); > > boolean isDSR(); > > boolean isCD(); > > boolean isRI(); > > boolean isRTS(); > > void sendBreak(int duration); > > void addEventListener(SerialPortEventListener lsnr) > throws TooManyListenersException; > > void removeEventListener(); > > void notifyOnDataAvailable(boolean enable); > > void notifyOnOutputEmpty(boolean enable); > > void notifyOnCTS(boolean enable); > > void notifyOnDSR(boolean enable); > > void notifyOnRingIndicator(boolean enable); > > void notifyOnCarrierDetect(boolean enable); > > void notifyOnOverrunError(boolean enable); > > void notifyOnParityError(boolean enable); > > void notifyOnFramingError(boolean enable); > > void notifyOnBreakInterrupt(boolean enable); > > byte getParityErrorChar() > throws UnsupportedCommOperationException; > > boolean setParityErrorChar(byte b) > throws UnsupportedCommOperationException; > > byte getEndOfInputChar() > throws UnsupportedCommOperationException; > > boolean setEndOfInputChar(byte b) > throws UnsupportedCommOperationException; > > boolean setUARTType(String type, boolean test) > throws UnsupportedCommOperationException; > > String getUARTType() > throws UnsupportedCommOperationException; > > boolean setBaudBase(int BaudBase) > throws UnsupportedCommOperationException; > > int getBaudBase() > throws UnsupportedCommOperationException; > > boolean setDivisor(int Divisor) > throws UnsupportedCommOperationException; > > int getDivisor() > throws UnsupportedCommOperationException; > > boolean setLowLatency() > throws UnsupportedCommOperationException; > > boolean getLowLatency() > throws UnsupportedCommOperationException; > > boolean setCallOutHangup(boolean NoHup) > throws UnsupportedCommOperationException; > > boolean getCallOutHangup() > throws UnsupportedCommOperationException; > } > > And, of course, you need a parallel port: > package gnu.io; > > import java.util.TooManyListenersException; > > /** > * User: lyon > * Date: Jul 30, 2006 > * Time: 6:14:02 AM > * Copyright DocJava, Inc. 2005. > */ > public interface ParallelPortInterface extends CommPortInterface { > int LPT_MODE_ANY = 0; > int LPT_MODE_SPP = 1; > int LPT_MODE_PS2 = 2; > int LPT_MODE_EPP = 3; > int LPT_MODE_ECP = 4; > int LPT_MODE_NIBBLE = 5; > > int getMode(); > > int setMode(int mode) > throws UnsupportedCommOperationException; > > void restart(); > > void suspend(); > > boolean isPaperOut(); > > boolean isPrinterBusy(); > > boolean isPrinterError(); > > boolean isPrinterSelected(); > > boolean isPrinterTimedOut(); > > int getOutputBufferFree(); > > void addEventListener(ParallelPortEventListener lsnr) > throws TooManyListenersException; > > void removeEventListener(); > > void notifyOnError(boolean enable); > > void notifyOnBuffer(boolean enable); > } > > Now, I have refactored my code to take advantage of these interfaces. > And have done very limited testing. The problem is that we have some > static methods in > classes like CommPortIdentifier that don't refactor into interfaces cleanly. > > I don't know what to do about that... > > What do people think about the idea of using interfaces rather than > abstract classes for making the system a little more component oriented? > > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From berkland at spamcop.net Sun Jul 30 15:15:59 2006 From: berkland at spamcop.net (Doug Berkland) Date: Sun, 30 Jul 2006 17:15:59 -0400 Subject: [Rxtx] interfaces vs. abstract classes In-Reply-To: <269e40090607301408q41759906k6e45f0dd33618655@mail.gmail.com> References: <269e40090607301408q41759906k6e45f0dd33618655@mail.gmail.com> Message-ID: <269e40090607301415p3238e51eyce4b124f385c1918@mail.gmail.com> I think the interfaces are a good idea. They will allow more flexibility if someone needs to create a modified implementation. I just hope that all of this will end up in the javax.comm package instead of gnu.io. From gergg at cox.net Sun Jul 30 16:30:37 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 30 Jul 2006 17:30:37 -0500 Subject: [Rxtx] interfaces vs. abstract classes In-Reply-To: <269e40090607301415p3238e51eyce4b124f385c1918@mail.gmail.com> References: <269e40090607301408q41759906k6e45f0dd33618655@mail.gmail.com> <269e40090607301415p3238e51eyce4b124f385c1918@mail.gmail.com> Message-ID: <44CD330D.20608@cox.net> Doug Berkland wrote: > I think the interfaces are a good idea. They will allow more > flexibility if someone needs to create a modified implementation. I > just hope that all of this will end up in the javax.comm package > instead of gnu.io. You can provide an abstract class that implements the interface, but defers on the implementation details to allow porting parties the ability to reuse common code with less variations on the behavior that users experience. Please don't include anything in the interface that can't be described in 100% accuracy and perform identically on all possible ports, or throw a well described compatibility exception. Gregg Wonderly From lyon at docjava.com Sun Jul 30 17:27:13 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 30 Jul 2006 19:27:13 -0400 Subject: [Rxtx] interfaces vs abstract classes Message-ID: Hi All, If you ever want to use serial ports with RMI, a nice set of interfaces will be required. On the other hand, perhaps nobody wants that. On the other, other hand, there are some areas where we could really use some API clean-up. This could be a chance to shape the JSR with really clean interfaces with well defined semantics and some good Javadoc. For example: I2CPort, RS485Port and SerialPort all begin with duplicate code. We can put all the constants in a nice interface, as appears below. I have added a little Javadoc. Would someone like to finish it up? So far, I have not added any new features, other than documentation and refactoring. >More importantly is the philosophical start point for a >specification in a JSR; >that is speaking to the future: >Interfaces describe capabilities; >Classes implement capabilities; Methods execute capabilities. >In the long run, a plug-in based system can be used to substitute >implementation >but retain the use of the interface. > >So, use inheritance for internal code reuse and interfaces for >contract definition. > >As the famous GoF book says: > >Prefer interfaces over inheritance. > >Use interfaces as a design-time resource when you are planning your system. >It is almost always useful to define a contract of functionality for >a given set of features. Clients of such a contract should never >have to bother with details of actual implementations. - DL public interface SerialPortInterface extends CommPortInterface { int DATABITS_5 = 5; int DATABITS_6 = 6; int DATABITS_7 = 7; int DATABITS_8 = 8; int PARITY_NONE = 0; int PARITY_ODD = 1; int PARITY_EVEN = 2; int PARITY_MARK = 3; int PARITY_SPACE = 4; int STOPBITS_1 = 1; int STOPBITS_2 = 2; int STOPBITS_1_5 = 3; int FLOWCONTROL_NONE = 0; int FLOWCONTROL_RTSCTS_IN = 1; int FLOWCONTROL_RTSCTS_OUT = 2; int FLOWCONTROL_XONXOFF_IN = 4; int FLOWCONTROL_XONXOFF_OUT = 8; /** * @return true if the DTR bit is set. * * @see #setDTR */ boolean isCTS(); /** * @return true if the DTR bit is set. * */ boolean isDSR(); /** * @return true if the CD bit is set. * */ boolean isCD(); /** * @return true if the RI bit is set. * */ boolean isRI(); /** * @return true if the RTS bit is set. * * @see #setRTS */ boolean isRTS(); /** would someone like to write some nice javadoc for the following? */ void addEventListener(SerialPortEventListener lsnr) throws TooManyListenersException; void removeEventListener(); void notifyOnDataAvailable(boolean enable); void notifyOnOutputEmpty(boolean enable); void notifyOnCTS(boolean enable); void notifyOnDSR(boolean enable); void notifyOnRingIndicator(boolean enable); void notifyOnCarrierDetect(boolean enable); void notifyOnOverrunError(boolean enable); void notifyOnParityError(boolean enable); void notifyOnFramingError(boolean enable); void notifyOnBreakInterrupt(boolean enable); byte getParityErrorChar() throws UnsupportedCommOperationException; boolean setParityErrorChar(byte b) throws UnsupportedCommOperationException; byte getEndOfInputChar() throws UnsupportedCommOperationException; boolean setEndOfInputChar(byte b) throws UnsupportedCommOperationException; boolean setUARTType(String type, boolean test) throws UnsupportedCommOperationException; String getUARTType() throws UnsupportedCommOperationException; boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException; int getBaudBase() throws UnsupportedCommOperationException; boolean setDivisor(int Divisor) throws UnsupportedCommOperationException; int getDivisor() throws UnsupportedCommOperationException; boolean setLowLatency() throws UnsupportedCommOperationException; boolean getLowLatency() throws UnsupportedCommOperationException; boolean setCallOutHangup(boolean NoHup) throws UnsupportedCommOperationException; boolean getCallOutHangup() throws UnsupportedCommOperationException; /** * @return the current baud rate */ int getBaudRate(); /** * @return the current number of data bits: DATABITS_5, DATABITS_6, * DATABITS_7, or DATABITS_8. */ int getDataBits(); /** * @return the current number of stop bits: STOPBITS_1, STOPBITS_2, or * STOPBITS_1_5. */ int getStopBits(); /** * @return the current parity scheme: PARITY_NONE, PARITY_ODD, * PARITY_EVEN, PARITY_MARK or PARITY_SPACE. */ int getParity(); /** * Sends a break of the specified duration. * * @param millis the duration in milliseconds */ void sendBreak(int millis); /** * Sets the flow control mode. * * @param flowcontrol a bitmask combination of FLOWCONTROL_NONE, * FLOWCONTROL_RTSCTS_IN, FLOWCONTROL_RTSCTS_OUT, * FLOWCONTROL_XONXOFF_IN, and/or FLOWCONTROL_XONXOFF_OUT. */ void setFlowControlMode(int flowcontrol); /** * @return the current flow control mode as a bitmask of * FLOWCONTROL_NONE, FLOWCONTROL_RTSCTS_IN, FLOWCONTROL_RTSCTS_OUT, * FLOWCONTROL_XONXOFF_IN, and/or FLOWCONTROL_XONXOFF_OUT. */ int getFlowControlMode(); /** * Set the Receive Fifo trigger level. * If the UART has a FIFO and if it can have programmable trigger * levels, then this method will cause the UART to raise an interrupt * after trigger bytes have been received. * * @param trigger the trigger level * @deprecated */ void setRcvFifoTrigger(int trigger); /** * Sets the serial port parameters. * * @param baudRate the baud rate * @param dataBits the number of data bits: DATABITS_5, * DATABITS_6, DATABITS_7, or DATABITS_8 * @param stopBits the number of stop bits: STOPBITS_1, * STOPBITS_2, or STOPBITS_1_5 * @param parity the parity schema: PARITY_NONE, PARITY_ODD, * PARITY_EVEN, PARITY_MARK or PARITY_SPACE * @throws UnsupportedCommOperationException */ void setSerialPortParams(int baudRate, int dataBits, int stopBits, int parity) throws UnsupportedCommOperationException; /** * Sets or clears the DTR bit in the UART. * * @param dtr the Data Terminal Ready bit value * @see #isDTR */ void setDTR(boolean dtr); /** * @return true if the DTR bit is set. * * @see #setDTR */ boolean isDTR(); /** * Sets or clears the RTS bit in the UART. * * @param rts the Request To Send bit value */ void setRTS(boolean rts); } Here is the CommPortInterface: public interface CommPortInterface { /** * @return the name of this port. * */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is disabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } From tjarvi at qbang.org Sun Jul 30 17:43:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 30 Jul 2006 17:43:13 -0600 (MDT) Subject: [Rxtx] RMI In-Reply-To: References: Message-ID: On Sun, 30 Jul 2006, Dr. Douglas Lyon wrote: > Hi All, > > If you ever want to use serial ports with RMI, > a nice set of interfaces will be required. > So this would eventually lead to j2ee beans and such. The security model would have to be examined for this. Often there are tens of thousands of dollars in instrumentation or even cash drawers/POS sitting on the other end of the cable. A serial port should be no less secure than a hard drive. I think security is going to be OK but then we are opening up for a bunch of questions about how to get it working. That puts us in a position of answering how to bypass security with RMI to access hard drives [or serial ports]. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Jul 30 21:48:01 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 30 Jul 2006 22:48:01 -0500 Subject: [Rxtx] RMI In-Reply-To: References: Message-ID: <44CD7D71.2080306@cox.net> Trent Jarvi wrote: > On Sun, 30 Jul 2006, Dr. Douglas Lyon wrote: >>If you ever want to use serial ports with RMI, >>a nice set of interfaces will be required. > > So this would eventually lead to j2ee beans and such. > > The security model would have to be examined for this. Often there are > tens of thousands of dollars in instrumentation or even cash drawers/POS > sitting on the other end of the cable. > > A serial port should be no less secure than a hard drive. I think > security is going to be OK but then we are opening up for a bunch of > questions about how to get it working. > > That puts us in a position of answering how to bypass security with RMI to > access hard drives [or serial ports]. This really depends on whether you want those streams to be visible remotely, directly or not. I think that it is poor engineering practice for any Remote access to directly expose the raw hardware/stream/data. You need to have choices on how to transport and encapsulate data streams. This is the power of the RMI programming model. Mobile code can put computational activities on the client instead of the server. The next generation of RMI, with all of the security features you need was developed by the original RMI team and some others, and is the Jini Extensible Remote Invocation (JERI) stack that is available in Jini 2.0 and later versions (http://www.jini.org and http://starterkit.dev.java.net). One of the primary things that JERI provides is an authentication and authorization mechanism that is activated at deployment time, instead of being coded into the libraries. Gregg Wonderly From guille at sms.nl Mon Jul 31 03:17:29 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Mon, 31 Jul 2006 11:17:29 +0200 Subject: [Rxtx] interfaces vs. abstract classes In-Reply-To: References: Message-ID: <7.0.1.0.0.20060731111659.0363b620@sms.nl> At 12:28 30/07/2006, Dr. Douglas Lyon wrote: >Hi All, >I was thinking that the new JSR might be more >interface oriented and less abstract class oriented. > >For example, instead of subclassing CommPort, perhaps >we should implement a CommPortInterface. > >How would this look? Will it break backwards compatibility? Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From lyon at docjava.com Mon Jul 31 04:57:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 31 Jul 2006 06:57:39 -0400 Subject: [Rxtx] Rxtx RMI/SSL In-Reply-To: <44CD7D71.2080306@cox.net> References: <44CD7D71.2080306@cox.net> Message-ID: Hi All, Networked based serial ports are a nice option for java clients that do not need (or want) native method drivers installed. Applications include web-controlled robotics, network-based modems, auto-dialing addressbooks (remote dialers), remote sensing, etc. If you are behind a firewall, you may not feel the need for RMI/SSL security. After all, hacking into a serial port behind a firewall does seem a bit over-the-top. On the other hand, for those who feel they want to go over the Internet; I have been playing around with RMI over SSL. Here is a paper on the topic: http://show.docjava.com:8086/pub/document/jot/rjs.pdf Remote Job Submission Security by Pawel Krepstzul and Douglas A. Lyon, in Journal of Object Technology, vol. 5, no. 1, Janurary-February 2006, pp. 13-29. From the programmer point-of-view the SSL part is not quite transparent, but, given proper diligence, can be made somewhat secure. Naturally, you can put the exchange in a high-level of abstraction. I guess it really depends on the application. The question of how level-of-abstraction impacts security, remains open. You may observe a trend toward RMI based API's by looking at JAI (Java Advanced Imaging). Cheers! - Doug >Trent Jarvi wrote: >> On Sun, 30 Jul 2006, Dr. Douglas Lyon wrote: >>>If you ever want to use serial ports with RMI, >>>a nice set of interfaces will be required. >> >> So this would eventually lead to j2ee beans and such. >> >> The security model would have to be examined for this. Often there are >> tens of thousands of dollars in instrumentation or even cash drawers/POS >> sitting on the other end of the cable. >> >> A serial port should be no less secure than a hard drive. I think >> security is going to be OK but then we are opening up for a bunch of >> questions about how to get it working. >> >> That puts us in a position of answering how to bypass security with RMI to >> access hard drives [or serial ports]. > >This really depends on whether you want those streams to be visible remotely, >directly or not. I think that it is poor engineering practice for any Remote >access to directly expose the raw hardware/stream/data. You need to have >choices on how to transport and encapsulate data streams. This is >the power of >the RMI programming model. Mobile code can put computational >activities on the >client instead of the server. > >The next generation of RMI, with all of the security features you need was >developed by the original RMI team and some others, and is the Jini Extensible >Remote Invocation (JERI) stack that is available in Jini 2.0 and >later versions >(http://www.jini.org and http://starterkit.dev.java.net). > >One of the primary things that JERI provides is an authentication and >authorization mechanism that is activated at deployment time, instead of being >coded into the libraries. > >Gregg Wonderly >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Mon Jul 31 07:16:51 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 31 Jul 2006 15:16:51 +0200 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> Message-ID: <1154351811.44ce02c3a5539@webmail.eatserver.nl> Hi Doug, I understand. Note that we are not only concerned about source compatibility, but also about binary compatibility (which would be preserved as well with this approach if I understood correctly) Best regards, Guillermo Quoting "Dr. Douglas Lyon" : > Hi All, > At present I have a prototype version of the libraries that I am > testing that contains the Interfaces, with growing Javadoc. > I have been refactoring my code to take advantage of these > interfaces, but, in the interest of backward compatibility, > have left the abstract classes, for those who want to continue > to use and test them. So there is 100% backward compatibility. > > My goal is to identify the features of the class specification and > provide good documentation for them. I think this is seen most clearly in > the below code. This has ZERO impact on existing code that > seeks to make use of the CommPort class. > > I am adding interfaces and documentation to arrive at a specification. > Abstract methods and constants move from the abstract class into the > interface, but then the abstract class implements the interface. > > To the API user, it should have no effect. > > Cheers! > - Doug > > > public interface CommPortIdentifierInterface { > > int PORT_I2C = 3; > int PORT_RS485 = 4; > int PORT_RAW = 5; > /** > * RS-232 serial port. > */ > int PORT_SERIAL = 1; > /** > * IEEE 1284 parallel port. > */ > int PORT_PARALLEL = 2; > > > > /** > * @return the port name, typically an OS-dependent hardware label. > * > */ > String getName(); > > /** > * @return the port type, PORT_SERIAL or PORT_PARALLEL. > */ > int getPortType() > ; > > /** > * @return the current owner of this port. > */ > String getCurrentOwner() > ; > > /** > * @return true if this port is currently owned. > */ > boolean isCurrentlyOwned() ; > > /** > * @return communications port. > * If the port is in use by another application, it will be notified > * with a PORT_OWNERSHIP_REQUESTED event. If the current owner closes > * the port, then this method will succeed. Otherwise a > * PortInUseException will be thrown. > * @param appName the name of the application requesting the port > * @param timeout number of miliseconds to wait for the port to open > * @throws PortInUseException > */ > CommPortInterface open(String appName, int timeout) > throws PortInUseException; > > /** > * @return a port using a file descriptor. > * @param fd the file descriptor > * @exception UnsupportedCommOperationException if the platform does > not > * support this functionality > */ > CommPortInterface open(FileDescriptor fd) > throws UnsupportedCommOperationException; > > /** > * Adds the specified listener to the list of ownership listeners for > * this port. > * @param listener the ownership listener to add > */ > void addPortOwnershipListener(CommPortOwnershipListener listener); > > /** > * Removes the specified listener from the list of ownership listeners > for > * this port. > * @param listener the ownership listener to remove > */ > void removePortOwnershipListener(CommPortOwnershipListener listener); > } > public abstract class CommPort implements CommPortInterface { > protected String name; > private final static boolean debug = false; > > public void close() { > if (debug) System.out.println("CommPort:close()"); > > try { > CommPortIdentifierInterface cp = > CommPortIdentifier.getPortIdentifier(this); > if (cp != null) > > CommPortIdentifier.getPortIdentifier(this).internalClosePort(); > } > catch (NoSuchPortException e) { > e.printStackTrace(); > } > } > > public String getName() { > if (debug) System.out.println("CommPort:getName()"); > return (name); > } > > public String toString() { > if (debug) System.out.println("CommPort:toString()"); > return (name); > } > } > >At 12:28 30/07/2006, Dr. Douglas Lyon wrote: > >>Hi All, > >>I was thinking that the new JSR might be more > >>interface oriented and less abstract class oriented. > >> > >>For example, instead of subclassing CommPort, perhaps > >>we should implement a CommPortInterface. > >> > >>How would this look? > > > >Will it break backwards compatibility? > > > >Guillermo > >-- > >Guillermo Rodriguez Garcia > > > >Snijder Micro Systems phone +31-493-351020 > >G. Rodriguez Garcia fax +31-493-351530 > >Visser 25 email guille at sms.nl > >NL5751 BL Deurne > >The Netherlands http://www.snijder.com > > -- http://www.snijder.com/ SNIJDER Micro Systems From lyon at docjava.com Mon Jul 31 07:44:29 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 31 Jul 2006 09:44:29 -0400 Subject: [Rxtx] Do interfaces break backwards BINARY compatibility? Welcome to the serial ports of tomorrow! In-Reply-To: <1154351811.44ce02c3a5539@webmail.eatserver.nl> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> Message-ID: Hi All, The jar file, comm.jar, will change in the sense that there will be new byte codes for Interfaces and the abstract classes byte codes will change. However, the native methods are left unchanged. The goal is to specify "what is" via interfaces, minimizing the impact on the API. This enables RXTX to be a reference implementation of the interface specification. If the JSR is accepted and the interfaces become a part of the javax.comm package, then rxtx could implement the javax.comm specification. Thus, my VISION of the FUTURE (ta da): javax.comm programmers code to the javax.comm interfaces and use a factory method to get an RXTX-based driver. Does that sort of make sense? Thanks! - Doug >Hi Doug, > >I understand. Note that we are not only concerned about source >compatibility, but also about binary compatibility (which would be >preserved as well with this approach if I understood correctly) > >Best regards, >Guillermo > >Quoting "Dr. Douglas Lyon" : > >> Hi All, >> At present I have a prototype version of the libraries that I am >> testing that contains the Interfaces, with growing Javadoc. >> I have been refactoring my code to take advantage of these >> interfaces, but, in the interest of backward compatibility, >> have left the abstract classes, for those who want to continue >> to use and test them. So there is 100% backward compatibility. >> >> My goal is to identify the features of the class specification and >> provide good documentation for them. I think this is seen most clearly in >> the below code. This has ZERO impact on existing code that >> seeks to make use of the CommPort class. >> >> I am adding interfaces and documentation to arrive at a specification. >> Abstract methods and constants move from the abstract class into the >> interface, but then the abstract class implements the interface. >> >> To the API user, it should have no effect. >> >> Cheers! >> - Doug >> >> >> public interface CommPortIdentifierInterface { >> >> int PORT_I2C = 3; >> int PORT_RS485 = 4; >> int PORT_RAW = 5; >> /** >> * RS-232 serial port. >> */ >> int PORT_SERIAL = 1; >> /** >> * IEEE 1284 parallel port. >> */ >> int PORT_PARALLEL = 2; >> >> >> >> /** >> * @return the port name, typically an OS-dependent hardware label. >> * >> */ >> String getName(); >> >> /** >> * @return the port type, PORT_SERIAL or PORT_PARALLEL. >> */ >> int getPortType() >> ; >> >> /** >> * @return the current owner of this port. >> */ >> String getCurrentOwner() >> ; >> >> /** >> * @return true if this port is currently owned. >> */ >> boolean isCurrentlyOwned() ; >> >> /** >> * @return communications port. >> * If the port is in use by another application, it will be notified >> * with a PORT_OWNERSHIP_REQUESTED event. If the current owner closes >> * the port, then this method will succeed. Otherwise a >> * PortInUseException will be thrown. >> * @param appName the name of the application requesting the port >> * @param timeout number of miliseconds to wait for the port to open >> * @throws PortInUseException >> */ >> CommPortInterface open(String appName, int timeout) >> throws PortInUseException; >> >> /** >> * @return a port using a file descriptor. >> * @param fd the file descriptor >> * @exception UnsupportedCommOperationException if the platform does >> not >> * support this functionality >> */ >> CommPortInterface open(FileDescriptor fd) >> throws UnsupportedCommOperationException; >> >> /** >> * Adds the specified listener to the list of ownership listeners for >> * this port. >> * @param listener the ownership listener to add >> */ >> void addPortOwnershipListener(CommPortOwnershipListener listener); > > >> /** >> * Removes the specified listener from the list of ownership listeners >> for >> * this port. >> * @param listener the ownership listener to remove >> */ >> void removePortOwnershipListener(CommPortOwnershipListener listener); >> } >> public abstract class CommPort implements CommPortInterface { >> protected String name; >> private final static boolean debug = false; >> >> public void close() { >> if (debug) System.out.println("CommPort:close()"); >> >> try { >> CommPortIdentifierInterface cp = >> CommPortIdentifier.getPortIdentifier(this); >> if (cp != null) >>???????????????? >> CommPortIdentifier.getPortIdentifier(this).internalClosePort(); >> } >> catch (NoSuchPortException e) { >> e.printStackTrace(); >> } >> } >> >> public String getName() { >> if (debug) System.out.println("CommPort:getName()"); >> return (name); >> } >> >> public String toString() { >> if (debug) System.out.println("CommPort:toString()"); >> return (name); >> } >> } >> >At 12:28 30/07/2006, Dr. Douglas Lyon wrote: >> >>Hi All, >> >>I was thinking that the new JSR might be more >> >>interface oriented and less abstract class oriented. >> >> >> >>For example, instead of subclassing CommPort, perhaps >> >>we should implement a CommPortInterface. >> >> >> >>How would this look? >> > >> >Will it break backwards compatibility? >> > >> >Guillermo >> >-- >> >Guillermo Rodriguez Garcia >> > >> >Snijder Micro Systems phone +31-493-351020 >> >G. Rodriguez Garcia fax +31-493-351530 >> >Visser 25 email guille at sms.nl >> >NL5751 BL Deurne >> >The Netherlands http://www.snijder.com >> >> > > >-- >http://www.snijder.com/ >SNIJDER Micro Systems From berkland at spamcop.net Mon Jul 31 07:57:50 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 31 Jul 2006 09:57:50 -0400 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <1154351811.44ce02c3a5539@webmail.eatserver.nl> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> Message-ID: <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> Adding interfaces does not break any kind of compatibility. Java is more forgiving when it comes to this kind of change than languages that are compiled into native code. As long as the implementing class has the same name, same package, and all of the same methods (with the same signatures) you can add on anything you wish, including implementing additional interfaces. On 7/31/06, Guillermo Rodriguez wrote: > Hi Doug, > > I understand. Note that we are not only concerned about source > compatibility, but also about binary compatibility (which would be > preserved as well with this approach if I understood correctly) > > Best regards, > Guillermo From gergg at cox.net Mon Jul 31 08:12:20 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 31 Jul 2006 09:12:20 -0500 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> Message-ID: <44CE0FC4.9010307@cox.net> Doug Berkland wrote: > Adding interfaces does not break any kind of compatibility. Java is > more forgiving when it comes to this kind of change than languages > that are compiled into native code. As long as the implementing class > has the same name, same package, and all of the same methods (with the > same signatures) you can add on anything you wish, including > implementing additional interfaces. Check the Serialization compatibility guidelines for more information on exactly what binary compatibility requires, and what things can change in an interface and/or class which won't break things. Gregg Wonderly From berkland at spamcop.net Mon Jul 31 09:13:00 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 31 Jul 2006 11:13:00 -0400 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <44CE0FC4.9010307@cox.net> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> <44CE0FC4.9010307@cox.net> Message-ID: <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> As far as I can tell, nothing in either RXTX or Sun's JavaCOMM implements Serializable. Therefore, there are no worries from that either. (I can't think of a reason anything in JavaCOMM should implement Serializable either.) On 7/31/06, Gregg Wonderly wrote: > Doug Berkland wrote: > > Adding interfaces does not break any kind of compatibility. Java is > > more forgiving when it comes to this kind of change than languages > > that are compiled into native code. As long as the implementing class > > has the same name, same package, and all of the same methods (with the > > same signatures) you can add on anything you wish, including > > implementing additional interfaces. > > Check the Serialization compatibility guidelines for more information on exactly > what binary compatibility requires, and what things can change in an interface > and/or class which won't break things. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From berkland at spamcop.net Mon Jul 31 09:20:48 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 31 Jul 2006 11:20:48 -0400 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> <44CE0FC4.9010307@cox.net> <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> Message-ID: <269e40090607310820s15f2eee8j903e077917d7fc72@mail.gmail.com> Correction: Nothing except the classes extending Exception and Event implement Serializable. On 7/31/06, Doug Berkland wrote: > As far as I can tell, nothing in either RXTX or Sun's JavaCOMM > implements Serializable. Therefore, there are no worries from that > either. (I can't think of a reason anything in JavaCOMM should > implement Serializable either.) > > On 7/31/06, Gregg Wonderly wrote: > > Doug Berkland wrote: > > > Adding interfaces does not break any kind of compatibility. Java is > > > more forgiving when it comes to this kind of change than languages > > > that are compiled into native code. As long as the implementing class > > > has the same name, same package, and all of the same methods (with the > > > same signatures) you can add on anything you wish, including > > > implementing additional interfaces. > > > > Check the Serialization compatibility guidelines for more information on exactly > > what binary compatibility requires, and what things can change in an interface > > and/or class which won't break things. > > > > Gregg Wonderly > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > From gergg at cox.net Mon Jul 31 11:21:19 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 31 Jul 2006 12:21:19 -0500 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> <44CE0FC4.9010307@cox.net> <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> Message-ID: <44CE3C0F.3080408@cox.net> Doug Berkland wrote: > As far as I can tell, nothing in either RXTX or Sun's JavaCOMM > implements Serializable. Therefore, there are no worries from that > either. (I can't think of a reason anything in JavaCOMM should > implement Serializable either.) Any interface in javax.comm can become implemented by a serializable object. Thus, if someone wants to provide remote access to a serial port, then they might (and I think this is not wise) choose to subclass and add Serializable to the interface list. It's that kind of Serialization compatibility that I'm talking about. Gregg Wonderly From rwelty at suespammers.org Mon Jul 31 19:53:12 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 31 Jul 2006 21:53:12 -0400 Subject: [Rxtx] Application Name? Message-ID: <44CEB408.7040407@suespammers.org> trying to get my app running on a Mac OS X powerbook, when the following is executed as the first thing inside the run method of a Thread: try { port = (SerialPort) selectedPort.open( this.getClass().getName(), 2000); } catch ( PortInUseException ex){ ex.printStackTrace(); return; } i get the following: gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at com.krusty_motorsports.scale.monitor.ScaleWatcher.run(ScaleWatcher.java:143) i've not seen any documentation suggesting that rxtx would be finicky about application names... thanks for any suggestions, richard From stevebeemonkey at monkey-media.co.uk Wed Jul 5 05:59:02 2006 From: stevebeemonkey at monkey-media.co.uk (steve@monkey-media.co.uk) Date: Wed, 5 Jul 2006 04:59:02 -0700 Subject: [Rxtx] No output on WinXP Message-ID: <1152100742.44aba986565e7@www.webmail.ezpublishing.com> Hi there, I've installed RXTX 2.1.7 under Win XP, copying the .jar and .dll files according to the instructions given. I've changed the javax.comm import to gnu.io, but when I run the following code the only output I get is: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Then the program ends, without listing any of the ports. What am I doing wrong? Cheers, Steve Here's my code: ---------------------------------------- import gnu.io.*; import java.util.*; public class PortList { public static void main(String [] args) { Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while(portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); if( portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("Serial port: " + portId.getName()); } else if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { System.out.println("Parallel port: " + portId.getName()); } else System.out.println("Other port: " + portId.getName()); } } } ------------------------------- From tjarvi at qbang.org Wed Jul 5 07:57:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 5 Jul 2006 07:57:22 -0600 (MDT) Subject: [Rxtx] No output on WinXP In-Reply-To: <1152100742.44aba986565e7@www.webmail.ezpublishing.com> References: <1152100742.44aba986565e7@www.webmail.ezpublishing.com> Message-ID: On Wed, 5 Jul 2006, steve at monkey-media.co.uk wrote: > > > Hi there, > > I've installed RXTX 2.1.7 under Win XP, copying the .jar and .dll files > according to the instructions given. > > I've changed the javax.comm import to gnu.io, but when I run the following code > the only output I get is: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Then the program ends, without listing any of the ports. > > What am I doing wrong? > > Cheers, > > Steve > > Here's my code: > > ---------------------------------------- > > import gnu.io.*; > import java.util.*; > > public class PortList > { > public static void main(String [] args) > { > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > while(portList.hasMoreElements()) { > CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); > if( portId.getPortType() == > CommPortIdentifier.PORT_SERIAL) > { > System.out.println("Serial port: " + > portId.getName()); > } else if (portId.getPortType() == > CommPortIdentifier.PORT_PARALLEL) > { > System.out.println("Parallel port: " + > portId.getName()); > } else > System.out.println("Other port: " + > portId.getName()); > } > } > } > > ------------------------------- > If you have a port open with another terminal such as hyperterminal or even another copy of your application using rxtx, the port will not be enumerated. rxtx enumerates ports by opening prospective ports and doing a timed out read. If the port is open by another application, the open will fail. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Wed Jul 5 15:44:05 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Wed, 5 Jul 2006 15:44:05 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EA89@hqexchange3.dot.state.co.us> Trent, I did put some debug statements and the "index" returned to me in the while loop is "0" (see the code below) and it gets into the infinite loop, I can put a break statement but don't know the ramifications of it. Can you explain in what scenarios the index can be "0" or are we somehow in the native code loosing refrences to the indexes? Thanks Again Pawan Kharbanda while( searching ) { index = master_index; if( index ) { while( index->fd != fd && index->next ) index = index->next; if ( index->fd == fd ) searching = 0; } else report("Index"+index"x"); <<<<<< The code gets to this statement and index is returned as "0" and I don't see anyway to break out of this looop after. if( searching ) { report("@"); usleep(1000); } } -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, June 29, 2006 6:21 AM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports > Here is how you can test if you have resources/ test environment. > Write a program and try to open/close different ports(I will say have > a minimum of four) randomly and very frequently(may be 30 seconds), I > am pretty sure you will see the deadlocks and it happens in the native > call to interrptEventLoop in RXTXPort.java in removeEventListener() > method call. Hi Pawan I'll try to find a way to reproduce this. One thing to note is that you are using different kernel drivers (digi) to perform this task. So I probably will not be able to reproduce the exact same environment. In general, multiport kernel drivers have been tested far less than typical serial drivers. This may or may not be an issue. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Wed Jul 5 18:50:01 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Wed, 5 Jul 2006 18:50:01 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EA96@hqexchange3.dot.state.co.us> Trent, Sorry for so many emails, but as I mentioned earlier I will write a test to replicate the Locking problem. I am attaching a Java file to replicate the problem. You need atleast 4-5 ports to simulate the problem. Here is how to run the program. In the TestOpenClosePort.java please change the Serial Ports names(Add the ports installed on your machine). Then compile your java file and run as "java TestOpenClosePort 100" (100 is the no of times you want to open and close the port in one single thread). I have tested this with the Digi Boxes and able to replicate this over and over in Single JVM. Hope this test helps track down the problem. Thanks Pawan Kharbanda -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, June 29, 2006 6:21 AM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports > Here is how you can test if you have resources/ test environment. > Write a program and try to open/close different ports(I will say have > a minimum of four) randomly and very frequently(may be 30 seconds), I > am pretty sure you will see the deadlocks and it happens in the native > call to interrptEventLoop in RXTXPort.java in removeEventListener() > method call. Hi Pawan I'll try to find a way to reproduce this. One thing to note is that you are using different kernel drivers (digi) to perform this task. So I probably will not be able to reproduce the exact same environment. In general, multiport kernel drivers have been tested far less than typical serial drivers. This may or may not be an issue. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: TestOpenClosePort.java Type: application/octet-stream Size: 6038 bytes Desc: TestOpenClosePort.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060705/82f8488f/TestOpenClosePort-0356.obj From tjarvi at qbang.org Wed Jul 5 22:48:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 5 Jul 2006 22:48:52 -0600 (MDT) Subject: [Rxtx] Locked Ports In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3EA89@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03F3EA89@hqexchange3.dot.state.co.us> Message-ID: On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did put some debug statements and the "index" returned to me in > the while loop is "0" (see the code below) and it gets into the infinite > loop, I can put a break statement but don't know the ramifications of > it. Can you explain in what scenarios the index can be "0" or are we > somehow in the native code loosing refrences to the indexes? > > Thanks Again > Pawan Kharbanda > > while( searching ) > { > index = master_index; > > if( index ) > { > while( index->fd != fd && > index->next ) index = index->next; > if ( index->fd == fd ) searching = 0; > } > else > report("Index"+index"x"); <<<<<< The code gets > to this statement and index is returned as "0" and I don't see anyway to > break out of this looop after. > if( searching ) > { > report("@"); > usleep(1000); > } > } > Hi Pawan I am reading with interest :) So it sounds like this is a thread safe problem. The thing I don't understand here is open and close are synchronized in RXTXPort.java. I thought that would prevent any thread problems with the linked list. Looking closer, the linked list is actually populated in eventLoop/MonitorThread which is not synchronized. So you may be able to synchronize on an object in RXTXPort.java. A seperate native call would probably be required for the initalization to prevent a deadlock. A solution might involve making finalize_event_info_struct() and initialise_event_info_struct() [uk spelling?] thread safe with glib. http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads.html#id2786034 glib also has more robust linked lists which could be used. Thats the indirectly the problem found in termios.c for windows. The disadvantage is we would require linking to glib which is another step for systems that don't come with it. The advantage would be reduced code size we have to maintain. We could borrow bits of glib as the licenses are the same. Another solution might be to just use pthread_mutex_lock and unlock. http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html I don't think that would work on windows though. It would require linking cygwin.dll which would not work with nonGPL projects in practice. -- Trent Jarvi tjarvi From neville_seed at yahoo.com Thu Jul 6 06:42:29 2006 From: neville_seed at yahoo.com (neville seed) Date: Thu, 6 Jul 2006 05:42:29 -0700 (PDT) Subject: [Rxtx] port to palm OS? Message-ID: <20060706124230.55790.qmail@web51015.mail.yahoo.com> hello. Has rxtx been ported to PalmOS? regards neville __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From neville_seed at yahoo.com Thu Jul 6 06:43:44 2006 From: neville_seed at yahoo.com (neville seed) Date: Thu, 6 Jul 2006 05:43:44 -0700 (PDT) Subject: [Rxtx] example code Message-ID: <20060706124344.5063.qmail@web51013.mail.yahoo.com> hello. Could anyone provide me with example code of how to read from the serial port. regards neville __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From naranjo.manuel at gmail.com Thu Jul 6 06:48:20 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Thu, 06 Jul 2006 09:48:20 -0300 Subject: [Rxtx] port to palm OS? In-Reply-To: <20060706124230.55790.qmail@web51015.mail.yahoo.com> References: <20060706124230.55790.qmail@web51015.mail.yahoo.com> Message-ID: <44AD0694.1090703@gmail.com> neville seed wrote: > hello. > > Has rxtx been ported to PalmOS? > > regards > neville > I'm interested on this. Do you need rxtx ported to J2ME or to Superwaba?. Superwaba has it owns implementation of a serial port, but it is not rxtx. Regards, Manuel From joachim at buechse.de Thu Jul 6 07:20:57 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 6 Jul 2006 15:20:57 +0200 Subject: [Rxtx] port to palm OS? In-Reply-To: <20060706124230.55790.qmail@web51015.mail.yahoo.com> References: <20060706124230.55790.qmail@web51015.mail.yahoo.com> Message-ID: Which version of PalmOS are you targeting? I have been doing some Java on PalmOS programming for the Palm Vx using the JVM from Esmertec. The problem there was, that PalmOS can only process one kernel call at a time (it is (was?) not a multithreading OS). Threads were implemented by the VM. In a situation like this, any kind of "abort" mechanism is very difficult to handle - from what I know about the RXTX code and the way close() would have to be implemented it's the same as rewriting RXTX. Newer versions of PalmOS might have improved in this respect... Best regards, Joachim On 06.07.2006, at 14:42, neville seed wrote: > hello. > > Has rxtx been ported to PalmOS? > > regards > neville > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From neville_seed at yahoo.com Thu Jul 6 08:23:29 2006 From: neville_seed at yahoo.com (neville seed) Date: Thu, 6 Jul 2006 07:23:29 -0700 (PDT) Subject: [Rxtx] port to palm OS? In-Reply-To: Message-ID: <20060706142329.91625.qmail@web51005.mail.yahoo.com> The palmOS would be version 5.x however i am new to both palm and java. As such I would have to find out any questions. --- Joachim Buechse wrote: > Which version of PalmOS are you targeting? > > I have been doing some Java on PalmOS programming > for the Palm Vx > using the JVM from Esmertec. The problem there was, > that PalmOS can > only process one kernel call at a time (it is (was?) > not a > multithreading OS). Threads were implemented by the > VM. In a > situation like this, any kind of "abort" mechanism > is very difficult > to handle - from what I know about the RXTX code and > the way close() > would have to be implemented it's the same as > rewriting RXTX. Newer > versions of PalmOS might have improved in this > respect... > > Best regards, > Joachim > > On 06.07.2006, at 14:42, neville seed wrote: > > > hello. > > > > Has rxtx been ported to PalmOS? > > > > regards > > neville > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From jhaysonn at gmail.com Thu Jul 6 08:58:07 2006 From: jhaysonn at gmail.com (jhaysonn pathak) Date: Thu, 6 Jul 2006 10:58:07 -0400 Subject: [Rxtx] RXTX install (jhaysonn pathak) Message-ID: Thanks for the install tip. I figured out how to do the cvs update, but in my MACOSX_IDE dir I didn't have any Xcode folders and searching my computer, I only have 3 Xcode folders (one for application support, one for Max/MSP and one in developer tools). I have tried building each of the different *.xcodeproj files and in eachone they have little toolbox looking items that are in red (i assume that means it can't find them). Some of them I manage to locate but some of them just aren't on my computer. In any event, I still can't find the libserial.jnilib. After the update I read the README.OSX and it did make it seem a lot easier, but for the future, if I finally create a libserial.jnilib I don't know what the 'JavaVM' is in reference to this line "Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required)." PS - How do I uninstall everything RXTX so that I can try and re-download and re-install everything? From joachim at buechse.de Thu Jul 6 09:12:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 6 Jul 2006 17:12:24 +0200 Subject: [Rxtx] RXTX install (jhaysonn pathak) In-Reply-To: References: Message-ID: <98F15662-544D-41B5-8229-BB1DB6B6FD43@buechse.de> The Java VM ist the Java Virtual Machine. It runs your application. For the rest of your message ... your description is much to unprecise to help. To start, you could describe what IS in the MACOSX_IDE folder and its subfolders. On 06.07.2006, at 16:58, jhaysonn pathak wrote: > Thanks for the install tip. I figured out how to do the cvs update, > but in my MACOSX_IDE dir I didn't have any Xcode folders and searching > my computer, I only have 3 Xcode folders (one for application support, > one for Max/MSP and one in developer tools). I have tried building > each of the different *.xcodeproj files and in eachone they have > little toolbox looking items that are in red (i assume that means it > can't find them). Some of them I manage to locate but some of them > just aren't on my computer. In any event, I still can't find the > libserial.jnilib. > > After the update I read the README.OSX and it did make it seem a lot > easier, but for the future, if I finally create a libserial.jnilib I > don't know what the 'JavaVM' is in reference to this line > > "Put > libSerial.jnilib > in the directory of the application (the JavaVM will find it > there). Add > RXTXComm.jar > to the application classpath or include the classes in the > application jar. > (Some applications already include the RXTX classes in their > application jar, > in which case only the file libSerial.jnilib is required)." > > PS - How do I uninstall everything RXTX so that I can try and > re-download and re-install everything? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jul 6 09:20:16 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 6 Jul 2006 17:20:16 +0200 Subject: [Rxtx] RXTX install (jhaysonn pathak) In-Reply-To: References: Message-ID: <8F03CA0E-44F4-434F-AA7E-3A8B5054AA6F@buechse.de> Rethinking about your problem... I think you should try a cvs up -d Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 06.07.2006, at 16:58, jhaysonn pathak wrote: > Thanks for the install tip. I figured out how to do the cvs update, > but in my MACOSX_IDE dir I didn't have any Xcode folders and searching > my computer, I only have 3 Xcode folders (one for application support, > one for Max/MSP and one in developer tools). I have tried building > each of the different *.xcodeproj files and in eachone they have > little toolbox looking items that are in red (i assume that means it > can't find them). Some of them I manage to locate but some of them > just aren't on my computer. In any event, I still can't find the > libserial.jnilib. > > After the update I read the README.OSX and it did make it seem a lot > easier, but for the future, if I finally create a libserial.jnilib I > don't know what the 'JavaVM' is in reference to this line > > "Put > libSerial.jnilib > in the directory of the application (the JavaVM will find it > there). Add > RXTXComm.jar > to the application classpath or include the classes in the > application jar. > (Some applications already include the RXTX classes in their > application jar, > in which case only the file libSerial.jnilib is required)." > > PS - How do I uninstall everything RXTX so that I can try and > re-download and re-install everything? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Thu Jul 6 10:19:17 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Thu, 06 Jul 2006 13:19:17 -0300 Subject: [Rxtx] port to palm OS? In-Reply-To: <20060706142329.91625.qmail@web51005.mail.yahoo.com> References: <20060706142329.91625.qmail@web51005.mail.yahoo.com> Message-ID: <44AD3805.3010609@gmail.com> neville seed wrote: > The palmOS would be version 5.x however i am new to > both palm and java. As such I would have to find out > any questions. > Hello if you are new you could use Superwaba, url: www.superwaba.com, which is not exactly Java but works great, and has a serial port. If you need any more info please let me know. Manuel From Pawan.Kharbanda at dot.state.co.us Thu Jul 6 12:49:50 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 6 Jul 2006 12:49:50 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EB11@hqexchange3.dot.state.co.us> Trent, I did made the eventLoop() call in the Monitor Thread synchronized, it improved but still see the same problem. Your comment > A solution might involve making finalize_event_info_struct() and > initialise_event_info_struct() [uk spelling?] thread safe with glib. I didn't follow this how I can implement this. I am not a C guy, can you help me understand how I can implement this? Thanks Pawan Kharbanda -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, July 05, 2006 10:49 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did put some debug statements and the "index" returned to me in > the while loop is "0" (see the code below) and it gets into the > infinite loop, I can put a break statement but don't know the > ramifications of it. Can you explain in what scenarios the index can > be "0" or are we somehow in the native code loosing refrences to the indexes? > > Thanks Again > Pawan Kharbanda > > while( searching ) > { > index = master_index; > > if( index ) > { > while( index->fd != fd && > index->next ) index = index->next; > if ( index->fd == fd ) searching = 0; > } > else > report("Index"+index"x"); <<<<<< The code gets to this statement > and index is returned as "0" and I don't see anyway to break out of > this looop after. > if( searching ) > { > report("@"); > usleep(1000); > } > } > Hi Pawan I am reading with interest :) So it sounds like this is a thread safe problem. The thing I don't understand here is open and close are synchronized in RXTXPort.java. I thought that would prevent any thread problems with the linked list. Looking closer, the linked list is actually populated in eventLoop/MonitorThread which is not synchronized. So you may be able to synchronize on an object in RXTXPort.java. A seperate native call would probably be required for the initalization to prevent a deadlock. A solution might involve making finalize_event_info_struct() and initialise_event_info_struct() [uk spelling?] thread safe with glib. http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. html#id2786034 glib also has more robust linked lists which could be used. Thats the indirectly the problem found in termios.c for windows. The disadvantage is we would require linking to glib which is another step for systems that don't come with it. The advantage would be reduced code size we have to maintain. We could borrow bits of glib as the licenses are the same. Another solution might be to just use pthread_mutex_lock and unlock. http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html I don't think that would work on windows though. It would require linking cygwin.dll which would not work with nonGPL projects in practice. -- Trent Jarvi tjarvi _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From zhanglong at adventnet.com Wed Jul 5 20:44:18 2006 From: zhanglong at adventnet.com (zhanglong) Date: Thu, 06 Jul 2006 10:44:18 +0800 Subject: [Rxtx] rxtx can not read data from serialport Message-ID: <44AC7902.8070407@adventnet.com> Dear sir, When I use rxrx2.1-7-bin-r2?I can write data into serialport,But can not read data from serialport on windowsXP. I can not write and read data from serialport on Redhat Linux9.0. I can get serialport list on my machine.And no error with open serialport. I can get and read data from serialport on windowsXP with SUN's javacomm20-win32.zip. How can I read data on windows and write,read data on Linux with rxtx? Best Regards, Zhanglong From tjarvi at qbang.org Thu Jul 6 19:07:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 19:07:13 -0600 (MDT) Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: <44AC7902.8070407@adventnet.com> References: <44AC7902.8070407@adventnet.com> Message-ID: On Thu, 6 Jul 2006, zhanglong wrote: > Dear sir, > > When I use rxrx2.1-7-bin-r2??I can write data into serialport,But can > not read data from serialport on windowsXP. > I can not write and read data from serialport on Redhat Linux9.0. > I can get serialport list on my machine.And no error with open serialport. > > I can get and read data from serialport on windowsXP with SUN's > javacomm20-win32.zip. > > How can I read data on windows and write,read data on Linux with rxtx? > > Hi Zhanglong Make sure that you specify the flow control, timeout and threshold that you want. The defaults may vary between rxtx and Sun. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jul 6 19:10:25 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 19:10:25 -0600 (MDT) Subject: [Rxtx] Controlling Individual Signals DTR and RTS In-Reply-To: References: Message-ID: On Thu, 29 Jun 2006, Chris Pine wrote: > Dear Moussa Ba, > I hope I am not being too forward, but we are having the exact same > issue with needing to control DTR from RXTX in Linux. Did you ever have any > luck figuring it out? > > Thank you very much for your time, > Hi Chris Are you using an unusual serial port? It could be that the port does not support DTR/RTS. Especially if its an inexpensive USB->Serial dongle. I'll double check Linux tomorrow but I'm fairly sure it works. I have verified windows after a questions like yours. Some multiport cards and usb dongles do not support everything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jul 6 19:17:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 19:17:09 -0600 (MDT) Subject: [Rxtx] Locked Ports In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3EB11@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03F3EB11@hqexchange3.dot.state.co.us> Message-ID: Hi Pawan There is an example of doing this in the link I provided below. They make a pointer to the function they want to be thread safe and then use that with the glib functions. I'm not ready to just toss out a quick hack because I'd like to think through this a bit to make sure I understand what types of problems we may run into. The code still hung in the same place after synchronizing the eventLoop? I think that eventLoop needs to be refactored to pull out the initialization code so people do not need to run the monitor. On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did made the eventLoop() call in the Monitor Thread synchronized, it > improved but still see the same problem. > > Your comment >> A solution might involve making finalize_event_info_struct() and >> initialise_event_info_struct() [uk spelling?] thread safe with glib. > > I didn't follow this how I can implement this. I am not a C guy, can you > help me understand how I can implement this? > > Thanks > Pawan Kharbanda > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Wednesday, July 05, 2006 10:49 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] Locked Ports > > On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > >> Trent, >> I did put some debug statements and the "index" returned to me in >> the while loop is "0" (see the code below) and it gets into the >> infinite loop, I can put a break statement but don't know the >> ramifications of it. Can you explain in what scenarios the index can >> be "0" or are we somehow in the native code loosing refrences to the > indexes? >> >> Thanks Again >> Pawan Kharbanda >> >> while( searching ) >> { >> index = master_index; >> >> if( index ) >> { >> while( index->fd != fd && >> index->next ) index = index->next; >> if ( index->fd == fd ) searching = 0; >> } >> else >> report("Index"+index"x"); <<<<<< The code gets > to this statement >> and index is returned as "0" and I don't see anyway to break out of >> this looop after. >> if( searching ) >> { >> report("@"); >> usleep(1000); >> } >> } >> > > Hi Pawan > > I am reading with interest :) > > So it sounds like this is a thread safe problem. > > The thing I don't understand here is open and close are synchronized in > RXTXPort.java. I thought that would prevent any thread problems with > the linked list. Looking closer, the linked list is actually populated > in eventLoop/MonitorThread which is not synchronized. > > So you may be able to synchronize on an object in RXTXPort.java. A > seperate native call would probably be required for the initalization to > prevent a deadlock. > > A solution might involve making finalize_event_info_struct() and > initialise_event_info_struct() [uk spelling?] thread safe with glib. > > http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. > html#id2786034 > > glib also has more robust linked lists which could be used. Thats the > indirectly the problem found in termios.c for windows. The disadvantage > is we would require linking to glib which is another step for systems > that don't come with it. The advantage would be reduced code size we > have to maintain. We could borrow bits of glib as the licenses are the > same. > > Another solution might be to just use pthread_mutex_lock and unlock. > > http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html > > I don't think that would work on windows though. It would require > linking cygwin.dll which would not work with nonGPL projects in > practice. > > -- > Trent Jarvi > tjarvi > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Pawan.Kharbanda at dot.state.co.us Thu Jul 6 21:46:08 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 6 Jul 2006 21:46:08 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EB35@hqexchange3.dot.state.co.us> Trent, Just curious to know if you were able to replicate the problem with my example? Pawan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, July 06, 2006 7:17 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports Hi Pawan There is an example of doing this in the link I provided below. They make a pointer to the function they want to be thread safe and then use that with the glib functions. I'm not ready to just toss out a quick hack because I'd like to think through this a bit to make sure I understand what types of problems we may run into. The code still hung in the same place after synchronizing the eventLoop? I think that eventLoop needs to be refactored to pull out the initialization code so people do not need to run the monitor. On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did made the eventLoop() call in the Monitor Thread synchronized, > it improved but still see the same problem. > > Your comment >> A solution might involve making finalize_event_info_struct() and >> initialise_event_info_struct() [uk spelling?] thread safe with glib. > > I didn't follow this how I can implement this. I am not a C guy, can > you help me understand how I can implement this? > > Thanks > Pawan Kharbanda > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Wednesday, July 05, 2006 10:49 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] Locked Ports > > On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > >> Trent, >> I did put some debug statements and the "index" returned to me in >> the while loop is "0" (see the code below) and it gets into the >> infinite loop, I can put a break statement but don't know the >> ramifications of it. Can you explain in what scenarios the index can >> be "0" or are we somehow in the native code loosing refrences to the > indexes? >> >> Thanks Again >> Pawan Kharbanda >> >> while( searching ) >> { >> index = master_index; >> >> if( index ) >> { >> while( index->fd != fd && >> index->next ) index = index->next; >> if ( index->fd == fd ) searching = 0; >> } >> else >> report("Index"+index"x"); <<<<<< The code gets > to this statement >> and index is returned as "0" and I don't see anyway to break out of >> this looop after. >> if( searching ) >> { >> report("@"); >> usleep(1000); >> } >> } >> > > Hi Pawan > > I am reading with interest :) > > So it sounds like this is a thread safe problem. > > The thing I don't understand here is open and close are synchronized > in RXTXPort.java. I thought that would prevent any thread problems > with the linked list. Looking closer, the linked list is actually > populated in eventLoop/MonitorThread which is not synchronized. > > So you may be able to synchronize on an object in RXTXPort.java. A > seperate native call would probably be required for the initalization > to prevent a deadlock. > > A solution might involve making finalize_event_info_struct() and > initialise_event_info_struct() [uk spelling?] thread safe with glib. > > http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. > html#id2786034 > > glib also has more robust linked lists which could be used. Thats the > indirectly the problem found in termios.c for windows. The > disadvantage is we would require linking to glib which is another step > for systems that don't come with it. The advantage would be reduced > code size we have to maintain. We could borrow bits of glib as the > licenses are the same. > > Another solution might be to just use pthread_mutex_lock and unlock. > > http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html > > I don't think that would work on windows though. It would require > linking cygwin.dll which would not work with nonGPL projects in > practice. > > -- > Trent Jarvi > tjarvi > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jul 6 21:53:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 21:53:49 -0600 (MDT) Subject: [Rxtx] Locked Ports In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3EB35@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03F3EB35@hqexchange3.dot.state.co.us> Message-ID: Pawan: I'm sure I can reproduce the problem. What you have described makes very good sense and has changed how I think about rxtx. 64 ports. Take your design specs and write 'open source' on them. On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > Trent, > Just curious to know if you were able to replicate the problem > with my example? > > Pawan > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Thursday, July 06, 2006 7:17 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] Locked Ports > > > Hi Pawan > > There is an example of doing this in the link I provided below. They > make a pointer to the function they want to be thread safe and then use > that with the glib functions. > > I'm not ready to just toss out a quick hack because I'd like to think > through this a bit to make sure I understand what types of problems we > may run into. > > The code still hung in the same place after synchronizing the eventLoop? > > > > > I think that eventLoop needs to be refactored to pull out the > initialization code so people do not need to run the monitor. > > On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > >> Trent, >> I did made the eventLoop() call in the Monitor Thread synchronized, >> it improved but still see the same problem. >> >> Your comment >>> A solution might involve making finalize_event_info_struct() and >>> initialise_event_info_struct() [uk spelling?] thread safe with glib. >> >> I didn't follow this how I can implement this. I am not a C guy, can >> you help me understand how I can implement this? >> >> Thanks >> Pawan Kharbanda >> >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > >> Of Trent Jarvi >> Sent: Wednesday, July 05, 2006 10:49 PM >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] Locked Ports >> >> On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: >> >>> Trent, >>> I did put some debug statements and the "index" returned to me in >>> the while loop is "0" (see the code below) and it gets into the >>> infinite loop, I can put a break statement but don't know the >>> ramifications of it. Can you explain in what scenarios the index can >>> be "0" or are we somehow in the native code loosing refrences to the >> indexes? >>> >>> Thanks Again >>> Pawan Kharbanda >>> >>> while( searching ) >>> { >>> index = master_index; >>> >>> if( index ) >>> { >>> while( index->fd != fd && >>> index->next ) index = index->next; >>> if ( index->fd == fd ) searching = 0; >>> } >>> else >>> report("Index"+index"x"); <<<<<< The code gets >> to this statement >>> and index is returned as "0" and I don't see anyway to break out of >>> this looop after. >>> if( searching ) >>> { >>> report("@"); >>> usleep(1000); >>> } >>> } >>> >> >> Hi Pawan >> >> I am reading with interest :) >> >> So it sounds like this is a thread safe problem. >> >> The thing I don't understand here is open and close are synchronized >> in RXTXPort.java. I thought that would prevent any thread problems >> with the linked list. Looking closer, the linked list is actually >> populated in eventLoop/MonitorThread which is not synchronized. >> >> So you may be able to synchronize on an object in RXTXPort.java. A >> seperate native call would probably be required for the initalization >> to prevent a deadlock. >> >> A solution might involve making finalize_event_info_struct() and >> initialise_event_info_struct() [uk spelling?] thread safe with glib. >> >> > http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. >> html#id2786034 >> >> glib also has more robust linked lists which could be used. Thats the > >> indirectly the problem found in termios.c for windows. The >> disadvantage is we would require linking to glib which is another step > >> for systems that don't come with it. The advantage would be reduced >> code size we have to maintain. We could borrow bits of glib as the >> licenses are the same. >> >> Another solution might be to just use pthread_mutex_lock and unlock. >> >> http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html >> >> I don't think that would work on windows though. It would require >> linking cygwin.dll which would not work with nonGPL projects in >> practice. >> >> -- >> Trent Jarvi >> tjarvi >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pascal at quies.net Fri Jul 7 08:45:59 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Fri, 7 Jul 2006 16:45:59 +0200 Subject: [Rxtx] Java installer Message-ID: <200607071645.59765.pascal@quies.net> Hello everybody, We need a *simple* installer for the RXTX extension. I'm working on a pure Java installer right now. Let's get this thing working over the weekend. The license of choise is the modified BSD license. My plan is to make a JAR with: * the RXTX binaries * a simple API to detect any installed version * a simple Swing installer * a executeable detector: java -jar communicationapi.jar detect javax.comm * a executable installer: java -jar communicationapi.jar install gnu.io * Java 1.2 compatible Comments? _The Java API_: class CommunicationAPI { CommunicationAPI() CommunicationAPI(String path) boolean available() boolean supportsRS232() boolean supportsRS485() boolean supportsI2C() boolean supportsIEEE1280() static void main(String[] args) static boolean installRXTX(boolean headless) } Comments? To get this working we need binaries. Who is having what? The package from the official site has the following: * Linux: i686, x86_64, ia64 * Solaris: sparc32, sparc64 * Windows: i386 Now that's a start. I had to modify the code (what a mess!) to get it working on OpenBSD but I don't have the time to get it working for every platform. Any help here? From j.a.horsmeier at wanadoo.nl Fri Jul 7 09:11:24 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Fri, 7 Jul 2006 17:11:24 +0200 Subject: [Rxtx] Java installer In-Reply-To: <200607071645.59765.pascal@quies.net> Message-ID: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> > Pascal S. de Kloe wrote: > We need a *simple* installer for the RXTX extension. > I'm working on a pure Java installer right now. Let's get > this thing working > over the weekend. The license of choise is the modified BSD license. > > My plan is to make a JAR with: > * the RXTX binaries > * a simple API to detect any installed version > * a simple Swing installer > * a executeable detector: java -jar communicationapi.jar > detect javax.comm > * a executable installer: java -jar communicationapi.jar > install gnu.io > * Java 1.2 compatible > > Comments? Have a look at IzPack: http://www.izforge.com/izpack/ I use it all the time to install rxtx as part of our application. kind regards, Jos From brian at mbari.org Fri Jul 7 10:01:27 2006 From: brian at mbari.org (Brian Schlining) Date: Fri, 7 Jul 2006 09:01:27 -0700 Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: <44AC7902.8070407@adventnet.com> References: <44AC7902.8070407@adventnet.com> Message-ID: On Jul 5, 2006, at 7:44 PM, zhanglong wrote: > Dear sir, > > When I use rxrx2.1-7-bin-r2?I can write data into serialport,But can > not read data from serialport on windowsXP. > I can not write and read data from serialport on Redhat Linux9.0. > I can get serialport list on my machine.And no error with open > serialport. > > I can get and read data from serialport on windowsXP with SUN's > javacomm20-win32.zip. > > How can I read data on windows and write,read data on Linux with rxtx? On windows, if all else fails you may need to use this flow control: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_IN); Also, for some command/response applications that I've tried with RXTX, I find that if I write to the serialport and then immediately try to read from it I get byte arrays filled with zeros, no matter what I set the recieveTimeout to (this has occurred on both Mac OS X and Windows). The workaround that I found was to very briefly put the I/O thread to sleep, like so: // DO set up and get I/O streams //in = serialPort.getInputStream(); //out = serialPort.getOutputStream(); out.write(someByteArray); try { Thread.sleep(10); catch (InterruptedException e) { // handle exception } in.read(anotherByteArray); Note: I've never had to put the thread to sleep using Java comm, only with RXTX. Anyone know why this might be? Cheers B Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060707/f0799573/attachment-0354.html From pascal at quies.net Fri Jul 7 16:55:03 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 00:55:03 +0200 Subject: [Rxtx] Java installer In-Reply-To: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> Message-ID: <200607080055.04501.pascal@quies.net> Op vrijdag 7 juli 2006 17:11, schreef Jos A. Horsmeier: > > Pascal S. de Kloe wrote: > > > > We need a *simple* installer for the RXTX extension. > > I'm working on a pure Java installer right now. Let's get > > this thing working > > over the weekend. The license of choise is the modified BSD license. > > > > My plan is to make a JAR with: > > * the RXTX binaries > > * a simple API to detect any installed version > > * a simple Swing installer > > * a executeable detector: java -jar communicationapi.jar > > detect javax.comm > > * a executable installer: java -jar communicationapi.jar > > install gnu.io > > * Java 1.2 compatible > > > > Comments? > > Have a look at IzPack: http://www.izforge.com/izpack/ > I use it all the time to install rxtx as part of our application. Hello Jos, Thanks for the idea. Could you publish the IzPack configuration and the binaries? That would be very helpful since the current installation procedure is somewhat "unprofessional". ;) IzPack is great but this API is a little more than that. It allows java applications who require the extension to detect available versions and install RXTX on the fly if needed. Is Izpack: * able to install binaries for the right platform (os + hardware architecture)? * Java 1.2 compatible * able to run from the command line? I need as many pre-compiled binaries as possible. Could you help me with that? The detection system already works. Thanks again, Pascal PS Is the gnu.io namespace still necessary? I couldn't find the problem. From naranjo.manuel at gmail.com Fri Jul 7 17:04:31 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 07 Jul 2006 20:04:31 -0300 Subject: [Rxtx] Java installer In-Reply-To: <200607080055.04501.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: <44AEE87F.60202@gmail.com> Pascal: I will be a little short with my answer but very informative :) > Could you publish the IzPack configuration and the binaries? That would be > very helpful since the current installation procedure is > somewhat "unprofessional". ;) > > IzPack is great but this API is a little more than that. It allows java > applications who require the extension to detect available versions and > install RXTX on the fly if needed. > > Is Izpack: > * able to install binaries for the right platform (os + hardware > architecture)? Yes. > * Java 1.2 compatible Yes of course > * able to run from the command line? Yes, and can run from command line detecting which is the underlaying os. I have attached an old version of one of my installer, I can't find the last one, but it is like this one. In this you will see how to detect the OS and architecture and install binaries for that plataform. Regards, Manuel -------------- next part -------------- A non-text attachment was scrubbed... Name: installer.xml Type: text/xml Size: 4683 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060707/fbc3be3c/installer-0354.xml From pascal at quies.net Fri Jul 7 18:35:29 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 02:35:29 +0200 Subject: [Rxtx] Java installer In-Reply-To: <44AEE87F.60202@gmail.com> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <44AEE87F.60202@gmail.com> Message-ID: <200607080235.29486.pascal@quies.net> Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: > > Is Izpack: > > * able to install binaries for the right platform (os + hardware > > architecture)? > > Yes. > > > * Java 1.2 compatible > > Yes of course > > > * able to run from the command line? > > Yes, and can run from command line detecting which is the underlaying os. > I have attached an old version of one of my installer, I can't find the > last one, but it is like this one. In this you will see how to detect > the OS and architecture and install binaries for that plataform. > Regards, > Manuel You are right. IzPack looks like the right tool for this job. As far as I can see there is no commandline support but I'll get over it. ;) I'll link my detection system to the IzPack installation procedure and publish the results. From tjarvi at qbang.org Fri Jul 7 19:00:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 7 Jul 2006 19:00:56 -0600 (MDT) Subject: [Rxtx] Controlling Individual Signals DTR and RTS In-Reply-To: References: Message-ID: On Thu, 6 Jul 2006, Trent Jarvi wrote: > On Thu, 29 Jun 2006, Chris Pine wrote: > >> Dear Moussa Ba, >> I hope I am not being too forward, but we are having the exact same >> issue with needing to control DTR from RXTX in Linux. Did you ever have any >> luck figuring it out? >> >> Thank you very much for your time, >> > > Hi Chris > > Are you using an unusual serial port? It could be that the port does not > support DTR/RTS. Especially if its an inexpensive USB->Serial dongle. > > I'll double check Linux tomorrow but I'm fairly sure it works. I have > verified windows after a questions like yours. Some multiport cards and > usb dongles do not support everything. > I double checked that DTR and RTS are working. The system was a 64 bit opteron with an inexexpensive dual port serial card. Suse 9.3 rxtx 2.1-7 (final). I just used the demo SerialBlackBox that used to come with commapi modified to use rxtx 2.1. The serial card was a NetMos PCI NM9835CV with a 16C550 high speed UART dual port. These are not expensive cards. Everything worked fine. I could see the voltage flipping back and forth on the scope for both DTR(pin 4) and CTS(pin 7). You are not the first to report problems. But everytime I try to reproduce the problem, it appears to work. I suspect it is either hardware or kernel driver related and not specific to RXTX. Note that playing with RTS and DTR with hardware flow control enabled does not make sense as those pins are used for the flow control. I've not looked at many USB serial dongles but I have noticed that some are not as good as others. I think one lacked DTR/CTS support. Another one appeared to be fully functional. The one I noticed no issues with was the Hawking Tech HUC232S on windows. I did not test it on Mac OS X or Linux. The same variability can be observed with multiport serial cards. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jul 7 19:15:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 7 Jul 2006 19:15:06 -0600 (MDT) Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: References: <44AC7902.8070407@adventnet.com> Message-ID: On Fri, 7 Jul 2006, Brian Schlining wrote: > Also, for some command/response applications that I've tried with RXTX, I > find that if I write to the serialport and then immediately try to read from > it I get byte arrays filled with zeros, no matter what I set the > recieveTimeout to (this has occurred on both Mac OS X and Windows). The > workaround that I found was to very briefly put the I/O thread to sleep, like > so: > > // DO set up and get I/O streams > //in = serialPort.getInputStream(); > //out = serialPort.getOutputStream(); > > out.write(someByteArray); > try { > Thread.sleep(10); > catch (InterruptedException e) { > // handle exception > } > in.read(anotherByteArray); > > Note: I've never had to put the thread to sleep using Java comm, only with > RXTX. Anyone know why this might be? Hi Brian Interesting. Is this something that can be reproduced with a loopback connection or something commonly available? I was unaware of this behavior. Is it restricted to something that quickly opens, writes, reads and closes the port by chance? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jul 7 19:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 7 Jul 2006 19:39:37 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607080055.04501.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > Is the gnu.io namespace still necessary? I couldn't find the problem. Hi Pascal CommAPI is a little different in that it was grandfathered into the javax namespace with its own license at the time. It is my understanding that if CommAPI went through the JSR process, anyone would _clearly_ be able to implement a javax.comm package and RXTX would then be one of the first to do so. I believe Doug has expressed some interest in RXTX trying to work with the JSR process. Besides the license questions, there is the fact that RXTX has extensions to CommAPI which could cause confusion in the namespace. Not being a lawyer and *really* not liking to talk to lawyers in my free time, it is better to be safe than sorry. The lawyers tend to come in wolf packs when they do come. There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay there as long as we are just geeks trying to figure out if a license does or does not allow us to implement in the javax.comm namespace. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Sat Jul 8 05:30:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 13:30:24 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: <200607081330.24381.pascal@quies.net> Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > > Is the gnu.io namespace still necessary? I couldn't find the problem. > > Hi Pascal > > CommAPI is a little different in that it was grandfathered into the javax > namespace with its own license at the time. > > It is my understanding that if CommAPI went through the JSR process, > anyone would _clearly_ be able to implement a javax.comm package and RXTX > would then be one of the first to do so. I believe Doug has expressed > some interest in RXTX trying to work with the JSR process. > > Besides the license questions, there is the fact that RXTX has extensions > to CommAPI which could cause confusion in the namespace. Not being a > lawyer and *really* not liking to talk to lawyers in my free time, it is > better to be safe than sorry. The lawyers tend to come in wolf packs > when they do come. > > There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay > there as long as we are just geeks trying to figure out if a license does > or does not allow us to implement in the javax.comm namespace. Nicely said. :) The whole point of namespaces is to create a universal registry of, in this case, classes. This gnu.io namespace is very inconvenient. We feel the same way about lawyers. However I'd like to go into the details of the license (see attachment) if you don't mind? The first license does not apply since RXTX does not use the software. The second one at point 3 specifies our options. > 3. You may not modify the Java Platform Interface ("JPI", identified as > classes contained within the "java" package or any subpackages of the > "java" package), by creating additional classes within the JPI or otherwise > causing the addition to or modification of the classes in the JPI. RXTX is a extension. > In the event that you create an additional class and associated API(s) > which (i) extends the functionality of the Java platform, and (ii) is > exposed to third party software developers for the purpose of developing > additional software which invokes such additional API, you must promptly > publish broadly an accurate specification for such API for free use by all > developers. That's the way we operate. :) > You may not create, or authorize your licensees to create additional > classes, interfaces, or subpackages that are in any way identified as > "java", "javax", "sun" or similar convention as specified by Sun in any > naming convention designation. They don't want additional components in the Communication API since they don't want a mess in theire namespace. So we *can* use javax.comm for the core: javax.comm.CommDriver javax.comm.CommPort javax.comm.CommPortIdentifier javax.comm.CommPortOwnershipListener javax.comm.NoSuchPortException javax.comm.PortInUseException javax.comm.UnsupportedCommOperationException ...and for the default hardware support: javax.comm.SerialPort javax.comm.SerialPortEvent javax.comm.SerialPortEventListener javax.comm.ParralelPort javax.comm.ParralelPortEvent javax.comm.ParralelPortEventListener ...but RXTX aditional hardware support has to go somewhere else like: org.rxtx.RS485Port org.rxtx.RS485PortEvent org.rxtx.RS485PortEventListener org.rxtx.I2CPort org.rxtx.I2CPortEvent org.rxtx.I2CPortEventListener Right? -------------- next part -------------- Sun Microsystems, Inc. Binary Code License Agreement READ THE TERMS OF THIS AGREEMENT AND ANY PROVIDED SUPPLEMENTAL LICENSE TERMS (COLLECTIVELY "AGREEMENT") CAREFULLY BEFORE OPENING THE SOFTWARE MEDIA PACKAGE. BY OPENING THE SOFTWARE MEDIA PACKAGE, YOU AGREE TO THE TERMS OF THIS AGREEMENT. IF YOU ARE ACCESSING THE SOFTWARE ELECTRONICALLY, INDICATE YOUR ACCEPTANCE OF THESE TERMS BY SELECTING THE "ACCEPT" BUTTON AT THE END OF THIS AGREEMENT. IF YOU DO NOT AGREE TO ALL THESE TERMS, PROMPTLY RETURN THE UNUSED SOFTWARE TO YOUR PLACE OF PURCHASE FOR A REFUND OR, IF THE SOFTWARE IS ACCESSED ELECTRONICALLY, SELECT THE "DECLINE" BUTTON AT THE END OF THIS AGREEMENT. 1. LICENSE TO USE. Sun grants you a non-exclusive and non-transferable license for the internal use only of the accompanying software and documentation and any error corrections provided by Sun (collectively "Software"), by the number of users and the class of computer hardware for which the corresponding fee has been paid. 2. RESTRICTIONS. Software is confidential and copyrighted. Title to Software and all associated intellectual property rights is retained by Sun and/or its licensors. Except as specifically authorized in any Supplemental License Terms, you may not make copies of Software, other than a single copy of Software for archival purposes. Unless enforcement is prohibited by applicable law, you may not modify, decompile, or reverse engineer Software. Licensee acknowledges that Licensed Software is not designed or intended for use in the design, construction, operation or maintenance of any nuclear facility. Sun Microsystems, Inc. disclaims any express or implied warranty of fitness for such uses. No right, title or interest in or to any trademark, service mark, logo or trade name of Sun or its licensors is granted under this Agreement. 3. LIMITED WARRANTY. Sun warrants to you that for a period of ninety (90) days from the date of purchase, as evidenced by a copy of the receipt, the media on which Software is furnished (if any) will be free of defects in materials and workmanship under normal use. Except for the foregoing, Software is provided "AS IS". Your exclusive remedy and Sun's entire liability under this limited warranty will be at Sun's option to replace Software media or refund the fee paid for Software. 4. DISCLAIMER OF WARRANTY. UNLESS SPECIFIED IN THIS AGREEMENT, ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT THESE DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. 5.LIMITATION OF LIABILITY. TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF OR RELATED TO THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. In no event will Sun's liability to you, whether in contract, tort (including negligence), or otherwise, exceed the amount paid by you for Software under this Agreement. The foregoing limitations will apply even if the above stated warranty fails of its essential purpose. 6. TERMINATION. This Agreement is effective until terminated. You may terminate this Agreement at any time by destroying all copies of Software. This Agreement will terminate immediately without notice from Sun if you fail to comply with any provision of this Agreement. Upon Termination, you must destroy all copies of Software. 7. EXPORT REGULATIONS. All Software and technical data delivered under this Agreement are subject to US export control laws and may be subject to export or import regulations in other countries. You agree to comply strictly with all such laws and regulations and acknowledge that you have the responsibility to obtain such licenses to export, re-export, or import as may be required after delivery to you. 8. U.S. GOVERNMENT RESTRICTED RIGHTS. If Software is being acquired by or on behalf of the U.S. Government or by a U.S. Government prime contractor or subcontractor (at any tier), then the Government's rights in Software and accompanying documentation will be only as set forth in this Agreement; this is in accordance with 48 CFR 227.7201 through 227.7202-4 (for Department of Defense (DOD) acquisitions) and with 48 CFR 2.101 and 12.212 (for non-DOD acquisitions). 9. GOVERNING LAW. Any action related to this Agreement will be governed by California law and controlling U.S. federal law. No choice of law rules of any jurisdiction will apply. 10, SEVERABILITY. If any provision of this Agreement is held to be unenforceable, this Agreement will remain in effect with the provision omitted, unless omission would frustrate the intent of the parties, in which case this Agreement will immediately terminate. 11. INTEGRATION This Agreement is the entire agreement between you and Sun relating to its subject matter. It supersedes all prior or contemporaneous oral or written communications, proposals, representations and warranties and prevails over any conflicting or additional terms of any quote, order, acknowledgment, or other communication between the parties relating to its subject matter during the term of this Agreement. No modification of this Agreement will be binding, unless in writing and signed by an authorized representative of each party. JAVA OPTIONAL PACKAGE JAVAX.COMM 3.0 SUPPLEMENTAL LICENSE TERMS These supplemental license terms ("Supplemental Terms") add to or modify the terms of the Binary Code License Agreement (collectively, the "Agreement"). Capitalized terms not defined in these Supplemental Terms shall have the same meanings ascribed to them in the Agreement. These Supplemental Terms shall supersede any inconsistent or conflicting terms in the Agreement, or in any license contained within the Software. 1. Software Internal Use and Development License Grant. Subject to the terms and conditions of this Agreement, including, but not limited to Section 3 (Java(TM) Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce internally and use internally the binary form of the Software, complete and unmodified, for the sole purpose of designing, developing and testing your Java applets and applications ("Programs"). 2. License to Distribute Software. In addition to the license granted in Section 1 (Software Internal Use and Development License Grant) of these Supplemental Terms, subject to the terms and conditions of this Agreement, including but not limited to, Section 3 (Java Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce and distribute the Software in binary code form only, provided that you (i) distribute the Software complete and unmodified and only bundled as part of your Programs, (ii) do not distribute additional software intended to replace any component(s) of the Software, (iii) do not remove or alter any proprietary legends or notices contained in the Software, (iv) only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (v) agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software. 3. Java Technology Restrictions. You may not modify the Java Platform Interface ("JPI", identified as classes contained within the "java" package or any subpackages of the "java" package), by creating additional classes within the JPI or otherwise causing the addition to or modification of the classes in the JPI. In the event that you create an additional class and associated API(s) which (i) extends the functionality of the Java platform, and (ii) is exposed to third party software developers for the purpose of developing additional software which invokes such additional API, you must promptly publish broadly an accurate specification for such API for free use by all developers. You may not create, or authorize your licensees to create additional classes, interfaces, or subpackages that are in any way identified as "java", "javax", "sun" or similar convention as specified by Sun in any naming convention designation. 4. Trademarks and Logos. You acknowledge and agree as between you and Sun that Sun owns the SUN, SOLARIS, JAVA, JINI, FORTE, and iPLANET trademarks and all SUN, SOLARIS, JAVA, JINI, FORTE, and iPLANET-related trademarks, service marks, logos and other brand designations ("Sun Marks"), and you agree to comply with the Sun Trademark and Logo Usage Requirements currently located at http://www.sun.com/policies/trademarks. Any use you make of the Sun Marks inures to Sun's benefit. 5. Source Code. Software may contain source code that is provided solely for reference purposes pursuant to the terms of this Agreement. Source code may not be redistributed unless expressly provided for in this Agreement. 6. Termination for Infringement. Either party may terminate this Agreement immediately should any Software become, or in either party's opinion be likely to become, the subject of a claim of infringement of any intellectual property right. For inquiries please contact: Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, California 95054. (LFI#143217/Form ID#011801) From tjarvi at qbang.org Sat Jul 8 10:12:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 10:12:55 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607081330.24381.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <200607081330.24381.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> Is the gnu.io namespace still necessary? I couldn't find the problem. >> >> Hi Pascal >> >> CommAPI is a little different in that it was grandfathered into the javax >> namespace with its own license at the time. >> >> It is my understanding that if CommAPI went through the JSR process, >> anyone would _clearly_ be able to implement a javax.comm package and RXTX >> would then be one of the first to do so. I believe Doug has expressed >> some interest in RXTX trying to work with the JSR process. >> >> Besides the license questions, there is the fact that RXTX has extensions >> to CommAPI which could cause confusion in the namespace. Not being a >> lawyer and *really* not liking to talk to lawyers in my free time, it is >> better to be safe than sorry. The lawyers tend to come in wolf packs >> when they do come. >> >> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay >> there as long as we are just geeks trying to figure out if a license does >> or does not allow us to implement in the javax.comm namespace. > > Nicely said. :) > > The whole point of namespaces is to create a universal registry of, in this > case, classes. This gnu.io namespace is very inconvenient. > > We feel the same way about lawyers. However I'd like to go into the details of > the license (see attachment) if you don't mind? > > The first license does not apply since RXTX does not use the software. The > second one at point 3 specifies our options. > >> 3. You may not modify the Java Platform Interface ("JPI", identified as >> classes contained within the "java" package or any subpackages of the >> "java" package), by creating additional classes within the JPI or otherwise >> causing the addition to or modification of the classes in the JPI. > > RXTX is a extension. > >> In the event that you create an additional class and associated API(s) >> which (i) extends the functionality of the Java platform, and (ii) is >> exposed to third party software developers for the purpose of developing >> additional software which invokes such additional API, you must promptly >> publish broadly an accurate specification for such API for free use by all >> developers. > > That's the way we operate. :) > >> You may not create, or authorize your licensees to create additional >> classes, interfaces, or subpackages that are in any way identified as >> "java", "javax", "sun" or similar convention as specified by Sun in any >> naming convention designation. > > They don't want additional components in the Communication API since they > don't want a mess in theire namespace. > > So we *can* use javax.comm for the core: > javax.comm.CommDriver > javax.comm.CommPort > javax.comm.CommPortIdentifier > javax.comm.CommPortOwnershipListener > javax.comm.NoSuchPortException > javax.comm.PortInUseException > javax.comm.UnsupportedCommOperationException > > ...and for the default hardware support: > javax.comm.SerialPort > javax.comm.SerialPortEvent > javax.comm.SerialPortEventListener > javax.comm.ParralelPort > javax.comm.ParralelPortEvent > javax.comm.ParralelPortEventListener > > ...but RXTX aditional hardware support has to go somewhere else like: > org.rxtx.RS485Port > org.rxtx.RS485PortEvent > org.rxtx.RS485PortEventListener > org.rxtx.I2CPort > org.rxtx.I2CPortEvent > org.rxtx.I2CPortEventListener > > Right? > I do not disagree with anything you said :) RXTX and Sun agree with each other almost completely but not exactly. I think there are three uses of CommAPI and Sun is mainly interested in one. 1) Point of sale. This is the direction Sun is going with limited resources thats causing some problems. They would obviously cause fewer problems with more resources just like rxtx would work with them better with more resources. I'm sure if you talk to people in this area they are very optimitsic about what CommAPI could be. 2) Instrument Control. This is my area of interest as its my job too. I'm still formulating opinions here and it is far to early to say much but I'm very optimistic about what CommAPI could be. 3) Hobby and other hardware control. Circuts, road signs, rxtx in cell phones controlling TVs, you name it. People asking about palm, wince, embeded hardware. This is why I thought it was important to open source rxtx in the beginning and still find it my primary motive to read rxtx email every morning and evening. The optimism here is abundant and self explained. Nothing would make me happier than having someone get a working demo of controlling LEDs with parallel ports that could be used by people learning. So everyone agrees with almost everything. Nobody is looking for conflicts. But these various interests have not been _clearly_ formalized. Licenses are tools for manipulating behavior. Until the above is clearly in line with each other, the license will be a tool for lawyers to cause problems for people working for free. This is why I support a move to go through the JSR process and formalize the relationship. My concern is not really Sun comming after RXTX with Lawyers. I have a great deal of respect for Sun going back to their sunsite project. My concern is how lawyers think. They look at the intent which is not all in line. Then I get what feels like insane conference calls that cost companies over $2000 an hour which pisses me off to no end. Companies paying lawyers to take time from developers for free. This really does happen when a fortune 50 company developer asks their legal department if they can use rxtx. I don't have enough bullets for that. The way you avoid this is formalize everones intent so lawyers don't make conference call meetings in outlook. I want to put those lawyers out of work and if it takes a little discomfort, thats perfectly fine. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Sat Jul 8 11:44:40 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 19:44:40 +0200 Subject: [Rxtx] Fwd: Re: Java installer Message-ID: <200607081944.41123.pascal@quies.net> For some reason the first mail failed... ---------- Doorgestuurd bericht ---------- Subject: Re: [Rxtx] Java installer Date: zaterdag 8 juli 2006 17:18 From: "Pascal S. de Kloe" To: RXTX Developers and Users Hello Manuel, In case of a JDK the installation goes into the "jre" directory. I can't find a simple way to get this information into a variable of IzPack. (see attachment) Do you have a idea? Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: > Pascal: > I will be a little short with my answer but very informative :) > > > Could you publish the IzPack configuration and the binaries? That would > > be very helpful since the current installation procedure is > > somewhat "unprofessional". ;) > > > > IzPack is great but this API is a little more than that. It allows java > > applications who require the extension to detect available versions and > > install RXTX on the fly if needed. > > > > Is Izpack: > > * able to install binaries for the right platform (os + hardware > > architecture)? > > Yes. > > > * Java 1.2 compatible > > Yes of course > > > * able to run from the command line? > > Yes, and can run from command line detecting which is the underlaying os. > I have attached an old version of one of my installer, I can't find the > last one, but it is like this one. In this you will see how to detect > the OS and architecture and install binaries for that plataform. > Regards, > Manuel ------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: izpack.xml Type: text/xml Size: 1401 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060708/413315d2/izpack-0353.xml From joachim at buechse.de Sat Jul 8 10:02:18 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 8 Jul 2006 18:02:18 +0200 Subject: [Rxtx] Java installer In-Reply-To: <200607080055.04501.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: <7D4FA261-44FA-4A6E-8EB9-7A7B0116BB2C@buechse.de> Hello Pascal, as soon as the 2.1.8 version is "released" I'll happily provide you with a precompiled library for Mac OSX. The currently tagged version is 2.17 which has a non standard implementation for OSX. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 08.07.2006, at 00:55, Pascal S. de Kloe wrote: > > I need as many pre-compiled binaries as possible. > Could you help me with that? > > The detection system already works. > > Thanks again, > > Pascal > > > PS > Is the gnu.io namespace still necessary? I couldn't find the problem. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 8 09:18:09 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 17:18:09 +0200 Subject: [Rxtx] Java installer In-Reply-To: <44AEE87F.60202@gmail.com> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <44AEE87F.60202@gmail.com> Message-ID: <200607081718.09605.pascal@quies.net> Hello Manuel, In case of a JDK the installation goes into the "jre" directory. I can't find a simple way to get this information into a variable of IzPack. (see attachment) Do you have a idea? Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: > Pascal: > I will be a little short with my answer but very informative :) > > > Could you publish the IzPack configuration and the binaries? That would > > be very helpful since the current installation procedure is > > somewhat "unprofessional". ;) > > > > IzPack is great but this API is a little more than that. It allows java > > applications who require the extension to detect available versions and > > install RXTX on the fly if needed. > > > > Is Izpack: > > * able to install binaries for the right platform (os + hardware > > architecture)? > > Yes. > > > * Java 1.2 compatible > > Yes of course > > > * able to run from the command line? > > Yes, and can run from command line detecting which is the underlaying os. > I have attached an old version of one of my installer, I can't find the > last one, but it is like this one. In this you will see how to detect > the OS and architecture and install binaries for that plataform. > Regards, > Manuel -------------- next part -------------- A non-text attachment was scrubbed... Name: izpack.xml Type: text/xml Size: 1401 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060708/fa6f5a81/izpack-0353.xml From naranjo.manuel at gmail.com Sat Jul 8 12:52:23 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 15:52:23 -0300 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607081944.41123.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> Message-ID: <44AFFEE7.3090306@gmail.com> Pascal: I can't get exactly your point, but my installer was to avoid modifying the users JDK or JRE. Download this app made by me, and you will get my point: http://www.aircable.net/downloads/AIRcable_Configuration_Utility_v0.2_ALPHA_1.zip, this app bundles RXTX library inside the zip file, and does not need RXTX installed on the Users system. Manuel > For some reason the first mail failed... > > > ---------- Doorgestuurd bericht ---------- > > Subject: Re: [Rxtx] Java installer > Date: zaterdag 8 juli 2006 17:18 > From: "Pascal S. de Kloe" > To: RXTX Developers and Users > > Hello Manuel, > > In case of a JDK the installation goes into the "jre" directory. > I can't find a simple way to get this information into a variable of IzPack. > (see attachment) > > Do you have a idea? > > Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: >> Pascal: >> I will be a little short with my answer but very informative :) >> >>> Could you publish the IzPack configuration and the binaries? That would >>> be very helpful since the current installation procedure is >>> somewhat "unprofessional". ;) >>> >>> IzPack is great but this API is a little more than that. It allows java >>> applications who require the extension to detect available versions and >>> install RXTX on the fly if needed. >>> >>> Is Izpack: >>> * able to install binaries for the right platform (os + hardware >>> architecture)? >> Yes. >> >>> * Java 1.2 compatible >> Yes of course >> >>> * able to run from the command line? >> Yes, and can run from command line detecting which is the underlaying os. >> I have attached an old version of one of my installer, I can't find the >> last one, but it is like this one. In this you will see how to detect >> the OS and architecture and install binaries for that plataform. >> Regards, >> Manuel > > ------------------------------------------------------- > > > ------------------------------------------------------------------------ > > > > > RXTX > 2... > http://www.rxtx.org/ > 1.2 > uninstallRXTX > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Jul 8 12:53:32 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 15:53:32 -0300 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607081944.41123.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> Message-ID: <44AFFF2C.8090005@gmail.com> Even more, the variable ${CURRENT_JRE} referees to the actuall JVM as far as I know, so you will have no difference in installing towards a JDK. > For some reason the first mail failed... > > > ---------- Doorgestuurd bericht ---------- > > Subject: Re: [Rxtx] Java installer > Date: zaterdag 8 juli 2006 17:18 > From: "Pascal S. de Kloe" > To: RXTX Developers and Users > > Hello Manuel, > > In case of a JDK the installation goes into the "jre" directory. > I can't find a simple way to get this information into a variable of IzPack. > (see attachment) > > Do you have a idea? > > Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: >> Pascal: >> I will be a little short with my answer but very informative :) >> >>> Could you publish the IzPack configuration and the binaries? That would >>> be very helpful since the current installation procedure is >>> somewhat "unprofessional". ;) >>> >>> IzPack is great but this API is a little more than that. It allows java >>> applications who require the extension to detect available versions and >>> install RXTX on the fly if needed. >>> >>> Is Izpack: >>> * able to install binaries for the right platform (os + hardware >>> architecture)? >> Yes. >> >>> * Java 1.2 compatible >> Yes of course >> >>> * able to run from the command line? >> Yes, and can run from command line detecting which is the underlaying os. >> I have attached an old version of one of my installer, I can't find the >> last one, but it is like this one. In this you will see how to detect >> the OS and architecture and install binaries for that plataform. >> Regards, >> Manuel > > ------------------------------------------------------- > > > ------------------------------------------------------------------------ > > > > > RXTX > 2... > http://www.rxtx.org/ > 1.2 > uninstallRXTX > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Jul 8 12:54:22 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 15:54:22 -0300 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <200607081330.24381.pascal@quies.net> Message-ID: <44AFFF5E.50603@gmail.com> > > I do not disagree with anything you said :) > > RXTX and Sun agree with each other almost completely but not exactly. I > think there are three uses of CommAPI and Sun is mainly interested in one. > > 1) Point of sale. This is the direction Sun is going with limited > resources thats causing some problems. They would obviously cause fewer > problems with more resources just like rxtx would work with them better > with more resources. I'm sure if you talk to people in this area they are > very optimitsic about what CommAPI could be. > > 2) Instrument Control. This is my area of interest as its my job too. I'm > still formulating opinions here and it is far to early to say much but I'm > very optimistic about what CommAPI could be. > > 3) Hobby and other hardware control. Circuts, road signs, rxtx in cell > phones controlling TVs, you name it. People asking about palm, wince, > embeded hardware. This is why I thought it was important to open source > rxtx in the beginning and still find it my primary motive to read rxtx > email every morning and evening. The optimism here is abundant and self > explained. Nothing would make me happier than having someone get a > working demo of controlling LEDs with parallel ports that could be used by > people learning. > > So everyone agrees with almost everything. Nobody is looking for > conflicts. But these various interests have not been _clearly_ > formalized. Licenses are tools for manipulating behavior. Until the > above is clearly in line with each other, the license will be a tool for > lawyers to cause problems for people working for free. This is why I > support a move to go through the JSR process and formalize the > relationship. > > My concern is not really Sun comming after RXTX with Lawyers. I have a > great deal of respect for Sun going back to their sunsite project. My > concern is how lawyers think. They look at the intent which is not all in > line. Then I get what feels like insane conference calls that cost > companies over $2000 an hour which pisses me off to no end. Companies > paying lawyers to take time from developers for free. This really does > happen when a fortune 50 company developer asks their legal department if > they can use rxtx. I don't have enough bullets for that. > > The way you avoid this is formalize everones intent so lawyers don't > make conference call meetings in outlook. I want to put those lawyers out > of work and if it takes a little discomfort, thats perfectly fine. > > -- > Trent Jarvi > tjarvi at qbang.org > > Trent: GREAT MAIL, I hate lawyers too. From naranjo.manuel at gmail.com Sat Jul 8 07:52:47 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 10:52:47 -0300 Subject: [Rxtx] Java installer In-Reply-To: <200607080235.29486.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <44AEE87F.60202@gmail.com> <200607080235.29486.pascal@quies.net> Message-ID: <44AFB8AF.50403@gmail.com> > > You are right. IzPack looks like the right tool for this job. > > As far as I can see there is no commandline support but I'll get over it. ;) Actually there is a way to execute native app in the Underlaying OS. Check out the JavaDOC and all the documentation given by them. If you need to also generate warper around the jar files, check this projects out: http://launch4j.sourceforge.net and http://jsmooth.sourceforge.net/ I have been able to make and exe with jsmooth that does not need to have RXTX installed if you want I can send the source of it. But it is simple. Do not put the jar inside the exe file, and add to the classpath relative paths to rxtx jar and then your jar file, and then add to the JVM command line (I can't remeber the actual name of it :P) -Djava.library.path=bin\ (Or were ever you installed the binary package). I have tryied doing the same with Java Comm from Sun but it actually is imposible, the main difference to me that make me move to RXTX, was that there is no need to have the javax.comm.properties file, which gave me lot of headaches. Regards, Manuel. From naranjo.manuel at gmail.com Sat Jul 8 08:03:58 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 11:03:58 -0300 Subject: [Rxtx] License question. Message-ID: <44AFBB4E.70808@gmail.com> Hi: I have a question, haven't you ever thought about changing RXTX license from GNU/GPL to a more open license like Apache v2 or BSD like?. As far as I understand if I make an application that uses RXTX libraries, I must release my app under the GNU/GPL. I have no problem with that in fact I'm an Open Source user and defender. The fact is that in same cases the applications made by one, could get into hands of a company that needs to release a Closed Source app. I understand that using GNU/GPL do not give you the power to do this, but a more "open" license like Apache does. By "open" I mean that the license respects the Open Source license, but also lives the user the opportunity to use the library in closed source programs. I have seen that there is an exception to the license that applies to RXTX v2.0-5 and above, the only problem with it is that Java Comm Api (the jar file) needs the file javax.comm.properties installed correctly, which in lot of cases is a headache. RXTX jar does not need this, actually I think that RXTX is more user friendly than Java Comm. Maybe there has been a discussion like this before, but I just wanted to ask, and to get an answer that is adequate to our time. Regards, Manuel From pascal at quies.net Sat Jul 8 14:03:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:03:13 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <44AFFF2C.8090005@gmail.com> References: <200607081944.41123.pascal@quies.net> <44AFFF2C.8090005@gmail.com> Message-ID: <200607082203.13696.pascal@quies.net> Op zaterdag 8 juli 2006 20:53, schreef Manuel Naranjo: > Even more, the variable ${CURRENT_JRE} referees to the actuall JVM as > far as I know, so you will have no difference in installing towards a JDK. As far as the installation instructions go the location of the libraries is the following. Windows * JRE: $JAVA_HOME/bin/ * JDK: $JAVA_HOME/jre/bin/ UNIX * JRE: $JAVA_HOME/lib/ * JRE: $JAVA_HOME/jre/lib/ From pascal at quies.net Sat Jul 8 14:04:50 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:04:50 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <44AFFEE7.3090306@gmail.com> References: <200607081944.41123.pascal@quies.net> <44AFFEE7.3090306@gmail.com> Message-ID: <200607082204.50712.pascal@quies.net> Op zaterdag 8 juli 2006 20:52, schreef Manuel Naranjo: > Pascal: > I can't get exactly your point, but my installer was to avoid modifying > the users JDK or JRE. Download this app made by me, and you will get my > point: > http://www.aircable.net/downloads/AIRcable_Configuration_Utility_v0.2_ALPHA >_1.zip, this app bundles RXTX library inside the zip file, and does not need > RXTX installed on the Users system. > Manuel I didn't get the point indeed and I still don't get it. :$ The installation instructions state that RXTX.jar must be in the classpath and the libraries should go as my previous mail stated. Do you have another way? I don't have Windows so i can't run that EXE. From pascal at quies.net Sat Jul 8 14:05:40 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:05:40 +0200 Subject: [Rxtx] Java installer In-Reply-To: <7D4FA261-44FA-4A6E-8EB9-7A7B0116BB2C@buechse.de> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <7D4FA261-44FA-4A6E-8EB9-7A7B0116BB2C@buechse.de> Message-ID: <200607082205.40527.pascal@quies.net> Op zaterdag 8 juli 2006 18:02, schreef Joachim Buechse: > as soon as the 2.1.8 version is "released" I'll happily provide you ? > with a precompiled library for Mac OSX. The currently tagged version ? > is 2.17 which has a non standard implementation for OSX. Perfect! :) Do you have a idea when that will be? Like this month? From pascal at quies.net Sat Jul 8 14:14:44 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:14:44 +0200 Subject: [Rxtx] Java installer In-Reply-To: <44AFB8AF.50403@gmail.com> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080235.29486.pascal@quies.net> <44AFB8AF.50403@gmail.com> Message-ID: <200607082214.45115.pascal@quies.net> Op zaterdag 8 juli 2006 15:52, schreef Manuel Naranjo: > > You are right. IzPack looks like the right tool for this job. > > > > As far as I can see there is no commandline support but I'll get over it. > > ;) > > Actually there is a way to execute native app in the Underlaying OS. > Check out the JavaDOC and all the documentation given by them. > If you need to also generate warper around the jar files, check this > projects out: > http://launch4j.sourceforge.net and http://jsmooth.sourceforge.net/ > I have been able to make and exe with jsmooth that does not need to > have RXTX installed if you want I can send the source of it. But it is > simple. > Do not put the jar inside the exe file, and add to the classpath > relative paths to rxtx jar and then your jar file, and then add to the > JVM command line (I can't remeber the actual name of it :P) > -Djava.library.path=bin\ (Or were ever you installed the binary package). > I have tryied doing the same with Java Comm from Sun but it actually is > imposible, the main difference to me that make me move to RXTX, was that > there is no need to have the javax.comm.properties file, which gave me > lot of headaches. > Regards, > Manuel. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Those are verry interresting and impressive tools for Windows. However, I wanted (and still do) a universal installer for all supported platforms as a single JAR. IzPack seemed quite suitable but it is limited and not well written so I'me still searching... Thanks for the help though. :) From pascal at quies.net Sat Jul 8 14:19:59 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:19:59 +0200 Subject: [Rxtx] License question. In-Reply-To: <44AFBB4E.70808@gmail.com> References: <44AFBB4E.70808@gmail.com> Message-ID: <200607082219.59514.pascal@quies.net> I thought of the same thing. The modified BSD license would certainly make it more eazy and acceptable for Sun to include RXTX in theire products. Unfortunately in general people who chose GPL don't like other licenses. ;) Op zaterdag 8 juli 2006 16:03, schreef Manuel Naranjo: > Hi: > I have a question, haven't you ever thought about changing RXTX license > from GNU/GPL to a more open license like Apache v2 or BSD like?. > As far as I understand if I make an application that uses RXTX > libraries, I must release my app under the GNU/GPL. I have no problem > with that in fact I'm an Open Source user and defender. > The fact is that in same cases the applications made by one, could get > into hands of a company that needs to release a Closed Source app. I > understand that using GNU/GPL do not give you the power to do this, but > a more "open" license like Apache does. By "open" I mean that the > license respects the Open Source license, but also lives the user the > opportunity to use the library in closed source programs. > I have seen that there is an exception to the license that applies to > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > (the jar file) needs the file javax.comm.properties installed correctly, > which in lot of cases is a headache. RXTX jar does not need this, > actually I think that RXTX is more user friendly than Java Comm. > Maybe there has been a discussion like this before, but I just wanted to > ask, and to get an answer that is adequate to our time. > Regards, > Manuel > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jul 8 15:30:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 15:30:31 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <44AFBB4E.70808@gmail.com> References: <44AFBB4E.70808@gmail.com> Message-ID: On Sat, 8 Jul 2006, Manuel Naranjo wrote: > Hi: > I have a question, haven't you ever thought about changing RXTX license > from GNU/GPL to a more open license like Apache v2 or BSD like?. > As far as I understand if I make an application that uses RXTX > libraries, I must release my app under the GNU/GPL. I have no problem > with that in fact I'm an Open Source user and defender. > The fact is that in same cases the applications made by one, could get > into hands of a company that needs to release a Closed Source app. I > understand that using GNU/GPL do not give you the power to do this, but > a more "open" license like Apache does. By "open" I mean that the > license respects the Open Source license, but also lives the user the > opportunity to use the library in closed source programs. > I have seen that there is an exception to the license that applies to > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > (the jar file) needs the file javax.comm.properties installed correctly, > which in lot of cases is a headache. RXTX jar does not need this, > actually I think that RXTX is more user friendly than Java Comm. > Maybe there has been a discussion like this before, but I just wanted to > ask, and to get an answer that is adequate to our time. > Regards, > Manuel Hi Manuel As one of the primary copyright 'owners' and a representative of all the people who have worked on RXTX I feel very compelled to comment on this. I often observe this misconception and just ignore it. RXTX is very commercial friendly both in open and closed source. The license is LGPL not GPL. This allows for linking to any application you like without sharing yoru application code. It is not unlike Apache or BSD in that sense. I like the BSD license but not in this case. The difference is you can not keep your changes to rxtx itself if your product is distributed in practice. To me this makes no sense and is a basic flaw in BSD licensing for libraries. I have _no_ intentions of "competing" with various incarnations of RXTX. If you use RXTX in your commercial application, I hope for two things. First I want you to do well for using rxtx even if you somehow compete with me in the commercial world. Second I want to see changes to RXTX come back to RXTX so we all do well for choosing RXTX. This is not possible with the BSD, MIT ... licenses. They result in multiple forks from the code and this is used to disrupt 'standards' by companies you would recognize (I no longer mention any company when saying bad things without fair notice). Your code is your code. Thats how the LGPL works. But don't take RXTX and fork it where I or anyone else that has worked on RXTX can see it. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Sat Jul 8 16:06:17 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 00:06:17 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> Message-ID: <200607090006.18197.pascal@quies.net> Op zaterdag 8 juli 2006 23:30, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Manuel Naranjo wrote: > > Hi: > > I have a question, haven't you ever thought about changing RXTX license > > from GNU/GPL to a more open license like Apache v2 or BSD like?. > > As far as I understand if I make an application that uses RXTX > > libraries, I must release my app under the GNU/GPL. I have no problem > > with that in fact I'm an Open Source user and defender. > > The fact is that in same cases the applications made by one, could get > > into hands of a company that needs to release a Closed Source app. I > > understand that using GNU/GPL do not give you the power to do this, but > > a more "open" license like Apache does. By "open" I mean that the > > license respects the Open Source license, but also lives the user the > > opportunity to use the library in closed source programs. > > I have seen that there is an exception to the license that applies to > > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > > (the jar file) needs the file javax.comm.properties installed correctly, > > which in lot of cases is a headache. RXTX jar does not need this, > > actually I think that RXTX is more user friendly than Java Comm. > > Maybe there has been a discussion like this before, but I just wanted to > > ask, and to get an answer that is adequate to our time. > > Regards, > > Manuel > > Hi Manuel > > As one of the primary copyright 'owners' and a representative of all the > people who have worked on RXTX I feel very compelled to comment on this. > I often observe this misconception and just ignore it. > > RXTX is very commercial friendly both in open and closed source. The > license is LGPL not GPL. This allows for linking to any application you > like without sharing yoru application code. It is not unlike Apache or > BSD in that sense. I like the BSD license but not in this case. > > The difference is you can not keep your changes to rxtx itself if your > product is distributed in practice. To me this makes no sense and is a > basic flaw in BSD licensing for libraries. I have _no_ intentions of > "competing" with various incarnations of RXTX. If you use RXTX in your > commercial application, I hope for two things. First I want you to do > well for using rxtx even if you somehow compete with me in the commercial > world. Second I want to see changes to RXTX come back to RXTX so we all > do well for choosing RXTX. > > This is not possible with the BSD, MIT ... licenses. They result in > multiple forks from the code and this is used to disrupt 'standards' by > companies you would recognize (I no longer mention any company when > saying bad things without fair notice). > > Your code is your code. Thats how the LGPL works. But don't take RXTX > and fork it where I or anyone else that has worked on RXTX can see it. > > -- > Trent Jarvi Hallo Trent, The BSD license wants to give and GPL wants to improve the public available content. What do you prefer? If you build the code to provide everyone a better experience then the BSD license would be suitable since the business acceptance is much higher. If you see this as a crucial component to build a complete free Java infrastructure that has no place for commerce then the GPL would be better In both situations RXTX will be free. I say that the chance a company would not contribute does not outweight the chance that the API is less available to the users. The entire API is a dead end. Mustang has USB support. Please let's make this as good as it gets. From tjarvi at qbang.org Sat Jul 8 16:09:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 16:09:31 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <200607082219.59514.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > I thought of the same thing. The modified BSD license would certainly make it > more eazy and acceptable for Sun to include RXTX in theire products. > > Unfortunately in general people who chose GPL don't like other licenses. ;) > If Sun can not accept the license, thats their problem. I have no problem with Sun distributing RXTX and working with the community. I've even stepped down as then primary and given that power to Doug to facilitate different opinions. For licensing changes, I am the primary copyright owner and have very strong opinions though I have a great deal of respect for everyone that has contributed to RXTX. Sun has their process and we have our process - screwy but a process and real. RXTX is not going to rubber stamp into any company without process that gives major power to the contributors to RXTX. There is a community here and it is not Sun's. (It isn't "gnu" either; the license is closest) This isn't about Trent. He is a wierd guy you should fear. That said, I'm not fundamentally against Sun distributing RXTX and changing package names. What I am fundametally against is multiple RXTXs. There isnt enough space for that game. -- Trent Jarvi tarvi at qbang.org From pascal at quies.net Sat Jul 8 16:25:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 00:25:24 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> Message-ID: <200607090025.24884.pascal@quies.net> Op zondag 9 juli 2006 00:09, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > > I thought of the same thing. The modified BSD license would certainly > > make it more eazy and acceptable for Sun to include RXTX in theire > > products. > > > > Unfortunately in general people who chose GPL don't like other licenses. > > ;) > > If Sun can not accept the license, thats their problem. > > I have no problem with Sun distributing RXTX and working with the > community. I've even stepped down as then primary and given that power to > Doug to facilitate different opinions. For licensing changes, I am the > primary copyright owner and have very strong opinions though I have a > great deal of respect for everyone that has contributed to RXTX. > > Sun has their process and we have our process - screwy but a process and > real. RXTX is not going to rubber stamp into any company without process > that gives major power to the contributors to RXTX. There is a community > here and it is not Sun's. (It isn't "gnu" either; the license is closest) > This isn't about Trent. He is a wierd guy you should fear. Hahaha, I found him very reasonable. The LGPL is not going to prevent forks. Any company which would take the code and keep little improvements to theirselves is stupid since they throw away a great deal of support and they know it. RXTX works. It needs a huge cleanup and more strict platform definitions but that's just a matter of time. What do you have to loose? From tjarvi at qbang.org Sat Jul 8 16:33:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 16:33:32 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <200607090025.24884.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> <200607090025.24884.pascal@quies.net> Message-ID: On Sun, 9 Jul 2006, Pascal S. de Kloe wrote: > Op zondag 9 juli 2006 00:09, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> I thought of the same thing. The modified BSD license would certainly >>> make it more eazy and acceptable for Sun to include RXTX in theire >>> products. >>> >>> Unfortunately in general people who chose GPL don't like other licenses. >>> ;) >> >> If Sun can not accept the license, thats their problem. >> >> I have no problem with Sun distributing RXTX and working with the >> community. I've even stepped down as then primary and given that power to >> Doug to facilitate different opinions. For licensing changes, I am the >> primary copyright owner and have very strong opinions though I have a >> great deal of respect for everyone that has contributed to RXTX. >> >> Sun has their process and we have our process - screwy but a process and >> real. RXTX is not going to rubber stamp into any company without process >> that gives major power to the contributors to RXTX. There is a community >> here and it is not Sun's. (It isn't "gnu" either; the license is closest) >> This isn't about Trent. He is a wierd guy you should fear. > > Hahaha, I found him very reasonable. > > The LGPL is not going to prevent forks. No it will not, but it will allow for you or me to view forks and absorb them. It renders forks of RXTX useless at the price of whatever product is shipped. I would ask that you consider the larger picture here. Termios and DCB are almost dead but almost being used like a VISA interface. Everyone just wants it to work but it does not always. So your proposal is to make mulitiple deal protocols? -- Trent Jarvi tjarvi at qbang.org From naranjo.manuel at gmail.com Sat Jul 8 17:20:44 2006 From: naranjo.manuel at gmail.com (Naranjo Manuel Francisco) Date: Sat, 8 Jul 2006 20:20:44 -0300 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> Message-ID: <360bc8300607081620x4e5d0f23h88fef8d81e6b6a0b@mail.gmail.com> Sorry, my mistake then, I thought the license was GPL not LGPL, I guess I readed some thing badly. I have readed all the emails, and you are right, there is no need for a Fork of RXTX, I think it works right as it is. So I can make my app Apache v2 with out any worry, because RXTX is LGPL :), great then. From tjarvi at qbang.org Sat Jul 8 17:57:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 17:57:05 -0600 (MDT) Subject: [Rxtx] License question ver2. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> <200607090025.24884.pascal@quies.net> Message-ID: Are there any more questions relating to this subject? From tjarvi at qbang.org Sat Jul 8 21:14:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 21:14:09 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <200607090006.18197.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607090006.18197.pascal@quies.net> Message-ID: On Sun, 9 Jul 2006, Pascal S. de Kloe wrote: > Op zaterdag 8 juli 2006 23:30, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Manuel Naranjo wrote: >>> Hi: >>> I have a question, haven't you ever thought about changing RXTX license >>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>> As far as I understand if I make an application that uses RXTX >>> libraries, I must release my app under the GNU/GPL. I have no problem >>> with that in fact I'm an Open Source user and defender. >>> The fact is that in same cases the applications made by one, could get >>> into hands of a company that needs to release a Closed Source app. I >>> understand that using GNU/GPL do not give you the power to do this, but >>> a more "open" license like Apache does. By "open" I mean that the >>> license respects the Open Source license, but also lives the user the >>> opportunity to use the library in closed source programs. >>> I have seen that there is an exception to the license that applies to >>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>> (the jar file) needs the file javax.comm.properties installed correctly, >>> which in lot of cases is a headache. RXTX jar does not need this, >>> actually I think that RXTX is more user friendly than Java Comm. >>> Maybe there has been a discussion like this before, but I just wanted to >>> ask, and to get an answer that is adequate to our time. >>> Regards, >>> Manuel >> >> Hi Manuel >> >> As one of the primary copyright 'owners' and a representative of all the >> people who have worked on RXTX I feel very compelled to comment on this. >> I often observe this misconception and just ignore it. >> >> RXTX is very commercial friendly both in open and closed source. The >> license is LGPL not GPL. This allows for linking to any application you >> like without sharing yoru application code. It is not unlike Apache or >> BSD in that sense. I like the BSD license but not in this case. >> >> The difference is you can not keep your changes to rxtx itself if your >> product is distributed in practice. To me this makes no sense and is a >> basic flaw in BSD licensing for libraries. I have _no_ intentions of >> "competing" with various incarnations of RXTX. If you use RXTX in your >> commercial application, I hope for two things. First I want you to do >> well for using rxtx even if you somehow compete with me in the commercial >> world. Second I want to see changes to RXTX come back to RXTX so we all >> do well for choosing RXTX. >> >> This is not possible with the BSD, MIT ... licenses. They result in >> multiple forks from the code and this is used to disrupt 'standards' by >> companies you would recognize (I no longer mention any company when >> saying bad things without fair notice). >> >> Your code is your code. Thats how the LGPL works. But don't take RXTX >> and fork it where I or anyone else that has worked on RXTX can see it. >> >> -- >> Trent Jarvi > > Hallo Trent, > > The BSD license wants to give and GPL wants to improve the public available > content. What do you prefer? > > If you build the code to provide everyone a better experience then the BSD > license would be suitable since the business acceptance is much higher. > If you see this as a crucial component to build a complete free Java > infrastructure that has no place for commerce then the GPL would be better > In both situations RXTX will be free. > > I say that the chance a company would not contribute does not outweight the > chance that the API is less available to the users. > The entire API is a dead end. Mustang has USB support. Please let's make this > as good as it gets. Hi Pascal I can not speak for any company here. I just happen to have become interesting to companies. With RXTX, the intent has always been to improve functionality. I don't play between the two worlds except for borrowing a scope at late in the evening. Thats rxtx and there is nothing else going on. Note that the RXTX library is LGPL. I would be interested in knowing where the GPL confusion comes from. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Jul 9 04:46:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 09 Jul 2006 06:46:49 -0400 Subject: [Rxtx] Java installer In-Reply-To: <200607082214.45115.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080235.29486.pascal@quies.net> <44AFB8AF.50403@gmail.com> <200607082214.45115.pascal@quies.net> Message-ID: Hi All, The problem of improving Java's ability to install and configure applications is a topic of current research. Configuration is a loaded word. When I think of configuration, I think, discover the properties of the operating environment and configure the software to work within that environment. Properties may include, but are not limited to, number and kind of monitors, serial ports, JVM versions, native method libs, graphics cards, graphics libs, write access to directories, changing the default screen saver (a new research topic) etc. There are two deployment solutions I can think of, please correct me, if I have left something out: 1. A source code distro with build tools (i.e., make and or ant) that enable the user to do a build for the target platform. 2. A binary distro built for each platform. Now, Java (in theory), is compile once, run anywhere. This assumes you don't use native methods. Once you start using native methods, you end up with many builds of the libs (one for each supported platform). Assuming you want binary distros for each platform, then you are faced with how to deploy them. Here are two basic approaches I know: 1. Build an application installer 2. Build a web-start distribution Some would argue for the application installer, as this is what many people are used to. Others will argue for a web-start distro. For a JNI-based application, like one that makes use of RXTX, I don't know which approach is "better". To know, one must first establish what "better" means. I think there must be (at least) two properties here: 1. Minimal installation effort 2. Trust. For minimal installation effort, I think that I should be able to download software, on demand, and just run it. Updates are obtained with minimal effort. Everything just works. And on all platforms that I use. For trust, I want to make sure I know the author and am able to hold someone accountable for application creation. I need to be able to thwart man-in-the-middle attacks and assure my user-base that I have signed off on my software. I have been making use of web-start, as a multi-year experiment. I have had mixed results. Particularly with more complex installs that make use of Java3d. In my view, several open problems remain. And cross-platform testing is needed for each major new application, platform, or major native method revision. On the other hand, I have had some good results with Java web start and RXTX. I can cite: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Which is an address book program that should identify your serial port and enable dialing via the modem. The web start system seems to be able to adapt to multiple operating environments. The question of how well this deploys remains open. It should work on mac, windows and linux. If people want to try it and give me feedback, I would appreciate it. Deployment is semi-automatic using Project Initium. This is described in: http://show.docjava.com:8086/pub/document/jot/web.pdf and http://show.docjava.com:8086/pub/document/jot/initium.pdf Thanks! - Doug >Op zaterdag 8 juli 2006 15:52, schreef Manuel Naranjo: >> > You are right. IzPack looks like the right tool for this job. >> > >> > As far as I can see there is no commandline support but I'll get over it. >> > ;) >> >> Actually there is a way to execute native app in the Underlaying OS. >> Check out the JavaDOC and all the documentation given by them. >> If you need to also generate warper around the jar files, check this > > projects out: > > http://launch4j.sourceforge.net and http://jsmooth.sourceforge.net/ > > I have been able to make and exe with jsmooth that does not need to >> have RXTX installed if you want I can send the source of it. But it is >> simple. >> Do not put the jar inside the exe file, and add to the classpath >> relative paths to rxtx jar and then your jar file, and then add to the >> JVM command line (I can't remeber the actual name of it :P) > > -Djava.library.path=bin\ (Or were ever you installed the binary package). >> I have tryied doing the same with Java Comm from Sun but it actually is >> imposible, the main difference to me that make me move to RXTX, was that >> there is no need to have the javax.comm.properties file, which gave me >> lot of headaches. >> Regards, >> Manuel. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >Those are verry interresting and impressive tools for Windows. >However, I wanted (and still do) a universal installer for all supported >platforms as a single JAR. IzPack seemed quite suitable but it is limited and >not well written so I'me still searching... > >Thanks for the help though. :) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 9 05:15:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 13:15:13 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607090006.18197.pascal@quies.net> Message-ID: <200607091315.14053.pascal@quies.net> Op zondag 9 juli 2006 05:14, schreef Trent Jarvi: > Hi Pascal > > I can not speak for any company here. I just happen to have become > interesting to companies. > > With RXTX, the intent has always been to improve functionality. > > I don't play between the two worlds except for borrowing a scope at late > in the evening. Thats rxtx and there is nothing else going on. > > Note that the RXTX library is LGPL. I would be interested in knowing > where the GPL confusion comes from. Hi Trent, The license is stated clearly everywhere so don't worry. You are right that the LGPL should not be a problem for companies. The problem is, especially in larger companies, that the people who take the decissions think differend. When they hear about the demands of the license they rather spend "some" money on a commercial solution just to be sure because the trouble it might cause is not worth it. From pascal at quies.net Sun Jul 9 05:15:41 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 13:15:41 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607090025.24884.pascal@quies.net> Message-ID: <200607091315.41848.pascal@quies.net> Op zondag 9 juli 2006 00:33, schreef Trent Jarvi: > I would ask that you consider the larger picture here. Termios and DCB > are almost dead but almost being used like a VISA interface. Everyone > just wants it to work but it does not always. > > So your proposal is to make mulitiple deal protocols? No, nothing like that. Just use native calls where possible. I'll send you some things this week anyway. From pascal at quies.net Sun Jul 9 05:52:11 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 13:52:11 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607082214.45115.pascal@quies.net> Message-ID: <200607091352.11696.pascal@quies.net> Op zondag 9 juli 2006 12:46, schreef Dr. Douglas Lyon: > Hi All, > The problem of improving Java's ability to > install and configure applications is a topic of current research. > > Configuration is a loaded word. When I think of configuration, > I think, discover the properties of the operating environment and > configure the software to work within that environment. > > Properties may include, but are not limited to, number and > kind of monitors, serial ports, JVM versions, native method libs, > graphics cards, graphics libs, write access to directories, > changing the default screen saver (a new research topic) etc. > > There are two deployment solutions I can think of, > please correct me, if I have left something out: > 1. A source code distro with build tools (i.e., make and or ant) that > enable the user to do a build for the target platform. > 2. A binary distro built for each platform. > > Now, Java (in theory), is compile once, run anywhere. This assumes you > don't use native methods. Once you start using native methods, > you end up with many builds of the libs (one for each supported platform). > > Assuming you want binary distros for each platform, then you are faced with > how to deploy them. Here are two basic approaches I know: > 1. Build an application installer > 2. Build a web-start distribution > > Some would argue for the application installer, as this is what > many people are used to. Others will argue for a web-start distro. > > For a JNI-based application, like one that makes use of RXTX, > I don't know which approach is "better". To know, one must > first establish what "better" means. I think there must be (at least) two > properties here: > 1. Minimal installation effort > 2. Trust. > > For minimal installation effort, I think that I should be able to download > software, on demand, and just run it. Updates are obtained with minimal > effort. Everything just works. And on all platforms that I use. > > For trust, I want to make sure I know the author and am able to hold > someone accountable for application creation. I need to be able to thwart > man-in-the-middle > attacks and assure my user-base that I have signed off on my software. > > I have been making > use of web-start, as a multi-year experiment. > > I have had mixed results. Particularly with more complex installs > that make use of Java3d. In my view, several open problems remain. > And cross-platform testing is needed for each major new application, > platform, or major native method revision. > > On the other hand, I have had some good results with Java web start > and RXTX. I can cite: > http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jn >lp Which is an address book program that should identify your > serial port and enable dialing via the modem. > > The web start system seems to be able to adapt to multiple operating > environments. The question of how well this deploys remains open. > > It should work on mac, windows and linux. If people want to try it > and give me feedback, I would appreciate it. > > Deployment is semi-automatic using Project Initium. This is described in: > http://show.docjava.com:8086/pub/document/jot/web.pdf > and > http://show.docjava.com:8086/pub/document/jot/initium.pdf > > Thanks! > - Doug Hello Dough, We are bumping into the same problems. Youre web-based plan is definitely the way to go. I still didn't find a way to get around two IzPack problems without hacking into the code and it's taking too long so I started again on the inital plan. The CommunicationAPI class does leave the trust thing up to the implementation. This means that users can download and run the JAR and other applications can include the jar to install things if needed. If you could "Initum" this process then RXTX has no installating limits anymore. From joachim at buechse.de Sun Jul 9 07:13:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 9 Jul 2006 15:13:34 +0200 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44AFBB4E.70808@gmail.com> References: <44AFBB4E.70808@gmail.com> Message-ID: <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> Manuel, a simple way to avoid the javax.comm.properties file is to include a class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } into your application jar file and make sure, that you include the javax.comm jar after it. That's all you need. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 08.07.2006, at 16:03, Manuel Naranjo wrote: > Hi: > I have a question, haven't you ever thought about changing RXTX > license > from GNU/GPL to a more open license like Apache v2 or BSD like?. > As far as I understand if I make an application that uses RXTX > libraries, I must release my app under the GNU/GPL. I have no problem > with that in fact I'm an Open Source user and defender. > The fact is that in same cases the applications made by one, could get > into hands of a company that needs to release a Closed Source app. I > understand that using GNU/GPL do not give you the power to do this, > but > a more "open" license like Apache does. By "open" I mean that the > license respects the Open Source license, but also lives the user the > opportunity to use the library in closed source programs. > I have seen that there is an exception to the license that applies to > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > (the jar file) needs the file javax.comm.properties installed > correctly, > which in lot of cases is a headache. RXTX jar does not need this, > actually I think that RXTX is more user friendly than Java Comm. > Maybe there has been a discussion like this before, but I just > wanted to > ask, and to get an answer that is adequate to our time. > Regards, > Manuel > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Sun Jul 9 07:19:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 9 Jul 2006 15:19:43 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607082203.13696.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> <44AFFF2C.8090005@gmail.com> <200607082203.13696.pascal@quies.net> Message-ID: <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> Pascal, I would strongly suggest NOT to follow these installation instructions for OSX. It "poisons" the global Java VM with a specific implementation of RXTX. Plus: there is not one, but several Java VMs installed on every version of OSX. An application specific file and global preference pane defines which VM launches which application. There is really no good reason to install RXTX globally. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 08.07.2006, at 22:03, Pascal S. de Kloe wrote: > > As far as the installation instructions go the location of the > libraries is > the following. > > Windows > * JRE: $JAVA_HOME/bin/ > * JDK: $JAVA_HOME/jre/bin/ > > UNIX > * JRE: $JAVA_HOME/lib/ > * JRE: $JAVA_HOME/jre/lib/ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 9 09:01:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 17:01:24 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> References: <200607081944.41123.pascal@quies.net> <200607082203.13696.pascal@quies.net> <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> Message-ID: <200607091701.24661.pascal@quies.net> Op zondag 9 juli 2006 15:19, schreef Joachim Buechse: > Pascal, > > I would strongly suggest NOT to follow these installation > instructions for OSX. It "poisons" the global Java VM with a specific > implementation of RXTX. Plus: there is not one, but several Java VMs > installed on every version of OSX. An application specific file and > global preference pane defines which VM launches which application. > There is really no good reason to install RXTX globally. I see your points. How can you use the extension non-globally? I asked the same thing for Windows to Manuel. The system will allow you to detect any implementation. So the "poison" becomes a alternative. Applications can install the extension if needed to the current runtime with something like: CommunicationAPI comm = new CommunicationAPI(); if (! comm.available()) { if (comm.installRXTX()) restart(); else handleError("I need the extension!"); } From naranjo.manuel at gmail.com Sun Jul 9 10:36:21 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 09 Jul 2006 13:36:21 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> Message-ID: <44B13085.2000805@gmail.com> Joachim, Does that really work???? I will try it later, thanks :) Manuel > Manuel, > > a simple way to avoid the javax.comm.properties file is to include a > class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > into your application jar file and make sure, that you include the > javax.comm jar after it. That's all you need. > > Regards, > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 08.07.2006, at 16:03, Manuel Naranjo wrote: > >> Hi: >> I have a question, haven't you ever thought about changing RXTX >> license >> from GNU/GPL to a more open license like Apache v2 or BSD like?. >> As far as I understand if I make an application that uses RXTX >> libraries, I must release my app under the GNU/GPL. I have no problem >> with that in fact I'm an Open Source user and defender. >> The fact is that in same cases the applications made by one, could get >> into hands of a company that needs to release a Closed Source app. I >> understand that using GNU/GPL do not give you the power to do this, >> but >> a more "open" license like Apache does. By "open" I mean that the >> license respects the Open Source license, but also lives the user the >> opportunity to use the library in closed source programs. >> I have seen that there is an exception to the license that applies to >> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >> (the jar file) needs the file javax.comm.properties installed >> correctly, >> which in lot of cases is a headache. RXTX jar does not need this, >> actually I think that RXTX is more user friendly than Java Comm. >> Maybe there has been a discussion like this before, but I just >> wanted to >> ask, and to get an answer that is adequate to our time. >> Regards, >> Manuel >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jul 9 10:50:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Jul 2006 10:50:11 -0600 (MDT) Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44B13085.2000805@gmail.com> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> Message-ID: I won't prevent people from discussing this hack. You can discuss anything on the list including things I do not agree with. But I do not agree with that hack. That is not in line with the history of RXTX respecting all that contribute including Sun. If you do this, it is your own thing. Agreeing to disagree is fine and usually the default here :). I just want to make it clear I do disagree. On Sun, 9 Jul 2006, Manuel Naranjo wrote: > Joachim, > Does that really work???? I will try it later, thanks :) > Manuel > >> Manuel, >> >> a simple way to avoid the javax.comm.properties file is to include a >> class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> into your application jar file and make sure, that you include the >> javax.comm jar after it. That's all you need. >> >> Regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 08.07.2006, at 16:03, Manuel Naranjo wrote: >> >>> Hi: >>> I have a question, haven't you ever thought about changing RXTX >>> license >>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>> As far as I understand if I make an application that uses RXTX >>> libraries, I must release my app under the GNU/GPL. I have no problem >>> with that in fact I'm an Open Source user and defender. >>> The fact is that in same cases the applications made by one, could get >>> into hands of a company that needs to release a Closed Source app. I >>> understand that using GNU/GPL do not give you the power to do this, >>> but >>> a more "open" license like Apache does. By "open" I mean that the >>> license respects the Open Source license, but also lives the user the >>> opportunity to use the library in closed source programs. >>> I have seen that there is an exception to the license that applies to >>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>> (the jar file) needs the file javax.comm.properties installed >>> correctly, >>> which in lot of cases is a headache. RXTX jar does not need this, >>> actually I think that RXTX is more user friendly than Java Comm. >>> Maybe there has been a discussion like this before, but I just >>> wanted to >>> ask, and to get an answer that is adequate to our time. >>> Regards, >>> Manuel >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From naranjo.manuel at gmail.com Sun Jul 9 11:43:33 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 09 Jul 2006 14:43:33 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> Message-ID: <44B14045.9030601@gmail.com> Trent: Do you know any other way, to use Java Comm API with RXTX with out the javax.comm.properties?. Have any information about how is the JSR going? Regards, Manuel > > I won't prevent people from discussing this hack. You can discuss > anything on the list including things I do not agree with. > > But I do not agree with that hack. That is not in line with the history > of RXTX respecting all that contribute including Sun. If you do this, > it is your own thing. > > Agreeing to disagree is fine and usually the default here :). I just > want to make it clear I do disagree. > > On Sun, 9 Jul 2006, Manuel Naranjo wrote: > >> Joachim, >> Does that really work???? I will try it later, thanks :) >> Manuel >> >>> Manuel, >>> >>> a simple way to avoid the javax.comm.properties file is to include a >>> class >>> >>> package com.sun.comm; >>> public class SolarisDriver extends gnu.io.RXTXCommDriver { >>> } >>> >>> into your application jar file and make sure, that you include the >>> javax.comm jar after it. That's all you need. >>> >>> Regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich >>> >>> >>> On 08.07.2006, at 16:03, Manuel Naranjo wrote: >>> >>>> Hi: >>>> I have a question, haven't you ever thought about changing RXTX >>>> license >>>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>>> As far as I understand if I make an application that uses RXTX >>>> libraries, I must release my app under the GNU/GPL. I have no problem >>>> with that in fact I'm an Open Source user and defender. >>>> The fact is that in same cases the applications made by one, could get >>>> into hands of a company that needs to release a Closed Source app. I >>>> understand that using GNU/GPL do not give you the power to do this, >>>> but >>>> a more "open" license like Apache does. By "open" I mean that the >>>> license respects the Open Source license, but also lives the user the >>>> opportunity to use the library in closed source programs. >>>> I have seen that there is an exception to the license that applies to >>>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>>> (the jar file) needs the file javax.comm.properties installed >>>> correctly, >>>> which in lot of cases is a headache. RXTX jar does not need this, >>>> actually I think that RXTX is more user friendly than Java Comm. >>>> Maybe there has been a discussion like this before, but I just >>>> wanted to >>>> ask, and to get an answer that is adequate to our time. >>>> Regards, >>>> Manuel >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Jul 9 11:53:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Jul 2006 11:53:19 -0600 (MDT) Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44B14045.9030601@gmail.com> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> Message-ID: Hi Manuel I do not know of another way. If you look at rxtx.org, even the compiled version is hard to find, always late and not what you want. At rxtx.org we just worry about the source and do a minimal effort to provide binaries. I'd love nothing more than someone to start selling RXTX binaries or working with us like Doug is to deliver the problems solved to users. The Free here is Freedom. Not price. There is a need for services rxtx.org is not able to provide well. That said I do not ever expect to recieve anything. It just makes sense for everyone to work together and compete outside of the source. On Sun, 9 Jul 2006, Manuel Naranjo wrote: > Trent: > Do you know any other way, to use Java Comm API with RXTX with out the > javax.comm.properties?. > Have any information about how is the JSR going? > Regards, > Manuel >> >> I won't prevent people from discussing this hack. You can discuss >> anything on the list including things I do not agree with. >> >> But I do not agree with that hack. That is not in line with the history >> of RXTX respecting all that contribute including Sun. If you do this, >> it is your own thing. >> >> Agreeing to disagree is fine and usually the default here :). I just >> want to make it clear I do disagree. >> >> On Sun, 9 Jul 2006, Manuel Naranjo wrote: >> >>> Joachim, >>> Does that really work???? I will try it later, thanks :) >>> Manuel >>> >>>> Manuel, >>>> >>>> a simple way to avoid the javax.comm.properties file is to include a >>>> class >>>> >>>> package com.sun.comm; >>>> public class SolarisDriver extends gnu.io.RXTXCommDriver { >>>> } >>>> >>>> into your application jar file and make sure, that you include the >>>> javax.comm jar after it. That's all you need. >>>> >>>> Regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >>>> >>>> >>>> On 08.07.2006, at 16:03, Manuel Naranjo wrote: >>>> >>>>> Hi: >>>>> I have a question, haven't you ever thought about changing RXTX >>>>> license >>>>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>>>> As far as I understand if I make an application that uses RXTX >>>>> libraries, I must release my app under the GNU/GPL. I have no problem >>>>> with that in fact I'm an Open Source user and defender. >>>>> The fact is that in same cases the applications made by one, could get >>>>> into hands of a company that needs to release a Closed Source app. I >>>>> understand that using GNU/GPL do not give you the power to do this, >>>>> but >>>>> a more "open" license like Apache does. By "open" I mean that the >>>>> license respects the Open Source license, but also lives the user the >>>>> opportunity to use the library in closed source programs. >>>>> I have seen that there is an exception to the license that applies to >>>>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>>>> (the jar file) needs the file javax.comm.properties installed >>>>> correctly, >>>>> which in lot of cases is a headache. RXTX jar does not need this, >>>>> actually I think that RXTX is more user friendly than Java Comm. >>>>> Maybe there has been a discussion like this before, but I just >>>>> wanted to >>>>> ask, and to get an answer that is adequate to our time. >>>>> Regards, >>>>> Manuel >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From naranjo.manuel at gmail.com Sun Jul 9 12:04:28 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 09 Jul 2006 15:04:28 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> Message-ID: <44B1452C.60208@gmail.com> Trent Jarvi wrote: > > Hi Manuel > > I do not know of another way. If you look at rxtx.org, even the > compiled version is hard to find, always late and not what you want. At > rxtx.org we just worry about the source and do a minimal effort to > provide binaries. Then that probes my theory, RXTX is much better than Java comm :) > I'd love nothing more than someone to start selling RXTX binaries or > working with us like Doug is to deliver the problems solved to users. > The Free here is Freedom. Not price. There is a need for services > rxtx.org is not able to provide well. That said I do not ever expect to > recieve anything. It just makes sense for everyone to work together and > compete outside of the source. I would like to contribute with the project giving support, I have worked using JSmooth and IzPack, and been able to make things that make RXTX easier to use and install. I will try to debug them, and send them to the mailing list, so you can do what ever you want with this :). Regards, Manuel From tjarvi at qbang.org Sun Jul 9 22:15:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Jul 2006 22:15:28 -0600 (MDT) Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44B1452C.60208@gmail.com> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> <44B1452C.60208@gmail.com> Message-ID: On Sun, 9 Jul 2006, Manuel Naranjo wrote: > Trent Jarvi wrote: >> >> Hi Manuel >> >> I do not know of another way. If you look at rxtx.org, even the >> compiled version is hard to find, always late and not what you want. At >> rxtx.org we just worry about the source and do a minimal effort to >> provide binaries. > Then that probes my theory, RXTX is much better than Java comm :) > >> I'd love nothing more than someone to start selling RXTX binaries or >> working with us like Doug is to deliver the problems solved to users. >> The Free here is Freedom. Not price. There is a need for services >> rxtx.org is not able to provide well. That said I do not ever expect to >> recieve anything. It just makes sense for everyone to work together and >> compete outside of the source. > I would like to contribute with the project giving support, I have > worked using JSmooth and IzPack, and been able to make things that make > RXTX easier to use and install. I will try to debug them, and send them > to the mailing list, so you can do what ever you want with this :). > Regards, Hi Manuel This is interesting. There are some checks and balances that we do at rxtx.org to make sure random material does not get in. It isn't personal just a low bar that must be crossed. After you get your changes in, you will know that others must cross the same bar. The basic question asked is "Does this change reflect the intent and work of those that have contributed to RXTX." Perhaps Doug is the best person to be the bar here. I'm more than willing to admit my limitations and obviously this is a limitation I face. If Doug is willing to take this task, I'd be glad to give him CVS write access which is more than overdue as he is the official maintainer now :) He then could optionally give you write access if your changes are fine and you represent a bar for new changes. I trust Doug. We do take the bar seriously as you can see. But it is not intended to prevent fair use of RXTX or prevent facilitating new uses. If we don't manage expectations here, there will be all sorts of problems and issues. -- Trent Jarvi tjarvi at qbang.org From zhanglong at adventnet.com Mon Jul 10 02:02:20 2006 From: zhanglong at adventnet.com (zhanglong) Date: Mon, 10 Jul 2006 16:02:20 +0800 Subject: [Rxtx] rxtx can not read data from serialport Message-ID: <44B2098C.6050407@adventnet.com> Dear brian and tjarvi, Thank you! After I set flowcontrol as FLOWCONTROL_RTSCTS_IN serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_IN); Then I can read and write data from serial port on Windows. But On linux9.0,No response,no data. I can get serialport list on my machine.And no error when I open serialport. I use Wevecom GSM modem device.I install Linux in VWware Workstation. And VWware Workstation install on windowsXP,So windowsXP and redhat Linux9.0 are on the same PC. On windows,I use COM1 serialport. On Linux,I use /dev/ttyS0 serialport. I hava test with SerialPort.FLOWCONTROL_XONXOFF_IN flow control,But still no data. How to set flow control,timeout and threshold on linux9.0? Thanks & Regards, Zhanglong -------------- next part -------------- A non-text attachment was scrubbed... Name: ListPort.java Type: text/x-java Size: 1659 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060710/334802b0/ListPort-0352.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: listport return on Windows and Linux.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060710/334802b0/listportreturnonWindowsandLinux-0352.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: TwoWaySerialComm.java Type: text/x-java Size: 3516 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060710/334802b0/TwoWaySerialComm-0352.bin From joachim at buechse.de Mon Jul 10 02:53:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 10 Jul 2006 10:53:09 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607091701.24661.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> <200607082203.13696.pascal@quies.net> <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> <200607091701.24661.pascal@quies.net> Message-ID: <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> The problem is, that once the libraries are installed in JAVA_HOME/ lib they will be loaded in preference to classes in your application classpath. If all you want is to use RXTX, then: - put the native lib in your application directory - include the javax.comm classes and RXTX classes in your application classpath - add the little stub class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } before the javax.comm classes in your application classpath. Alternatively you could also include the native lib in your application jar, extract it at runtime to a temp file, load it with System.load(). This will work on Windows and OSX. I didn't test it on Linux, but it should work. Regards, Joachim On 09.07.2006, at 17:01, Pascal S. de Kloe wrote: > Op zondag 9 juli 2006 15:19, schreef Joachim Buechse: >> Pascal, >> >> I would strongly suggest NOT to follow these installation >> instructions for OSX. It "poisons" the global Java VM with a specific >> implementation of RXTX. Plus: there is not one, but several Java VMs >> installed on every version of OSX. An application specific file and >> global preference pane defines which VM launches which application. >> There is really no good reason to install RXTX globally. > > I see your points. > How can you use the extension non-globally? I asked the same thing > for Windows > to Manuel. > > The system will allow you to detect any implementation. So the > "poison" > becomes a alternative. Applications can install the extension if > needed to > the current runtime with something like: > > CommunicationAPI comm = new CommunicationAPI(); > if (! comm.available()) { > if (comm.installRXTX()) > restart(); > else > handleError("I need the extension!"); > } > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jul 10 06:07:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 10 Jul 2006 06:07:23 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607081330.24381.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <200607081330.24381.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> Is the gnu.io namespace still necessary? I couldn't find the problem. >> >> Hi Pascal >> >> CommAPI is a little different in that it was grandfathered into the javax >> namespace with its own license at the time. >> >> It is my understanding that if CommAPI went through the JSR process, >> anyone would _clearly_ be able to implement a javax.comm package and RXTX >> would then be one of the first to do so. I believe Doug has expressed >> some interest in RXTX trying to work with the JSR process. >> >> Besides the license questions, there is the fact that RXTX has extensions >> to CommAPI which could cause confusion in the namespace. Not being a >> lawyer and *really* not liking to talk to lawyers in my free time, it is >> better to be safe than sorry. The lawyers tend to come in wolf packs >> when they do come. >> >> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay >> there as long as we are just geeks trying to figure out if a license does >> or does not allow us to implement in the javax.comm namespace. > > Nicely said. :) > > The whole point of namespaces is to create a universal registry of, in this > case, classes. This gnu.io namespace is very inconvenient. > > We feel the same way about lawyers. However I'd like to go into the details of > the license (see attachment) if you don't mind? > > The first license does not apply since RXTX does not use the software. The > second one at point 3 specifies our options. > >> 3. You may not modify the Java Platform Interface ("JPI", identified as >> classes contained within the "java" package or any subpackages of the >> "java" package), by creating additional classes within the JPI or otherwise >> causing the addition to or modification of the classes in the JPI. > > RXTX is a extension. > >> In the event that you create an additional class and associated API(s) >> which (i) extends the functionality of the Java platform, and (ii) is >> exposed to third party software developers for the purpose of developing >> additional software which invokes such additional API, you must promptly >> publish broadly an accurate specification for such API for free use by all >> developers. > > That's the way we operate. :) > >> You may not create, or authorize your licensees to create additional >> classes, interfaces, or subpackages that are in any way identified as >> "java", "javax", "sun" or similar convention as specified by Sun in any >> naming convention designation. > > They don't want additional components in the Communication API since they > don't want a mess in theire namespace. > > So we *can* use javax.comm for the core: > javax.comm.CommDriver > javax.comm.CommPort > javax.comm.CommPortIdentifier > javax.comm.CommPortOwnershipListener > javax.comm.NoSuchPortException > javax.comm.PortInUseException > javax.comm.UnsupportedCommOperationException > > ...and for the default hardware support: > javax.comm.SerialPort > javax.comm.SerialPortEvent > javax.comm.SerialPortEventListener > javax.comm.ParralelPort > javax.comm.ParralelPortEvent > javax.comm.ParralelPortEventListener > > ...but RXTX aditional hardware support has to go somewhere else like: > org.rxtx.RS485Port > org.rxtx.RS485PortEvent > org.rxtx.RS485PortEventListener > org.rxtx.I2CPort > org.rxtx.I2CPortEvent > org.rxtx.I2CPortEventListener > > Right? > The one thing this discussion does not cover is in SerialPort.java. See the extensions to commapi listed after the following line: /* ---------------------- end of commapi ------------------------ */ The intent is not to break commapi but it could be perceived as so. The extensions added have been placed there as requested by users of RXTX. It would be nice to discuss these modifications with Sun and perhaps have some added to the final version of CommAPI. Some of them may not make sense while others do. Some can not be implemented in a platform neutral fashion. It would not make sense for RXTX to just bring these into Sun's namespace without due process. This is why I am fundamentally apposed to people "poisoning" Sun's namespace with RXTX 2.1 although I understand that is not their intent. These modifications are not advertised and their use is discouraged. But they are there. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Mon Jul 10 06:47:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 10 Jul 2006 14:47:24 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607081330.24381.pascal@quies.net> Message-ID: <200607101447.25071.pascal@quies.net> Op maandag 10 juli 2006 14:07, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > > Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: > >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > >>> Is the gnu.io namespace still necessary? I couldn't find the problem. > >> > >> Hi Pascal > >> > >> CommAPI is a little different in that it was grandfathered into the > >> javax namespace with its own license at the time. > >> > >> It is my understanding that if CommAPI went through the JSR process, > >> anyone would _clearly_ be able to implement a javax.comm package and > >> RXTX would then be one of the first to do so. I believe Doug has > >> expressed some interest in RXTX trying to work with the JSR process. > >> > >> Besides the license questions, there is the fact that RXTX has > >> extensions to CommAPI which could cause confusion in the namespace. Not > >> being a lawyer and *really* not liking to talk to lawyers in my free > >> time, it is better to be safe than sorry. The lawyers tend to come in > >> wolf packs when they do come. > >> > >> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay > >> there as long as we are just geeks trying to figure out if a license > >> does or does not allow us to implement in the javax.comm namespace. > > > > Nicely said. :) > > > > The whole point of namespaces is to create a universal registry of, in > > this case, classes. This gnu.io namespace is very inconvenient. > > > > We feel the same way about lawyers. However I'd like to go into the > > details of the license (see attachment) if you don't mind? > > > > The first license does not apply since RXTX does not use the software. > > The second one at point 3 specifies our options. > > > >> 3. You may not modify the Java Platform Interface ("JPI", identified as > >> classes contained within the "java" package or any subpackages of the > >> "java" package), by creating additional classes within the JPI or > >> otherwise causing the addition to or modification of the classes in the > >> JPI. > > > > RXTX is a extension. > > > >> In the event that you create an additional class and associated API(s) > >> which (i) extends the functionality of the Java platform, and (ii) is > >> exposed to third party software developers for the purpose of developing > >> additional software which invokes such additional API, you must promptly > >> publish broadly an accurate specification for such API for free use by > >> all developers. > > > > That's the way we operate. :) > > > >> You may not create, or authorize your licensees to create additional > >> classes, interfaces, or subpackages that are in any way identified as > >> "java", "javax", "sun" or similar convention as specified by Sun in any > >> naming convention designation. > > > > They don't want additional components in the Communication API since they > > don't want a mess in theire namespace. > > > > So we *can* use javax.comm for the core: > > javax.comm.CommDriver > > javax.comm.CommPort > > javax.comm.CommPortIdentifier > > javax.comm.CommPortOwnershipListener > > javax.comm.NoSuchPortException > > javax.comm.PortInUseException > > javax.comm.UnsupportedCommOperationException > > > > ...and for the default hardware support: > > javax.comm.SerialPort > > javax.comm.SerialPortEvent > > javax.comm.SerialPortEventListener > > javax.comm.ParralelPort > > javax.comm.ParralelPortEvent > > javax.comm.ParralelPortEventListener > > > > ...but RXTX aditional hardware support has to go somewhere else like: > > org.rxtx.RS485Port > > org.rxtx.RS485PortEvent > > org.rxtx.RS485PortEventListener > > org.rxtx.I2CPort > > org.rxtx.I2CPortEvent > > org.rxtx.I2CPortEventListener > > > > Right? > > The one thing this discussion does not cover is in SerialPort.java. See > the extensions to commapi listed after the following line: > > /* ---------------------- end of commapi ------------------------ */ > > The intent is not to break commapi but it could be perceived as so. The > extensions added have been placed there as requested by users of RXTX. It > would be nice to discuss these modifications with Sun and perhaps have > some added to the final version of CommAPI. > > Some of them may not make sense while others do. Some can not be > implemented in a platform neutral fashion. It would not make sense > for RXTX to just bring these into Sun's namespace without due process. > > This is why I am fundamentally apposed to people "poisoning" Sun's > namespace with RXTX 2.1 although I understand that is not their intent. > > These modifications are not advertised and their use is discouraged. But > they are there. Hi Trent, So you are saying that gnu.io.SerialPort has some aditional methods over javax.comm.SerialPort? That does not change the API at all but it would be a problem if people would start using those methods in the javax.comm namespace in the same way like some people use the com.sun namespace. Could wrapper classes at javax.comm do the job? In that way RXTX stays in its namespace, javadoc can notice the aditional methods and the Communication API will be available as expected. From pascal at quies.net Mon Jul 10 06:48:09 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 10 Jul 2006 14:48:09 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> References: <200607081944.41123.pascal@quies.net> <200607091701.24661.pascal@quies.net> <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> Message-ID: <200607101448.09594.pascal@quies.net> Op maandag 10 juli 2006 10:53, schreef Joachim Buechse: > If all you want is to use RXTX, then: > > - put the native lib in your application directory > - include the javax.comm classes and RXTX classes in your application > classpath > - add the little stub class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > before the javax.comm classes in your application classpath. > > Alternatively you could also include the native lib in your > application jar, extract it at runtime to a temp file, load it with > System.load(). So java will load the native libraries automaticly if they are in the same directory as the Java application? Why isn't this very interresting information noticed in the documentation or is that too obvious and I simply didn't knew? From naranjo.manuel at gmail.com Mon Jul 10 06:56:10 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Mon, 10 Jul 2006 09:56:10 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> <44B1452C.60208@gmail.com> Message-ID: <44B24E6A.1010805@gmail.com> Trent Jarvi wrote: > On Sun, 9 Jul 2006, Manuel Naranjo wrote: > >> Trent Jarvi wrote: >>> Hi Manuel >>> >>> I do not know of another way. If you look at rxtx.org, even the >>> compiled version is hard to find, always late and not what you want. At >>> rxtx.org we just worry about the source and do a minimal effort to >>> provide binaries. >> Then that probes my theory, RXTX is much better than Java comm :) >> >>> I'd love nothing more than someone to start selling RXTX binaries or >>> working with us like Doug is to deliver the problems solved to users. >>> The Free here is Freedom. Not price. There is a need for services >>> rxtx.org is not able to provide well. That said I do not ever expect to >>> recieve anything. It just makes sense for everyone to work together and >>> compete outside of the source. >> I would like to contribute with the project giving support, I have >> worked using JSmooth and IzPack, and been able to make things that make >> RXTX easier to use and install. I will try to debug them, and send them >> to the mailing list, so you can do what ever you want with this :). >> Regards, > > > Hi Manuel > > This is interesting. There are some checks and balances that we do at > rxtx.org to make sure random material does not get in. It isn't personal > just a low bar that must be crossed. After you get your changes in, you > will know that others must cross the same bar. The basic question asked > is "Does this change reflect the intent and work of those that have > contributed to RXTX." > > Perhaps Doug is the best person to be the bar here. I'm more than willing > to admit my limitations and obviously this is a limitation I face. > > If Doug is willing to take this task, I'd be glad to give him CVS write > access which is more than overdue as he is the official maintainer now :) > He then could optionally give you write access if your changes are fine > and you represent a bar for new changes. I trust Doug. > > We do take the bar seriously as you can see. But it is not intended to > prevent fair use of RXTX or prevent facilitating new uses. If we don't > manage expectations here, there will be all sorts of problems and issues. > > -- > Trent Jarvi > tjarvi at qbang.org > > Trent, What I want to send you is not a modification to rxtx, it just a developers helper if you want to put a name to it. I have make an IzPack installer, which installs RXTX binaries depending on underlaying OS. And make an JSmooth warper that launches my app with out the need to have rxtx installed on the host JVM folder, it only need the RXTX to be in the bin\ of my app. I think this is more useful for Wiki than to the main project. Another thing I have experience in PalmOS programming, when ever I have time, I will investigate about the JNI of J2ME and try to port RXTX to Palm, I do not know when I will start, because I have a lot of work now. Regards, Manuel From christopher.dawes at the-logic-group.com Mon Jul 10 08:00:15 2006 From: christopher.dawes at the-logic-group.com (christopher.dawes@the-logic-group.com) Date: Mon, 10 Jul 2006 15:00:15 +0100 Subject: [Rxtx] Chris Dawes/Retaillogic/NISABA is out of the office. Message-ID: I will be out of the office starting 10/07/2006 and will not return until 11/07/2008. Hello, unfortunately I no longer work for The Logic Group, if you're trying to contact me on a work related issue please contact Pete Avery (pete.avery at the-logic-group.com) however if it is a personal matter please e-mail root at ants.me.uk or phone 07899 842 759. Thanks Christopher Dawes From tjarvi at qbang.org Mon Jul 10 08:19:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 10 Jul 2006 08:19:52 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607101447.25071.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607081330.24381.pascal@quies.net> <200607101447.25071.pascal@quies.net> Message-ID: On Mon, 10 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 10 juli 2006 14:07, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: >>>> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>>>> Is the gnu.io namespace still necessary? I couldn't find the problem. >>>> >>>> Hi Pascal >>>> >>>> CommAPI is a little different in that it was grandfathered into the >>>> javax namespace with its own license at the time. >>>> >>>> It is my understanding that if CommAPI went through the JSR process, >>>> anyone would _clearly_ be able to implement a javax.comm package and >>>> RXTX would then be one of the first to do so. I believe Doug has >>>> expressed some interest in RXTX trying to work with the JSR process. >>>> >>>> Besides the license questions, there is the fact that RXTX has >>>> extensions to CommAPI which could cause confusion in the namespace. Not >>>> being a lawyer and *really* not liking to talk to lawyers in my free >>>> time, it is better to be safe than sorry. The lawyers tend to come in >>>> wolf packs when they do come. >>>> >>>> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay >>>> there as long as we are just geeks trying to figure out if a license >>>> does or does not allow us to implement in the javax.comm namespace. >>> >>> Nicely said. :) >>> >>> The whole point of namespaces is to create a universal registry of, in >>> this case, classes. This gnu.io namespace is very inconvenient. >>> >>> We feel the same way about lawyers. However I'd like to go into the >>> details of the license (see attachment) if you don't mind? >>> >>> The first license does not apply since RXTX does not use the software. >>> The second one at point 3 specifies our options. >>> >>>> 3. You may not modify the Java Platform Interface ("JPI", identified as >>>> classes contained within the "java" package or any subpackages of the >>>> "java" package), by creating additional classes within the JPI or >>>> otherwise causing the addition to or modification of the classes in the >>>> JPI. >>> >>> RXTX is a extension. >>> >>>> In the event that you create an additional class and associated API(s) >>>> which (i) extends the functionality of the Java platform, and (ii) is >>>> exposed to third party software developers for the purpose of developing >>>> additional software which invokes such additional API, you must promptly >>>> publish broadly an accurate specification for such API for free use by >>>> all developers. >>> >>> That's the way we operate. :) >>> >>>> You may not create, or authorize your licensees to create additional >>>> classes, interfaces, or subpackages that are in any way identified as >>>> "java", "javax", "sun" or similar convention as specified by Sun in any >>>> naming convention designation. >>> >>> They don't want additional components in the Communication API since they >>> don't want a mess in theire namespace. >>> >>> So we *can* use javax.comm for the core: >>> javax.comm.CommDriver >>> javax.comm.CommPort >>> javax.comm.CommPortIdentifier >>> javax.comm.CommPortOwnershipListener >>> javax.comm.NoSuchPortException >>> javax.comm.PortInUseException >>> javax.comm.UnsupportedCommOperationException >>> >>> ...and for the default hardware support: >>> javax.comm.SerialPort >>> javax.comm.SerialPortEvent >>> javax.comm.SerialPortEventListener >>> javax.comm.ParralelPort >>> javax.comm.ParralelPortEvent >>> javax.comm.ParralelPortEventListener >>> >>> ...but RXTX aditional hardware support has to go somewhere else like: >>> org.rxtx.RS485Port >>> org.rxtx.RS485PortEvent >>> org.rxtx.RS485PortEventListener >>> org.rxtx.I2CPort >>> org.rxtx.I2CPortEvent >>> org.rxtx.I2CPortEventListener >>> >>> Right? >> >> The one thing this discussion does not cover is in SerialPort.java. See >> the extensions to commapi listed after the following line: >> >> /* ---------------------- end of commapi ------------------------ */ >> >> The intent is not to break commapi but it could be perceived as so. The >> extensions added have been placed there as requested by users of RXTX. It >> would be nice to discuss these modifications with Sun and perhaps have >> some added to the final version of CommAPI. >> >> Some of them may not make sense while others do. Some can not be >> implemented in a platform neutral fashion. It would not make sense >> for RXTX to just bring these into Sun's namespace without due process. >> >> This is why I am fundamentally apposed to people "poisoning" Sun's >> namespace with RXTX 2.1 although I understand that is not their intent. >> >> These modifications are not advertised and their use is discouraged. But >> they are there. > > Hi Trent, > > So you are saying that gnu.io.SerialPort has some aditional methods over > javax.comm.SerialPort? > That does not change the API at all but it would be a problem if people would > start using those methods in the javax.comm namespace in the same way like > some people use the com.sun namespace. > Could wrapper classes at javax.comm do the job? In that way RXTX stays in its > namespace, javadoc can notice the aditional methods and the Communication API > will be available as expected. Hi Pascal Yes. There are additional methods in gnu.io.SerialPort. We clearly mark those as extensions to CommAPI and discourage their use. There just isn't a way to get the intended functionality out of CommAPI without them. I think the right thing to do here may be to remove these methods to avoid unintentional polution of the javax namespace if people are going to be putting these classes in that namespace. The way people are using RXTX 2.1 is not the same as it was originally pictured. Thats fine but we need to be responsible. We need to prevent what could be a problem. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Mon Jul 10 08:57:10 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 10 Jul 2006 16:57:10 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101447.25071.pascal@quies.net> Message-ID: <200607101657.11223.pascal@quies.net> > Yes. There are additional methods in gnu.io.SerialPort. We clearly mark > those as extensions to CommAPI and discourage their use. There just isn't > a way to get the intended functionality out of CommAPI without them. If you don't want the users to use the methods then make them class protected (remove the word "public" before the method) and if you can't do that we might do the following: ---- SerialPort.java package javax.comm class SerialPort extends gnu.io.SerialPort { public void rxtxOnlyMethod() { throw new Error("Don't use this method here!\nUse gnu.io.SerialPort instead"); } ---- end From neville_seed at yahoo.com Mon Jul 10 10:20:12 2006 From: neville_seed at yahoo.com (neville seed) Date: Mon, 10 Jul 2006 09:20:12 -0700 (PDT) Subject: [Rxtx] writing first application and compiling In-Reply-To: Message-ID: <20060710162012.9888.qmail@web51015.mail.yahoo.com> Can anyone recommend a starting place for writing, compiling and uploading the first app, ie a simple hello world. It seems that the PALM SDK does not have a build environment. I am happy to develop under linux of windows. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From bob_tai2001 at yahoo.com Mon Jul 10 14:48:30 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 10 Jul 2006 13:48:30 -0700 (PDT) Subject: [Rxtx] Java installer Message-ID: <20060710204830.53745.qmail@web32810.mail.mud.yahoo.com> Hi Manuel, I found your post from the newsletter, hope I am not off topic. You mention there is a IZpack installer for Rxtx? I been waiting for this type of deplyment idea from Rxtx! is this documented in the web site? I am in windows environment but didn't want to create classpath for each workstation. I rather install :) I apologize for cutting into this topic. Bob > >Trent, >What I want to send you is not a modification to rxtx, it just a >developers helper if you want to put a name to it. I have make an IzPack installer, which installs RXTX binaries depending on underlaying OS. And make an JSmooth warper that launches my app with out the need to have rxtx installed on the host JVM folder, it only need the RXTX to be in the bin\ of my app. I think this is more useful for Wiki than to the main project. Another thing I have experience in PalmOS programming, when ever I have time, I will investigate about the JNI of J2ME and try to port RXTX to Palm, I do not know when I will start, because I have a lot of work now. Regards, Manuel __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From naranjo.manuel at gmail.com Mon Jul 10 15:10:21 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Mon, 10 Jul 2006 18:10:21 -0300 Subject: [Rxtx] Java installer In-Reply-To: <20060710204830.53745.qmail@web32810.mail.mud.yahoo.com> References: <20060710204830.53745.qmail@web32810.mail.mud.yahoo.com> Message-ID: <44B2C23D.8050901@gmail.com> Bob, Hi, not this is not a RXTX installer, I have develop an installer with IzPack which actually installs RXTX and my hole app, and I think this can be useful for RXTX users, Regards, Manuel > Hi Manuel, > > I found your post from the newsletter, hope I am not > off topic. You mention there is a IZpack installer > for Rxtx? I been waiting for this type of deplyment > idea from Rxtx! is this documented in the web site? > I am in windows environment but didn't want to create > classpath for each workstation. I rather install :) > > I apologize for cutting into this topic. > > Bob > >> Trent, >> What I want to send you is not a modification to > rxtx, it just a >> developers > helper if you want to put a name to it. I have make an > IzPack > installer, > which installs RXTX binaries depending on underlaying > OS. And make an > JSmooth warper that launches my app with out the need > to have rxtx > installed > on the host JVM folder, it only need the RXTX to be in > the bin\ of my > app. > I think this is more useful for Wiki than to the main > project. > Another thing I have experience in PalmOS programming, > when ever I have > time, > I will investigate about the JNI of J2ME and try to > port RXTX to Palm, > I do not know when I will start, because I have a lot > of work now. > Regards, > Manuel > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From brian at mbari.org Tue Jul 11 11:59:24 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 11 Jul 2006 10:59:24 -0700 Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: References: <44AC7902.8070407@adventnet.com> Message-ID: <485C28F0-CA08-4393-9E34-4C8E7F22C125@mbari.org> Hi Trent, On Jul 7, 2006, at 6:15 PM, Trent Jarvi wrote: > On Fri, 7 Jul 2006, Brian Schlining wrote: >> Also, for some command/response applications that I've tried with >> RXTX, I >> find that if I write to the serialport and then immediately try to >> read from >> it I get byte arrays filled with zeros, no matter what I set the >> recieveTimeout to (this has occurred on both Mac OS X and >> Windows). The >> workaround that I found was to very briefly put the I/O thread to >> sleep, like >> so: >> >> // DO set up and get I/O streams >> //in = serialPort.getInputStream(); >> //out = serialPort.getOutputStream(); >> >> out.write(someByteArray); >> try { >> Thread.sleep(10); >> catch (InterruptedException e) { >> // handle exception >> } >> in.read(anotherByteArray); >> >> Note: I've never had to put the thread to sleep using Java comm, >> only with >> RXTX. Anyone know why this might be? > > Hi Brian > > Interesting. Is this something that can be reproduced with a loopback > connection or something commonly available? I was unaware of this > behavior. Is it restricted to something that quickly opens, > writes, reads > and closes the port by chance? I've encountered this while using RXTX to talk to VCR's that support RS422; I've never tried it with a loopback connection. Note that connection setup is: PC[RS232] <---> RS232/422 Converter <---> VCR[RS422] The application I'm using it for opens a connection and keeps it open for the life of the application. It makes a lot of read and writes when running...probably about as fast as the VCR hardware supports; with Javacomm, I think it was on the order of an IO transaction every 40ms. However even if I perform an IO read/write every 2 seconds with RXTX I still encounter the same problem, so it's not a matter of the frequency of the IO transactions. If you want to look at the code a test example can be found at https://svn.sourceforge.net/svnroot/vars/trunk/vars/src/test/java/ test/org/mbari/vcr/SimpleReadRxtx.java. The actual production code is at https://svn.sourceforge.net/svnroot/vars/trunk/vars/src/main/java/ org/mbari/vcr/rs422/VCR.java. The methods that you might be interested in to see how the code is used are initComm(), sendCommand (), getResponse() in VCR.java. You'll notice Thread.sleep(IO_DELAY) sprinkled in the sendCommand() methods and getResponse(). Without that I get arrays of zeros returned. If the IO_DELAY is less than 15ms then sending commands works fine but reading the responses is not reliable; I mostly get problems when trying to read the last few bytes or a response. Again, everything works fine with Sun's Javacomm w/o the Thread.sleep() on windows. Also, FYI, I tried to run this on a Mac using RXTX 2.0, but I ran into thread synchronization issues. These issues went away when I switched to RXTX 2.1. Cheers B ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining MBARI Software Engineer brian at mbari.org (831)775-1855 http://www.mbari.org/staff/brian I went to the woods because I wished to live deliberately, to front only the essential facts of life, and see if I could not learn what it had to teach, and not, when I came to die, discover that I had not lived. ~ Henry Thoreau -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060711/59b607f3/attachment-0350.html From ajmas at sympatico.ca Wed Jul 12 13:46:51 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 12 Jul 2006 15:46:51 -0400 Subject: [Rxtx] writing first application and compiling Message-ID: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Take a look in the Wiki. I have added a couple of examples in there: http://rxtx.qbang.org/wiki/index.php/Examples Andre > > From: neville seed > Date: 2006/07/10 Mon PM 12:20:12 EDT > To: RXTX Developers and Users > Subject: [Rxtx] writing first application and compiling > > > Can anyone recommend a starting place for writing, > compiling and uploading the first app, ie a simple > hello world. > > It seems that the PALM SDK does not have a build > environment. I am happy to develop under linux of windows. > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Jul 12 19:22:25 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 12 Jul 2006 19:22:25 -0600 (MDT) Subject: [Rxtx] writing first application and compiling In-Reply-To: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Thank you for doing this Andre. I'm sure it will get well used by people learning. I think the old commapi examples are no longer easily available so these are really needed. On Wed, 12 Jul 2006, Andre-John Mas wrote: > Hi, > > Take a look in the Wiki. I have added a couple of examples in there: > > http://rxtx.qbang.org/wiki/index.php/Examples > > Andre > >> >> From: neville seed >> Date: 2006/07/10 Mon PM 12:20:12 EDT >> To: RXTX Developers and Users >> Subject: [Rxtx] writing first application and compiling >> >> >> Can anyone recommend a starting place for writing, >> compiling and uploading the first app, ie a simple >> hello world. >> >> It seems that the PALM SDK does not have a build >> environment. I am happy to develop under linux of windows. >> >> __________________________________________________ >> Do You Yahoo!? >> Tired of spam? Yahoo! Mail has the best spam protection around >> http://mail.yahoo.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Thu Jul 13 17:21:26 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Thu, 13 Jul 2006 19:21:26 -0400 Subject: [Rxtx] writing first application and compiling In-Reply-To: References: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <54D55D35-A143-43AA-AF03-B89ADE9B9246@sympatico.ca> No problems. I would also like to encourage anyone else to contribute other useful stuff they might have. On 12-Jul-06, at 21:22 , Trent Jarvi wrote: > > Thank you for doing this Andre. > > I'm sure it will get well used by people learning. I think the old > commapi examples are no longer easily available so these are really > needed. > > On Wed, 12 Jul 2006, Andre-John Mas wrote: > >> Hi, >> >> Take a look in the Wiki. I have added a couple of examples in there: >> >> http://rxtx.qbang.org/wiki/index.php/Examples >> >> Andre >> >>> >>> From: neville seed >>> Date: 2006/07/10 Mon PM 12:20:12 EDT >>> To: RXTX Developers and Users >>> Subject: [Rxtx] writing first application and compiling >>> >>> >>> Can anyone recommend a starting place for writing, >>> compiling and uploading the first app, ie a simple >>> hello world. >>> >>> It seems that the PALM SDK does not have a build >>> environment. I am happy to develop under linux of windows. >>> >>> __________________________________________________ >>> Do You Yahoo!? >>> Tired of spam? Yahoo! Mail has the best spam protection around >>> http://mail.yahoo.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Sat Jul 8 15:05:46 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sat, 08 Jul 2006 17:05:46 -0400 Subject: [Rxtx] License question. In-Reply-To: <200607082219.59514.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> Message-ID: <44B01E2A.9010207@suespammers.org> Pascal S. de Kloe wrote: > I thought of the same thing. The modified BSD license would certainly make it > more eazy and acceptable for Sun to include RXTX in theire products. > > Unfortunately in general people who chose GPL don't like other licenses. ;) i have a general preference for BSD, but i'll defend RXTX here. RXTX is LGPL, not GPL. they're different, look it up. richard From pascal at quies.net Sun Jul 16 17:40:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 17 Jul 2006 01:40:13 +0200 Subject: [Rxtx] Java installer In-Reply-To: <200607101657.11223.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> Message-ID: <200607170140.14116.pascal@quies.net> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: > > Yes. There are additional methods in gnu.io.SerialPort. We clearly mark > > those as extensions to CommAPI and discourage their use. There just > > isn't a way to get the intended functionality out of CommAPI without > > them. > > If you don't want the users to use the methods then make them class > protected (remove the word "public" before the method) and if you can't do > that we might do the following: > > ---- SerialPort.java > package javax.comm > > class SerialPort extends gnu.io.SerialPort { > > public void > rxtxOnlyMethod() { > throw new Error("Don't use this method here!\nUse gnu.io.SerialPort > instead"); > } > ---- end So how about it, Trent? Can we ship those classes with the next release? From pascal at quies.net Sun Jul 16 17:45:42 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 17 Jul 2006 01:45:42 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> References: <200607081944.41123.pascal@quies.net> <200607091701.24661.pascal@quies.net> <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> Message-ID: <200607170145.43156.pascal@quies.net> Op maandag 10 juli 2006 10:53, schreef Joachim Buechse: > Alternatively you could also include the native lib in your > application jar, extract it at runtime to a temp file, load it with > System.load(). That works indeed. :) I'll finish my "detection class" with such a loader and the RXTX package tomorrow. Then one can simply include the JAR in the classpath and run org.rxtx.CommunicationAPI.initialize() to make sure the API is available. From tjarvi at qbang.org Sun Jul 16 18:59:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 16 Jul 2006 18:59:06 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607170140.14116.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> <200607170140.14116.pascal@quies.net> Message-ID: On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>> Yes. There are additional methods in gnu.io.SerialPort. We clearly mark >>> those as extensions to CommAPI and discourage their use. There just >>> isn't a way to get the intended functionality out of CommAPI without >>> them. >> >> If you don't want the users to use the methods then make them class >> protected (remove the word "public" before the method) and if you can't do >> that we might do the following: >> >> ---- SerialPort.java >> package javax.comm >> >> class SerialPort extends gnu.io.SerialPort { >> >> public void >> rxtxOnlyMethod() { >> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >> instead"); >> } >> ---- end > > So how about it, Trent? > > Can we ship those classes with the next release? Hi Pascal I'm not going to say what people can or can not ship. I'm going to propose removing all of the above extensions from SerialPort.java. I think it is the best thing to do after cooling off a bit. But thats all I've considered at this point. I'm in favor of removing the extensions and staying in gnu.io which more importantly means staying at arms length from javax. I can remove the extensions, put a windows fix in, bump the versions and tag the releases without changing packages if everyone agrees to that. If people want to know why CommAPI has not gone through a JSR which makes it clear rxtx can be in javax.comm and explains how conformancy is determined, I do not think this is the right forum though you can freely do so. -- Trent Jarvi tjarvi at qbang.org From phillip at uow.edu.au Sun Jul 16 22:08:30 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Mon, 17 Jul 2006 14:08:30 +1000 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application" in Mac OSX Message-ID: Hi I downloaded RXTX 2.1-7r2 http://rxtx.org/ (latest download), found the MacOSX folder, manually installed RXTXcomm.jar and librxtxSerial.jnilib in / Library/Java/Extensions and manually setup /var/spool/ucp and became a member of it. I have tried two programs (both built in XCode - TwoWaySerialComm and SerialDemo). Both can find the serial ports but throw a 'port in use exception' with the error "Unknown Application" when I try to open the port. The following is part of the code of TwoWaySerialComm void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { System.out.println("Current owner is " + portIdentifier.getCurrentOwner()); System.out.println("Name is " + this.getClass().getName()); CommPort commPort = portIdentifier.open(this.getClass ().getName(),2000); //throws exception if ( commPort instanceof SerialPort ) The method connect is called from main: public static void main ( String[] args ) { try { listPorts(); (new TwoWaySerialComm()).connect("/dev/tty.KeySerial1"); The following is the console run log of a program TwoWaySerialComm [Session started at 2006-07-14 14:50:29 +1000.] Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.modem - Serial /dev/cu.modem - Serial /dev/tty.KeySerial1 - Serial /dev/cu.KeySerial1 - Serial /dev/tty.USA28X2b2P2.2 - Serial /dev/cu.USA28X2b2P2.2 - Serial 6 ports found Current owner is null Name is TwoWaySerialComm gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:48) at TwoWaySerialComm.main(TwoWaySerialComm.java:163) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at apple.launcher.LaunchRunner.run(LaunchRunner.java:88) at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:50) at apple.launcher.JavaApplicationLauncher.launch (JavaApplicationLauncher.java:52) TwoWaySerialComm has exited with status 0. I am stuck, Can you help me please. thanks Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From pascal at quies.net Mon Jul 17 06:12:09 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 17 Jul 2006 14:12:09 +0200 Subject: [Rxtx] JSR In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607170140.14116.pascal@quies.net> Message-ID: <200607171412.09571.pascal@quies.net> Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: > On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > > Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: > >>> Yes. There are additional methods in gnu.io.SerialPort. We clearly > >>> mark those as extensions to CommAPI and discourage their use. There > >>> just isn't a way to get the intended functionality out of CommAPI > >>> without them. > >> > >> If you don't want the users to use the methods then make them class > >> protected (remove the word "public" before the method) and if you can't > >> do that we might do the following: > >> > >> ---- SerialPort.java > >> package javax.comm > >> > >> class SerialPort extends gnu.io.SerialPort { > >> > >> public void > >> rxtxOnlyMethod() { > >> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort > >> instead"); > >> } > >> ---- end > > > > So how about it, Trent? > > > > Can we ship those classes with the next release? > > Hi Pascal > > I'm not going to say what people can or can not ship. I'm going to > propose removing all of the above extensions from SerialPort.java. I > think it is the best thing to do after cooling off a bit. > > But thats all I've considered at this point. I'm in favor of removing the > extensions and staying in gnu.io which more importantly means staying at > arms length from javax. > > I can remove the extensions, put a windows fix in, bump the versions and > tag the releases without changing packages if everyone agrees to that. > If people want to know why CommAPI has not gone through a JSR which makes > it clear rxtx can be in javax.comm and explains how conformancy is > determined, I do not think this is the right forum though you can freely > do so. Hi Trent, If I understand it correctly you don't want to put those javax.comm classes in the distribution until a JSR completes. :( Sun wants a JSR too to change the API: > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. How about it? I can spend 5 hours a week. From tjarvi at qbang.org Mon Jul 17 07:32:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 07:32:06 -0600 (MDT) Subject: [Rxtx] JSR In-Reply-To: <200607171412.09571.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607170140.14116.pascal@quies.net> <200607171412.09571.pascal@quies.net> Message-ID: On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: >> On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: >>> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>>> Yes. There are additional methods in gnu.io.SerialPort. We clearly >>>>> mark those as extensions to CommAPI and discourage their use. There >>>>> just isn't a way to get the intended functionality out of CommAPI >>>>> without them. >>>> >>>> If you don't want the users to use the methods then make them class >>>> protected (remove the word "public" before the method) and if you can't >>>> do that we might do the following: >>>> >>>> ---- SerialPort.java >>>> package javax.comm >>>> >>>> class SerialPort extends gnu.io.SerialPort { >>>> >>>> public void >>>> rxtxOnlyMethod() { >>>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>>> instead"); >>>> } >>>> ---- end >>> >>> So how about it, Trent? >>> >>> Can we ship those classes with the next release? >> >> Hi Pascal >> >> I'm not going to say what people can or can not ship. I'm going to >> propose removing all of the above extensions from SerialPort.java. I >> think it is the best thing to do after cooling off a bit. >> >> But thats all I've considered at this point. I'm in favor of removing the >> extensions and staying in gnu.io which more importantly means staying at >> arms length from javax. >> >> I can remove the extensions, put a windows fix in, bump the versions and >> tag the releases without changing packages if everyone agrees to that. >> If people want to know why CommAPI has not gone through a JSR which makes >> it clear rxtx can be in javax.comm and explains how conformancy is >> determined, I do not think this is the right forum though you can freely >> do so. > > Hi Trent, > > If I understand it correctly you don't want to put those javax.comm classes in > the distribution until a JSR completes. :( > > Sun wants a JSR too to change the API: >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. > > How about it? I can spend 5 hours a week. Yes. I'm all in favor of this. Dr. Doug Lyon is our fearless leader in these matters and has final say. He has asked everyone if they have an issue with going through the JSR. I have seen no responses though some may have responeded to him in private. I am now working for The MathWorks in a related field. To best represent the RXTX community, we have asked Doug to be the neutral maintainer. This does not mean he is taking on all the work like making releases. He has the ability to and the power. But thats not really spending his time efficiently. It does mean when there are decisions to be made that may have conflicts, he has final say. The easy solution :) is to bug Trent or Doug and see if they will just go into javax.comm namespace. The right solution is to work with Doug and try to get the JSR process completed. I'm willing to help too as time permits. I'm willing to work with Doug. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Jul 17 09:11:20 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 17 Jul 2006 11:11:20 -0400 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Message-ID: <20060717151120.RSBG13653.tomts36-srv.bellnexxia.net@smtp1.sympatico.ca> I am told that this is an issue that will be resolved in 2.1-8. The changes are already in version control, so you can use that. I have and it resolved the problem for me. Phillip McKerrow wrote: > > Hi > > I downloaded RXTX 2.1-7r2 http://rxtx.org/ (latest download), > found the MacOSX folder, > manually installed RXTXcomm.jar and librxtxSerial.jnilib in / > Library/Java/Extensions and > manually setup /var/spool/ucp and became a member of it. > > I have tried two programs (both built in XCode - TwoWaySerialComm and > SerialDemo). Both can find the serial ports but throw a 'port in use > exception' with the error "Unknown Application" when I try to open > the port. > > The following is part of the code of TwoWaySerialComm > void connect ( String portName ) throws Exception > { > CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > if ( portIdentifier.isCurrentlyOwned() ) > { > System.out.println("Error: Port is currently in use"); > } > else > { > System.out.println("Current owner is " + > portIdentifier.getCurrentOwner()); > System.out.println("Name is " + this.getClass().getName()); > CommPort commPort = portIdentifier.open(this.getClass > ().getName(),2000); //throws exception > > if ( commPort instanceof SerialPort ) > > > The method connect is called from main: > public static void main ( String[] args ) > { > try > { > listPorts(); > (new TwoWaySerialComm()).connect("/dev/tty.KeySerial1"); > > > The following is the console run log of a program TwoWaySerialComm > [Session started at 2006-07-14 14:50:29 +1000.] > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > /dev/tty.modem - Serial > /dev/cu.modem - Serial > /dev/tty.KeySerial1 - Serial > /dev/cu.KeySerial1 - Serial > /dev/tty.USA28X2b2P2.2 - Serial > /dev/cu.USA28X2b2P2.2 - Serial > 6 ports found > Current owner is null > Name is TwoWaySerialComm > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at TwoWaySerialComm.connect(TwoWaySerialComm.java:48) > at TwoWaySerialComm.main(TwoWaySerialComm.java:163) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at apple.launcher.LaunchRunner.run(LaunchRunner.java:88) > at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:50) > at apple.launcher.JavaApplicationLauncher.launch > (JavaApplicationLauncher.java:52) > > TwoWaySerialComm has exited with status 0. > > I am stuck, Can you help me please. > > thanks > Phillip > > > ---------------------------------------------------------------------- > Phillip McKerrow http:// > www.uow.edu.au/~phillip/ > School of Information Technology and Computer Science > University of Wollongong * > Northfields Avenue, * * > Wollongong, NSW, 2522. + > AUSTRALIA * the land of the > southern cross > tel : +61 2 4221 3771 fax : +61 2 4221 4170 > > God so loved the world that he gave his one and only Son (Jesus), > that whoever believes in him shall not perish but have eternal life. > John 3:16 > ---------------------------------------------------------------------- > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Mon Jul 17 10:34:14 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 17 Jul 2006 12:34:14 -0400 Subject: [Rxtx] summary of issues In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607170140.14116.pascal@quies.net> <200607171412.09571.pascal@quies.net> Message-ID: Hi All, As I see it, at this stage of the discussion, I think it would be helpful to summarize the concerns. Let me see if I can get this straight, and please correct me, if I am wrong: 1. Sun is making no progress on improving the CommAPI spec. 2. We are seeking to reinvigorate a JSR for the CommAPI in order to keep sun involved. 3. Meanwhile we are extending the RXTX API, with non- commAPI improvements. 4. People are worried that the improvements will be non-portable, when the commAPI re-activates. 5. I have asked for feedback on the JSR approach and obtained zero response. 6. My limited imagination does not see any drawback to taking the JSR approach (except, possibly, from the overhead of a committee, or some license issue that I do not understand). 7. http://www.jcp.org/en/jsr/detail?id=922 shows the status of the JSR now. Status: Withdrawn The sun contact is: vincent.zhang at sun.com I have written to Vincent at Sun to ask him what would be involved with reactivation of JSR 922. If I hear back I will let you know. If there are any objections or suggestions, please let me know. Thanks! - Doug >On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > >> Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: >>> On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: >>>> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>>>> Yes. There are additional methods in gnu.io.SerialPort. We clearly >>>>>> mark those as extensions to CommAPI and discourage their use. There >>>>>> just isn't a way to get the intended functionality out of CommAPI >>>>>> without them. >>>>> >>>>> If you don't want the users to use the methods then make them class >>>>> protected (remove the word "public" before the method) and if you can't >>>>> do that we might do the following: >>>>> >>>>> ---- SerialPort.java >>>>> package javax.comm >>>>> >>>>> class SerialPort extends gnu.io.SerialPort { >>>>> >>>>> public void >>>>> rxtxOnlyMethod() { >>>>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>>>> instead"); >>>>> } >>>>> ---- end >>>> >>>> So how about it, Trent? >>>> >>>> Can we ship those classes with the next release? >>> >>> Hi Pascal >>> >>> I'm not going to say what people can or can not ship. I'm going to >>> propose removing all of the above extensions from SerialPort.java. I >>> think it is the best thing to do after cooling off a bit. >>> >>> But thats all I've considered at this point. I'm in favor of removing the >>> extensions and staying in gnu.io which more importantly means staying at >>> arms length from javax. >>> >>> I can remove the extensions, put a windows fix in, bump the versions and >>> tag the releases without changing packages if everyone agrees to that. >>> If people want to know why CommAPI has not gone through a JSR which makes >>> it clear rxtx can be in javax.comm and explains how conformancy is >>> determined, I do not think this is the right forum though you can freely >>> do so. >> >> Hi Trent, >> >> If I understand it correctly you don't want to put those >>javax.comm classes in >> the distribution until a JSR completes. :( >> >> Sun wants a JSR too to change the API: >>> Ultimately the COMMAPI would be better served if a Java >>> Community Process JSR (http://www.jcp.org) was opened and >>> the COMMAPI was rearchitected to provide a more pluggable >>> framework to improve cross-platform support. Such an >>> architecture would embody a better defined and better >>> documented SPI interface, including a way for comm. ports >>> to be revealed to the client application through the API >>> via platform-aware plugins. Similarly, native code used >>> to access comm port in general could be handled more >>> flexibly using a plugin model, whereby on any platform, >>> multiple native modules could be in use simultaneously. >> >> How about it? I can spend 5 hours a week. > >Yes. I'm all in favor of this. Dr. Doug Lyon is our fearless leader in >these matters and has final say. He has asked everyone if they have an >issue with going through the JSR. I have seen no responses though some >may have responeded to him in private. > >I am now working for The MathWorks in a related field. To best represent >the RXTX community, we have asked Doug to be the neutral maintainer. >This does not mean he is taking on all the work like making releases. He >has the ability to and the power. But thats not really spending his time >efficiently. It does mean when there are decisions to be made that may >have conflicts, he has final say. > >The easy solution :) is to bug Trent or Doug and see if they will just go >into javax.comm namespace. The right solution is to work with Doug and >try to get the JSR process completed. I'm willing to help too as time >permits. > >I'm willing to work with Doug. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jul 17 11:31:58 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 17 Jul 2006 13:31:58 -0400 Subject: [Rxtx] JSR Message-ID: <20060717173158.USWI24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> In the meantime could these methods not be added to a child class. This way the extra functionality can be provided, but you would have to explictly check to see of the class is an RXTX specifc interface. For example: class RxTxCommPort extends CommPort { //RxTx specific methods } CommPort port = commPortIdentifierInstance.open(...); if ( port instanceof RxTxCommPort ) { // do RxTx specifc stuff } // continue doing usual stuff Andre > > From: "Pascal S. de Kloe" > Date: 2006/07/17 Mon AM 08:12:09 EDT > To: RXTX Developers and Users > Subject: [Rxtx] JSR > > Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: > > On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > > > Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: > > >>> Yes. There are additional methods in gnu.io.SerialPort. We clearly > > >>> mark those as extensions to CommAPI and discourage their use. There > > >>> just isn't a way to get the intended functionality out of CommAPI > > >>> without them. > > >> > > >> If you don't want the users to use the methods then make them class > > >> protected (remove the word "public" before the method) and if you can't > > >> do that we might do the following: > > >> > > >> ---- SerialPort.java > > >> package javax.comm > > >> > > >> class SerialPort extends gnu.io.SerialPort { > > >> > > >> public void > > >> rxtxOnlyMethod() { > > >> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort > > >> instead"); > > >> } > > >> ---- end > > > > > > So how about it, Trent? > > > > > > Can we ship those classes with the next release? > > > > Hi Pascal > > > > I'm not going to say what people can or can not ship. I'm going to > > propose removing all of the above extensions from SerialPort.java. I > > think it is the best thing to do after cooling off a bit. > > > > But thats all I've considered at this point. I'm in favor of removing the > > extensions and staying in gnu.io which more importantly means staying at > > arms length from javax. > > > > I can remove the extensions, put a windows fix in, bump the versions and > > tag the releases without changing packages if everyone agrees to that. > > If people want to know why CommAPI has not gone through a JSR which makes > > it clear rxtx can be in javax.comm and explains how conformancy is > > determined, I do not think this is the right forum though you can freely > > do so. > > Hi Trent, > > If I understand it correctly you don't want to put those javax.comm classes in > the distribution until a JSR completes. :( > > Sun wants a JSR too to change the API: > > Ultimately the COMMAPI would be better served if a Java > > Community Process JSR (http://www.jcp.org) was opened and > > the COMMAPI was rearchitected to provide a more pluggable > > framework to improve cross-platform support. Such an > > architecture would embody a better defined and better > > documented SPI interface, including a way for comm. ports > > to be revealed to the client application through the API > > via platform-aware plugins. Similarly, native code used > > to access comm port in general could be handled more > > flexibly using a plugin model, whereby on any platform, > > multiple native modules could be in use simultaneously. > > How about it? I can spend 5 hours a week. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From joachim at buechse.de Mon Jul 17 11:59:19 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 17 Jul 2006 19:59:19 +0200 Subject: [Rxtx] Bumping versions In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> <200607170140.14116.pascal@quies.net> Message-ID: <6ABAF770-41AE-4BA0-800D-2DCC8025FCA8@buechse.de> Hello Trent, I would appreciate if we could get to a version 2.1.8. In fact as several recent posting have shown, almost anyone working on OSX would appreciate getting there. Should anything be removed before that? I dont know. There is nothing wrong with having 2.1.9 following shortly after 2.1.8. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 17.07.2006, at 02:59, Trent Jarvi wrote: > On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > >> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>> Yes. There are additional methods in gnu.io.SerialPort. We >>>> clearly mark >>>> those as extensions to CommAPI and discourage their use. There >>>> just >>>> isn't a way to get the intended functionality out of CommAPI >>>> without >>>> them. >>> >>> If you don't want the users to use the methods then make them class >>> protected (remove the word "public" before the method) and if you >>> can't do >>> that we might do the following: >>> >>> ---- SerialPort.java >>> package javax.comm >>> >>> class SerialPort extends gnu.io.SerialPort { >>> >>> public void >>> rxtxOnlyMethod() { >>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>> instead"); >>> } >>> ---- end >> >> So how about it, Trent? >> >> Can we ship those classes with the next release? > > Hi Pascal > > I'm not going to say what people can or can not ship. I'm going to > propose removing all of the above extensions from SerialPort.java. I > think it is the best thing to do after cooling off a bit. > > But thats all I've considered at this point. I'm in favor of > removing the > extensions and staying in gnu.io which more importantly means > staying at > arms length from javax. > > I can remove the extensions, put a windows fix in, bump the > versions and > tag the releases without changing packages if everyone agrees to that. > If people want to know why CommAPI has not gone through a JSR which > makes > it clear rxtx can be in javax.comm and explains how conformancy is > determined, I do not think this is the right forum though you can > freely > do so. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jul 17 12:40:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 12:40:32 -0600 (MDT) Subject: [Rxtx] Bumping versions In-Reply-To: <6ABAF770-41AE-4BA0-800D-2DCC8025FCA8@buechse.de> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> <200607170140.14116.pascal@quies.net> <6ABAF770-41AE-4BA0-800D-2DCC8025FCA8@buechse.de> Message-ID: Hi Joachim I will work with you towards that. I'm going to the Linux Symposium this week which should mean I have time to tinker. I'll work on rxtx while riding in a carpool to Ottawa. On Mon, 17 Jul 2006, Joachim Buechse wrote: > Hello Trent, > > I would appreciate if we could get to a version 2.1.8. In fact as > several recent posting have shown, almost anyone working on OSX would > appreciate getting there. Should anything be removed before that? I > dont know. There is nothing wrong with having 2.1.9 following shortly > after 2.1.8. > > Regards, > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 17.07.2006, at 02:59, Trent Jarvi wrote: > >> On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: >> >>> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>>> Yes. There are additional methods in gnu.io.SerialPort. We >>>>> clearly mark >>>>> those as extensions to CommAPI and discourage their use. There >>>>> just >>>>> isn't a way to get the intended functionality out of CommAPI >>>>> without >>>>> them. >>>> >>>> If you don't want the users to use the methods then make them class >>>> protected (remove the word "public" before the method) and if you >>>> can't do >>>> that we might do the following: >>>> >>>> ---- SerialPort.java >>>> package javax.comm >>>> >>>> class SerialPort extends gnu.io.SerialPort { >>>> >>>> public void >>>> rxtxOnlyMethod() { >>>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>>> instead"); >>>> } >>>> ---- end >>> >>> So how about it, Trent? >>> >>> Can we ship those classes with the next release? >> >> Hi Pascal >> >> I'm not going to say what people can or can not ship. I'm going to >> propose removing all of the above extensions from SerialPort.java. I >> think it is the best thing to do after cooling off a bit. >> >> But thats all I've considered at this point. I'm in favor of >> removing the >> extensions and staying in gnu.io which more importantly means >> staying at >> arms length from javax. >> >> I can remove the extensions, put a windows fix in, bump the >> versions and >> tag the releases without changing packages if everyone agrees to that. >> If people want to know why CommAPI has not gone through a JSR which >> makes >> it clear rxtx can be in javax.comm and explains how conformancy is >> determined, I do not think this is the right forum though you can >> freely >> do so. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pascal at quies.net Mon Jul 17 17:54:56 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Tue, 18 Jul 2006 01:54:56 +0200 Subject: [Rxtx] summary of issues In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> Message-ID: <200607180154.56359.pascal@quies.net> Op maandag 17 juli 2006 18:34, schreef Dr. Douglas Lyon: > Hi All, > As I see it, at this stage of the discussion, I think it would be helpful > to summarize the concerns. Let me see if I can get this > straight, and please correct me, if I am wrong: Thank you. :) > 1. Sun is making no progress on improving the CommAPI spec. > 2. We are seeking to reinvigorate a JSR for the CommAPI in order > to keep sun involved. Sun wants a JSR becouse they have other concerns than a almost obsolete piece of hardware. > 3. Meanwhile we are extending the RXTX API, with non- > commAPI improvements. > 4. People are worried that the improvements will be non-portable, > when the commAPI re-activates. > 5. I have asked for feedback on the JSR approach and obtained > zero response. > 6. My limited imagination does not see any drawback to taking > the JSR approach (except, possibly, from the overhead of a committee, or > some license issue that I do not understand). > 7. http://www.jcp.org/en/jsr/detail?id=922 shows the status of the JSR now. > Status: Withdrawn > The sun contact is: vincent.zhang at sun.com > I have written to Vincent at Sun to ask him what would be involved with > reactivation of JSR 922. We don't need to communicate with the employees but we need a plan. We need a working implementation with a free license. They have offered us some ideas like in the 2.0.3 README (see attachment). Is there a plan based on the differences of the various platforms? Is there a API purposal? Is there a plan of the JNI? If not I am willing to help. I can write/represent the POSIX part with special interrest of the free UNIX systems. -------------- next part -------------- DISTRIBUTION NOTES: This distribution contains the comm.jar file original part of the COMMAPI 2.0.3 release. The 2.0.3 release itself is no longer distributed. comm.jar, which contains the comm API java class files (eg. Sun's binary implementation of the interface classes), is being made available, unsupported, with no obligation to fix bugs, at the request of the RXTX project. The RxTx project (http://www.rxtx.org), uses the comm.jar class files, but provides their own native library components to provide support for other platforms. The 2.0.3 comm.jar is being provided in this way because as of COMMAPI 3.x, the java binary implementation forked and became incompatible with the RxTx project's native code. Due to the lack of a clear business case, and to resource constraints, no additional resources are being provided to provide an alternative engineering solution at the time of writing. RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: Ultimately the COMMAPI would be better served if a Java Community Process JSR (http://www.jcp.org) was opened and the COMMAPI was rearchitected to provide a more pluggable framework to improve cross-platform support. Such an architecture would embody a better defined and better documented SPI interface, including a way for comm. ports to be revealed to the client application through the API via platform-aware plugins. Similarly, native code used to access comm port in general could be handled more flexibly using a plugin model, whereby on any platform, multiple native modules could be in use simultaneously. Since there are now various ways serial ports can be implemented and accessed, modular comm. port JNI native libraries would be of benefit insofar as removing the burden of over-generalization from any single native component, or inversely, by relieving the implicit constraint that comm. drivers be accessed only via a monolithic mechanism, such as the UNIX vnode interface. paul.klissner at sun.com 6/10/06 From tjarvi at qbang.org Mon Jul 17 18:24:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 18:24:47 -0600 (MDT) Subject: [Rxtx] summary of issues In-Reply-To: <200607180154.56359.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607180154.56359.pascal@quies.net> Message-ID: On Tue, 18 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 17 juli 2006 18:34, schreef Dr. Douglas Lyon: >> Hi All, >> As I see it, at this stage of the discussion, I think it would be helpful >> to summarize the concerns. Let me see if I can get this >> straight, and please correct me, if I am wrong: > > Thank you. :) > >> 1. Sun is making no progress on improving the CommAPI spec. >> 2. We are seeking to reinvigorate a JSR for the CommAPI in order >> to keep sun involved. > > Sun wants a JSR becouse they have other concerns than a almost obsolete piece > of hardware. > >> 3. Meanwhile we are extending the RXTX API, with non- >> commAPI improvements. >> 4. People are worried that the improvements will be non-portable, >> when the commAPI re-activates. >> 5. I have asked for feedback on the JSR approach and obtained >> zero response. >> 6. My limited imagination does not see any drawback to taking >> the JSR approach (except, possibly, from the overhead of a committee, or >> some license issue that I do not understand). >> 7. http://www.jcp.org/en/jsr/detail?id=922 shows the status of the JSR now. >> Status: Withdrawn >> The sun contact is: vincent.zhang at sun.com >> I have written to Vincent at Sun to ask him what would be involved with >> reactivation of JSR 922. > > We don't need to communicate with the employees but we need a plan. We need a > working implementation with a free license. They have offered us some ideas > like in the 2.0.3 README (see attachment). > > Is there a plan based on the differences of the various platforms? Is there a > API purposal? Is there a plan of the JNI? > > If not I am willing to help. I can write/represent the POSIX part with special > interrest of the free UNIX systems. > Not to put words in your mouth but it sounds like you would rather not be in javax.comm namespace at all and do something like a VFS for serial ports as suggested in the readme? Maybe call it a VCS for character streams. That sounds like a major version change rather than an incremental change. So a vote for cutting the ropes and floating in the current? rxtx 3.0 or whatever abandoning current application requirements and perhaps largely rewriting rxtx.. Thats possible and could happen at the same time. An email to Vincent sounds polite enough at this stage. -- Trent Jarvi tjarvi at qbang.org From phillip at uow.edu.au Mon Jul 17 19:33:19 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Tue, 18 Jul 2006 11:33:19 +1000 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application in Mac OSX" Message-ID: <7DBE5FEB-EA06-45BC-ABBE-A9990281E32D@uow.edu.au> Hi We found a workaround - Problem fixed by creating /var/lock directory - seems that they changed the directory from /var/spool/uucp for the lock file but didn't update the documentation. audfg5:~ phillip$ sudo mkdir /var/lock Password: audfg5:~ phillip$ ls -ld /var/lock drwxr-xr-x 2 root wheel 68 Jul 18 09:51 /var/lock audfg5:~ phillip$ sudo chmod 775 /var/lock audfg5:~ phillip$ ls -ld /var/lock drwxrwxr-x 2 root wheel 68 Jul 18 09:51 /var/lock audfg5:~ phillip$ sudo chgrp uucp /var/lock audfg5:~ phillip$ ls -ld /var/lock drwxrwxr-x 2 root uucp 68 Jul 18 09:51 /var/lock audfg5:~ phillip$ ls -l /var/lock total 8 -r--r--r-- 1 phillip uucp 11 Jul 18 09:58 LK.003.009.002 Now both programs work and we get a warning on the console: RXTX Warning: Removing stale lock file. /var/lock/LK.003.009.002 Do we still need the /var/spool/uucp directory?? thanks Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From tjarvi at qbang.org Mon Jul 17 19:40:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 19:40:26 -0600 (MDT) Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application in Mac OSX" In-Reply-To: <7DBE5FEB-EA06-45BC-ABBE-A9990281E32D@uow.edu.au> References: <7DBE5FEB-EA06-45BC-ABBE-A9990281E32D@uow.edu.au> Message-ID: On Tue, 18 Jul 2006, Phillip McKerrow wrote: > Hi > We found a workaround - Problem fixed by creating /var/lock directory > - seems that they changed the directory from /var/spool/uucp for the > lock file but didn't update the documentation. > > audfg5:~ phillip$ sudo mkdir /var/lock > Password: > audfg5:~ phillip$ ls -ld /var/lock > drwxr-xr-x 2 root wheel 68 Jul 18 09:51 /var/lock > audfg5:~ phillip$ sudo chmod 775 /var/lock > audfg5:~ phillip$ ls -ld /var/lock > drwxrwxr-x 2 root wheel 68 Jul 18 09:51 /var/lock > audfg5:~ phillip$ sudo chgrp uucp /var/lock > audfg5:~ phillip$ ls -ld /var/lock > drwxrwxr-x 2 root uucp 68 Jul 18 09:51 /var/lock > audfg5:~ phillip$ ls -l /var/lock > total 8 > -r--r--r-- 1 phillip uucp 11 Jul 18 09:58 LK.003.009.002 > > Now both programs work and we get a warning on the console: > RXTX Warning: Removing stale lock file. /var/lock/LK.003.009.002 > > Do we still need the /var/spool/uucp directory?? > [The new code in CVS will not use Lockfiles on Mac OS X.] The above can happen if you did not close the port before exiting the program. The warning is harmless. RXTX notes that the old program is not running and removes the stale lockfile. -- Trent Jarvi tjarvi at qbang.org From phillip at uow.edu.au Tue Jul 18 01:07:40 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Tue, 18 Jul 2006 17:07:40 +1000 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX Message-ID: Hi I am trying to run a precompiled Java program (JavaKit for setting up the TINI processor over a serial link from http://www.maxim-ic.com/ products/tini/software/downloads.cfm). It uses javax.comm for serial communication. 1. I downloaded the Sparc Solaris version of comm.jar and placed it in /Library/Java/Extensions with RXTXcomm.jar and librxtxSerial.jnilib. 2. I added a javax.com.properties file to /System/Library/Frameworks/ JavaVM.framework/Versions/CurrentJDK/Home/lib It is a text file with one line Driver=gnu.io.RXTXCommDriver 3. When I execute JavaKit it crashes with the following console output audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver (CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:109) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Exception in thread "main" java.lang.UnsatisfiedLinkError: isSessionActive at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts (Portmapping.java:155) at com.sun.comm.Portmapping.refreshPortDatabase (Portmapping.java:100) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:138) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ Home/lib/ext instead of /Library/Java/Extensions it makes no difference: If I use the generic version of comm,jar file from Sun, JavaKit brings up a gui but can't find the serial ports: The console output is: audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while loading driver gnu.io.RXTXCommDriver Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no SolarisSerialParallel in java.library.path Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while loading driver com.sun.comm.SolarisDriver Am I doing something wrong in my efforts to get this going? Should I have another file loaded somewhere or have I run into a bug in RXTX?? thanks again for your help. Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From joachim at buechse.de Tue Jul 18 02:53:38 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 18 Jul 2006 10:53:38 +0200 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: References: Message-ID: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> 2.1.7 is the gnu.io.* version. You need 2.0.7 ie the javax.comm.* version. --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 18.07.2006, at 09:07, Phillip McKerrow wrote: > Hi > > I am trying to run a precompiled Java program (JavaKit for setting up > the TINI processor over a serial link from http://www.maxim-ic.com/ > products/tini/software/downloads.cfm). It uses javax.comm for serial > communication. > > 1. I downloaded the Sparc Solaris version of comm.jar and placed it > in /Library/Java/Extensions with RXTXcomm.jar and > librxtxSerial.jnilib. > > 2. I added a javax.com.properties file to /System/Library/Frameworks/ > JavaVM.framework/Versions/CurrentJDK/Home/lib > It is a text file with one line > Driver=gnu.io.RXTXCommDriver > > 3. When I execute JavaKit it crashes with the following console output > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver > (CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:109) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > Exception in thread "main" java.lang.UnsatisfiedLinkError: > isSessionActive > at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > at com.sun.comm.Portmapping.registerCommPorts > (Portmapping.java:155) > at com.sun.comm.Portmapping.refreshPortDatabase > (Portmapping.java:100) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:138) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > > If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ > Home/lib/ext > instead of /Library/Java/Extensions it makes no difference: > > If I use the generic version of comm,jar file from Sun, JavaKit > brings up a gui but can't find the serial ports: The console > output is: > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while > loading driver gnu.io.RXTXCommDriver > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no > SolarisSerialParallel in java.library.path > Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while > loading driver com.sun.comm.SolarisDriver > > > Am I doing something wrong in my efforts to get this going? Should I > have another file loaded somewhere or have I run into a bug in RXTX?? > > thanks again for your help. > > Phillip > > > ---------------------------------------------------------------------- > Phillip McKerrow http:// > www.uow.edu.au/~phillip/ > School of Information Technology and Computer Science > University of Wollongong * > Northfields Avenue, * * > Wollongong, NSW, 2522. + > AUSTRALIA * the land of the > southern cross > tel : +61 2 4221 3771 fax : +61 2 4221 > 4170 > > God so loved the world that he gave his one and only Son (Jesus), > that whoever believes in him shall not perish but have eternal life. > John 3:16 > ---------------------------------------------------------------------- > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alex at det.ua.pt Tue Jul 18 03:29:15 2006 From: alex at det.ua.pt (Alexandre Mota) Date: Tue, 18 Jul 2006 10:29:15 +0100 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: Message-ID: Hello Edit the JavaKit.java in order to use the gnu.io and compile everything. If you have the RXTX already installed and working it will work. I am using it on linux and windows with jdk 1.5. Best Regards Alexandre -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Phillip McKerrow Sent: ter?a-feira, 18 de Julho de 2006 8:08 To: rxtx at qbang.org Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX Hi I am trying to run a precompiled Java program (JavaKit for setting up the TINI processor over a serial link from http://www.maxim-ic.com/ products/tini/software/downloads.cfm). It uses javax.comm for serial communication. 1. I downloaded the Sparc Solaris version of comm.jar and placed it in /Library/Java/Extensions with RXTXcomm.jar and librxtxSerial.jnilib. 2. I added a javax.com.properties file to /System/Library/Frameworks/ JavaVM.framework/Versions/CurrentJDK/Home/lib It is a text file with one line Driver=gnu.io.RXTXCommDriver 3. When I execute JavaKit it crashes with the following console output audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver (CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:109) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Exception in thread "main" java.lang.UnsatisfiedLinkError: isSessionActive at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts (Portmapping.java:155) at com.sun.comm.Portmapping.refreshPortDatabase (Portmapping.java:100) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:138) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ Home/lib/ext instead of /Library/Java/Extensions it makes no difference: If I use the generic version of comm,jar file from Sun, JavaKit brings up a gui but can't find the serial ports: The console output is: audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while loading driver gnu.io.RXTXCommDriver Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no SolarisSerialParallel in java.library.path Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while loading driver com.sun.comm.SolarisDriver Am I doing something wrong in my efforts to get this going? Should I have another file loaded somewhere or have I run into a bug in RXTX?? thanks again for your help. Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jul 18 04:52:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 18 Jul 2006 04:52:02 -0600 (MDT) Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: References: Message-ID: On Tue, 18 Jul 2006, Phillip McKerrow wrote: > Hi > > I am trying to run a precompiled Java program (JavaKit for setting up > the TINI processor over a serial link from http://www.maxim-ic.com/ > products/tini/software/downloads.cfm). It uses javax.comm for serial > communication. > > 1. I downloaded the Sparc Solaris version of comm.jar and placed it > in /Library/Java/Extensions with RXTXcomm.jar and > librxtxSerial.jnilib. > > 2. I added a javax.com.properties file to /System/Library/Frameworks/ > JavaVM.framework/Versions/CurrentJDK/Home/lib > It is a text file with one line > Driver=gnu.io.RXTXCommDriver > > 3. When I execute JavaKit it crashes with the following console output > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver > (CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:109) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > Exception in thread "main" java.lang.UnsatisfiedLinkError: > isSessionActive > at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > at com.sun.comm.Portmapping.registerCommPorts > (Portmapping.java:155) > at com.sun.comm.Portmapping.refreshPortDatabase > (Portmapping.java:100) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:138) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > > If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ > Home/lib/ext > instead of /Library/Java/Extensions it makes no difference: > > If I use the generic version of comm,jar file from Sun, JavaKit > brings up a gui but can't find the serial ports: The console output is: > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while > loading driver gnu.io.RXTXCommDriver > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no > SolarisSerialParallel in java.library.path > Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while > loading driver com.sun.comm.SolarisDriver > > > Am I doing something wrong in my efforts to get this going? Should I > have another file loaded somewhere or have I run into a bug in RXTX?? > > thanks again for your help. > RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for that. Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Tue Jul 18 16:14:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 18 Jul 2006 18:14:38 -0400 Subject: [Rxtx] jcp and jsr In-Reply-To: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> References: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> Message-ID: Hi All, I have been in touch with: Paul Klissner Please read what Paul writes below. I am not sure, but this might be a good chance for the RXTX group to take action. As to what we should write for the JSR, I am thinking about something in the javax.comm namespace. What is the collective feeling about that? Thanks! - Doug Paul writes: "I think a JSR should be opened, but I don't see any point in proceeding with 922, which never formed and expert group, or provided a specification or reference implementation. It was a placeholder, and the title wasn't even relevant. I think we should discuss our ideas about what we'd like to accomplish and javax.comm and see if we can reach an agreement. You would submit a JSR through the Java Community Process, and if you do, I'd like to represent Sun on the expert group, and contribute to the effort. We may want to start with a fresh specification, borrowing what we want from the current javax.com, adding what we need, and creating a reference implementation. Paul" From pascal at quies.net Tue Jul 18 18:12:26 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 02:12:26 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> Message-ID: <200607190212.27131.pascal@quies.net> Hi Dr., The namespace is the last thing we need to worry about. Let's start with the common goals. For instance the current API is not very object oriented. It might be a good idea to have a static set of objects available representing every supported port available on the system in realtime. Each object should clearly know its own state and its capabilities. To get a port there could be a method like synchronized void connect(PortUser) where PortUser is a interface which handles the interaction with a input and a output stream and listers like PortStillAvailableListener, PortBufferListener and a DataAvailableListener. What is the collective feeling about that? Op woensdag 19 juli 2006 00:14, schreef Dr. Douglas Lyon: > Hi All, > I have been in touch with: > Paul Klissner > Please read what Paul writes below. > I am not sure, but this might be a good chance for > the RXTX group to take action. > As to what we should write for the JSR, I am thinking > about something in the javax.comm namespace. > What is the collective feeling about that? > Thanks! > - Doug > > Paul writes: > "I think a JSR should be opened, but I don't see any point > in proceeding with 922, which never formed and expert group, > or provided a specification or reference implementation. > It was a placeholder, and the title wasn't even relevant. > > I think we should discuss our ideas about what we'd like > to accomplish and javax.comm and see if we can reach an > agreement. > > You would submit a JSR through the Java Community Process, > and if you do, I'd like to represent Sun on the expert group, > and contribute to the effort. We may want to start with > a fresh specification, borrowing what we want from the > current javax.com, adding what we need, and creating > a reference implementation. From phillip at uow.edu.au Tue Jul 18 23:44:25 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Wed, 19 Jul 2006 15:44:25 +1000 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application in Mac OSX" Message-ID: <7EEF3F56-A406-4532-BB3D-AA642A4818CA@uow.edu.au> > > Do we still need the /var/spool/uucp directory?? > > >> Trent Jarvi wrote >>[The new code in CVS will not use Lockfiles on Mac OS X.] Great, that should make installation easier. When will the next version be released? Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From phillip at uow.edu.au Wed Jul 19 00:14:26 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Wed, 19 Jul 2006 16:14:26 +1000 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: References: Message-ID: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> > > Edit the JavaKit.java in order to use the gnu.io and compile > everything. > > Alexandre > Unfotunately all I have is a .jar that contains it. I haven't found the source on their web site. > From: Joachim Buechse > 2.1.7 is the gnu.io.* version. You need 2.0.7 ie the javax.comm.* > version. > > RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for > that. > > Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. > > Trent Jarv I found the rxtx download page and downloaded rxtx-2.0-7pre1 (source/ Mac) The Install folder in ForPackageMaker has librxtxSerial.jnilib and java.com.properties but instead of RXTXComm.jar it has jcl.jar (I have no idea what is is for - it doesn't seem to be a replacement for RXTXCom.jar) I tried to run the XCode project to build it but there is a syntax error - nativeSetSerialPortParams returns a void not a jboolean. Also, there is no target to make RXTXComm.jar JNIEXPORT void JNICALL Java_gnu_io_RXTXPort_nativeSetSerialPortParams (JNIEnv *, jobject, jint, jint, jint, jint); Can you tell me where to find either a working copy of 2.0 for Mac OSX, or RXTXComm.jar or a working XCode project for Version 2. This is getting very frustrating. thanks Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From joachim at buechse.de Wed Jul 19 01:17:03 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 19 Jul 2006 09:17:03 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607190212.27131.pascal@quies.net> References: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> <200607190212.27131.pascal@quies.net> Message-ID: <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> The static objects will work for Windows and Linux, however for OSX they will create problems: - ports can appear and disappear at any time with VCP drivers for USB - the port names are not known until the usb-port is "plugged in" Please do not forget that tty ports can be opened by several applications concurrently. All of those will "loose" the port if anyone opens the corresponding cu port. As this naming based mechanism does not exist on Windows (maybe it does via an API) it should probably be reflected in the API. In other words there are "two levels of open": - Open for reading status lines (1) - Open for reading/writing data (2) I am not sure if state (1) should also allow the modification of certain status lines (ie to set a modem ready). I am also not sure if the api should unify corresponding cu. and tty. ports into one single port. Regards, Joachim On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: > For instance the current API is not very object oriented. > It might be a good idea to have a static set of objects available > representing > every supported port available on the system in realtime. Each > object should > clearly know its own state and its capabilities. To get a port > there could be > a method like synchronized void connect(PortUser) where PortUser is a > interface which handles the interaction with a input and a output > stream and > listers like PortStillAvailableListener, PortBufferListener and a > DataAvailableListener. > > What is the collective feeling about that? From joachim at buechse.de Wed Jul 19 01:29:53 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 19 Jul 2006 09:29:53 +0200 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> References: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> Message-ID: <2D32167B-3830-41D6-9FDD-462301F0453F@buechse.de> As you have already downloaded the source, just cd into the main folder and do a "cvs up -d" this will remove some outdated files and create a new XCode project which should compile without problems. You may also want to search the mail archive or checkout README.OSX for my suggestion on how to avoid the javax.comm.properties file by creating a class com.sun.comm.SolarisDriver. Regards, Joachim PS: I can feel your pain... it was the same for me. In fact I never understood why there are different native or java implementations for 2.0 and 2.1. The two versions could easily be unified by using the simplest of OO programing (intermediate abstract classes). But I guess at the time of branching the direction was not clear. Also the licences are not the same... On 19.07.2006, at 08:14, Phillip McKerrow wrote: >> RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for >> that. >> >> Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. >> >> Trent Jarv > > I found the rxtx download page and downloaded rxtx-2.0-7pre1 (source/ > Mac) > > The Install folder in ForPackageMaker has librxtxSerial.jnilib and > java.com.properties but instead of RXTXComm.jar it has jcl.jar (I > have no idea what is is for - it doesn't seem to be a replacement for > RXTXCom.jar) > > I tried to run the XCode project to build it but there is a syntax > error - nativeSetSerialPortParams returns a void not a jboolean. > Also, there is no target to make RXTXComm.jar > > JNIEXPORT void JNICALL Java_gnu_io_RXTXPort_nativeSetSerialPortParams > (JNIEnv *, jobject, jint, jint, jint, jint); > > Can you tell me where to find either a working copy of 2.0 for Mac > OSX, or RXTXComm.jar or a working XCode project for Version 2. This > is getting very frustrating. > > thanks > > Phillip > > ---------------------------------------------------------------------- > Phillip McKerrow http:// > www.uow.edu.au/~phillip/ > School of Information Technology and Computer Science > University of Wollongong * > Northfields Avenue, * * > Wollongong, NSW, 2522. + > AUSTRALIA * the land of the > southern cross > tel : +61 2 4221 3771 fax : +61 2 4221 > 4170 > > God so loved the world that he gave his one and only Son (Jesus), > that whoever believes in him shall not perish but have eternal life. > John 3:16 > ---------------------------------------------------------------------- > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alex at det.ua.pt Wed Jul 19 03:02:40 2006 From: alex at det.ua.pt (Alexandre Mota) Date: Wed, 19 Jul 2006 10:02:40 +0100 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> References: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> Message-ID: <44BDF530.5080502@det.ua.pt> Phillip McKerrow wrote: >>Edit the JavaKit.java in order to use the gnu.io and compile >>everything. >> >>Alexandre >> >> >> >Unfotunately all I have is a .jar that contains it. I haven't found >the source on their web site. > > > > Download http://files.dalsemi.com/pub/tini/tini1_17.tgz Decompress it and you will find the JavaKiTSrc.jar in the src dir. Decompress it with jar -xf JavaKitSrc.jar and you will get all the source files you need. Alexandre PS: Remenber that puting JavaKit into work is allways a pain... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060719/f5172a01/attachment-0343.html From lyon at docjava.com Wed Jul 19 05:27:47 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 19 Jul 2006 07:27:47 -0400 Subject: [Rxtx] RXTX binary for mac In-Reply-To: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> References: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> Message-ID: Hi All, I have some older RXTX binaries that are deployed in a webstart application. You can try it with: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp The libs are signed and packed for webstart disto by me. http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/ Shows them. - DL > > >> Edit the JavaKit.java in order to use the gnu.io and compile? >> everything. >> >> Alexandre >> >Unfotunately all I have is a .jar that contains it. I haven't found? >the source on their web site. > > >> From: Joachim Buechse >> 2.1.7 is the gnu.io.* version. You need 2.0.7 ie the javax.comm.* >> version. >> > >> RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for? >> that. >> >> Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. >> >> Trent Jarv > >I found the rxtx download page and downloaded rxtx-2.0-7pre1 (source/ >Mac) > >The Install folder in ForPackageMaker has librxtxSerial.jnilib and? >java.com.properties but instead of RXTXComm.jar it has jcl.jar (I? >have no idea what is is for - it doesn't seem to be a replacement for? >RXTXCom.jar) > >I tried to run the XCode project to build it but there is a syntax? >error - nativeSetSerialPortParams returns a void not a jboolean.?? >Also, there is no target to make RXTXComm.jar > >JNIEXPORT void JNICALL Java_gnu_io_RXTXPort_nativeSetSerialPortParams > (JNIEnv *, jobject, jint, jint, jint, jint); > >Can you tell me where to find either a working copy of 2.0 for Mac? >OSX, or RXTXComm.jar or a working XCode project for Version 2. This? >is getting very frustrating. > >thanks > >Phillip > >---------------------------------------------------------------------- >Phillip McKerrow http:// >www.uow.edu.au/~phillip/ >School of Information Technology and Computer Science >University of Wollongong * >Northfields Avenue, * * >Wollongong, NSW, 2522. + >AUSTRALIA * the land of the? >southern cross >tel : +61 2 4221 3771 fax : +61 2 4221 4170 > >God so loved the world that he gave his one and only Son (Jesus), >that whoever believes in him shall not perish but have eternal life. >John 3:16 >---------------------------------------------------------------------- > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Wed Jul 19 06:11:27 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 14:11:27 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> Message-ID: <200607191411.27566.pascal@quies.net> Hi Joachim, Thanks for the constructive critisism. :) Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: > The static objects will work for Windows and Linux, however for OSX > they will create problems: > - ports can appear and disappear at any time with VCP drivers for USB > - the port names are not known until the usb-port is "plugged in" Ports can appear and disappear on *any* OS with USB support. Some Linux distributions even create and remove devicefiles on the fly. With the current API you fetch a list of all available ports and then you try to cast one. What happens if the port is no longer available at that time? What happens if a port vanishes during the data transfer? Of course you can catch exceptions but that makes the code quite messy. The idea was to get a PortStillAvailableListener interface. In that way the implementation is free to handle a cleanup or wait for return routine in a OO way. The I/O streams should just lock. The word static was not ment as persistent but as Java static available. Considder the following: java.lang.hw.HardwareConfiguration { public enum PortType { RS232, I2C, etc. }; /** Gets the currently available ports of type {@code PortType}. */ public static java.lang.hw.Port[] getPorts(PortType); } com.example.Driver implements PortUser, implements PortStillAvailableListener { public portNoLongerAvailable(PortEvent event) { // cleanup & dismiss. } } com.example.Application { public static void main(String[] args) { Driver someDriver = new Driver(); Port radomPort = HardwareConfiguration.getPorts( HardwareConfiguration.PortType.RS232)[1]; myDevice.addStillAvailableListener(someDriver); myDevice.connect(someDriver); } } > Please do not forget that tty ports can be opened by several > applications concurrently. All of those will "loose" the port if > anyone opens the corresponding cu port. Indeed we need a good overview of the differences between the various platforms. Should we create a document or a Wiki for this purpose? FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: http://www.openbsd.org/cgi-bin/man.cgi?query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html Linux uses /var/lock: http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES Is there absolutely no way to get a lock under Windows? > As this naming based > mechanism does not exist on Windows (maybe it does via an API) it > should probably be reflected in the API. In other words there are > "two levels of open": > > - Open for reading status lines (1) > - Open for reading/writing data (2) > > I am not sure if state (1) should also allow the modification of > certain status lines (ie to set a modem ready). I'm not sure I understand. Do you mean canonical and noncanonical mode? How far is Windows with the canonical mode. Is it comparable to POSIX? > I am also not sure if > the api should unify corresponding cu. and tty. ports into one single > port. I think the API should hide low-level details like devicefiles. Who is participating anyway? Is it just the four of us? Cheers, Pascal > On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: > > For instance the current API is not very object oriented. > > It might be a good idea to have a static set of objects available > > representing > > every supported port available on the system in realtime. Each > > object should > > clearly know its own state and its capabilities. To get a port > > there could be > > a method like synchronized void connect(PortUser) where PortUser is a > > interface which handles the interaction with a input and a output > > stream and > > listers like PortStillAvailableListener, PortBufferListener and a > > DataAvailableListener. > > > > What is the collective feeling about that? From joachim at buechse.de Wed Jul 19 07:09:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 19 Jul 2006 15:09:27 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191411.27566.pascal@quies.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> Message-ID: <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> Pascal, I think that the PortNoLongerAvailableListener creates more problems than it solves. I think that exceptions are much better suited for this case. There might be an additional method "Port.isOpen" or "Port.isAvailable" which interested applications may call at times best suited. Most implementations will only find out, that a port disappeared when trying to read or write. Anything else would require polling with a high frequency or kernel hooks that do not exist (in POSIX). Any kind of call back like portNoLongerAvailable() creates the risk of deadlocks and races which require an involved implementation as the library does not know what it is calling (ie a user might try to call close from the callback which can block a very long time). Callbacks introduce concurrency which unneccessarily increases the complexity. Regards, Joachim On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: > Hi Joachim, > > Thanks for the constructive critisism. :) > > Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >> The static objects will work for Windows and Linux, however for OSX >> they will create problems: >> - ports can appear and disappear at any time with VCP drivers for USB >> - the port names are not known until the usb-port is "plugged in" > > Ports can appear and disappear on *any* OS with USB support. Some > Linux > distributions even create and remove devicefiles on the fly. > > With the current API you fetch a list of all available ports and > then you try > to cast one. What happens if the port is no longer available at > that time? > What happens if a port vanishes during the data transfer? Of course > you can > catch exceptions but that makes the code quite messy. > > The idea was to get a PortStillAvailableListener interface. In that > way the > implementation is free to handle a cleanup or wait for return > routine in a OO > way. The I/O streams should just lock. > > The word static was not ment as persistent but as Java static > available. > Considder the following: > > java.lang.hw.HardwareConfiguration { > public enum PortType { RS232, I2C, etc. }; > > /** Gets the currently available ports of type {@code PortType}. */ > public static java.lang.hw.Port[] getPorts(PortType); > } > > com.example.Driver implements PortUser, implements > PortStillAvailableListener > { > public portNoLongerAvailable(PortEvent event) { > // cleanup & dismiss. > } > } > > com.example.Application { > public static void main(String[] args) { > Driver someDriver = new Driver(); > Port radomPort = HardwareConfiguration.getPorts( > HardwareConfiguration.PortType.RS232)[1]; > myDevice.addStillAvailableListener(someDriver); > myDevice.connect(someDriver); > } > } > >> Please do not forget that tty ports can be opened by several >> applications concurrently. All of those will "loose" the port if >> anyone opens the corresponding cu port. > > Indeed we need a good overview of the differences between the various > platforms. Should we create a document or a Wiki for this purpose? > > FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: > http://www.openbsd.org/cgi-bin/man.cgi? > query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD > +Current&arch=i386&format=html > > Linux uses /var/lock: > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > Is there absolutely no way to get a lock under Windows? > >> As this naming based >> mechanism does not exist on Windows (maybe it does via an API) it >> should probably be reflected in the API. In other words there are >> "two levels of open": >> >> - Open for reading status lines (1) >> - Open for reading/writing data (2) >> >> I am not sure if state (1) should also allow the modification of >> certain status lines (ie to set a modem ready). > > I'm not sure I understand. Do you mean canonical and noncanonical > mode? > > How far is Windows with the canonical mode. Is it comparable to POSIX? > >> I am also not sure if >> the api should unify corresponding cu. and tty. ports into one single >> port. > > I think the API should hide low-level details like devicefiles. > > > Who is participating anyway? Is it just the four of us? > > Cheers, > > Pascal > > >> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>> For instance the current API is not very object oriented. >>> It might be a good idea to have a static set of objects available >>> representing >>> every supported port available on the system in realtime. Each >>> object should >>> clearly know its own state and its capabilities. To get a port >>> there could be >>> a method like synchronized void connect(PortUser) where PortUser >>> is a >>> interface which handles the interaction with a input and a output >>> stream and >>> listers like PortStillAvailableListener, PortBufferListener and a >>> DataAvailableListener. >>> >>> What is the collective feeling about that? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Wed Jul 19 08:33:08 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Wed, 19 Jul 2006 11:33:08 -0300 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191411.27566.pascal@quies.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> Message-ID: <44BE42A4.3030203@gmail.com> > Linux uses /var/lock: > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > Is there absolutely no way to get a lock under Windows? Indeed Windows block ports when someone open ones. Java Comm could manage this feature. > Who is participating anyway? Is it just the four of us? I can help too. Regards, Manuel From pascal at quies.net Wed Jul 19 09:01:17 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 17:01:17 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> References: <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> Message-ID: <200607191701.17607.pascal@quies.net> In the POSIX world things are simple. If any transaction fails with ENOTTY we lock the I/O streams and create a PortNoLongerAvailableEvent. We *might* even go so far as to start a thread which polls the tty say once a second afther a PortNoLongerAvailableEvent and kill it if there is succes with a PortAvailableAgainEvent but there won't be anything like deadlocks and races. I promise. ;) Methods like isOpen and isAvailable require polling which is exactly what we both don't want and they can't be reliable since it is a moment. A clean sepparation of the functional code and Listeners for events makes the code better readable and more flexible. PS If OS X has a notification system for changes in the available ports this OS specific functionality is more simple to implement too. Op woensdag 19 juli 2006 15:09, schreef Joachim Buechse: > Pascal, > > I think that the PortNoLongerAvailableListener creates more problems > than it solves. > > I think that exceptions are much better suited for this case. There > might be an additional method "Port.isOpen" or "Port.isAvailable" > which interested applications may call at times best suited. > > Most implementations will only find out, that a port disappeared when > trying to read or write. Anything else would require polling with a > high frequency or kernel hooks that do not exist (in POSIX). Any kind > of call back like portNoLongerAvailable() creates the risk of > deadlocks and races which require an involved implementation as the > library does not know what it is calling (ie a user might try to call > close from the callback which can block a very long time). Callbacks > introduce concurrency which unneccessarily increases the complexity. > > Regards, > Joachim From jredman at ergotech.com Wed Jul 19 09:20:39 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 09:20:39 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191411.27566.pascal@quies.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> Message-ID: <44BE4DC7.7@ergotech.com> Pascal S. de Kloe wrote: >> I am also not sure if >> the api should unify corresponding cu. and tty. ports into one single >> port. > > I think the API should hide low-level details like devicefiles. Not all ports have device files. It's long been my goal to add support for virtual serial ports, that is, serial ports on Ethernet terminal servers, for example integrating RFC2217. This means that the port name is some combination of an IP address and TCP port number. Nothing in /dev. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From brian at mbari.org Wed Jul 19 10:04:51 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 19 Jul 2006 09:04:51 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BE42A4.3030203@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <44BE42A4.3030203@gmail.com> Message-ID: <5FDA8DB5-FD08-4EAA-81A7-C46A7CF6FA18@mbari.org> >> Who is participating anyway? Is it just the four of us? > I'm not much of a POSIX or C guy. But I do a lot of OO design. I'm happy to throw my 2 cents in too. Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060719/404de230/attachment-0342.html From pascal at quies.net Wed Jul 19 10:16:16 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 18:16:16 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BE4DC7.7@ergotech.com> References: <200607191411.27566.pascal@quies.net> <44BE4DC7.7@ergotech.com> Message-ID: <200607191816.17099.pascal@quies.net> Op woensdag 19 juli 2006 17:20, schreef Jim Redman: > Pascal S. de Kloe wrote: > >> I am also not sure if > >> the api should unify corresponding cu. and tty. ports into one single > >> port. > > > > I think the API should hide low-level details like devicefiles. > > Not all ports have device files. It's long been my goal to add support > for virtual serial ports, that is, serial ports on Ethernet terminal > servers, for example integrating RFC2217. This means that the port name > is some combination of an IP address and TCP port number. Nothing in /dev. > > Jim This idea doesn't need any native calls at all, right? How would you like to realize that? Jini? I'm sure you knew that the server is already there: http://www.viara.cn/en/jts.htm From pascal at quies.net Wed Jul 19 10:17:12 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 18:17:12 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <5FDA8DB5-FD08-4EAA-81A7-C46A7CF6FA18@mbari.org> References: <44BE42A4.3030203@gmail.com> <5FDA8DB5-FD08-4EAA-81A7-C46A7CF6FA18@mbari.org> Message-ID: <200607191817.12769.pascal@quies.net> Op woensdag 19 juli 2006 18:04, schreef Brian Schlining: > >> Who is participating anyway? Is it just the four of us? > > I'm not much of a POSIX or C guy. But I do a lot of OO design. I'm > happy to throw my 2 cents in too. > > Brian Schlining > Software Engineer > http://www.mbari.org Excellent! :) We need a lot of opinions from all kinds of users. From jredman at ergotech.com Wed Jul 19 10:54:18 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 10:54:18 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191816.17099.pascal@quies.net> References: <200607191411.27566.pascal@quies.net> <44BE4DC7.7@ergotech.com> <200607191816.17099.pascal@quies.net> Message-ID: <44BE63BA.9090905@ergotech.com> Pascal, Pascal S. de Kloe wrote: > Op woensdag 19 juli 2006 17:20, schreef Jim Redman: >> Pascal S. de Kloe wrote: >>>> I am also not sure if >>>> the api should unify corresponding cu. and tty. ports into one single >>>> port. >>> I think the API should hide low-level details like devicefiles. >> Not all ports have device files. It's long been my goal to add support >> for virtual serial ports, that is, serial ports on Ethernet terminal >> servers, for example integrating RFC2217. This means that the port name >> is some combination of an IP address and TCP port number. Nothing in /dev. >> >> Jim > > This idea doesn't need any native calls at all, right? No native calls, it's just a Socket link. > > How would you like to realize that? I keep wondering that myself. I had in mind port names that are, for example, "192.168.0.99:3000". These would need to be added to the properties file (or the -D option). I'm open for suggestion. It's conceptually, it's the same as USB. Instead of USB->Serial it's Ethernet->Serial. The difference is that the USB devices create virtual serial ports within the OS. Some Ethernet devices also do this, but since, unlike USB communications, TCP/IP is supported natively within Java such a driver is unnecessary. > Jini? Is that still alive and kicking? > > I'm sure you knew that the server is already there: > > http://www.viara.cn/en/jts.htm Yes, that library is part of the plan. These devices are real serial ports. Somewhere, out in the Ether there's a DB9/DB25 cable with RS232/485 bits flowing over it. Since these are real ports, I'd like the ports to look like real serial ports (SerialPort) and not have to handle them as special cases. We have a bunch of code that deals with serial devices (PLCs, Barcode, Temperature Controllers, RFID, SECS, etc. etc.) and to rewrite each one of those to handle this case doesn't make much sense when the correct place to encapsulate a serial port is in the SerialPort layer. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From pascal at quies.net Wed Jul 19 12:44:01 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 20:44:01 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BE63BA.9090905@ergotech.com> References: <200607191816.17099.pascal@quies.net> <44BE63BA.9090905@ergotech.com> Message-ID: <200607192044.01966.pascal@quies.net> Op woensdag 19 juli 2006 18:54, schreef Jim Redman: > I keep wondering that myself. I had in mind port names that are, for > example, "192.168.0.99:3000". These would need to be added to the > properties file (or the -D option). > > I'm open for suggestion. Jini works very well especialy for ethernets like the one you describe. It's a shame that it never got the attention it deserves. > > Jini? > > Is that still alive and kicking? Not that it does matter becouse Java software doesn't need much maintenance. ;) Have a look at http://www.jini.org/. From Paul.Klissner at Sun.COM Wed Jul 19 15:45:38 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 14:45:38 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> Message-ID: <44BEA802.7060508@sun.com> Joachim Buechse wrote: > Pascal, > > I think that the PortNoLongerAvailableListener creates more problems > than it solves. > > I think that exceptions are much better suited for this case. There > might be an additional method "Port.isOpen" or "Port.isAvailable" > which interested applications may call at times best suited. > > Most implementations will only find out, that a port disappeared when > trying to read or write. Anything else would require polling with a > high frequency or kernel hooks that do not exist (in POSIX). Any kind > of call back like portNoLongerAvailable() creates the risk of > deadlocks and races which require an involved implementation as the > library does not know what it is calling (ie a user might try to call > close from the callback which can block a very long time). Callbacks > introduce concurrency which unneccessarily increases the complexity. I think we should find out what are the minimum requirements to get a JSR open, form an expert group, and get that group discussing these things in the JSR. I'm not pushing for Sun to sponsor it, as I think there is a community interest already and that it deserves an independent life and commitment. ACCESS EXCEPTIONS: ----------------- I agree, exceptions of this sort are the way to go. Exceptions are already simpler than having to err check at each function call, so a big improvement. No need to architect a more trouble prone complexity into the API. PROJECT SCOPE: ------------- Also, we should think carefully about what the scope of this project would be. Should it be javax."comm" which handles both serial and parallel (is parallel going by the wayside). Should it be split into two project: javax.EIA232 (or javax.RS232), and javax.IEEE1284? Should we differentiate between single-ended serial protocols, like EIA232, I2C, 2-WIRE, SPI, vs. quasi-multidrop and full multidrop busses such as EIA422, EIA432 and EIA485? If we really were to add I2C support to the API, we'd have to delve into the semantics more, because there could be some implicit decoding of the bus the API users would want to see. At this point, I'm thinking they're all different, and should be their own projects.. perhaps there could be an umbrella layer that abstracted out some of the generic issues like device ownership and access, perhaps not. javax.eia232 javax.eia485 or (javax.EIX4xx?) javax.i2c, javax.spi (or javax.chipbus?) DRIVER PLUGINS: -------------- Taking javax.eia232 for example, I think we need an architecture that allows for multiple plugins to provide multiple simultaneous drivers/adapters to allow for heterogeneous providers on a single system. For example, not only can there be USB based serial devices but networked serial devices, for example accessing devices on thin clients. PORTMAPPING: ----------- For Sun's javax.comm 3.0, we introduced a portmapping abstraction layer, that creates a mechansim to help administer the view (filtering)of available ports given to the application, and the name of such ports. I hope we can consider the right platform neutral way to accomplish that. In javax.comm as it is now, the API has to know where to go and look to find ports. In 3.x I added the ability to specify where to look for standard ports as properties to make it more flexible, but for our thin client platform, which can represent a very dynamic buffet of ports splayed in the leaf nodes of a tree that isn't good enough. That complicates things for the users (having to specify and manage unique and long path names to ports which can come and go), so there is an option whereby the user can configure something like "com1" such that on a thin client it represents the first port of the first USB/serial dongle connected. Javax.comm knows how to find that in the context of the current thin client, but the administrator doesn't have to worry about it. How to architect the API flexibly enough to allow for this kind of thing needs to be considered. Paul > > Regards, > Joachim > > On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: > >> Hi Joachim, >> >> Thanks for the constructive critisism. :) >> >> Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >>> The static objects will work for Windows and Linux, however for OSX >>> they will create problems: >>> - ports can appear and disappear at any time with VCP drivers for USB >>> - the port names are not known until the usb-port is "plugged in" >> Ports can appear and disappear on *any* OS with USB support. Some >> Linux >> distributions even create and remove devicefiles on the fly. >> >> With the current API you fetch a list of all available ports and >> then you try >> to cast one. What happens if the port is no longer available at >> that time? >> What happens if a port vanishes during the data transfer? Of course >> you can >> catch exceptions but that makes the code quite messy. >> >> The idea was to get a PortStillAvailableListener interface. In that >> way the >> implementation is free to handle a cleanup or wait for return >> routine in a OO >> way. The I/O streams should just lock. >> >> The word static was not ment as persistent but as Java static >> available. >> Considder the following: >> >> java.lang.hw.HardwareConfiguration { >> public enum PortType { RS232, I2C, etc. }; >> >> /** Gets the currently available ports of type {@code PortType}. */ >> public static java.lang.hw.Port[] getPorts(PortType); >> } >> >> com.example.Driver implements PortUser, implements >> PortStillAvailableListener >> { >> public portNoLongerAvailable(PortEvent event) { >> // cleanup & dismiss. >> } >> } >> >> com.example.Application { >> public static void main(String[] args) { >> Driver someDriver = new Driver(); >> Port radomPort = HardwareConfiguration.getPorts( >> HardwareConfiguration.PortType.RS232)[1]; >> myDevice.addStillAvailableListener(someDriver); >> myDevice.connect(someDriver); >> } >> } >> >>> Please do not forget that tty ports can be opened by several >>> applications concurrently. All of those will "loose" the port if >>> anyone opens the corresponding cu port. >> Indeed we need a good overview of the differences between the various >> platforms. Should we create a document or a Wiki for this purpose? >> >> FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: >> http://www.openbsd.org/cgi-bin/man.cgi? >> query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD >> +Current&arch=i386&format=html >> >> Linux uses /var/lock: >> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES >> >> Is there absolutely no way to get a lock under Windows? >> >>> As this naming based >>> mechanism does not exist on Windows (maybe it does via an API) it >>> should probably be reflected in the API. In other words there are >>> "two levels of open": >>> >>> - Open for reading status lines (1) >>> - Open for reading/writing data (2) >>> >>> I am not sure if state (1) should also allow the modification of >>> certain status lines (ie to set a modem ready). >> I'm not sure I understand. Do you mean canonical and noncanonical >> mode? >> >> How far is Windows with the canonical mode. Is it comparable to POSIX? >> >>> I am also not sure if >>> the api should unify corresponding cu. and tty. ports into one single >>> port. >> I think the API should hide low-level details like devicefiles. >> >> >> Who is participating anyway? Is it just the four of us? >> >> Cheers, >> >> Pascal >> >> >>> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>>> For instance the current API is not very object oriented. >>>> It might be a good idea to have a static set of objects available >>>> representing >>>> every supported port available on the system in realtime. Each >>>> object should >>>> clearly know its own state and its capabilities. To get a port >>>> there could be >>>> a method like synchronized void connect(PortUser) where PortUser >>>> is a >>>> interface which handles the interaction with a input and a output >>>> stream and >>>> listers like PortStillAvailableListener, PortBufferListener and a >>>> DataAvailableListener. >>>> >>>> What is the collective feeling about that? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Wed Jul 19 16:32:37 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 16:32:37 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEA802.7060508@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <44BEB305.3030208@ergotech.com> For one, I'd object to the splitting of 232 and 485 and question why it's necessary. Often the only difference between 232 access and 485 access is whether there's a converter attached to the serial port. Put another way, while 485 is multidrop, I think that's an application level issue rather than a driver level issue. If the issue is electrical, I don't think that it's possible to reliably support receiver switching of a 2-wire 485 network within Java, the timing is just too tight, so your stuck with requiring a 485 converter that automatically switches (not an onerous burden for us) or some OS level intervention. Anyway, if we're going to start differentiating at the electrical level we still support some current loop systems (Siemens S5 PLC if you care). Jim Paul Klissner wrote: > Joachim Buechse wrote: >> Pascal, >> >> I think that the PortNoLongerAvailableListener creates more problems >> than it solves. >> >> I think that exceptions are much better suited for this case. There >> might be an additional method "Port.isOpen" or "Port.isAvailable" >> which interested applications may call at times best suited. >> >> Most implementations will only find out, that a port disappeared when >> trying to read or write. Anything else would require polling with a >> high frequency or kernel hooks that do not exist (in POSIX). Any kind >> of call back like portNoLongerAvailable() creates the risk of >> deadlocks and races which require an involved implementation as the >> library does not know what it is calling (ie a user might try to call >> close from the callback which can block a very long time). Callbacks >> introduce concurrency which unneccessarily increases the complexity. > > I think we should find out what are the minimum requirements > to get a JSR open, form an expert group, and get that group > discussing these things in the JSR. I'm not pushing for > Sun to sponsor it, as I think there is a community interest > already and that it deserves an independent life and > commitment. > > ACCESS EXCEPTIONS: > ----------------- > I agree, exceptions of this sort are the way to go. > Exceptions are already simpler than having to err > check at each function call, so a big improvement. > No need to architect a more trouble prone complexity > into the API. > > PROJECT SCOPE: > ------------- > > Also, we should think carefully about what the scope of > this project would be. Should it be javax."comm" which > handles both serial and parallel (is parallel going by the > wayside). Should it be split into two project: > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > > Should we differentiate between single-ended serial > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > quasi-multidrop and full multidrop busses such as > EIA422, EIA432 and EIA485? If we really were to > add I2C support to the API, we'd have to delve into > the semantics more, because there could be some > implicit decoding of the bus the API users would > want to see. > > At this point, I'm thinking they're all different, > and should be their own projects.. perhaps there > could be an umbrella layer that abstracted out > some of the generic issues like device ownership > and access, perhaps not. > > javax.eia232 > javax.eia485 or (javax.EIX4xx?) > javax.i2c, javax.spi (or javax.chipbus?) > > DRIVER PLUGINS: > -------------- > Taking javax.eia232 for example, I think we need an > architecture that allows for multiple plugins to > provide multiple simultaneous drivers/adapters to > allow for heterogeneous providers on a single system. > For example, not only can there be USB based serial > devices but networked serial devices, for example > accessing devices on thin clients. > > PORTMAPPING: > ----------- > For Sun's javax.comm 3.0, we introduced a portmapping > abstraction layer, that creates a mechansim to help > administer the view (filtering)of available ports given > to the application, and the name of such ports. I hope we > can consider the right platform neutral way to > accomplish that. > > In javax.comm as it is now, the API has to know > where to go and look to find ports. In 3.x I added > the ability to specify where to look for standard > ports as properties to make it more flexible, but > for our thin client platform, which can represent > a very dynamic buffet of ports splayed in the > leaf nodes of a tree that isn't good enough. > That complicates things for the users (having > to specify and manage unique and long path names > to ports which can come and go), so there is > an option whereby the user can configure > something like "com1" such that on a thin client > it represents the first port of the first USB/serial > dongle connected. Javax.comm knows how to find > that in the context of the current thin client, > but the administrator doesn't have to worry about it. > > How to architect the API flexibly enough to allow > for this kind of thing needs to be considered. > > Paul > > > >> Regards, >> Joachim >> >> On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: >> >>> Hi Joachim, >>> >>> Thanks for the constructive critisism. :) >>> >>> Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >>>> The static objects will work for Windows and Linux, however for OSX >>>> they will create problems: >>>> - ports can appear and disappear at any time with VCP drivers for USB >>>> - the port names are not known until the usb-port is "plugged in" >>> Ports can appear and disappear on *any* OS with USB support. Some >>> Linux >>> distributions even create and remove devicefiles on the fly. >>> >>> With the current API you fetch a list of all available ports and >>> then you try >>> to cast one. What happens if the port is no longer available at >>> that time? >>> What happens if a port vanishes during the data transfer? Of course >>> you can >>> catch exceptions but that makes the code quite messy. >>> >>> The idea was to get a PortStillAvailableListener interface. In that >>> way the >>> implementation is free to handle a cleanup or wait for return >>> routine in a OO >>> way. The I/O streams should just lock. >>> >>> The word static was not ment as persistent but as Java static >>> available. >>> Considder the following: >>> >>> java.lang.hw.HardwareConfiguration { >>> public enum PortType { RS232, I2C, etc. }; >>> >>> /** Gets the currently available ports of type {@code PortType}. */ >>> public static java.lang.hw.Port[] getPorts(PortType); >>> } >>> >>> com.example.Driver implements PortUser, implements >>> PortStillAvailableListener >>> { >>> public portNoLongerAvailable(PortEvent event) { >>> // cleanup & dismiss. >>> } >>> } >>> >>> com.example.Application { >>> public static void main(String[] args) { >>> Driver someDriver = new Driver(); >>> Port radomPort = HardwareConfiguration.getPorts( >>> HardwareConfiguration.PortType.RS232)[1]; >>> myDevice.addStillAvailableListener(someDriver); >>> myDevice.connect(someDriver); >>> } >>> } >>> >>>> Please do not forget that tty ports can be opened by several >>>> applications concurrently. All of those will "loose" the port if >>>> anyone opens the corresponding cu port. >>> Indeed we need a good overview of the differences between the various >>> platforms. Should we create a document or a Wiki for this purpose? >>> >>> FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: >>> http://www.openbsd.org/cgi-bin/man.cgi? >>> query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD >>> +Current&arch=i386&format=html >>> >>> Linux uses /var/lock: >>> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES >>> >>> Is there absolutely no way to get a lock under Windows? >>> >>>> As this naming based >>>> mechanism does not exist on Windows (maybe it does via an API) it >>>> should probably be reflected in the API. In other words there are >>>> "two levels of open": >>>> >>>> - Open for reading status lines (1) >>>> - Open for reading/writing data (2) >>>> >>>> I am not sure if state (1) should also allow the modification of >>>> certain status lines (ie to set a modem ready). >>> I'm not sure I understand. Do you mean canonical and noncanonical >>> mode? >>> >>> How far is Windows with the canonical mode. Is it comparable to POSIX? >>> >>>> I am also not sure if >>>> the api should unify corresponding cu. and tty. ports into one single >>>> port. >>> I think the API should hide low-level details like devicefiles. >>> >>> >>> Who is participating anyway? Is it just the four of us? >>> >>> Cheers, >>> >>> Pascal >>> >>> >>>> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>>>> For instance the current API is not very object oriented. >>>>> It might be a good idea to have a static set of objects available >>>>> representing >>>>> every supported port available on the system in realtime. Each >>>>> object should >>>>> clearly know its own state and its capabilities. To get a port >>>>> there could be >>>>> a method like synchronized void connect(PortUser) where PortUser >>>>> is a >>>>> interface which handles the interaction with a input and a output >>>>> stream and >>>>> listers like PortStillAvailableListener, PortBufferListener and a >>>>> DataAvailableListener. >>>>> >>>>> What is the collective feeling about that? >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Paul.Klissner at Sun.COM Wed Jul 19 17:31:36 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 16:31:36 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEB305.3030208@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> Message-ID: <44BEC0D8.4050806@sun.com> Jim Redman wrote: > For one, I'd object to the splitting of 232 and 485 and question why > it's necessary. Often the only difference between 232 access and 485 > access is whether there's a converter attached to the serial port. > > Put another way, while 485 is multidrop, I think that's an application > level issue rather than a driver level issue. > > If the issue is electrical, I don't think that it's possible to reliably > support receiver switching of a 2-wire 485 network within Java, the > timing is just too tight, so your stuck with requiring a 485 converter > that automatically switches (not an onerous burden for us) or some OS > level intervention. > > Anyway, if we're going to start differentiating at the electrical level > we still support some current loop systems (Siemens S5 PLC if you care). > > Jim To be honest, I've not done anything with 422, 423 or 485, so I have no objection to keeping them together if there isn't enough of a protocol distinction to make it worth seperating them out. I'd just like to find another suitable name than javax.comm, unless the JSR wants to start with javax.comm 4.0, since all the previous 'major revisions' are accounted for. javax.serialport? Paul > > Paul Klissner wrote: >> Joachim Buechse wrote: >>> Pascal, >>> >>> I think that the PortNoLongerAvailableListener creates more problems >>> than it solves. >>> >>> I think that exceptions are much better suited for this case. There >>> might be an additional method "Port.isOpen" or "Port.isAvailable" >>> which interested applications may call at times best suited. >>> >>> Most implementations will only find out, that a port disappeared when >>> trying to read or write. Anything else would require polling with a >>> high frequency or kernel hooks that do not exist (in POSIX). Any kind >>> of call back like portNoLongerAvailable() creates the risk of >>> deadlocks and races which require an involved implementation as the >>> library does not know what it is calling (ie a user might try to call >>> close from the callback which can block a very long time). Callbacks >>> introduce concurrency which unneccessarily increases the complexity. >> I think we should find out what are the minimum requirements >> to get a JSR open, form an expert group, and get that group >> discussing these things in the JSR. I'm not pushing for >> Sun to sponsor it, as I think there is a community interest >> already and that it deserves an independent life and >> commitment. >> >> ACCESS EXCEPTIONS: >> ----------------- >> I agree, exceptions of this sort are the way to go. >> Exceptions are already simpler than having to err >> check at each function call, so a big improvement. >> No need to architect a more trouble prone complexity >> into the API. >> >> PROJECT SCOPE: >> ------------- >> >> Also, we should think carefully about what the scope of >> this project would be. Should it be javax."comm" which >> handles both serial and parallel (is parallel going by the >> wayside). Should it be split into two project: >> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >> >> Should we differentiate between single-ended serial >> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >> quasi-multidrop and full multidrop busses such as >> EIA422, EIA432 and EIA485? If we really were to >> add I2C support to the API, we'd have to delve into >> the semantics more, because there could be some >> implicit decoding of the bus the API users would >> want to see. >> >> At this point, I'm thinking they're all different, >> and should be their own projects.. perhaps there >> could be an umbrella layer that abstracted out >> some of the generic issues like device ownership >> and access, perhaps not. >> >> javax.eia232 >> javax.eia485 or (javax.EIX4xx?) >> javax.i2c, javax.spi (or javax.chipbus?) >> >> DRIVER PLUGINS: >> -------------- >> Taking javax.eia232 for example, I think we need an >> architecture that allows for multiple plugins to >> provide multiple simultaneous drivers/adapters to >> allow for heterogeneous providers on a single system. >> For example, not only can there be USB based serial >> devices but networked serial devices, for example >> accessing devices on thin clients. >> >> PORTMAPPING: >> ----------- >> For Sun's javax.comm 3.0, we introduced a portmapping >> abstraction layer, that creates a mechansim to help >> administer the view (filtering)of available ports given >> to the application, and the name of such ports. I hope we >> can consider the right platform neutral way to >> accomplish that. >> >> In javax.comm as it is now, the API has to know >> where to go and look to find ports. In 3.x I added >> the ability to specify where to look for standard >> ports as properties to make it more flexible, but >> for our thin client platform, which can represent >> a very dynamic buffet of ports splayed in the >> leaf nodes of a tree that isn't good enough. >> That complicates things for the users (having >> to specify and manage unique and long path names >> to ports which can come and go), so there is >> an option whereby the user can configure >> something like "com1" such that on a thin client >> it represents the first port of the first USB/serial >> dongle connected. Javax.comm knows how to find >> that in the context of the current thin client, >> but the administrator doesn't have to worry about it. >> >> How to architect the API flexibly enough to allow >> for this kind of thing needs to be considered. >> >> Paul >> >> >> >>> Regards, >>> Joachim >>> >>> On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: >>> >>>> Hi Joachim, >>>> >>>> Thanks for the constructive critisism. :) >>>> >>>> Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >>>>> The static objects will work for Windows and Linux, however for OSX >>>>> they will create problems: >>>>> - ports can appear and disappear at any time with VCP drivers for USB >>>>> - the port names are not known until the usb-port is "plugged in" >>>> Ports can appear and disappear on *any* OS with USB support. Some >>>> Linux >>>> distributions even create and remove devicefiles on the fly. >>>> >>>> With the current API you fetch a list of all available ports and >>>> then you try >>>> to cast one. What happens if the port is no longer available at >>>> that time? >>>> What happens if a port vanishes during the data transfer? Of course >>>> you can >>>> catch exceptions but that makes the code quite messy. >>>> >>>> The idea was to get a PortStillAvailableListener interface. In that >>>> way the >>>> implementation is free to handle a cleanup or wait for return >>>> routine in a OO >>>> way. The I/O streams should just lock. >>>> >>>> The word static was not ment as persistent but as Java static >>>> available. >>>> Considder the following: >>>> >>>> java.lang.hw.HardwareConfiguration { >>>> public enum PortType { RS232, I2C, etc. }; >>>> >>>> /** Gets the currently available ports of type {@code PortType}. */ >>>> public static java.lang.hw.Port[] getPorts(PortType); >>>> } >>>> >>>> com.example.Driver implements PortUser, implements >>>> PortStillAvailableListener >>>> { >>>> public portNoLongerAvailable(PortEvent event) { >>>> // cleanup & dismiss. >>>> } >>>> } >>>> >>>> com.example.Application { >>>> public static void main(String[] args) { >>>> Driver someDriver = new Driver(); >>>> Port radomPort = HardwareConfiguration.getPorts( >>>> HardwareConfiguration.PortType.RS232)[1]; >>>> myDevice.addStillAvailableListener(someDriver); >>>> myDevice.connect(someDriver); >>>> } >>>> } >>>> >>>>> Please do not forget that tty ports can be opened by several >>>>> applications concurrently. All of those will "loose" the port if >>>>> anyone opens the corresponding cu port. >>>> Indeed we need a good overview of the differences between the various >>>> platforms. Should we create a document or a Wiki for this purpose? >>>> >>>> FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: >>>> http://www.openbsd.org/cgi-bin/man.cgi? >>>> query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD >>>> +Current&arch=i386&format=html >>>> >>>> Linux uses /var/lock: >>>> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES >>>> >>>> Is there absolutely no way to get a lock under Windows? >>>> >>>>> As this naming based >>>>> mechanism does not exist on Windows (maybe it does via an API) it >>>>> should probably be reflected in the API. In other words there are >>>>> "two levels of open": >>>>> >>>>> - Open for reading status lines (1) >>>>> - Open for reading/writing data (2) >>>>> >>>>> I am not sure if state (1) should also allow the modification of >>>>> certain status lines (ie to set a modem ready). >>>> I'm not sure I understand. Do you mean canonical and noncanonical >>>> mode? >>>> >>>> How far is Windows with the canonical mode. Is it comparable to POSIX? >>>> >>>>> I am also not sure if >>>>> the api should unify corresponding cu. and tty. ports into one single >>>>> port. >>>> I think the API should hide low-level details like devicefiles. >>>> >>>> >>>> Who is participating anyway? Is it just the four of us? >>>> >>>> Cheers, >>>> >>>> Pascal >>>> >>>> >>>>> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>>>>> For instance the current API is not very object oriented. >>>>>> It might be a good idea to have a static set of objects available >>>>>> representing >>>>>> every supported port available on the system in realtime. Each >>>>>> object should >>>>>> clearly know its own state and its capabilities. To get a port >>>>>> there could be >>>>>> a method like synchronized void connect(PortUser) where PortUser >>>>>> is a >>>>>> interface which handles the interaction with a input and a output >>>>>> stream and >>>>>> listers like PortStillAvailableListener, PortBufferListener and a >>>>>> DataAvailableListener. >>>>>> >>>>>> What is the collective feeling about that? >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Wed Jul 19 18:03:40 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 18:03:40 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEC0D8.4050806@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> Message-ID: <44BEC85C.2030809@ergotech.com> Paul Klissner wrote: > I'd just like to find another suitable name than javax.comm, unless > the JSR wants to start with javax.comm 4.0, since all the previous > 'major revisions' are accounted for. javax.serialport? Which perhaps brings us back to what are we trying to fix and how badly. There are a number of 3rd party implementation of Java Comm, at least one from IBM - part of what was J9, now Websphere, or something (presumbly soon to get a name that has eclipse in it sometime soon). Esmertec has one, and there are few others rolling around. If RXTX is the only implementation of the JSR with no backward compatibility, we've just forked Java Serial support and we (for a least one) will be worse off. We won't be able to use the new support because of a lack of support on J2ME platforms that we have no control over and RXTX/current JavaComm will be in maintenance mode or unsupported on all other platforms. So, is there any chance of building a compatibility requirement into this. To pick are really bad example JDBC has support for a DataSource or a Driver. Could we have an ExcellentSerialPort with a fallback to a SerialPort on a class not found exception? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From pascal at quies.net Wed Jul 19 18:22:45 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Thu, 20 Jul 2006 02:22:45 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEC85C.2030809@ergotech.com> References: <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> Message-ID: <200607200222.46023.pascal@quies.net> Op donderdag 20 juli 2006 02:03, schreef Jim Redman: > Which perhaps brings us back to what are we trying to fix and how badly. The initail problem was the license. :) RXTX is sitting in this gnu.comm namespace and is afraid to go to javax.comm. Getting a JSR would solve this problem. And while we're at it we might as well improve the situation with the various platforms. I made some sugestions that where denied as too complex. Cheers, Pascal From Paul.Klissner at Sun.COM Wed Jul 19 19:09:35 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 18:09:35 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607200222.46023.pascal@quies.net> References: <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <200607200222.46023.pascal@quies.net> Message-ID: <44BED7CF.5080405@sun.com> Pascal S. de Kloe wrote: > Op donderdag 20 juli 2006 02:03, schreef Jim Redman: >> Which perhaps brings us back to what are we trying to fix and how badly. > > The initail problem was the license. :) > > RXTX is sitting in this gnu.comm namespace and is afraid to go to javax.comm. > Getting a JSR would solve this problem. > > And while we're at it we might as well improve the situation with the various > platforms. I made some sugestions that where denied as too complex. "Denied" is a bit harsh :) I'll re-examine your e-mails to see if my preferences change. It's not like your proposition has been put up to a formal vote, just discussion. Paul From Paul.Klissner at Sun.COM Wed Jul 19 19:28:47 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 18:28:47 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEC85C.2030809@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> Message-ID: <44BEDC4F.9030403@sun.com> Jim Redman wrote: > Paul Klissner wrote: >> I'd just like to find another suitable name than javax.comm, unless >> the JSR wants to start with javax.comm 4.0, since all the previous >> 'major revisions' are accounted for. javax.serialport? > > Which perhaps brings us back to what are we trying to fix and how badly. The goals I'm most interested in at the moment are: 1. A pluggable platform portmapping scheme wherein each platform can determine which ports to present to the application, and preferably as some configurable logical name. For example on the Sun Ray thin client platform, if an application aquiring a view of serial ports available on the system, it will be informed of Sun Ray serial ports if the application is running in a session currently directed to that particular Sun Ray unit, even though the serial port's device node happens to be server-side deeply nested in a leaf node. If the application is not running on a Sun Ray the port doesn't show up. The Sun Ray plugin would make the decision about when and which ports to present to the application. 2. Pluggable driver-side interface where multiple platform-specific drivers can be utilized simultaneously to introduce more flexibility with the back end. > There are a number of 3rd party implementation of Java Comm, at least > one from IBM - part of what was J9, now Websphere, or something > (presumbly soon to get a name that has eclipse in it sometime soon). > Esmertec has one, and there are few others rolling around. I have not been advocating gutting the API, since much of it is perfectly adequate. I'm not totally opposed to making substantial changes or improvements depending on other people's needs. There's no reason previous versions of javax.comm need to suddenly disappear if products need legacy support. > > If RXTX is the only implementation of the JSR with no backward > compatibility, we've just forked Java Serial support and we (for a least > one) will be worse off. We won't be able to use the new support because > of a lack of support on J2ME platforms that we have no control over and > RXTX/current JavaComm will be in maintenance mode or unsupported on all > other platforms. There can't be *that* many platforms this is ported to. And it will be no javax.usb. Seems like most of the standard platforms will be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, JDBC... > > So, is there any chance of building a compatibility requirement into > this. To pick are really bad example JDBC has support for a DataSource > or a Driver. Could we have an ExcellentSerialPort with a fallback to a > SerialPort on a class not found exception? Maybe, or maybe we just let people know what we are doing and try to figure out how to get their applications ported. Might not be that difficult. From my standpoint anyway, earthshaking changes aren't really necessary. Others might disagree. Paul From rwelty at averillpark.net Wed Jul 19 19:35:54 2006 From: rwelty at averillpark.net (Richard P. Welty) Date: Wed, 19 Jul 2006 21:35:54 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter Message-ID: <44BEDDFA.7020108@averillpark.net> I'm returning to the use of rxtx after 2 years off doing things that don't need serial ports. I'm trying to get my laptop (fedora core 1) talking to a set of portable auto scales through a Keyspan USB adapter (in my past use of rxtx, I had actual serial ports, but those days are long gone.) I have the keyspan kernel module loaded, and lsusb shows the device as correctly identified. I'm missing the bit of magic needed to get rxtx to provide the port in response to CommPortIdentifier.getPortIdentifiers() thanks in advance for any help, richard From jredman at ergotech.com Wed Jul 19 19:43:25 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 19:43:25 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BED7CF.5080405@sun.com> References: <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <200607200222.46023.pascal@quies.net> <44BED7CF.5080405@sun.com> Message-ID: <44BEDFBD.4020404@ergotech.com> Paul Klissner wrote: > Pascal S. de Kloe wrote: >> Op donderdag 20 juli 2006 02:03, schreef Jim Redman: >>> Which perhaps brings us back to what are we trying to fix and how badly. >> The initail problem was the license. :) >> >> RXTX is sitting in this gnu.comm namespace and is afraid to go to javax.comm. >> Getting a JSR would solve this problem. >> >> And while we're at it we might as well improve the situation with the various >> platforms. I made some sugestions that where denied as too complex. > > "Denied" is a bit harsh :) I'll re-examine your e-mails > to see if my preferences change. It's not like your > proposition has been put up to a formal vote, just discussion. OK, I'll officially float backwards compatibility in the form of "It should be possible to use anything that comes out of the JSR in place of an existing java comm implementation". I wonder if "Denied" is too harsh for that one :) Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From ajmas at sympatico.ca Wed Jul 19 19:47:06 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Wed, 19 Jul 2006 21:47:06 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEDDFA.7020108@averillpark.net> References: <44BEDDFA.7020108@averillpark.net> Message-ID: <35101C10-59A5-4F02-AEEE-DB69112F8130@sympatico.ca> Do you see an associated device in /dev ? On 19-Jul-06, at 21:35 , Richard P. Welty wrote: > I'm returning to the use of rxtx after 2 years off doing > things that don't need serial ports. > > I'm trying to get my laptop (fedora core 1) talking to a > set of portable auto scales through a Keyspan USB adapter > (in my past use of rxtx, I had actual serial ports, but those > days are long gone.) I have the keyspan kernel module loaded, > and lsusb shows the device as correctly identified. I'm missing > the bit of magic needed to get rxtx to provide the port > in response to CommPortIdentifier.getPortIdentifiers() > > thanks in advance for any help, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Wed Jul 19 19:54:03 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 19:54:03 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEDC4F.9030403@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> Message-ID: <44BEE23B.30908@ergotech.com> Paul, For the record we're STILL supporting some PersonalJava platforms. We're _almost_ at the point where we can assume that the platforms will have a Collections framework, but routinely compile with a 1.1 check so that we don't make that assumption unnecessarily. Of 50+ non-graphical Factory Automation JavaBeans we have 2 that require Java2 (Reporting and JavaScripting), and we have people asking for a back-port. Embedded platforms don't change in a hurry. Unlike desktop platforms, embedded systems are expected to last 5-10+ years. There are factory automation vendors in the pharmaceutical industry who are buying systems on eBay because that's the FDA validate platform. It must be that make/model, spec'd sometime in the mid-90's. So... If you make an incompatible change TODAY figure we can start using that code _at the earliest_ somewhere around 2012 or the low teens. Are we _really_ the only people on the list supporting embedded/factory automation platforms? Jim Paul Klissner wrote: > Jim Redman wrote: >> Paul Klissner wrote: >>> I'd just like to find another suitable name than javax.comm, unless >>> the JSR wants to start with javax.comm 4.0, since all the previous >>> 'major revisions' are accounted for. javax.serialport? >> Which perhaps brings us back to what are we trying to fix and how badly. > The goals I'm most interested in at the moment are: > > 1. A pluggable platform portmapping scheme wherein each platform > can determine which ports to present to the application, and > preferably as some configurable logical name. > > For example on the Sun Ray thin client platform, if an application > aquiring a view of serial ports available on the system, it will > be informed of Sun Ray serial ports if the application is running > in a session currently directed to that particular Sun Ray unit, > even though the serial port's device node happens to be server-side > deeply nested in a leaf node. If the application is not running on > a Sun Ray the port doesn't show up. The Sun Ray plugin would make > the decision about when and which ports to present to the application. > > 2. Pluggable driver-side interface where multiple platform-specific > drivers can be utilized simultaneously to introduce more flexibility > with the back end. > >> There are a number of 3rd party implementation of Java Comm, at least >> one from IBM - part of what was J9, now Websphere, or something >> (presumbly soon to get a name that has eclipse in it sometime soon). >> Esmertec has one, and there are few others rolling around. > > I have not been advocating gutting the API, since much of it is > perfectly adequate. I'm not totally opposed to making substantial > changes or improvements depending on other people's needs. There's > no reason previous versions of javax.comm need to suddenly disappear > if products need legacy support. > > >> If RXTX is the only implementation of the JSR with no backward >> compatibility, we've just forked Java Serial support and we (for a least >> one) will be worse off. We won't be able to use the new support because >> of a lack of support on J2ME platforms that we have no control over and >> RXTX/current JavaComm will be in maintenance mode or unsupported on all >> other platforms. > > There can't be *that* many platforms this is ported to. And it will > be no javax.usb. Seems like most of the standard platforms will > be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, > JDBC... > >> So, is there any chance of building a compatibility requirement into >> this. To pick are really bad example JDBC has support for a DataSource >> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >> SerialPort on a class not found exception? > > Maybe, or maybe we just let people know what we are doing and > try to figure out how to get their applications ported. Might not > be that difficult. From my standpoint anyway, earthshaking > changes aren't really necessary. Others might disagree. > > Paul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tod at todbot.com Wed Jul 19 19:59:52 2006 From: tod at todbot.com (Tod E. Kurt) Date: Wed, 19 Jul 2006 18:59:52 -0700 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEDDFA.7020108@averillpark.net> References: <44BEDDFA.7020108@averillpark.net> Message-ID: Hi, "lsusb" doesn't show if you have the proper drivers loaded for the specific USB device, just that a USB device is plugged in. The text identifiers sent by the USB device aren't used by the OS except for things like lsusb. Look at the output of "dmesg" or /var/log/messages and see if you have a lines that looks like: keyspan 1-1:1.0: Keyspan 1 port adapter converter detected usb 1-1: Keyspan 1 port adapter converter now attached to ttyUSB0 If you do, then you've got a serial port at "/dev/ttyUSB0", and you can use minicom or whatever (even RXTX!) to play with it. If you get a message like: usb.c: USB device 4 (vend/prod 0x06cd/0x0121) is not claimed by any active driver. Then the USB driver can't find the 'keyspan' driver. If you're sure you have this driver, then hotplug isn't working for some reason. You could try running the command: % sudo modprobe keyspan And see if anything useful happens. You should see the 'keyspan' driver when you type "lsmod" to list the currently loaded kernel modules. -=tod On Jul 19, 2006, at 6:35 PM, Richard P. Welty wrote: > I'm returning to the use of rxtx after 2 years off doing > things that don't need serial ports. > > I'm trying to get my laptop (fedora core 1) talking to a > set of portable auto scales through a Keyspan USB adapter > (in my past use of rxtx, I had actual serial ports, but those > days are long gone.) I have the keyspan kernel module loaded, > and lsusb shows the device as correctly identified. I'm missing > the bit of magic needed to get rxtx to provide the port > in response to CommPortIdentifier.getPortIdentifiers() > > thanks in advance for any help, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From rwelty at suespammers.org Wed Jul 19 20:05:18 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Wed, 19 Jul 2006 22:05:18 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <35101C10-59A5-4F02-AEEE-DB69112F8130@sympatico.ca> References: <44BEDDFA.7020108@averillpark.net> <35101C10-59A5-4F02-AEEE-DB69112F8130@sympatico.ca> Message-ID: <44BEE4DE.9080707@suespammers.org> Andr?-John Mas wrote: > Do you see an associated device in /dev ? Well, there are lots of /dev/ttyUSB devices, there, but nothing jumps out as having been assigned to the keyspan. But then, I'm not that knowledgable about the USB mapping here; this is the first time I've tried to use one this way and I'm on the steep part of the learning curve. richard From rwelty at suespammers.org Wed Jul 19 20:08:20 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Wed, 19 Jul 2006 22:08:20 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: References: <44BEDDFA.7020108@averillpark.net> Message-ID: <44BEE594.50402@suespammers.org> Tod E. Kurt wrote: > Then the USB driver can't find the 'keyspan' driver. If you're sure > you have this driver, then hotplug isn't working for some reason. > You could try running the command: Ok, it looks like the keyspan driver may be the problem; it's having some sort of problem loading it. I'll have to look into this further tomorrow night. thanks, richard From pascal at quies.net Wed Jul 19 20:11:21 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Thu, 20 Jul 2006 04:11:21 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEDFBD.4020404@ergotech.com> References: <44BED7CF.5080405@sun.com> <44BEDFBD.4020404@ergotech.com> Message-ID: <200607200411.22012.pascal@quies.net> Op donderdag 20 juli 2006 03:43, schreef Jim Redman: > Paul Klissner wrote: > > Pascal S. de Kloe wrote: > >> Op donderdag 20 juli 2006 02:03, schreef Jim Redman: > >>> Which perhaps brings us back to what are we trying to fix and how > >>> badly. > >> > >> The initail problem was the license. :) > >> > >> RXTX is sitting in this gnu.comm namespace and is afraid to go to > >> javax.comm. Getting a JSR would solve this problem. > >> > >> And while we're at it we might as well improve the situation with the > >> various platforms. I made some sugestions that where denied as too > >> complex. > > > > "Denied" is a bit harsh :) I'll re-examine your e-mails > > to see if my preferences change. It's not like your > > proposition has been put up to a formal vote, just discussion. > > OK, I'll officially float backwards compatibility in the form of "It > should be possible to use anything that comes out of the JSR in place of > an existing java comm implementation". > > I wonder if "Denied" is too harsh for that one :) > > Jim Hehehe. I don't have any troubles with people voting against my ideas at all so don't worry Paul. :) However, it is exactly the compatibilty thing where Jim is talking about what makes me want to make a *huge* change if any. From jredman at ergotech.com Wed Jul 19 20:25:50 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 20:25:50 -0600 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEE594.50402@suespammers.org> References: <44BEDDFA.7020108@averillpark.net> <44BEE594.50402@suespammers.org> Message-ID: <44BEE9AE.3030200@ergotech.com> Some who remembers this better than me please help. You also need something like: -Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3 When you start the application. This can be put in a properties files (where?). Jim Richard P. Welty wrote: > Tod E. Kurt wrote: > >> Then the USB driver can't find the 'keyspan' driver. If you're sure >> you have this driver, then hotplug isn't working for some reason. >> You could try running the command: > > Ok, it looks like the keyspan driver may be the problem; it's having > some sort of problem loading it. I'll have to look into this further > tomorrow night. > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From ajmas at sympatico.ca Wed Jul 19 20:32:52 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Wed, 19 Jul 2006 22:32:52 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEE9AE.3030200@ergotech.com> References: <44BEDDFA.7020108@averillpark.net> <44BEE594.50402@suespammers.org> <44BEE9AE.3030200@ergotech.com> Message-ID: Are you sure about this? I know on MacOS X no such configuration was needed. If this is indeed true, this is poor design, in this day and age of dynamic devices. On 19-Jul-06, at 22:25 , Jim Redman wrote: > Some who remembers this better than me please help. > > You also need something like: > > -Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyUSB0:/dev/ttyUSB1:/ > dev/ttyUSB2:/dev/ttyUSB3 > > When you start the application. This can be put in a properties files > (where?). > > Jim > > Richard P. Welty wrote: >> Tod E. Kurt wrote: >> >>> Then the USB driver can't find the 'keyspan' driver. If you're sure >>> you have this driver, then hotplug isn't working for some reason. >>> You could try running the command: >> >> Ok, it looks like the keyspan driver may be the problem; it's having >> some sort of problem loading it. I'll have to look into this further >> tomorrow night. >> >> thanks, >> richard >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Wed Jul 19 20:41:01 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Wed, 19 Jul 2006 22:41:01 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEE9AE.3030200@ergotech.com> References: <44BEDDFA.7020108@averillpark.net> <44BEE594.50402@suespammers.org> <44BEE9AE.3030200@ergotech.com> Message-ID: <44BEED3D.5020304@suespammers.org> Jim Redman wrote: > Some who remembers this better than me please help. > > You also need something like: > > -Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3 > > When you start the application. This can be put in a properties files > (where?). Thanks for all the help, guys. Thinking back on how this laptop came to be in its current state, I'm of the opinion a format and complete rebuild with a newer version of Fedora is in order before I waste any more time in diagnosis. The problems I'm seeing clearly have nothing to do with RXTX and everything to do with how many upgrades have been chained together getting this laptop from whereever I started (RH 7.0 or 7.1) to FC1. It could probably be fixed in place, but I shudder to think about the amount of time needed to figure out the proper fix. But the software I'm putting together will need to run on Y2K/XP and Mac OS X, so I'll be following portability and installer discussions on this list rather intently (http://scale-app.sourceforge.net for anyone who cares.) richard From Paul.Klissner at Sun.COM Wed Jul 19 22:53:53 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 21:53:53 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEE23B.30908@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> Message-ID: <44BF0C61.4020900@sun.com> Jim Redman wrote: > Paul, > > For the record we're STILL supporting some PersonalJava platforms. > We're _almost_ at the point where we can assume that the platforms will > have a Collections framework, but routinely compile with a 1.1 check so > that we don't make that assumption unnecessarily. Of 50+ non-graphical > Factory Automation JavaBeans we have 2 that require Java2 (Reporting and > JavaScripting), and we have people asking for a back-port. > > Embedded platforms don't change in a hurry. Unlike desktop platforms, > embedded systems are expected to last 5-10+ years. > > There are factory automation vendors in the pharmaceutical industry who > are buying systems on eBay because that's the FDA validate platform. It > must be that make/model, spec'd sometime in the mid-90's. > > So... If you make an incompatible change TODAY figure we can start using > that code _at the earliest_ somewhere around 2012 or the low teens. > > Are we _really_ the only people on the list supporting embedded/factory > automation platforms? > > Jim Do you provide your own implementation classes? Why can't you just continue to use 2.1 for the embedded platform until 2012 if you're locked down? Are you worried bugs won't get fixed? Sun might consider open sourcing the 2.1 Java source. I can't promise that, but it's been discussed and hasn't met resistance, except from me, because I wasn't super impressed with the code. I can probably be persuaded to champion open sourcing that and going through the process/legal machinations within Sun if it frees us to pursue a JSR for a new generation of javax.comm where we can have a chunk of common code in Open Source and each platform is simply responsible for it's platform specific plugins. I don't have many opinions about this set in stone because there are a lot of technical and pragmatic considerations such as yours the community has that I am probably not aware of or sufficiently sensitive to yet. I don't feel I really have the bird's eye view of all of this yet. The other thing is, I can only offer 10% of my time right now, according to my management, which is why I'm not pushing to be the spec lead for the JSR, and want only to be a participant to represent Sun's interests on the E.G. There is nothing sacred about Sun employees in the JCP as far as a JSR initiated by another entity is concerned. I am not the person everything needs to be cleared through. Ideas I have will pass or fail based on their merit and the community perception just like anyone else's. Paul > > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul Klissner wrote: >>>> I'd just like to find another suitable name than javax.comm, unless >>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>> 'major revisions' are accounted for. javax.serialport? >>> Which perhaps brings us back to what are we trying to fix and how badly. >> The goals I'm most interested in at the moment are: >> >> 1. A pluggable platform portmapping scheme wherein each platform >> can determine which ports to present to the application, and >> preferably as some configurable logical name. >> >> For example on the Sun Ray thin client platform, if an application >> aquiring a view of serial ports available on the system, it will >> be informed of Sun Ray serial ports if the application is running >> in a session currently directed to that particular Sun Ray unit, >> even though the serial port's device node happens to be server-side >> deeply nested in a leaf node. If the application is not running on >> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >> the decision about when and which ports to present to the application. >> >> 2. Pluggable driver-side interface where multiple platform-specific >> drivers can be utilized simultaneously to introduce more flexibility >> with the back end. >> >>> There are a number of 3rd party implementation of Java Comm, at least >>> one from IBM - part of what was J9, now Websphere, or something >>> (presumbly soon to get a name that has eclipse in it sometime soon). >>> Esmertec has one, and there are few others rolling around. >> I have not been advocating gutting the API, since much of it is >> perfectly adequate. I'm not totally opposed to making substantial >> changes or improvements depending on other people's needs. There's >> no reason previous versions of javax.comm need to suddenly disappear >> if products need legacy support. >> >> >>> If RXTX is the only implementation of the JSR with no backward >>> compatibility, we've just forked Java Serial support and we (for a least >>> one) will be worse off. We won't be able to use the new support because >>> of a lack of support on J2ME platforms that we have no control over and >>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>> other platforms. >> There can't be *that* many platforms this is ported to. And it will >> be no javax.usb. Seems like most of the standard platforms will >> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >> JDBC... >> >>> So, is there any chance of building a compatibility requirement into >>> this. To pick are really bad example JDBC has support for a DataSource >>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>> SerialPort on a class not found exception? >> Maybe, or maybe we just let people know what we are doing and >> try to figure out how to get their applications ported. Might not >> be that difficult. From my standpoint anyway, earthshaking >> changes aren't really necessary. Others might disagree. >> >> Paul >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From Paul.Klissner at Sun.COM Thu Jul 20 00:27:41 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 23:27:41 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BF0C61.4020900@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> Message-ID: <44BF225D.80104@sun.com> Paul Klissner wrote: > Jim Redman wrote: >> Paul, >> >> For the record we're STILL supporting some PersonalJava platforms. >> We're _almost_ at the point where we can assume that the platforms will >> have a Collections framework, but routinely compile with a 1.1 check so >> that we don't make that assumption unnecessarily. Of 50+ non-graphical >> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >> JavaScripting), and we have people asking for a back-port. >> >> Embedded platforms don't change in a hurry. Unlike desktop platforms, >> embedded systems are expected to last 5-10+ years. >> >> There are factory automation vendors in the pharmaceutical industry who >> are buying systems on eBay because that's the FDA validate platform. It >> must be that make/model, spec'd sometime in the mid-90's. >> >> So... If you make an incompatible change TODAY figure we can start using >> that code _at the earliest_ somewhere around 2012 or the low teens. >> >> Are we _really_ the only people on the list supporting embedded/factory >> automation platforms? >> >> Jim > > Do you provide your own implementation classes? > > Why can't you just continue to use 2.1 for the embedded platform until > 2012 if you're locked down? Are you worried bugs won't get fixed? > Sun might consider open sourcing the 2.1 Java source. Excuse me, I meant 2.0.3 > I can't promise > that, but it's been discussed and hasn't met resistance, except > from me, because I wasn't super impressed with the code. I can probably > be persuaded to champion open sourcing that and going through the > process/legal machinations within Sun if it frees us to pursue > a JSR for a new generation of javax.comm where we can have a chunk of > common code in Open Source and each platform is simply responsible > for it's platform specific plugins. > > I don't have many opinions about this set in stone because there > are a lot of technical and pragmatic considerations such as yours > the community has that I am probably not aware of or sufficiently > sensitive to yet. I don't feel I really have the bird's eye view > of all of this yet. > > The other thing is, I can only offer 10% of my time right now, > according to my management, which is why I'm not pushing to > be the spec lead for the JSR, and want only to be a participant > to represent Sun's interests on the E.G. There is nothing sacred > about Sun employees in the JCP as far as a JSR initiated by another > entity is concerned. I am not the person everything needs to be > cleared through. Ideas I have will pass or fail based on their > merit and the community perception just like anyone else's. > > Paul > >> Paul Klissner wrote: >>> Jim Redman wrote: >>>> Paul Klissner wrote: >>>>> I'd just like to find another suitable name than javax.comm, unless >>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>> 'major revisions' are accounted for. javax.serialport? >>>> Which perhaps brings us back to what are we trying to fix and how badly. >>> The goals I'm most interested in at the moment are: >>> >>> 1. A pluggable platform portmapping scheme wherein each platform >>> can determine which ports to present to the application, and >>> preferably as some configurable logical name. >>> >>> For example on the Sun Ray thin client platform, if an application >>> aquiring a view of serial ports available on the system, it will >>> be informed of Sun Ray serial ports if the application is running >>> in a session currently directed to that particular Sun Ray unit, >>> even though the serial port's device node happens to be server-side >>> deeply nested in a leaf node. If the application is not running on >>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>> the decision about when and which ports to present to the application. >>> >>> 2. Pluggable driver-side interface where multiple platform-specific >>> drivers can be utilized simultaneously to introduce more flexibility >>> with the back end. >>> >>>> There are a number of 3rd party implementation of Java Comm, at least >>>> one from IBM - part of what was J9, now Websphere, or something >>>> (presumbly soon to get a name that has eclipse in it sometime soon). >>>> Esmertec has one, and there are few others rolling around. >>> I have not been advocating gutting the API, since much of it is >>> perfectly adequate. I'm not totally opposed to making substantial >>> changes or improvements depending on other people's needs. There's >>> no reason previous versions of javax.comm need to suddenly disappear >>> if products need legacy support. >>> >>> >>>> If RXTX is the only implementation of the JSR with no backward >>>> compatibility, we've just forked Java Serial support and we (for a least >>>> one) will be worse off. We won't be able to use the new support because >>>> of a lack of support on J2ME platforms that we have no control over and >>>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>>> other platforms. >>> There can't be *that* many platforms this is ported to. And it will >>> be no javax.usb. Seems like most of the standard platforms will >>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>> JDBC... >>> >>>> So, is there any chance of building a compatibility requirement into >>>> this. To pick are really bad example JDBC has support for a DataSource >>>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>>> SerialPort on a class not found exception? >>> Maybe, or maybe we just let people know what we are doing and >>> try to figure out how to get their applications ported. Might not >>> be that difficult. From my standpoint anyway, earthshaking >>> changes aren't really necessary. Others might disagree. >>> >>> Paul >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Thu Jul 20 00:50:21 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 20 Jul 2006 08:50:21 +0200 Subject: [Rxtx] jcp and jsr Message-ID: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> Hi all, I work with SNIJDER Micro Systems. We're doing embedded Java and just heard about this discussion by way of Ted Kosan from the embedded Java community. We think Jim is right about the compatibility issues for embedded Java platforms. Our own embedded Java platform (see http://www.embedded-web.com ) uses a 3rd party implementation of javax.comm written by the JVM vendor. As Jim says, changes take much longer to propagate in the embedded space. If the 'new' javax.comm is not backwards compatible, embedded JVM vendors (esmertec, IBM, Tao Group, etc.) will probably evaluate whether it makes sense for them to support the new API. Some will eventually adopt it, but that will take time. Some will just stay with the current API, thus increasing the gap between embedded Java developers and desktop Java developers (different APIs to do the same thing) This is a very real problem in our opinion. Also taking into account that many desktop computers nowadays don't even have standard serial ports, I believe that the embedded Java community already gathers a significant share of the potential javax.comm users. I think backwards compatibility should be seriously considered. Best regards, Guillermo Jim Redman wrote: >Paul Klissner wrote: > > I'd just like to find another suitable name than javax.comm, unless > > the JSR wants to start with javax.comm 4.0, since all the previous > > 'major revisions' are accounted for. javax.serialport? > >Which perhaps brings us back to what are we trying to fix and how badly. > >There are a number of 3rd party implementation of Java Comm, at least >one from IBM - part of what was J9, now Websphere, or something >(presumbly soon to get a name that has eclipse in it sometime soon). >Esmertec has one, and there are few others rolling around. > >If RXTX is the only implementation of the JSR with no backward >compatibility, we've just forked Java Serial support and we (for a least >one) will be worse off. We won't be able to use the new support because >of a lack of support on J2ME platforms that we have no control over and >RXTX/current JavaComm will be in maintenance mode or unsupported on all >other platforms. > >So, is there any chance of building a compatibility requirement into >this. To pick are really bad example JDBC has support for a DataSource >or a Driver. Could we have an ExcellentSerialPort with a fallback to a >SerialPort on a class not found exception? > >Jim -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Thu Jul 20 00:57:04 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 20 Jul 2006 08:57:04 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> References: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> Message-ID: <7.0.1.0.0.20060720085221.036d88e8@sms.nl> Paul Klissner wrote: >Jim Redman wrote: > > Paul, > > > > For the record we're STILL supporting some PersonalJava platforms. > > We're _almost_ at the point where we can assume that the platforms will > > have a Collections framework, but routinely compile with a 1.1 check so > > that we don't make that assumption unnecessarily. Of 50+ non-graphical > > Factory Automation JavaBeans we have 2 that require Java2 (Reporting and > > JavaScripting), and we have people asking for a back-port. > > > > Embedded platforms don't change in a hurry. Unlike desktop platforms, > > embedded systems are expected to last 5-10+ years. > > > > There are factory automation vendors in the pharmaceutical industry who > > are buying systems on eBay because that's the FDA validate platform. It > > must be that make/model, spec'd sometime in the mid-90's. > > > > So... If you make an incompatible change TODAY figure we can start using > > that code _at the earliest_ somewhere around 2012 or the low teens. > > > > Are we _really_ the only people on the list supporting embedded/factory > > automation platforms? > > > > Jim > >Do you provide your own implementation classes? > >Why can't you just continue to use 2.1 for the embedded platform until >2012 if you're locked down? Are you worried bugs won't get fixed? If embedded platforms keep using the "old" (current) javax.comm API but the desktop Java world starts to use a new, backwards-incompatible API, then this will result in more trouble for embedded Java application developers as they will no longer be able to use the same API on desktop systems and embedded platforms. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Thu Jul 20 00:59:16 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 20 Jul 2006 08:59:16 +0200 Subject: [Rxtx] jcp and jsr Message-ID: <7.0.1.0.0.20060720085812.036d9c28@sms.nl> Pascal S. de Kloe wrote: >Who is participating anyway? Is it just the four of us? > >Cheers, > >Pascal We would be more than happy to participate if we can be of any help. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From Paul.Klissner at Sun.COM Thu Jul 20 02:23:42 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Thu, 20 Jul 2006 01:23:42 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <7.0.1.0.0.20060720085221.036d88e8@sms.nl> References: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> <7.0.1.0.0.20060720085221.036d88e8@sms.nl> Message-ID: <44BF3D8E.4030705@sun.com> Guillermo Rodriguez Garcia wrote: > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul, >>> >>> For the record we're STILL supporting some PersonalJava platforms. >>> We're _almost_ at the point where we can assume that the platforms will >>> have a Collections framework, but routinely compile with a 1.1 check so >>> that we don't make that assumption unnecessarily. Of 50+ non-graphical >>> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >>> JavaScripting), and we have people asking for a back-port. >>> >>> Embedded platforms don't change in a hurry. Unlike desktop platforms, >>> embedded systems are expected to last 5-10+ years. >>> >>> There are factory automation vendors in the pharmaceutical industry who >>> are buying systems on eBay because that's the FDA validate platform. It >>> must be that make/model, spec'd sometime in the mid-90's. >>> >>> So... If you make an incompatible change TODAY figure we can start using >>> that code _at the earliest_ somewhere around 2012 or the low teens. >>> >>> Are we _really_ the only people on the list supporting embedded/factory >>> automation platforms? >>> >>> Jim >> Do you provide your own implementation classes? >> >> Why can't you just continue to use 2.1 for the embedded platform until >> 2012 if you're locked down? Are you worried bugs won't get fixed? > > If embedded platforms keep using the "old" (current) javax.comm API but > the desktop Java world starts to use a new, backwards-incompatible API, > then this will result in more trouble for embedded Java application > developers as they will no longer be able to use the same API on desktop > systems and embedded platforms. OK, I understand the situation more clearly now. The kinds of changes I'm opting don't seem difficult to design in a backward compatible way. I haven't scrutinized the other requests on the list. I guess it will be interesting to hear what the proponents for other changes have to say. Paul > > Guillermo > > -- > Guillermo Rodriguez Garcia > > Snijder Micro Systems phone +31-493-351020 > G. Rodriguez Garcia fax +31-493-351530 > Visser 25 email guille at sms.nl > NL5751 BL Deurne > The Netherlands http://www.snijder.com > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jul 20 02:46:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 20 Jul 2006 10:46:09 +0200 Subject: [Rxtx] quo vadis API/namespace (Re: jcp and jsr) In-Reply-To: <44BEDC4F.9030403@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> Message-ID: Paul, for the first time in many months, I have the impression, that we have the same agenda;-) If the "driver-level"-api changes however "nobody" will be disappointed. However, regarding the user-level-api I disagree. As fundamental changes to the API have been suggested several times I must be ignoring something. I would be delighted to learn were the current API fails - i.e. what can not be done or is overly complex based on the current API. Of course it is better fun to start something from scratch, but unless there are really substantial gains from completely redesigning an API I don't see the point. The promise of Java is to write once (which I interpret as write against the same API for all platforms). Getting VM providers like esmertec to support a new/replacement API is not a simple task, it requires a business case which for the biggest part simply does not exist. If we keep the javax.comm namespace and keep the "user-level"-api a superset of the current PortIdentifier/Port-api, the same application can work against javax.comm 2.0/3.0/future.x. Of course a factory/wrapping approach can always unify different APIs but this adds more implementation/ testing complexity to every application. So in short: Unless we find a strong argument why javax.comm can't be used I prefer that we keep it. Unless we find a strong feature / use- case that can not be handled with (an extension of) the current CommPort/CommPortIndentifier I'd prefer to keep that as well. Regards, Joachim On 20.07.2006, at 03:28, Paul Klissner wrote: > The goals I'm most interested in at the moment are: > > 1. A pluggable platform portmapping scheme wherein each platform > can determine which ports to present to the application, and > preferably as some configurable logical name. > > For example on the Sun Ray thin client platform, if an application > aquiring a view of serial ports available on the system, it will > be informed of Sun Ray serial ports if the application is running > in a session currently directed to that particular Sun Ray unit, > even though the serial port's device node happens to be server-side > deeply nested in a leaf node. If the application is not running on > a Sun Ray the port doesn't show up. The Sun Ray plugin would make > the decision about when and which ports to present to the application. > > 2. Pluggable driver-side interface where multiple platform-specific > drivers can be utilized simultaneously to introduce more flexibility > with the back end. > >> There are a number of 3rd party implementation of Java Comm, at least >> one from IBM - part of what was J9, now Websphere, or something >> (presumbly soon to get a name that has eclipse in it sometime soon). >> Esmertec has one, and there are few others rolling around. > > I have not been advocating gutting the API, since much of it is > perfectly adequate. I'm not totally opposed to making substantial > changes or improvements depending on other people's needs. There's > no reason previous versions of javax.comm need to suddenly disappear > if products need legacy support. > > >> >> If RXTX is the only implementation of the JSR with no backward >> compatibility, we've just forked Java Serial support and we (for a >> least >> one) will be worse off. We won't be able to use the new support >> because >> of a lack of support on J2ME platforms that we have no control >> over and >> RXTX/current JavaComm will be in maintenance mode or unsupported >> on all >> other platforms. > > There can't be *that* many platforms this is ported to. And it will > be no javax.usb. Seems like most of the standard platforms will > be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, > JDBC... > >> >> So, is there any chance of building a compatibility requirement into >> this. To pick are really bad example JDBC has support for a >> DataSource >> or a Driver. Could we have an ExcellentSerialPort with a fallback >> to a >> SerialPort on a class not found exception? > > Maybe, or maybe we just let people know what we are doing and > try to figure out how to get their applications ported. Might not > be that difficult. From my standpoint anyway, earthshaking > changes aren't really necessary. Others might disagree. > > Paul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Luis.Moreira at jet.uk Thu Jul 20 03:56:38 2006 From: Luis.Moreira at jet.uk (Luis Moreira) Date: Thu, 20 Jul 2006 10:56:38 +0100 Subject: [Rxtx] problems with setting up Rxtx Message-ID: Hi Guys, I have just joined the list and I am very new to JAVA. I am investigating serial communications and I just realised that the JAVAX.COMM package does not support windows anymore. I then looked at alternatives and the RXTX package came up. The problem I have at the moment is not using the classes but, rather how to install RXTX package so that I can use the classes, what do I need to install to support it and how if I write a program using it, do I make it portable. Best regards Luis From lyon at docjava.com Thu Jul 20 07:16:55 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 20 Jul 2006 09:16:55 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> Message-ID: Hi All, There has been some discussion about plugins for serial communications. As I see it, what Java really needs is a NativeLibraryManager. This is a rather much larger charge than "just" RXTX. The RXTX basic mode of operation is that we associate static blocks of code with a "System.load". Failure occurs when the class containing such a block of code is loaded AND the native library is not found. What are some of the options? 1. Do nothing, let the program fail with an exception. 2. try to catch an UnsatisfiedLinkError as a part of making the driver. 3. Search the java.library.path to see if the driver is present (i.e., guard the input). 4. Other?? In the case of either step 2 or 3, we need to fix the lack of a library. What are the options for fixing a library? 1. Do nothing, but give the user an interesting error with instructions on what to do. 2. Attempt to find the library on the file system (perhaps with user help). 3. Attempt to download the library and install it (perhaps with user permission). 4. Attempt to internalize the library as a UUEncoded serialized object and install it (better ask the user, again!). 5. Other?? My attempts at making RXTX more robust on install have led to mixed results. Altering the java.library.path has led to a bit of byte-code engineering (as this is loaded at JVM start time). Internalizing of libraries is attractive, until you realize how many libraries are involved. Dyanmically changing libraries during development is very attractive, for developers, who are changing libraries often. It is also very interesting for those who want to control the version of the libraries in the run-time. For example, something like the following will guard the input to the system load: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getInstance() { if (driver != null) return driver; if (!NativeLibDetect.isLibInPath("rxtxSerial")) fixDriver(); if (NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } At the other extreme, something like: try { System.load("rxtxSerial"); } catch (UnsatisfiedLinkError e) { System.out.println("could not load lib"); } Will at least attempt to handle the missing lib, in a simple way. Perhaps some error handling is better than none. To fix the driver, I can beam it down from a web page, using: private static void fixDriver() { File tmpDir = new File( SystemUtils.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); try { UrlUtils.getUrl(getResourceUrl(), tmpDir); String nativeLib = getNativeLibName(); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(nativeLib); if (b == null) { System.out.println("could not get:" + nativeLib); return; } File f = getRxtxHome(); Futil.writeBytes(getRxtxLibFile(), b); SystemUtils.appendJavaLibraryPath(f); } catch (IOException e) { e.printStackTrace(); } } Where the libraries are stored in the hacky dispatch: private static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isMacOs()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); System.out.println("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } Appending to the library path is tricky, at run-time: public static void appendJavaLibraryPath(File p) { if (p.isFile()) System.out.println("warning: appendJavaLibraryPath:" + "only directories are findable:"+p); System.out.println("appending:"+p+" to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:"+System.getProperty(javaLibraryPa th)); } The key is altering the core visibility of the sys_paths in the class loader: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } No, it isn't simple (nor even easy) but once the API is set we have a kind of NativeLibraryManager that helps us to make libraries, like RXTX more robust. As far as I know, there is nothing quite like it (unless you all know differently). Is there any interest in this? Forgive me if this is too far off the beaten path, but the inability to load a native library remains a source of fragility in the RXTX system, IMHO. Thanks for your thoughts! - Doug From jredman at ergotech.com Thu Jul 20 08:06:41 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 20 Jul 2006 08:06:41 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BF0C61.4020900@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> Message-ID: <44BF8DF1.4040101@ergotech.com> Paul, The issue with a new, incompatible implementation is, as you've identified below, is support for the old API. Open sourcing would be helpful, but then someone (us?) would have to maintain the source through changing versions of Window, and RXTX on Linux platforms. Or we'd have to have to versions of our codebase, which doesn't appeal too much. The maintenance issue is not impossible, but I think that in essence I'm agreeing with a comment you made earlier. IF a huge change is required, then lets get on with it. However, if the changes that are required are just extensions and enhancements, with some low-level re-engineering, then can we keep a compatible high-level API so that people needing the new features can use an extended API and those who need cross-platform compatibility can continue to use the existing features. Jim Paul Klissner wrote: > Jim Redman wrote: >> Paul, >> >> For the record we're STILL supporting some PersonalJava platforms. >> We're _almost_ at the point where we can assume that the platforms will >> have a Collections framework, but routinely compile with a 1.1 check so >> that we don't make that assumption unnecessarily. Of 50+ non-graphical >> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >> JavaScripting), and we have people asking for a back-port. >> >> Embedded platforms don't change in a hurry. Unlike desktop platforms, >> embedded systems are expected to last 5-10+ years. >> >> There are factory automation vendors in the pharmaceutical industry who >> are buying systems on eBay because that's the FDA validate platform. It >> must be that make/model, spec'd sometime in the mid-90's. >> >> So... If you make an incompatible change TODAY figure we can start using >> that code _at the earliest_ somewhere around 2012 or the low teens. >> >> Are we _really_ the only people on the list supporting embedded/factory >> automation platforms? >> >> Jim > > Do you provide your own implementation classes? > > Why can't you just continue to use 2.1 for the embedded platform until > 2012 if you're locked down? Are you worried bugs won't get fixed? > Sun might consider open sourcing the 2.1 Java source. I can't promise > that, but it's been discussed and hasn't met resistance, except > from me, because I wasn't super impressed with the code. I can probably > be persuaded to champion open sourcing that and going through the > process/legal machinations within Sun if it frees us to pursue > a JSR for a new generation of javax.comm where we can have a chunk of > common code in Open Source and each platform is simply responsible > for it's platform specific plugins. > > I don't have many opinions about this set in stone because there > are a lot of technical and pragmatic considerations such as yours > the community has that I am probably not aware of or sufficiently > sensitive to yet. I don't feel I really have the bird's eye view > of all of this yet. > > The other thing is, I can only offer 10% of my time right now, > according to my management, which is why I'm not pushing to > be the spec lead for the JSR, and want only to be a participant > to represent Sun's interests on the E.G. There is nothing sacred > about Sun employees in the JCP as far as a JSR initiated by another > entity is concerned. I am not the person everything needs to be > cleared through. Ideas I have will pass or fail based on their > merit and the community perception just like anyone else's. > > Paul > >> Paul Klissner wrote: >>> Jim Redman wrote: >>>> Paul Klissner wrote: >>>>> I'd just like to find another suitable name than javax.comm, unless >>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>> 'major revisions' are accounted for. javax.serialport? >>>> Which perhaps brings us back to what are we trying to fix and how badly. >>> The goals I'm most interested in at the moment are: >>> >>> 1. A pluggable platform portmapping scheme wherein each platform >>> can determine which ports to present to the application, and >>> preferably as some configurable logical name. >>> >>> For example on the Sun Ray thin client platform, if an application >>> aquiring a view of serial ports available on the system, it will >>> be informed of Sun Ray serial ports if the application is running >>> in a session currently directed to that particular Sun Ray unit, >>> even though the serial port's device node happens to be server-side >>> deeply nested in a leaf node. If the application is not running on >>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>> the decision about when and which ports to present to the application. >>> >>> 2. Pluggable driver-side interface where multiple platform-specific >>> drivers can be utilized simultaneously to introduce more flexibility >>> with the back end. >>> >>>> There are a number of 3rd party implementation of Java Comm, at least >>>> one from IBM - part of what was J9, now Websphere, or something >>>> (presumbly soon to get a name that has eclipse in it sometime soon). >>>> Esmertec has one, and there are few others rolling around. >>> I have not been advocating gutting the API, since much of it is >>> perfectly adequate. I'm not totally opposed to making substantial >>> changes or improvements depending on other people's needs. There's >>> no reason previous versions of javax.comm need to suddenly disappear >>> if products need legacy support. >>> >>> >>>> If RXTX is the only implementation of the JSR with no backward >>>> compatibility, we've just forked Java Serial support and we (for a least >>>> one) will be worse off. We won't be able to use the new support because >>>> of a lack of support on J2ME platforms that we have no control over and >>>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>>> other platforms. >>> There can't be *that* many platforms this is ported to. And it will >>> be no javax.usb. Seems like most of the standard platforms will >>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>> JDBC... >>> >>>> So, is there any chance of building a compatibility requirement into >>>> this. To pick are really bad example JDBC has support for a DataSource >>>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>>> SerialPort on a class not found exception? >>> Maybe, or maybe we just let people know what we are doing and >>> try to figure out how to get their applications ported. Might not >>> be that difficult. From my standpoint anyway, earthshaking >>> changes aren't really necessary. Others might disagree. >>> >>> Paul >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Paul.Klissner at Sun.COM Thu Jul 20 09:31:38 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Thu, 20 Jul 2006 08:31:38 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BF8DF1.4040101@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> <44BF8DF1.4040101@ergotech.com> Message-ID: <44BFA1DA.10301@sun.com> Jim Redman wrote: > Paul, > > The issue with a new, incompatible implementation is, as you've > identified below, is support for the old API. Open sourcing would be > helpful, but then someone (us?) would have to maintain the source > through changing versions of Window, and RXTX on Linux platforms. Or > we'd have to have to versions of our codebase, which doesn't appeal too > much. > > The maintenance issue is not impossible, but I think that in essence I'm > agreeing with a comment you made earlier. > > IF a huge change is required, then lets get on with it. However, if the > changes that are required are just extensions and enhancements, with > some low-level re-engineering, then can we keep a compatible high-level > API so that people needing the new features can use an extended API and > those who need cross-platform compatibility can continue to use the > existing features. > > Jim Guillermo made a crystal clear case and I understand the problem that that will be caused by forking the API in any sense of the word. I only want to uphold Sun's interests and resolve the problems we ran into with the RXTX community when Sun added portmapping to 3.0, which was not easily undone and was implemented as kind of a hack because it wasn't directly supported by the javax.comm architection. As I mentioned previously the changes I want to make have primarily to do with adding platform-specific portmapping via plugins, and supporting multiple javax.comm backend drivers on the same host (some ports would use one driver, others ports might use another). Also I'd like to address some bugfixes that were done in Sun's version 3.0 (including better error reporting, and more robust code for locating configuration files). Besides that, I'm not aware of any deficiences, but I've glanced other e-mails where people have suggested some. It would be good to get a summary of everyone's wishes. I've stated mine. I given much thought to what it would take to properly address EIA-422, EIA-423 and EIA-485 (if any); but those would probably be extensions. Sounds like the differences might be transparent to the API. I'll look into that more. Paul > > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul, >>> >>> For the record we're STILL supporting some PersonalJava platforms. >>> We're _almost_ at the point where we can assume that the platforms will >>> have a Collections framework, but routinely compile with a 1.1 check so >>> that we don't make that assumption unnecessarily. Of 50+ non-graphical >>> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >>> JavaScripting), and we have people asking for a back-port. >>> >>> Embedded platforms don't change in a hurry. Unlike desktop platforms, >>> embedded systems are expected to last 5-10+ years. >>> >>> There are factory automation vendors in the pharmaceutical industry who >>> are buying systems on eBay because that's the FDA validate platform. It >>> must be that make/model, spec'd sometime in the mid-90's. >>> >>> So... If you make an incompatible change TODAY figure we can start using >>> that code _at the earliest_ somewhere around 2012 or the low teens. >>> >>> Are we _really_ the only people on the list supporting embedded/factory >>> automation platforms? >>> >>> Jim >> Do you provide your own implementation classes? >> >> Why can't you just continue to use 2.1 for the embedded platform until >> 2012 if you're locked down? Are you worried bugs won't get fixed? >> Sun might consider open sourcing the 2.1 Java source. I can't promise >> that, but it's been discussed and hasn't met resistance, except >> from me, because I wasn't super impressed with the code. I can probably >> be persuaded to champion open sourcing that and going through the >> process/legal machinations within Sun if it frees us to pursue >> a JSR for a new generation of javax.comm where we can have a chunk of >> common code in Open Source and each platform is simply responsible >> for it's platform specific plugins. >> >> I don't have many opinions about this set in stone because there >> are a lot of technical and pragmatic considerations such as yours >> the community has that I am probably not aware of or sufficiently >> sensitive to yet. I don't feel I really have the bird's eye view >> of all of this yet. >> >> The other thing is, I can only offer 10% of my time right now, >> according to my management, which is why I'm not pushing to >> be the spec lead for the JSR, and want only to be a participant >> to represent Sun's interests on the E.G. There is nothing sacred >> about Sun employees in the JCP as far as a JSR initiated by another >> entity is concerned. I am not the person everything needs to be >> cleared through. Ideas I have will pass or fail based on their >> merit and the community perception just like anyone else's. >> >> Paul >> >>> Paul Klissner wrote: >>>> Jim Redman wrote: >>>>> Paul Klissner wrote: >>>>>> I'd just like to find another suitable name than javax.comm, unless >>>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>>> 'major revisions' are accounted for. javax.serialport? >>>>> Which perhaps brings us back to what are we trying to fix and how badly. >>>> The goals I'm most interested in at the moment are: >>>> >>>> 1. A pluggable platform portmapping scheme wherein each platform >>>> can determine which ports to present to the application, and >>>> preferably as some configurable logical name. >>>> >>>> For example on the Sun Ray thin client platform, if an application >>>> aquiring a view of serial ports available on the system, it will >>>> be informed of Sun Ray serial ports if the application is running >>>> in a session currently directed to that particular Sun Ray unit, >>>> even though the serial port's device node happens to be server-side >>>> deeply nested in a leaf node. If the application is not running on >>>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>>> the decision about when and which ports to present to the application. >>>> >>>> 2. Pluggable driver-side interface where multiple platform-specific >>>> drivers can be utilized simultaneously to introduce more flexibility >>>> with the back end. >>>> >>>>> There are a number of 3rd party implementation of Java Comm, at least >>>>> one from IBM - part of what was J9, now Websphere, or something >>>>> (presumbly soon to get a name that has eclipse in it sometime soon). >>>>> Esmertec has one, and there are few others rolling around. >>>> I have not been advocating gutting the API, since much of it is >>>> perfectly adequate. I'm not totally opposed to making substantial >>>> changes or improvements depending on other people's needs. There's >>>> no reason previous versions of javax.comm need to suddenly disappear >>>> if products need legacy support. >>>> >>>> >>>>> If RXTX is the only implementation of the JSR with no backward >>>>> compatibility, we've just forked Java Serial support and we (for a least >>>>> one) will be worse off. We won't be able to use the new support because >>>>> of a lack of support on J2ME platforms that we have no control over and >>>>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>>>> other platforms. >>>> There can't be *that* many platforms this is ported to. And it will >>>> be no javax.usb. Seems like most of the standard platforms will >>>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>>> JDBC... >>>> >>>>> So, is there any chance of building a compatibility requirement into >>>>> this. To pick are really bad example JDBC has support for a DataSource >>>>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>>>> SerialPort on a class not found exception? >>>> Maybe, or maybe we just let people know what we are doing and >>>> try to figure out how to get their applications ported. Might not >>>> be that difficult. From my standpoint anyway, earthshaking >>>> changes aren't really necessary. Others might disagree. >>>> >>>> Paul >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From Paul.Klissner at Sun.COM Thu Jul 20 09:45:11 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Thu, 20 Jul 2006 08:45:11 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BFA1DA.10301@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> <44BF8DF1.4040101@ergotech.com> <44BFA1DA.10301@sun.com> Message-ID: <44BFA507.3020001@sun.com> Paul Klissner wrote: > Jim Redman wrote: >> Paul, >> >> The issue with a new, incompatible implementation is, as you've >> identified below, is support for the old API. Open sourcing would be >> helpful, but then someone (us?) would have to maintain the source >> through changing versions of Window, and RXTX on Linux platforms. Or >> we'd have to have to versions of our codebase, which doesn't appeal >> too much. >> >> The maintenance issue is not impossible, but I think that in essence >> I'm agreeing with a comment you made earlier. >> >> IF a huge change is required, then lets get on with it. However, if >> the changes that are required are just extensions and enhancements, >> with some low-level re-engineering, then can we keep a compatible >> high-level API so that people needing the new features can use an >> extended API and those who need cross-platform compatibility can >> continue to use the existing features. >> >> Jim > > Guillermo made a crystal clear case and I understand the problem > that that will be caused by forking the API in any sense of the > word. I only want to uphold Sun's interests and resolve the problems > we ran into with the RXTX community when Sun added portmapping > to 3.0, which was not easily undone and was implemented as kind > of a hack because it wasn't directly supported by the javax.comm > architection. ^^^"architecture" > > As I mentioned previously the changes I want to make have primarily > to do with adding platform-specific portmapping via plugins, > and supporting multiple javax.comm backend drivers on the same > host (some ports would use one driver, others ports might use another). > > Also I'd like to address some bugfixes that were done in Sun's > version 3.0 (including better error reporting, and more robust > code for locating configuration files). Besides that, I'm not > aware of any deficiences, but I've glanced other e-mails where > people have suggested some. It would be good to get a summary > of everyone's wishes. I've stated mine. > > I given much thought to what it would take to properly address ^^^haven't > EIA-422, EIA-423 and EIA-485 (if any); but those would > probably be extensions. Sounds like the differences might > be transparent to the API. I'll look into that more. > > Paul > > >> >> Paul Klissner wrote: >>> Jim Redman wrote: >>>> Paul, >>>> >>>> For the record we're STILL supporting some PersonalJava platforms. >>>> We're _almost_ at the point where we can assume that the platforms >>>> will have a Collections framework, but routinely compile with a 1.1 >>>> check so that we don't make that assumption unnecessarily. Of 50+ >>>> non-graphical Factory Automation JavaBeans we have 2 that require >>>> Java2 (Reporting and JavaScripting), and we have people asking for a >>>> back-port. >>>> >>>> Embedded platforms don't change in a hurry. Unlike desktop >>>> platforms, embedded systems are expected to last 5-10+ years. >>>> >>>> There are factory automation vendors in the pharmaceutical industry >>>> who are buying systems on eBay because that's the FDA validate >>>> platform. It must be that make/model, spec'd sometime in the mid-90's. >>>> >>>> So... If you make an incompatible change TODAY figure we can start >>>> using that code _at the earliest_ somewhere around 2012 or the low >>>> teens. >>>> >>>> Are we _really_ the only people on the list supporting >>>> embedded/factory automation platforms? >>>> >>>> Jim >>> Do you provide your own implementation classes? >>> >>> Why can't you just continue to use 2.1 for the embedded platform until >>> 2012 if you're locked down? Are you worried bugs won't get fixed? >>> Sun might consider open sourcing the 2.1 Java source. I can't promise >>> that, but it's been discussed and hasn't met resistance, except >>> from me, because I wasn't super impressed with the code. I can probably >>> be persuaded to champion open sourcing that and going through the >>> process/legal machinations within Sun if it frees us to pursue >>> a JSR for a new generation of javax.comm where we can have a chunk of >>> common code in Open Source and each platform is simply responsible >>> for it's platform specific plugins. >>> >>> I don't have many opinions about this set in stone because there >>> are a lot of technical and pragmatic considerations such as yours >>> the community has that I am probably not aware of or sufficiently >>> sensitive to yet. I don't feel I really have the bird's eye view >>> of all of this yet. >>> >>> The other thing is, I can only offer 10% of my time right now, >>> according to my management, which is why I'm not pushing to >>> be the spec lead for the JSR, and want only to be a participant >>> to represent Sun's interests on the E.G. There is nothing sacred >>> about Sun employees in the JCP as far as a JSR initiated by another >>> entity is concerned. I am not the person everything needs to be >>> cleared through. Ideas I have will pass or fail based on their >>> merit and the community perception just like anyone else's. >>> >>> Paul >>> >>>> Paul Klissner wrote: >>>>> Jim Redman wrote: >>>>>> Paul Klissner wrote: >>>>>>> I'd just like to find another suitable name than javax.comm, unless >>>>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>>>> 'major revisions' are accounted for. javax.serialport? >>>>>> Which perhaps brings us back to what are we trying to fix and how >>>>>> badly. >>>>> The goals I'm most interested in at the moment are: >>>>> >>>>> 1. A pluggable platform portmapping scheme wherein each platform >>>>> can determine which ports to present to the application, and >>>>> preferably as some configurable logical name. >>>>> >>>>> For example on the Sun Ray thin client platform, if an application >>>>> aquiring a view of serial ports available on the system, it will >>>>> be informed of Sun Ray serial ports if the application is running >>>>> in a session currently directed to that particular Sun Ray unit, >>>>> even though the serial port's device node happens to be server-side >>>>> deeply nested in a leaf node. If the application is not running on >>>>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>>>> the decision about when and which ports to present to the application. >>>>> >>>>> 2. Pluggable driver-side interface where multiple platform-specific >>>>> drivers can be utilized simultaneously to introduce more flexibility >>>>> with the back end. >>>>> >>>>>> There are a number of 3rd party implementation of Java Comm, at >>>>>> least one from IBM - part of what was J9, now Websphere, or >>>>>> something (presumbly soon to get a name that has eclipse in it >>>>>> sometime soon). Esmertec has one, and there are few others rolling >>>>>> around. >>>>> I have not been advocating gutting the API, since much of it is >>>>> perfectly adequate. I'm not totally opposed to making substantial >>>>> changes or improvements depending on other people's needs. There's >>>>> no reason previous versions of javax.comm need to suddenly disappear >>>>> if products need legacy support. >>>>> >>>>> >>>>>> If RXTX is the only implementation of the JSR with no backward >>>>>> compatibility, we've just forked Java Serial support and we (for a >>>>>> least one) will be worse off. We won't be able to use the new >>>>>> support because of a lack of support on J2ME platforms that we >>>>>> have no control over and RXTX/current JavaComm will be in >>>>>> maintenance mode or unsupported on all other platforms. >>>>> There can't be *that* many platforms this is ported to. And it will >>>>> be no javax.usb. Seems like most of the standard platforms will >>>>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>>>> JDBC... >>>>> >>>>>> So, is there any chance of building a compatibility requirement >>>>>> into this. To pick are really bad example JDBC has support for a >>>>>> DataSource or a Driver. Could we have an ExcellentSerialPort with >>>>>> a fallback to a SerialPort on a class not found exception? >>>>> Maybe, or maybe we just let people know what we are doing and >>>>> try to figure out how to get their applications ported. Might not >>>>> be that difficult. From my standpoint anyway, earthshaking >>>>> changes aren't really necessary. Others might disagree. >>>>> >>>>> Paul >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From jredman at ergotech.com Thu Jul 20 10:30:01 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 20 Jul 2006 10:30:01 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BFA507.3020001@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> <44BF8DF1.4040101@ergotech.com> <44BFA1DA.10301@sun.com> <44BFA507.3020001@sun.com> Message-ID: <44BFAF89.5010003@ergotech.com> Thast what hapens if you post late at nihgt nad erly in the moning as wel. :) Paul Klissner wrote: > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul, >>> >>> The issue with a new, incompatible implementation is, as you've >>> identified below, is support for the old API. Open sourcing would be >>> helpful, but then someone (us?) would have to maintain the source >>> through changing versions of Window, and RXTX on Linux platforms. Or >>> we'd have to have to versions of our codebase, which doesn't appeal >>> too much. >>> >>> The maintenance issue is not impossible, but I think that in essence >>> I'm agreeing with a comment you made earlier. >>> >>> IF a huge change is required, then lets get on with it. However, if >>> the changes that are required are just extensions and enhancements, >>> with some low-level re-engineering, then can we keep a compatible >>> high-level API so that people needing the new features can use an >>> extended API and those who need cross-platform compatibility can >>> continue to use the existing features. >>> >>> Jim >> Guillermo made a crystal clear case and I understand the problem >> that that will be caused by forking the API in any sense of the >> word. I only want to uphold Sun's interests and resolve the problems >> we ran into with the RXTX community when Sun added portmapping >> to 3.0, which was not easily undone and was implemented as kind >> of a hack because it wasn't directly supported by the javax.comm >> architection. > ^^^"architecture" >> As I mentioned previously the changes I want to make have primarily >> to do with adding platform-specific portmapping via plugins, >> and supporting multiple javax.comm backend drivers on the same >> host (some ports would use one driver, others ports might use another). >> >> Also I'd like to address some bugfixes that were done in Sun's >> version 3.0 (including better error reporting, and more robust >> code for locating configuration files). Besides that, I'm not >> aware of any deficiences, but I've glanced other e-mails where >> people have suggested some. It would be good to get a summary >> of everyone's wishes. I've stated mine. >> >> I given much thought to what it would take to properly address > ^^^haven't >> EIA-422, EIA-423 and EIA-485 (if any); but those would >> probably be extensions. Sounds like the differences might >> be transparent to the API. I'll look into that more. >> >> Paul >> >> >>> Paul Klissner wrote: >>>> Jim Redman wrote: >>>>> Paul, >>>>> >>>>> For the record we're STILL supporting some PersonalJava platforms. >>>>> We're _almost_ at the point where we can assume that the platforms >>>>> will have a Collections framework, but routinely compile with a 1.1 >>>>> check so that we don't make that assumption unnecessarily. Of 50+ >>>>> non-graphical Factory Automation JavaBeans we have 2 that require >>>>> Java2 (Reporting and JavaScripting), and we have people asking for a >>>>> back-port. >>>>> >>>>> Embedded platforms don't change in a hurry. Unlike desktop >>>>> platforms, embedded systems are expected to last 5-10+ years. >>>>> >>>>> There are factory automation vendors in the pharmaceutical industry >>>>> who are buying systems on eBay because that's the FDA validate >>>>> platform. It must be that make/model, spec'd sometime in the mid-90's. >>>>> >>>>> So... If you make an incompatible change TODAY figure we can start >>>>> using that code _at the earliest_ somewhere around 2012 or the low >>>>> teens. >>>>> >>>>> Are we _really_ the only people on the list supporting >>>>> embedded/factory automation platforms? >>>>> >>>>> Jim >>>> Do you provide your own implementation classes? >>>> >>>> Why can't you just continue to use 2.1 for the embedded platform until >>>> 2012 if you're locked down? Are you worried bugs won't get fixed? >>>> Sun might consider open sourcing the 2.1 Java source. I can't promise >>>> that, but it's been discussed and hasn't met resistance, except >>>> from me, because I wasn't super impressed with the code. I can probably >>>> be persuaded to champion open sourcing that and going through the >>>> process/legal machinations within Sun if it frees us to pursue >>>> a JSR for a new generation of javax.comm where we can have a chunk of >>>> common code in Open Source and each platform is simply responsible >>>> for it's platform specific plugins. >>>> >>>> I don't have many opinions about this set in stone because there >>>> are a lot of technical and pragmatic considerations such as yours >>>> the community has that I am probably not aware of or sufficiently >>>> sensitive to yet. I don't feel I really have the bird's eye view >>>> of all of this yet. >>>> >>>> The other thing is, I can only offer 10% of my time right now, >>>> according to my management, which is why I'm not pushing to >>>> be the spec lead for the JSR, and want only to be a participant >>>> to represent Sun's interests on the E.G. There is nothing sacred >>>> about Sun employees in the JCP as far as a JSR initiated by another >>>> entity is concerned. I am not the person everything needs to be >>>> cleared through. Ideas I have will pass or fail based on their >>>> merit and the community perception just like anyone else's. >>>> >>>> Paul >>>> >>>>> Paul Klissner wrote: >>>>>> Jim Redman wrote: >>>>>>> Paul Klissner wrote: >>>>>>>> I'd just like to find another suitable name than javax.comm, unless >>>>>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>>>>> 'major revisions' are accounted for. javax.serialport? >>>>>>> Which perhaps brings us back to what are we trying to fix and how >>>>>>> badly. >>>>>> The goals I'm most interested in at the moment are: >>>>>> >>>>>> 1. A pluggable platform portmapping scheme wherein each platform >>>>>> can determine which ports to present to the application, and >>>>>> preferably as some configurable logical name. >>>>>> >>>>>> For example on the Sun Ray thin client platform, if an application >>>>>> aquiring a view of serial ports available on the system, it will >>>>>> be informed of Sun Ray serial ports if the application is running >>>>>> in a session currently directed to that particular Sun Ray unit, >>>>>> even though the serial port's device node happens to be server-side >>>>>> deeply nested in a leaf node. If the application is not running on >>>>>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>>>>> the decision about when and which ports to present to the application. >>>>>> >>>>>> 2. Pluggable driver-side interface where multiple platform-specific >>>>>> drivers can be utilized simultaneously to introduce more flexibility >>>>>> with the back end. >>>>>> >>>>>>> There are a number of 3rd party implementation of Java Comm, at >>>>>>> least one from IBM - part of what was J9, now Websphere, or >>>>>>> something (presumbly soon to get a name that has eclipse in it >>>>>>> sometime soon). Esmertec has one, and there are few others rolling >>>>>>> around. >>>>>> I have not been advocating gutting the API, since much of it is >>>>>> perfectly adequate. I'm not totally opposed to making substantial >>>>>> changes or improvements depending on other people's needs. There's >>>>>> no reason previous versions of javax.comm need to suddenly disappear >>>>>> if products need legacy support. >>>>>> >>>>>> >>>>>>> If RXTX is the only implementation of the JSR with no backward >>>>>>> compatibility, we've just forked Java Serial support and we (for a >>>>>>> least one) will be worse off. We won't be able to use the new >>>>>>> support because of a lack of support on J2ME platforms that we >>>>>>> have no control over and RXTX/current JavaComm will be in >>>>>>> maintenance mode or unsupported on all other platforms. >>>>>> There can't be *that* many platforms this is ported to. And it will >>>>>> be no javax.usb. Seems like most of the standard platforms will >>>>>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>>>>> JDBC... >>>>>> >>>>>>> So, is there any chance of building a compatibility requirement >>>>>>> into this. To pick are really bad example JDBC has support for a >>>>>>> DataSource or a Driver. Could we have an ExcellentSerialPort with >>>>>>> a fallback to a SerialPort on a class not found exception? >>>>>> Maybe, or maybe we just let people know what we are doing and >>>>>> try to figure out how to get their applications ported. Might not >>>>>> be that difficult. From my standpoint anyway, earthshaking >>>>>> changes aren't really necessary. Others might disagree. >>>>>> >>>>>> Paul >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Thu Jul 20 10:31:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 20 Jul 2006 10:31:57 -0600 (MDT) Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEA802.7060508@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: > PROJECT SCOPE: > ------------- > > Also, we should think carefully about what the scope of > this project would be. Should it be javax."comm" which > handles both serial and parallel (is parallel going by the > wayside). Should it be split into two project: > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > > Should we differentiate between single-ended serial > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > quasi-multidrop and full multidrop busses such as > EIA422, EIA432 and EIA485? If we really were to > add I2C support to the API, we'd have to delve into > the semantics more, because there could be some > implicit decoding of the bus the API users would > want to see. > Hi Paul The way RXTX works, which is a fair representation of the people using the API, is complete support for RIA232, minimal support for IEEE1284. From what I understand, Sun was going along the same lines. If we combined both projects, we would have half a parallel port implementation. I see maybe 4 requests for features not in the parallel support a year. The other protocols should not be limited by a JSR which is going to be focused upon serial port interests. The IEA485 hacks in RXTX along with I2C and Raw should _not_ be considered a strong basis for extending the API to cover these protocols. If people want to do real implementations, they should not face a 'standard' which wasnt really focused upon their interests. I think we understand the parallel port issues fairly well but have not implemented many features and I don't know if we would. So a versatile API is favorable but I do not think we have the proper community to represent much more than Serial. We could provide a framework or maybe just a model for further work with other standards. -- Trent Jarvi tjarvi at qbang.org From naranjo.manuel at gmail.com Thu Jul 20 10:49:33 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Thu, 20 Jul 2006 13:49:33 -0300 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <44BFB41D.4010604@gmail.com> Trent Jarvi wrote: >> PROJECT SCOPE: >> ------------- >> >> Also, we should think carefully about what the scope of >> this project would be. Should it be javax."comm" which >> handles both serial and parallel (is parallel going by the >> wayside). Should it be split into two project: >> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >> >> Should we differentiate between single-ended serial >> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >> quasi-multidrop and full multidrop busses such as >> EIA422, EIA432 and EIA485? If we really were to >> add I2C support to the API, we'd have to delve into >> the semantics more, because there could be some >> implicit decoding of the bus the API users would >> want to see. >> > > Hi Paul > > The way RXTX works, which is a fair representation of the people using the > API, is complete support for RIA232, minimal support for IEEE1284. From > what I understand, Sun was going along the same lines. If we combined > both projects, we would have half a parallel port implementation. I see > maybe 4 requests for features not in the parallel support a year. > > The other protocols should not be limited by a JSR which is going to be > focused upon serial port interests. The IEA485 hacks in RXTX along with > I2C and Raw should _not_ be considered a strong basis for extending the > API to cover these protocols. If people want to do real implementations, > they should not face a 'standard' which wasnt really focused upon their > interests. I think we understand the parallel port issues fairly well but > have not implemented many features and I don't know if we would. > > So a versatile API is favorable but I do not think we have the proper > community to represent much more than Serial. We could provide a > framework or maybe just a model for further work with other standards. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Hi, I agree with Trent, as far as I have seen most projects that were using RXTX and Java Comm where designed to work only with Serial Ports. What is fact is that a Parallel port can not be modeled at all like a Serial Port, except that they both expose and Input Stream and an Output Stream. As I have read there is a huge market of embedded applications using port accessing. We could take two different aproaches with the JSR, one could be define a way to access every kind of port independent of the implementation of the port himself. We could access Serial, Parallel, I2C, USB, etc. But we will have huge problems with it, because we will have to face a lot of low level programming which of course will be platform dependent, and that is were the write one use everywhere of Java could dye. The other approach is to define an Api that only supports Serial Ports, compatible with the one that is defined in javax.comm 2.0, and make some classes that extend that packages, maybe even in another package, like AWT and JSWING do. We then could eventually extend to other kinds of ports but that will require a lot of work more. I'm not a person specialized on Informatical Engineering, so I do not think I can give a hand on Low Level programming, I do can help with the Java part, debugging and testing. Regards, Manuel From brian at mbari.org Thu Jul 20 11:19:33 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 20 Jul 2006 10:19:33 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <8BFCAB48-6302-44CD-ABF0-560BC04AD26E@mbari.org> > The way RXTX works, which is a fair representation of the people > using the > API, is complete support for RIA232, minimal support for IEEE1284. > From > what I understand, Sun was going along the same lines. If we combined > both projects, we would have half a parallel port implementation. > I see > maybe 4 requests for features not in the parallel support a year. > > The other protocols should not be limited by a JSR which is going > to be > focused upon serial port interests. The IEA485 hacks in RXTX along > with > I2C and Raw should _not_ be considered a strong basis for extending > the > API to cover these protocols. If people want to do real > implementations, > they should not face a 'standard' which wasnt really focused upon > their > interests. I think we understand the parallel port issues fairly > well but > have not implemented many features and I don't know if we would. > > So a versatile API is favorable but I do not think we have the proper > community to represent much more than Serial. We could provide a > framework or maybe just a model for further work with other standards. I agree completely. Folks use RXTX for serial ports. In my field (Oceanography), we uses RS232 to talk to nearly all our instruments. So we really need a great implementation of serial port communications in Java that runs on a variety of architectures. I'd prefer if the JSR focused on that. >> I given much thought to what it would take to properly address >> > ^^^haven't > >> EIA-422, EIA-423 and EIA-485 (if any); but those would >> probably be extensions. Sounds like the differences might >> be transparent to the API. I'll look into that more. I've had good luck using the current implementation of RXTX with RS422, although you'll need to use a pin converter. my 2 cents. Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060720/fb956c68/attachment-0341.html From pascal at quies.net Fri Jul 21 15:43:40 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Fri, 21 Jul 2006 23:43:40 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: Message-ID: <200607212343.40882.pascal@quies.net> Op donderdag 20 juli 2006 15:16, schreef Dr. Douglas Lyon: > Hi All, > There has been some discussion about plugins for serial communications. > > As I see it, what Java really needs is a NativeLibraryManager. This is > a rather much larger charge than "just" RXTX. > > The RXTX basic mode of operation is that we associate static > blocks of code with a "System.load". > > Failure occurs when the class containing such a block of code is > loaded AND the native library is not found. > > What are some of the options? > > 1. Do nothing, let the program fail with an exception. > 2. try to catch an UnsatisfiedLinkError as a part of making > the driver. > 3. Search the java.library.path to see if the driver is present > (i.e., guard the input). > 4. Other?? > > In the case of either step 2 or 3, we need to fix the lack of a library. > > What are the options for fixing a library? > 1. Do nothing, but give the user an interesting error with instructions on > what to do. > 2. Attempt to find the library on the file system (perhaps with user help). > 3. Attempt to download the library and install it (perhaps with user > permission). > 4. Attempt to internalize the library as a UUEncoded serialized object and > install it (better ask the user, again!). > 5. Other?? 5. Put the binaries together with the attached classes in a jar. Joachim told me that and it works! I forgot to publish the results. :$ ---- begin example import org.rxtx.CommunicationAPI; ... CommunicationAPI commExtension = new CommunicationAPI(); try { commExtenios.loadNativeLibraries(); } catch (Exception e) { // We *need* javax.comm } // Now we have the extension available. ... ---- end example Do you like it? Commens anyone? The path to the libraries is in the form of /native/rxtx/-/{libserial,libparallel} so /native/rxtx/windows-i386/libserial would do. I asked for binaries but only Joachim offered me help with OS X on the next release. Does anyone have javax.comm warper classes? -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 6781 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060721/b39a5592/CommunicationAPI-0340.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: PlatformNotSupportedException.java Type: text/x-java Size: 1621 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060721/b39a5592/PlatformNotSupportedException-0340.bin From pascal at quies.net Fri Jul 21 15:45:30 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Fri, 21 Jul 2006 23:45:30 +0200 Subject: [Rxtx] quo vadis API/namespace (Re: jcp and jsr) In-Reply-To: References: <44BEDC4F.9030403@sun.com> Message-ID: <200607212345.30495.pascal@quies.net> Op donderdag 20 juli 2006 10:46, schreef Joachim Buechse: > So in short: Unless we find a strong argument why javax.comm can't be > used I prefer that we keep it. Unless we find a strong feature / use- > case that can not be handled with (an extension of) the current > CommPort/CommPortIndentifier I'd prefer to keep that as well. I seem to be the only one who sees failures in the API so lets keep it that way. Now how do we get a JSR/lisence if we don't want any changes? :P From lyon at docjava.com Sat Jul 22 06:07:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 22 Jul 2006 08:07:03 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607212343.40882.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> Message-ID: Hi All, I like the idea of the native lib in a jar with other classes. An alternative I did not know would work. Now, if you place the rxtx classes and native library in the same jar, do they both have to be in any specific place in order to be found? In my approach, you can locate the native library at run-time, and you need not alter any environmental variables nor mangle the JDK home. Thus, each user can have a different native library, one for development and one for release, for example. Regards, - Doug >Op donderdag 20 juli 2006 15:16, schreef Dr. Douglas Lyon: >> Hi All, >> There has been some discussion about plugins for serial communications. >> >> As I see it, what Java really needs is a NativeLibraryManager. This is >> a rather much larger charge than "just" RXTX. >> >> The RXTX basic mode of operation is that we associate static >> blocks of code with a "System.load". >> >> Failure occurs when the class containing such a block of code is >> loaded AND the native library is not found. >> >> What are some of the options? >> >> 1. Do nothing, let the program fail with an exception. >> 2. try to catch an UnsatisfiedLinkError as a part of making >> the driver. >> 3. Search the java.library.path to see if the driver is present >> (i.e., guard the input). >> 4. Other?? >> >> In the case of either step 2 or 3, we need to fix the lack of a library. >> >> What are the options for fixing a library? >> 1. Do nothing, but give the user an interesting error with instructions on >> what to do. >> 2. Attempt to find the library on the file system (perhaps with user help). >> 3. Attempt to download the library and install it (perhaps with user >> permission). >> 4. Attempt to internalize the library as a UUEncoded serialized object and >> install it (better ask the user, again!). >> 5. Other?? > >5. Put the binaries together with the attached classes in a jar. > >Joachim told me that and it works! I forgot to publish the results. :$ > > >---- begin example >import org.rxtx.CommunicationAPI; > >... >CommunicationAPI commExtension = new CommunicationAPI(); >try { > commExtenios.loadNativeLibraries(); >} catch (Exception e) { > // We *need* javax.comm >} > >// Now we have the extension available. >... >---- end example > > >Do you like it? Commens anyone? > > >The path to the libraries is in the form >of /native/rxtx/-/{libserial,libparallel} >so /native/rxtx/windows-i386/libserial would do. > >I asked for binaries but only Joachim offered me help with OS X on the next >release. > >Does anyone have javax.comm warper classes? > >Attachment converted: PowerBookHd:CommunicationAPI.java (TEXT/ttxt) (001C1686) >Attachment converted: PowerBookHd:PlatformNotSupporte#1C1687.java >(TEXT/ttxt) (001C1687) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 22 07:06:06 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 15:06:06 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607212343.40882.pascal@quies.net> Message-ID: <200607221506.07140.pascal@quies.net> > Now, if you place the rxtx classes and native library in the same > jar, do they both have to be in any specific place in order to be found? Answer: > >The path to the libraries is in the form > >of /native/rxtx/-/{libserial,libparallel} > >so /native/rxtx/windows-i386/libserial would do. I'me looking for the various os.name and os.arch values right now. From lyon at docjava.com Sat Jul 22 08:06:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 22 Jul 2006 10:06:26 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607221506.07140.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> <200607221506.07140.pascal@quies.net> Message-ID: Hi All, Here is how I have arranged my signed versions of the native binaries: http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/windows/native.jar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/native.jar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/linux/native.jar Then I do: public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isMacOs()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); System.out.println("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } My new-age NativeLibraryManger concept-thang allows you to write stuff like: /** * This method fixes the driver by beaming over * to the tmp directory a native.jar file. * The native.jar file is signed and its * native libs are beamed over to the user home directory * ~/.rxtx/
* Finally, the java.library.path is altered to include
* ~/.rxtx/ */ private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), NativeLibraryManager.mapLibraryName("rxtxSerial")); } catch (IOException e) { e.printStackTrace(); } } I do a lazy singleton design pattern: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getInstance() { if (driver != null) return driver; if (!NativeLibraryManager.isLibInPath("rxtxSerial")) fixDriver(); if (NativeLibraryManager.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } I am at a cross-roads here, since a file-based distro might be preferable to a URL based distro. To make this really general, and to "remember" where the last version of a native library came from, I serialize a bean into user preferences The user can then store native libraries anywhere, remembering the location in the preferences. What is the general feeling about this? Thanks! - Doug > > Now, if you place the rxtx classes and native library in the same >> jar, do they both have to be in any specific place in order to be found? > >Answer: > >> >The path to the libraries is in the form >> >of /native/rxtx/-/{libserial,libparallel} >> >so /native/rxtx/windows-i386/libserial would do. > >I'me looking for the various os.name and os.arch values right now. >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Sat Jul 22 10:30:55 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 22 Jul 2006 11:30:55 -0500 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607212343.40882.pascal@quies.net> Message-ID: <44C252BF.6040404@cox.net> Dr. Douglas Lyon wrote: > Hi All, > I like the idea of the native lib in a jar with other classes. > An alternative I did not know would work. I have several applications that run with a security policy. In these applications, native library loading will require an appropriate FilePermission that should be known about ahead of time. The current native library implementation will require the native library to be extracted from the jar and written to disk, requiring a FilePermission("...","write") for that file, and then will also require read access to load the library. I personally don't want to give write access to a JVM for a shared library which can provide a point of abuse by errant code. Gregg Wonderly From gergg at cox.net Sat Jul 22 10:33:52 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 22 Jul 2006 11:33:52 -0500 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607212343.40882.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> Message-ID: <44C25370.9070506@cox.net> >Pascal S. de Kloe wrote: >>> I am also not sure if >>> the api should unify corresponding cu. and tty. ports into one single >>> port. >> >> I think the API should hide low-level details like devicefiles. > >Not all ports have device files. It's long been my goal to add support >for virtual serial ports, that is, serial ports on Ethernet terminal >servers, for example integrating RFC2217. This means that the port name >is some combination of an IP address and TCP port number. Nothing in /dev. What I think would make the most sense is a simple "device" enumeration Server Provider Interface that would bring port objects into the JVM based on the platform JVM providers knowledge of how to enumerate those ports. Application writers would provide a plugin using the SPI that would codify those devices into named entities that they are interested in. public interface HardwarePort { public String getName(); public String getHardwareID(); public String getManufacturer(); public List getCapabilities(); public Object getImplementation(); } public interface PortCapability { public String getDescription(); public CapabilityId getIdentifier(); } public enum CapabilityId { INPUT, // Can receive input OUTPUT, // Can send output ASYNCHRONOUS, // Can send and receive at the same time SYNCHRONOUS, // No synchronous I/O ADDRESSABLE // Port has an address associated } Then, you might imagine that the enumerated capabilities had a standardized/specified interface that you'd find implemented on ports that had such capabilities. The getImplementation() method would return the implementation class provided by the JVM provider that had all of the interfaces tied to it. These are just some quick thoughts, pick away at them. I am very interested in getting a new comm api in place which can provide the ability for all USB connected devices to have drivers provided as 100% java for all non-timing critical types of device interfaces. The JVM provider should have an SPI to write to which will enable them to abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into something that we can talk 100% java to. That's my big desire. Starting with something simple which gives a good start in that direction would be great! Gregg Wonderly From pascal at quies.net Sat Jul 22 10:43:27 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 18:43:27 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <44C252BF.6040404@cox.net> References: <44C252BF.6040404@cox.net> Message-ID: <200607221843.27765.pascal@quies.net> Op zaterdag 22 juli 2006 18:30, schreef Gregg Wonderly: > Dr. Douglas Lyon wrote: > > Hi All, > > I like the idea of the native lib in a jar with other classes. > > An alternative I did not know would work. > > I have several applications that run with a security policy. In these > applications, native library loading will require an appropriate > FilePermission that should be known about ahead of time. The current > native library implementation will require the native library to be > extracted from the jar and written to disk, requiring a > FilePermission("...","write") for that file, and then will also require > read access to load the library. I personally don't want to give write > access to a JVM for a shared library which can provide a point of abuse by > errant code. > > Gregg Wonderly That's indeed a pitty limitation. It creates a lot of possible exceptions too. On the other hand, any native lib passes the securiy model. Applications who can access hardware ports can be expected to create files, right? From pascal at quies.net Sat Jul 22 10:54:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 18:54:13 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607221506.07140.pascal@quies.net> Message-ID: <200607221854.13467.pascal@quies.net> Hi Dr., We're both trying to do the same thing. The CommunicationAPI does not only look at the OS but it also indexes the available hardware architectures and does not need OsUtils. Any Java 2 runtime will do. The plan was to make a single JAR with the binaries for all supported platforms, the RXTX gnu.io package and the javax.comm wrapers. A signed version would be nice. A few questions remain tough. Does anybody know how Sun uses the SunOS and Solaris identifiers for the Java property os.name? Op zaterdag 22 juli 2006 16:06, schreef Dr. Douglas Lyon: > Hi All, > Here is how I have arranged my signed versions of the native > binaries: > http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/windows/native.j >ar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/native.jar > http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/linux/native.jar > > Then I do: > public static URL getResourceUrl() throws MalformedURLException { > String rxtxUrl = "http://show.docjava.com:8086/" + > "book/cgij/code/jnlp/libs/rxtx/"; > if (OsUtils.isLinux()) > return new URL(rxtxUrl + "linux/native.jar"); > if (OsUtils.isMacOs()) > return new URL(rxtxUrl + "mac/native.jar"); > if (OsUtils.isWindows()) > return new URL(rxtxUrl + "windows/native.jar"); > System.out.println("no automatic install supported for this > platform. " + > "Please e-mail lyon at docjava.com with a bug report"); > return null; > } > > My new-age NativeLibraryManger concept-thang allows you to > write stuff like: > > /** > * This method fixes the driver by beaming over > * to the tmp directory a native.jar file. > * The native.jar file is signed and its > * native libs are beamed over to the user home directory > * ~/.rxtx/
> * Finally, the java.library.path is altered to include
> * ~/.rxtx/ > */ > private static void fixDriver() { > > try { > NativeLibraryManager.fixDriver(getResourceUrl(), > NativeLibraryManager.mapLibraryName("rxtxSerial")); > } catch (IOException e) { > e.printStackTrace(); > } > } > > I do a lazy singleton design pattern: > > public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public synchronized static RXTXCommDriver getInstance() { > if (driver != null) return driver; > if (!NativeLibraryManager.isLibInPath("rxtxSerial")) > fixDriver(); > if (NativeLibraryManager.isLibInPath("rxtxSerial")) { > driver = new RXTXCommDriver(); > driver.initialize(); > } > return driver; > } > > I am at a cross-roads here, since a file-based distro might be preferable > to a URL based distro. To make this really general, and to "remember" where > the last version of a native library came from, I serialize a bean into > user preferences > The user can then store native libraries anywhere, remembering the location > in the preferences. > > What is the general feeling about this? > > Thanks! > - Doug > > > > Now, if you place the rxtx classes and native library in the same > >> > >> jar, do they both have to be in any specific place in order to be > >> found? > > > >Answer: > >> >The path to the libraries is in the form > >> >of /native/rxtx/-/{libserial,libparallel} > >> >so /native/rxtx/windows-i386/libserial would do. > > > >I'me looking for the various os.name and os.arch values right now. > >_______________________________________________ > >Rxtx mailing list > >Rxtx at qbang.org > >http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Sat Jul 22 11:17:51 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 22 Jul 2006 19:17:51 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <44C252BF.6040404@cox.net> References: <200607212343.40882.pascal@quies.net> <44C252BF.6040404@cox.net> Message-ID: <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> We could easily have a stub method / flag that allows you to explicitly load the native library (via System.loadLibrary ie from the java.library.path). In this case the "auto-extraction" would not take place. On 22.07.2006, at 18:30, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> Hi All, >> I like the idea of the native lib in a jar with other classes. >> An alternative I did not know would work. > > I have several applications that run with a security policy. In these > applications, native library loading will require an appropriate > FilePermission > that should be known about ahead of time. The current native library > implementation will require the native library to be extracted from > the jar and > written to disk, requiring a FilePermission("...","write") for that > file, and > then will also require read access to load the library. I > personally don't want > to give write access to a JVM for a shared library which can > provide a point of > abuse by errant code. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 22 11:20:19 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 19:20:19 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607221506.07140.pascal@quies.net> Message-ID: <200607221920.20096.pascal@quies.net> The attachment setup.zip contains a very small update of CommunicationAPI and a good start with the various platforms. All we need to do is fill those directories with binaries. Various binaries are missing the pararlel library. Why is that? -------------- next part -------------- A non-text attachment was scrubbed... Name: setup.zip Type: application/x-zip Size: 8459 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060722/12770623/setup-0339.bin From gregg at cytetech.com Thu Jul 20 21:32:55 2006 From: gregg at cytetech.com (Gregg Wonderly) Date: Thu, 20 Jul 2006 22:32:55 -0500 Subject: [Rxtx] jcp and jsr Message-ID: <44C04AE7.9050800@cytetech.com> >Pascal S. de Kloe wrote: >>> I am also not sure if >>> the api should unify corresponding cu. and tty. ports into one single >>> port. >> >> I think the API should hide low-level details like devicefiles. > >Not all ports have device files. It's long been my goal to add support >for virtual serial ports, that is, serial ports on Ethernet terminal >servers, for example integrating RFC2217. This means that the port name >is some combination of an IP address and TCP port number. Nothing in /dev. What I think would make the most sense is a simple "device" enumeration Server Provider Interface that would bring port objects into the JVM based on the platform JVM providers knowledge of how to enumerate those ports. Application writers would provide a plugin using the SPI that would codify those devices into named entities that they are interested in. public interface HardwarePort { public String getName(); public String getHardwareID(); public String getManufacturer(); public List getCapabilities(); public Object getImplementation(); } public interface PortCapability { public String getDescription(); public CapabilityId getIdentifier(); } public enum CapabilityId { INPUT, // Can receive input OUTPUT, // Can send output ASYNCHRONOUS, // Can send and receive at the same time SYNCHRONOUS, // No synchronous I/O ADDRESSABLE // Port has an address associated } Then, you might imagine that the enumerated capabilities had a standardized/specified interface that you'd find implemented on ports that had such capabilities. The getImplementation() method would return the implementation class provided by the JVM provider that had all of the interfaces tied to it. These are just some quick thoughts, pick away at them. I am very interested in getting a new comm api in place which can provide the ability for all USB connected devices to have drivers provided as 100% java for all non-timing critical types of device interfaces. The JVM provider should have an SPI to write to which will enable them to abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into something that we can talk 100% java to. That's my big desire. Starting with something simple which gives a good start in that direction would be great! Gregg Wonderly From pascal at quies.net Sat Jul 22 11:32:03 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 19:32:03 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44C25370.9070506@cox.net> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> Message-ID: <200607221932.04194.pascal@quies.net> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: > >Pascal S. de Kloe wrote: > >>> I am also not sure if > >>> the api should unify corresponding cu. and tty. ports into one single > >>> port. > >> > >> I think the API should hide low-level details like devicefiles. > > > >Not all ports have device files. It's long been my goal to add support > >for virtual serial ports, that is, serial ports on Ethernet terminal > >servers, for example integrating RFC2217. This means that the port name > >is some combination of an IP address and TCP port number. Nothing in > > /dev. > > What I think would make the most sense is a simple "device" enumeration > Server Provider Interface that would bring port objects into the JVM based > on the platform JVM providers knowledge of how to enumerate those ports. > Application writers would provide a plugin using the SPI that would codify > those devices into named entities that they are interested in. > > public interface HardwarePort { > public String getName(); > public String getHardwareID(); > public String getManufacturer(); > public List getCapabilities(); > public Object getImplementation(); > } > > public interface PortCapability { > public String getDescription(); > public CapabilityId getIdentifier(); > } > > public enum CapabilityId { > INPUT, // Can receive input > OUTPUT, // Can send output > ASYNCHRONOUS, // Can send and receive at the same time > SYNCHRONOUS, // No synchronous I/O > ADDRESSABLE // Port has an address associated > } > > Then, you might imagine that the enumerated capabilities had a > standardized/specified interface that you'd find implemented on ports that > had such capabilities. > > The getImplementation() method would return the implementation class > provided by the JVM provider that had all of the interfaces tied to it. > > These are just some quick thoughts, pick away at them. > > I am very interested in getting a new comm api in place which can provide > the ability for all USB connected devices to have drivers provided as 100% > java for all non-timing critical types of device interfaces. > > The JVM provider should have an SPI to write to which will enable them to > abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into something > that we can talk 100% java to. > > That's my big desire. Starting with something simple which gives a good > start in that direction would be great! That was exactly my wish too. The point people brought up was: 1) It's too complex. 2) What does it solve? In both facts they are right. It'll take a *long* time to plan such a thing right but if it works you have a product. Anyway, I'd like to join. ;) From joachim at buechse.de Sat Jul 22 11:37:11 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 22 Jul 2006 19:37:11 +0200 Subject: [Rxtx] Strange error (show stopper) Message-ID: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> I just discovered a strange error in RXTX on OSX. SerialDemo.java manages to corrupt the event_info_structure by a simple OpenPort,ClosePort - this could be in relation to the deadlock problem that was reported recently. Could anyone try to reproduce this on Solaris or some other system which is neither WIN32 nor Linux (ie which uses a drain thread). In SerialImp.c : RXTXPort(interruptEventLoop) Apparently the event_info_structure gets corrupted shortly after pthread_kill(index->drain_tid, SIGABRT); In particular, the index->closing flag gets overwritten by a pointer value. **** Adding the following debugging code: pthread_kill(index->drain_tid, SIGABRT); sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i \n", index->fd, index, index->closing ); report( message ); /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ usleep(50 * 1000); sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i \n", index->fd, index, index->closing ); report( message ); **** gives me: 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 drain_loop: received EINTR------------------ drain_loop exiting --------------------- entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 eventLoop: got interrupt 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 **** Modifying SerialImp.h : event_info_struct by moving the prev*, next* pointers jmethodID checkMonitorThread; struct event_info_struct *dummy, *dummy2; fd_set rfds; struct timeval tv_sleep; int closing; struct event_info_struct *next, *prev; *** (ie replacing their original position with dummys and moving them *** behind the closing flag) results in this: 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 drain_loop: received EINTR------------------ drain_loop exiting --------------------- entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 eventLoop: got interrupt 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 *** I was not able to track down the problem. If anyone could check wether this happens on other platforms as well, we may get closer to a fix. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich From joachim at buechse.de Sat Jul 22 11:46:35 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 22 Jul 2006 19:46:35 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607221932.04194.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> Message-ID: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> It seems that Gregg's suggestion could be implemented without changing the existing "user-level" API of javax.comm. Most of the information suggested for HardwarePort is not accessible from within the POSSIX-API but this is a different story. It is clear that javax.comm can never provide a way to talk to all USB devices, simply because some USB devices have several endpoints. But it could provide a means of talking to devices that function as a bidirectional-pipe (ie any USB to serial bridge). Regards, Joachim On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>> Pascal S. de Kloe wrote: >>>>> I am also not sure if >>>>> the api should unify corresponding cu. and tty. ports into one >>>>> single >>>>> port. >>>> >>>> I think the API should hide low-level details like devicefiles. >>> >>> Not all ports have device files. It's long been my goal to add >>> support >>> for virtual serial ports, that is, serial ports on Ethernet terminal >>> servers, for example integrating RFC2217. This means that the >>> port name >>> is some combination of an IP address and TCP port number. >>> Nothing in >>> /dev. >> >> What I think would make the most sense is a simple "device" >> enumeration >> Server Provider Interface that would bring port objects into the >> JVM based >> on the platform JVM providers knowledge of how to enumerate those >> ports. >> Application writers would provide a plugin using the SPI that >> would codify >> those devices into named entities that they are interested in. >> >> public interface HardwarePort { >> public String getName(); >> public String getHardwareID(); >> public String getManufacturer(); >> public List getCapabilities(); >> public Object getImplementation(); >> } >> >> public interface PortCapability { >> public String getDescription(); >> public CapabilityId getIdentifier(); >> } >> >> public enum CapabilityId { >> INPUT, // Can receive input >> OUTPUT, // Can send output >> ASYNCHRONOUS, // Can send and receive at the same time >> SYNCHRONOUS, // No synchronous I/O >> ADDRESSABLE // Port has an address associated >> } >> >> Then, you might imagine that the enumerated capabilities had a >> standardized/specified interface that you'd find implemented on >> ports that >> had such capabilities. >> >> The getImplementation() method would return the implementation class >> provided by the JVM provider that had all of the interfaces tied >> to it. >> >> These are just some quick thoughts, pick away at them. >> >> I am very interested in getting a new comm api in place which can >> provide >> the ability for all USB connected devices to have drivers provided >> as 100% >> java for all non-timing critical types of device interfaces. >> >> The JVM provider should have an SPI to write to which will enable >> them to >> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >> something >> that we can talk 100% java to. >> >> That's my big desire. Starting with something simple which gives >> a good >> start in that direction would be great! > > That was exactly my wish too. > > The point people brought up was: > 1) It's too complex. > 2) What does it solve? > > In both facts they are right. It'll take a *long* time to plan such > a thing > right but if it works you have a product. Anyway, I'd like to join. ;) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Jul 22 11:55:23 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 22 Jul 2006 14:55:23 -0300 Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: <44C2668B.5080703@gmail.com> Joachim Buechse escribi?: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. > > It is clear that javax.comm can never provide a way to talk to all > USB devices, simply because some USB devices have several endpoints. > But it could provide a means of talking to devices that function as a > bidirectional-pipe (ie any USB to serial bridge). > > Regards, > Joachim Hi, About USB, why do not we contact the guys that make a library to support USB under Java from Linux? I think there is all ready an JSR for USB access, what we could do to this JSR is help to implement Usb access from other OSes. Regards, Manuel > > On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > >> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>> Pascal S. de Kloe wrote: >>>>>> I am also not sure if >>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>> single >>>>>> port. >>>>> I think the API should hide low-level details like devicefiles. >>>> Not all ports have device files. It's long been my goal to add >>>> support >>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>> servers, for example integrating RFC2217. This means that the >>>> port name >>>> is some combination of an IP address and TCP port number. >>>> Nothing in >>>> /dev. >>> What I think would make the most sense is a simple "device" >>> enumeration >>> Server Provider Interface that would bring port objects into the >>> JVM based >>> on the platform JVM providers knowledge of how to enumerate those >>> ports. >>> Application writers would provide a plugin using the SPI that >>> would codify >>> those devices into named entities that they are interested in. >>> >>> public interface HardwarePort { >>> public String getName(); >>> public String getHardwareID(); >>> public String getManufacturer(); >>> public List getCapabilities(); >>> public Object getImplementation(); >>> } >>> >>> public interface PortCapability { >>> public String getDescription(); >>> public CapabilityId getIdentifier(); >>> } >>> >>> public enum CapabilityId { >>> INPUT, // Can receive input >>> OUTPUT, // Can send output >>> ASYNCHRONOUS, // Can send and receive at the same time >>> SYNCHRONOUS, // No synchronous I/O >>> ADDRESSABLE // Port has an address associated >>> } >>> >>> Then, you might imagine that the enumerated capabilities had a >>> standardized/specified interface that you'd find implemented on >>> ports that >>> had such capabilities. >>> >>> The getImplementation() method would return the implementation class >>> provided by the JVM provider that had all of the interfaces tied >>> to it. >>> >>> These are just some quick thoughts, pick away at them. >>> >>> I am very interested in getting a new comm api in place which can >>> provide >>> the ability for all USB connected devices to have drivers provided >>> as 100% >>> java for all non-timing critical types of device interfaces. >>> >>> The JVM provider should have an SPI to write to which will enable >>> them to >>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>> something >>> that we can talk 100% java to. >>> >>> That's my big desire. Starting with something simple which gives >>> a good >>> start in that direction would be great! >> That was exactly my wish too. >> >> The point people brought up was: >> 1) It's too complex. >> 2) What does it solve? >> >> In both facts they are right. It'll take a *long* time to plan such >> a thing >> right but if it works you have a product. Anyway, I'd like to join. ;) >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Sat Jul 22 11:58:00 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Sat, 22 Jul 2006 13:58:00 -0400 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> Message-ID: <41E45C85-4A22-4C5B-915F-62ED36BACCF2@sympatico.ca> A couple of questions: - what version are you using? - does this happen with the version in cvs? Andre On 22-Jul-06, at 13:37 , Joachim Buechse wrote: > I just discovered a strange error in RXTX on OSX. SerialDemo.java > manages to corrupt the event_info_structure by a simple > OpenPort,ClosePort - this could be in relation to the deadlock > problem that was reported recently. > > Could anyone try to reproduce this on Solaris or some other system > which is neither WIN32 nor Linux (ie which uses a drain thread). > > In SerialImp.c : RXTXPort(interruptEventLoop) > > Apparently the event_info_structure gets corrupted shortly after > > pthread_kill(index->drain_tid, SIGABRT); > > In particular, the index->closing flag gets overwritten by a pointer > value. > > > **** Adding the following debugging code: > > pthread_kill(index->drain_tid, SIGABRT); > sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ > usleep(50 * 1000); > sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > > **** gives me: > > 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 > > **** Modifying SerialImp.h : event_info_struct by moving the > prev*, next* pointers > > jmethodID checkMonitorThread; > struct event_info_struct *dummy, *dummy2; > fd_set rfds; > struct timeval tv_sleep; > int closing; > struct event_info_struct *next, *prev; > > *** (ie replacing their original position with dummys and moving them > *** behind the closing flag) results in this: > > 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 > > > *** I was not able to track down the problem. If anyone could check > wether this happens on other platforms as well, we may get closer to > a fix. > > Regards, > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Paul.Klissner at Sun.COM Sat Jul 22 12:19:41 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Sat, 22 Jul 2006 11:19:41 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: <44C26C3D.8020501@sun.com> Joachim Buechse wrote: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. > > It is clear that javax.comm can never provide a way to talk to all > USB devices, simply because some USB devices have several endpoints. > But it could provide a means of talking to devices that function as a > bidirectional-pipe (ie any USB to serial bridge). If the 'back end' driver could be java as well an .so then driver's could be written using javax.usb, which is available currently for Linux. Paul > > Regards, > Joachim > > On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > >> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>> Pascal S. de Kloe wrote: >>>>>> I am also not sure if >>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>> single >>>>>> port. >>>>> I think the API should hide low-level details like devicefiles. >>>> Not all ports have device files. It's long been my goal to add >>>> support >>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>> servers, for example integrating RFC2217. This means that the >>>> port name >>>> is some combination of an IP address and TCP port number. >>>> Nothing in >>>> /dev. >>> What I think would make the most sense is a simple "device" >>> enumeration >>> Server Provider Interface that would bring port objects into the >>> JVM based >>> on the platform JVM providers knowledge of how to enumerate those >>> ports. >>> Application writers would provide a plugin using the SPI that >>> would codify >>> those devices into named entities that they are interested in. >>> >>> public interface HardwarePort { >>> public String getName(); >>> public String getHardwareID(); >>> public String getManufacturer(); >>> public List getCapabilities(); >>> public Object getImplementation(); >>> } >>> >>> public interface PortCapability { >>> public String getDescription(); >>> public CapabilityId getIdentifier(); >>> } >>> >>> public enum CapabilityId { >>> INPUT, // Can receive input >>> OUTPUT, // Can send output >>> ASYNCHRONOUS, // Can send and receive at the same time >>> SYNCHRONOUS, // No synchronous I/O >>> ADDRESSABLE // Port has an address associated >>> } >>> >>> Then, you might imagine that the enumerated capabilities had a >>> standardized/specified interface that you'd find implemented on >>> ports that >>> had such capabilities. >>> >>> The getImplementation() method would return the implementation class >>> provided by the JVM provider that had all of the interfaces tied >>> to it. >>> >>> These are just some quick thoughts, pick away at them. >>> >>> I am very interested in getting a new comm api in place which can >>> provide >>> the ability for all USB connected devices to have drivers provided >>> as 100% >>> java for all non-timing critical types of device interfaces. >>> >>> The JVM provider should have an SPI to write to which will enable >>> them to >>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>> something >>> that we can talk 100% java to. >>> >>> That's my big desire. Starting with something simple which gives >>> a good >>> start in that direction would be great! >> That was exactly my wish too. >> >> The point people brought up was: >> 1) It's too complex. >> 2) What does it solve? >> >> In both facts they are right. It'll take a *long* time to plan such >> a thing >> right but if it works you have a product. Anyway, I'd like to join. ;) >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 22 12:48:15 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 20:48:15 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607221920.20096.pascal@quies.net> References: <200607221920.20096.pascal@quies.net> Message-ID: <200607222048.16215.pascal@quies.net> http://quies.net/communicationapi.jar Fixed a few typo's and it works on Linux i386. It should also work on Windows i386. The rest is missing libParallel or more... -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 6664 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060722/5fd7c1ce/CommunicationAPI-0339.bin From Paul.Klissner at Sun.COM Sat Jul 22 12:53:12 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Sat, 22 Jul 2006 11:53:12 -0700 Subject: [Rxtx] jcp and jsr (libusb, javax.usb) In-Reply-To: <44C2668B.5080703@gmail.com> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> <44C2668B.5080703@gmail.com> Message-ID: <44C27418.1090309@sun.com> Manuel Naranjo wrote: > Joachim Buechse escribi?: >> It seems that Gregg's suggestion could be implemented without >> changing the existing "user-level" API of javax.comm. Most of the >> information suggested for HardwarePort is not accessible from within >> the POSSIX-API but this is a different story. >> >> It is clear that javax.comm can never provide a way to talk to all >> USB devices, simply because some USB devices have several endpoints. >> But it could provide a means of talking to devices that function as a >> bidirectional-pipe (ie any USB to serial bridge). >> >> Regards, >> Joachim > > Hi, > About USB, why do not we contact the guys that make a library to support > USB under Java from Linux? > I think there is all ready an JSR for USB access, what we could do to this > JSR is help to implement Usb access from other OSes. JAVAX.USB --------- javax.usb already a SourceForge project. I was Sun's rep on the expert group for JSR-80, javax.usb. I lived and breathed it for a 1.5 yrs working with spec lead from IBM on it. It's for real and the linux implementation works (not sure about the Win32 port on sourceforge). IBM even created a porting layer to simplify porting it to other platforms by implementing in Java all of the numerous 'clerical' functions of the API in Java so that the porting layer is absolutely minimal. The hardest part is managing the hotpluggable device tree topology as objects, and depending on one's platform or coding skills probably wouldn't take more than a week or two to get right. LIBUSB 1.0 (*NOT* libusb 0.1.8) ---------- There is also the native C library libusb. libusb 0.1.8 is weak, but libusb 1.0 under development holds the promise of being an extrordinarily robust C API to access USB devices through, and could definitely use some help getting people to port it to other platforms. I've attached the proposed libusb 1.0 API header which Sun worked with Johannes on for months before he went off into oblivion. The API has stalled and a fire might need to be lit under Johannes or it might need to be forked to get it moving again, but the spec for 1.0 is awesome, and this puppy is ready to turn into something sweet with some fresh blood on it. And it is a really good technology to become aquainted with... hint hint. Both of those APIs are really excellent and hold great promise for the community and use of USB technology in general. One of my goals, now which competes for my time with other higher priority projects was to layer an implementation of javax.usb over libusb 1.0, so that javax.usb would follow libusb to any platform and only one port would be required. But since libusb 1.0 is moving slowly, largely because the current sourceforge gatekeeper for the project, Johannes Erdfelt's lack of energy and sparse communication, it might be faster to simply port javax.usb to Mac OS, Win, Solaris and BSD if some people could get behind those, unless someone want's to get behind making libusb happen. >>>> >>>> public enum CapabilityId { >>>> INPUT, // Can receive input >>>> OUTPUT, // Can send output >>>> ASYNCHRONOUS, // Can send and receive at the same time >>>> SYNCHRONOUS, // No synchronous I/O >>>> ADDRESSABLE // Port has an address associated >>>> } My understanding is that synchronous/asynchronous refers to the way the data is clocked. I think FULLDUPLEX/HALFDUPLEX is what the author meant, or needs to be added. Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: libusb.h Type: text/x-sun-h-file Size: 26696 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060722/4a43e034/libusb-0339.bin From pascal at quies.net Sat Jul 22 17:53:31 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 01:53:31 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> References: <44C252BF.6040404@cox.net> <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> Message-ID: <200607230153.32328.pascal@quies.net> Hi Joachim, I'm not getting it. How do you easily get a "stub method / flag"? Op zaterdag 22 juli 2006 19:17, schreef Joachim Buechse: > We could easily have a stub method / flag that allows you to > explicitly load the native library (via System.loadLibrary ie from > the java.library.path). In this case the "auto-extraction" would not > take place. > > On 22.07.2006, at 18:30, Gregg Wonderly wrote: > > Dr. Douglas Lyon wrote: > >> Hi All, > >> I like the idea of the native lib in a jar with other classes. > >> An alternative I did not know would work. > > > > I have several applications that run with a security policy. In these > > applications, native library loading will require an appropriate > > FilePermission > > that should be known about ahead of time. The current native library > > implementation will require the native library to be extracted from > > the jar and > > written to disk, requiring a FilePermission("...","write") for that > > file, and > > then will also require read access to load the library. I > > personally don't want > > to give write access to a JVM for a shared library which can > > provide a point of > > abuse by errant code. > > > > Gregg Wonderly > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat Jul 22 18:46:33 2006 From: jredman at ergotech.com (Jim Redman) Date: Sat, 22 Jul 2006 18:46:33 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44C26C3D.8020501@sun.com> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> <44C26C3D.8020501@sun.com> Message-ID: <44C2C6E9.8020408@ergotech.com> Paul, I think that you've already proposed a "pluggable" underlying architecture and I think that this might be better implemented there. If you need some more examples, I'd like to have a Bluetooth interface (with dynamic discovery). Jim Paul Klissner wrote: > Joachim Buechse wrote: >> It seems that Gregg's suggestion could be implemented without >> changing the existing "user-level" API of javax.comm. Most of the >> information suggested for HardwarePort is not accessible from within >> the POSSIX-API but this is a different story. >> >> It is clear that javax.comm can never provide a way to talk to all >> USB devices, simply because some USB devices have several endpoints. >> But it could provide a means of talking to devices that function as a >> bidirectional-pipe (ie any USB to serial bridge). > > If the 'back end' driver could be java as well an .so > then driver's could be written using javax.usb, which > is available currently for Linux. > > Paul > > > >> Regards, >> Joachim >> >> On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: >> >>> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>>> Pascal S. de Kloe wrote: >>>>>>> I am also not sure if >>>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>>> single >>>>>>> port. >>>>>> I think the API should hide low-level details like devicefiles. >>>>> Not all ports have device files. It's long been my goal to add >>>>> support >>>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>>> servers, for example integrating RFC2217. This means that the >>>>> port name >>>>> is some combination of an IP address and TCP port number. >>>>> Nothing in >>>>> /dev. >>>> What I think would make the most sense is a simple "device" >>>> enumeration >>>> Server Provider Interface that would bring port objects into the >>>> JVM based >>>> on the platform JVM providers knowledge of how to enumerate those >>>> ports. >>>> Application writers would provide a plugin using the SPI that >>>> would codify >>>> those devices into named entities that they are interested in. >>>> >>>> public interface HardwarePort { >>>> public String getName(); >>>> public String getHardwareID(); >>>> public String getManufacturer(); >>>> public List getCapabilities(); >>>> public Object getImplementation(); >>>> } >>>> >>>> public interface PortCapability { >>>> public String getDescription(); >>>> public CapabilityId getIdentifier(); >>>> } >>>> >>>> public enum CapabilityId { >>>> INPUT, // Can receive input >>>> OUTPUT, // Can send output >>>> ASYNCHRONOUS, // Can send and receive at the same time >>>> SYNCHRONOUS, // No synchronous I/O >>>> ADDRESSABLE // Port has an address associated >>>> } >>>> >>>> Then, you might imagine that the enumerated capabilities had a >>>> standardized/specified interface that you'd find implemented on >>>> ports that >>>> had such capabilities. >>>> >>>> The getImplementation() method would return the implementation class >>>> provided by the JVM provider that had all of the interfaces tied >>>> to it. >>>> >>>> These are just some quick thoughts, pick away at them. >>>> >>>> I am very interested in getting a new comm api in place which can >>>> provide >>>> the ability for all USB connected devices to have drivers provided >>>> as 100% >>>> java for all non-timing critical types of device interfaces. >>>> >>>> The JVM provider should have an SPI to write to which will enable >>>> them to >>>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>>> something >>>> that we can talk 100% java to. >>>> >>>> That's my big desire. Starting with something simple which gives >>>> a good >>>> start in that direction would be great! >>> That was exactly my wish too. >>> >>> The point people brought up was: >>> 1) It's too complex. >>> 2) What does it solve? >>> >>> In both facts they are right. It'll take a *long* time to plan such >>> a thing >>> right but if it works you have a product. Anyway, I'd like to join. ;) >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From lyon at docjava.com Sun Jul 23 04:27:22 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 06:27:22 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607222048.16215.pascal@quies.net> References: <200607221920.20096.pascal@quies.net> <200607222048.16215.pascal@quies.net> Message-ID: The Class.forName is a static method. Therefore myClass.forName Should be Class.forName and myClass becomes an unused parameter. - DL >http://quies.net/communicationapi.jar > >Fixed a few typo's and it works on Linux i386. It should also work on Windows >i386. The rest is missing libParallel or more... > > >Attachment converted: PowerBookHd:CommunicationAPI 1.java >(TEXT/ttxt) (001C1A15) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Jul 23 04:32:45 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 06:32:45 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607222048.16215.pascal@quies.net> References: <200607221920.20096.pascal@quies.net> <200607222048.16215.pascal@quies.net> Message-ID: Also, the is Java2 check does not check if you are running under jdk1.5 - DL >http://quies.net/communicationapi.jar > >Fixed a few typo's and it works on Linux i386. It should also work on Windows >i386. The rest is missing libParallel or more... > > >Attachment converted: PowerBookHd:CommunicationAPI 1.java >(TEXT/ttxt) (001C1A15) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Jul 23 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 06:54:12 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607221843.27765.pascal@quies.net> References: <44C252BF.6040404@cox.net> <200607221843.27765.pascal@quies.net> Message-ID: Hi All, Perhaps Java web start can address Gregg's concerns. The native libs are placed into a signed jar for distribution. As to the assertion that serial-port based programs need file io abilities, that seems true, to me. Particularly for /dev/ttyN type native libs or libs that use lock files. The question of how to obtain a signed application that is given file-io authority may be settled by using a signing technology. Even applets can be signed, to enable improved access to the file system. What else can we try? Any ideas? Thanks! - Doug >Op zaterdag 22 juli 2006 18:30, schreef Gregg Wonderly: >> Dr. Douglas Lyon wrote: >> > Hi All, >> > I like the idea of the native lib in a jar with other classes. >> > An alternative I did not know would work. >> >> I have several applications that run with a security policy. In these >> applications, native library loading will require an appropriate >> FilePermission that should be known about ahead of time. The current >> native library implementation will require the native library to be >> extracted from the jar and written to disk, requiring a >> FilePermission("...","write") for that file, and then will also require >> read access to load the library. I personally don't want to give write >> access to a JVM for a shared library which can provide a point of abuse by >> errant code. >> >> Gregg Wonderly > >That's indeed a pitty limitation. It creates a lot of possible exceptions too. > >On the other hand, any native lib passes the securiy model. Applications who >can access hardware ports can be expected to create files, right? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 04:57:33 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 12:57:33 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607222048.16215.pascal@quies.net> Message-ID: <200607231257.34284.pascal@quies.net> Op zondag 23 juli 2006 12:27, schreef Dr. Douglas Lyon: > The Class.forName is a static method. Therefore > myClass.forName Should be Class.forName and > myClass becomes an unused parameter. > - DL Thank you. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 6625 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060723/00f3b627/CommunicationAPI-0339.bin From pascal at quies.net Sun Jul 23 05:02:59 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 13:02:59 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607222048.16215.pascal@quies.net> Message-ID: <200607231302.59252.pascal@quies.net> Op zondag 23 juli 2006 12:32, schreef Dr. Douglas Lyon: > Also, the is Java2 check does not check if you are running under > jdk1.5 > - DL Could you please explain? The JDK 1.5 will pass the check just fine. From lyon at docjava.com Sun Jul 23 05:34:10 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 07:34:10 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607221854.13467.pascal@quies.net> References: <200607221506.07140.pascal@quies.net> <200607221854.13467.pascal@quies.net> Message-ID: Hi All, Please call me Doug (the Dr. is for the classroom). Thanks! - Doug >Hi Dr., > >We're both trying to do the same thing. > >The CommunicationAPI does not only look at the OS but it also indexes the >available hardware architectures and does not need OsUtils. Any Java 2 >runtime will do. > >The plan was to make a single JAR with the binaries for all supported >platforms, the RXTX gnu.io package and the javax.comm wrapers. > >A signed version would be nice. > >A few questions remain tough. Does anybody know how Sun uses the SunOS and >Solaris identifiers for the Java property os.name? > > > >Op zaterdag 22 juli 2006 16:06, schreef Dr. Douglas Lyon: >> Hi All, >> Here is how I have arranged my signed versions of the native >> binaries: >> http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/windows/native.j >>ar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/native.jar >> http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/linux/native.jar >> >> Then I do: >> public static URL getResourceUrl() throws MalformedURLException { >> String rxtxUrl = "http://show.docjava.com:8086/" + >> "book/cgij/code/jnlp/libs/rxtx/"; >> if (OsUtils.isLinux()) >> return new URL(rxtxUrl + "linux/native.jar"); >> if (OsUtils.isMacOs()) >> return new URL(rxtxUrl + "mac/native.jar"); >> if (OsUtils.isWindows()) >> return new URL(rxtxUrl + "windows/native.jar"); >> System.out.println("no automatic install supported for this >> platform. " + >> "Please e-mail lyon at docjava.com with a bug report"); >> return null; >> } >> >> My new-age NativeLibraryManger concept-thang allows you to >> write stuff like: >> >> /** >> * This method fixes the driver by beaming over >> * to the tmp directory a native.jar file. >> * The native.jar file is signed and its >> * native libs are beamed over to the user home directory >> * ~/.rxtx/
>> * Finally, the java.library.path is altered to include
>> * ~/.rxtx/ >> */ >> private static void fixDriver() { >> >> try { >> NativeLibraryManager.fixDriver(getResourceUrl(), >> NativeLibraryManager.mapLibraryName("rxtxSerial")); >> } catch (IOException e) { >> e.printStackTrace(); >> } >> } >> >> I do a lazy singleton design pattern: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public synchronized static RXTXCommDriver getInstance() { >> if (driver != null) return driver; >> if (!NativeLibraryManager.isLibInPath("rxtxSerial")) >> fixDriver(); >> if (NativeLibraryManager.isLibInPath("rxtxSerial")) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> } >> return driver; >> } >> >> I am at a cross-roads here, since a file-based distro might be preferable >> to a URL based distro. To make this really general, and to "remember" where >> the last version of a native library came from, I serialize a bean into >> user preferences >> The user can then store native libraries anywhere, remembering the location >> in the preferences. >> >> What is the general feeling about this? >> >> Thanks! >> - Doug >> >> > > Now, if you place the rxtx classes and native library in the same >> >> >> >> jar, do they both have to be in any specific place in order to be >> >> found? >> > >> >Answer: >> >> >The path to the libraries is in the form >> >> >of /native/rxtx/-/{libserial,libparallel} >> >> >so /native/rxtx/windows-i386/libserial would do. >> > >> >I'me looking for the various os.name and os.arch values right now. >> >_______________________________________________ >> >Rxtx mailing list >> >Rxtx at qbang.org >> >http://mailman.qbang.org/mailman/listinfo/rxtx > > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 06:12:33 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 14:12:33 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607221843.27765.pascal@quies.net> Message-ID: <200607231412.34078.pascal@quies.net> Op zondag 23 juli 2006 12:54, schreef Dr. Douglas Lyon: > Hi All, > Perhaps Java web start can address Gregg's concerns. > The native libs are placed into a signed jar for distribution. > As to the assertion that serial-port based programs need file io > abilities, that seems true, to me. Particularly for /dev/ttyN type > native libs or libs that use lock files. > The question of how to obtain a signed application that is given > file-io authority may be settled by using a signing technology. > > Even applets can be signed, to enable improved access to the file > system. > > What else can we try? Any ideas? It might be a good idea to use a more optimized version for youre networked applications. These native libraries are huge for some reason. Can you build a "downloader"? From lyon at docjava.com Sun Jul 23 06:46:43 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 08:46:43 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607231302.59252.pascal@quies.net> References: <200607222048.16215.pascal@quies.net> <200607231302.59252.pascal@quies.net> Message-ID: public static void main(String[] args) { System.out.println("isJava2="+System.getProperty("java.version")); } Prints out 1.5_06 on my system, but you seem to need the "1.2" to be present on the system...right? RXTX does work under 1.5, at least on my system. - DL >Op zondag 23 juli 2006 12:32, schreef Dr. Douglas Lyon: >> Also, the is Java2 check does not check if you are running under >> jdk1.5 >> - DL > >Could you please explain? >The JDK 1.5 will pass the check just fine. >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Jul 23 06:58:02 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 08:58:02 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607231412.34078.pascal@quies.net> References: <200607221843.27765.pascal@quies.net> <200607231412.34078.pascal@quies.net> Message-ID: Hi All, Yes, I do have a download, as to the question of "huge": ls -al native.jar -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar 28kbytes is not really huge, right? In fact, if you uncompress the jar, you get: -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so Which is almost 80kbytes, so the jar is 40% of the native libs size, and it is signed. At least on the Linux version, it is smaller. I did not check the other versions. And with java web start, the JNLP only downloads the native jar if it is new or changed. And it only downloads the native jar used for the target platform. Here is how the jnlp looks, FYI... addbk.JAddressBook.Main DocJava, Inc. I have been playing around with "eager" and "lazy" directives, but I can't really tell the difference. Cheers! - Doug >Op zondag 23 juli 2006 12:54, schreef Dr. Douglas Lyon: >> Hi All, >> Perhaps Java web start can address Gregg's concerns. >> The native libs are placed into a signed jar for distribution. >> As to the assertion that serial-port based programs need file io >> abilities, that seems true, to me. Particularly for /dev/ttyN type >> native libs or libs that use lock files. >> The question of how to obtain a signed application that is given >> file-io authority may be settled by using a signing technology. >> >> Even applets can be signed, to enable improved access to the file >> system. >> >> What else can we try? Any ideas? > >It might be a good idea to use a more optimized version for youre networked >applications. These native libraries are huge for some reason. >Can you build a "downloader"? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 07:53:54 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 15:53:54 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607231302.59252.pascal@quies.net> Message-ID: <200607231553.55088.pascal@quies.net> Op zondag 23 juli 2006 14:46, schreef Dr. Douglas Lyon: > public static void main(String[] args) { > System.out.println("isJava2="+System.getProperty("java.version")); > > } > Prints out 1.5_06 on my system, but you seem to need the "1.2" to be > present on the system...right? if (System.getProperty("java.version").compareTo("1.2") < 0) throw new Error("RXTX requires a Java 2 platform."); The line requires a version string of "1.2" or higher. Sun decided to name all versions since 1.2 as Java 2. (That is why there is this 2 in J2SE.) The error should never happen anyway if you compile the code with the -target 1.2 flag. From pascal at quies.net Sun Jul 23 07:55:52 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 15:55:52 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607231412.34078.pascal@quies.net> Message-ID: <200607231555.52419.pascal@quies.net> Op zondag 23 juli 2006 14:58, schreef Dr. Douglas Lyon: > Hi All, > Yes, I do have a download, as to the question of "huge": > ls -al native.jar > -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar > 28kbytes is not really huge, right? > In fact, if you uncompress the jar, you get: > -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so > -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so > Which is almost 80kbytes, so the jar is 40% of the native libs size, and > it is signed. > At least on the Linux version, it is smaller. I did not check the > other versions. > > And with java web start, the JNLP only downloads the native jar if it is > new or changed. > And it only downloads the native jar used for the target platform. > > Here is how the jnlp looks, FYI... > codebase="http://show.docjava.com:8086/book/cgij/code/jnlp/"> > > addbk.JAddressBook.Main > DocJava, Inc. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have been playing around with "eager" and "lazy" directives, > but I can't really tell the difference. > > Cheers! > - Doug That is a nice sollution. Is there a tag for the architecture too becouse now you assume i386 and that is of course not necesairy true. From joachim at buechse.de Sun Jul 23 11:17:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 23 Jul 2006 19:17:29 +0200 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <41E45C85-4A22-4C5B-915F-62ED36BACCF2@sympatico.ca> References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> <41E45C85-4A22-4C5B-915F-62ED36BACCF2@sympatico.ca> Message-ID: <0B7FC525-4C71-49E8-B652-CCF6C67B4A58@buechse.de> This happens with the versions in CVS (2.07+ and 2.17+). On 22.07.2006, at 19:58, Andr?-John Mas wrote: > A couple of questions: > - what version are you using? > - does this happen with the version in cvs? > > Andre > > On 22-Jul-06, at 13:37 , Joachim Buechse wrote: > >> I just discovered a strange error in RXTX on OSX. SerialDemo.java >> manages to corrupt the event_info_structure by a simple >> OpenPort,ClosePort - this could be in relation to the deadlock >> problem that was reported recently. >> >> Could anyone try to reproduce this on Solaris or some other system >> which is neither WIN32 nor Linux (ie which uses a drain thread). >> >> In SerialImp.c : RXTXPort(interruptEventLoop) >> >> Apparently the event_info_structure gets corrupted shortly after >> >> pthread_kill(index->drain_tid, SIGABRT); >> >> In particular, the index->closing flag gets overwritten by a pointer >> value. >> >> >> **** Adding the following debugging code: >> >> pthread_kill(index->drain_tid, SIGABRT); >> sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i >> \n", index->fd, index, index->closing ); >> report( message ); >> /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ >> usleep(50 * 1000); >> sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i >> \n", index->fd, index, index->closing ); >> report( message ); >> >> **** gives me: >> >> 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 >> drain_loop: received EINTR------------------ drain_loop exiting >> --------------------- >> entering check_tiocmget_changes >> leaving check_tiocmget_changes >> port_has_changed_fionread: change is 0 >> eventLoop: got interrupt >> 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 >> >> **** Modifying SerialImp.h : event_info_struct by moving the >> prev*, next* pointers >> >> jmethodID checkMonitorThread; >> struct event_info_struct *dummy, *dummy2; >> fd_set rfds; >> struct timeval tv_sleep; >> int closing; >> struct event_info_struct *next, *prev; >> >> *** (ie replacing their original position with dummys and moving them >> *** behind the closing flag) results in this: >> >> 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 >> drain_loop: received EINTR------------------ drain_loop exiting >> --------------------- >> entering check_tiocmget_changes >> leaving check_tiocmget_changes >> port_has_changed_fionread: change is 0 >> eventLoop: got interrupt >> 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 >> >> >> *** I was not able to track down the problem. If anyone could check >> wether this happens on other platforms as well, we may get closer to >> a fix. >> >> Regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Sun Jul 23 11:44:48 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 23 Jul 2006 19:44:48 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607230153.32328.pascal@quies.net> References: <44C252BF.6040404@cox.net> <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> <200607230153.32328.pascal@quies.net> Message-ID: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> Gregg's concern was, that extracting the library from the jar and loading it via System.load needs file access privileges. To solve this concern, all that's required is a static method/flag that triggers loading via System.loadLibrary instead (of course, then he needs to make sure, that the library is on the java.library.path). This could also be handled via a system property of course. Regards, Joachim On 23.07.2006, at 01:53, Pascal S. de Kloe wrote: > Hi Joachim, > > I'm not getting it. > How do you easily get a "stub method / flag"? > > > Op zaterdag 22 juli 2006 19:17, schreef Joachim Buechse: >> We could easily have a stub method / flag that allows you to >> explicitly load the native library (via System.loadLibrary ie from >> the java.library.path). In this case the "auto-extraction" would not >> take place. >> >> On 22.07.2006, at 18:30, Gregg Wonderly wrote: >>> Dr. Douglas Lyon wrote: >>>> Hi All, >>>> I like the idea of the native lib in a jar with other classes. >>>> An alternative I did not know would work. >>> >>> I have several applications that run with a security policy. In >>> these >>> applications, native library loading will require an appropriate >>> FilePermission >>> that should be known about ahead of time. The current native >>> library >>> implementation will require the native library to be extracted from >>> the jar and >>> written to disk, requiring a FilePermission("...","write") for that >>> file, and >>> then will also require read access to load the library. I >>> personally don't want >>> to give write access to a JVM for a shared library which can >>> provide a point of >>> abuse by errant code. >>> >>> Gregg Wonderly >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 13:34:17 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 21:34:17 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> References: <200607230153.32328.pascal@quies.net> <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> Message-ID: <200607232134.17451.pascal@quies.net> Aaah, the penny drops. I was reading it as the stub method _root_ flag like using the root of a jar as a context for java.library.path. Thanks for explaining. :) I'll build it right away. Op zondag 23 juli 2006 19:44, schreef Joachim Buechse: > Gregg's concern was, that extracting the library from the jar and > loading it via System.load needs file access privileges. To solve > this concern, all that's required is a static method/flag that > triggers loading via System.loadLibrary instead (of course, then he > needs to make sure, that the library is on the java.library.path). > This could also be handled via a system property of course. > > Regards, > Joachim > > On 23.07.2006, at 01:53, Pascal S. de Kloe wrote: > > Hi Joachim, > > > > I'm not getting it. > > How do you easily get a "stub method / flag"? > > > > Op zaterdag 22 juli 2006 19:17, schreef Joachim Buechse: > >> We could easily have a stub method / flag that allows you to > >> explicitly load the native library (via System.loadLibrary ie from > >> the java.library.path). In this case the "auto-extraction" would not > >> take place. > >> > >> On 22.07.2006, at 18:30, Gregg Wonderly wrote: > >>> Dr. Douglas Lyon wrote: > >>>> Hi All, > >>>> I like the idea of the native lib in a jar with other classes. > >>>> An alternative I did not know would work. > >>> > >>> I have several applications that run with a security policy. In > >>> these > >>> applications, native library loading will require an appropriate > >>> FilePermission > >>> that should be known about ahead of time. The current native > >>> library > >>> implementation will require the native library to be extracted from > >>> the jar and > >>> written to disk, requiring a FilePermission("...","write") for that > >>> file, and > >>> then will also require read access to load the library. I > >>> personally don't want > >>> to give write access to a JVM for a shared library which can > >>> provide a point of > >>> abuse by errant code. > >>> > >>> Gregg Wonderly > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 18:10:45 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 02:10:45 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607232134.17451.pascal@quies.net> References: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> <200607232134.17451.pascal@quies.net> Message-ID: <200607240210.45992.pascal@quies.net> Hello gentleman, The CommunicationAPI class / utility is almost ready. Could you please have a final look and give your opinion? Does anybody know how the SunOS and the Solaris os.name is used? Sun uses just sparc as the description for os.arch. Is it safe to use the 32-bit binaries? @Gregg You can extract the necessary libraries during the installation with the extractNativeLibraries method to the application directory so they get loaded automatically. Is that good enough? @Trent Would you include this class afther any possible comments in the distribution? -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 10884 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060723/d2e99122/CommunicationAPI-0338.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: PlatformNotSupportedException.java Type: text/x-java Size: 1621 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060723/d2e99122/PlatformNotSupportedException-0338.bin From lyon at docjava.com Sun Jul 23 18:14:08 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 20:14:08 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607231555.52419.pascal@quies.net> References: <200607231412.34078.pascal@quies.net> <200607231555.52419.pascal@quies.net> Message-ID: Hi All, The present JNLP distro that I use: > > >> >> > Works for Macs using G3 and G4's. I have not tested this with an i386 mac, as I do not have one. And it only works with i386 based linux... As far as architecture goes: Allows for a chip arch, and this might address your question. The real bottleneck is that you need one of everything to test a deployment, or you have to know a bunch of people (like on this list!) to do a proper test. Cheers! - Doug >Op zondag 23 juli 2006 14:58, schreef Dr. Douglas Lyon: >> Hi All, >> Yes, I do have a download, as to the question of "huge": >> ls -al native.jar >> -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar >> 28kbytes is not really huge, right? >> In fact, if you uncompress the jar, you get: >> -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so >> -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so >> Which is almost 80kbytes, so the jar is 40% of the native libs size, and >> it is signed. >> At least on the Linux version, it is smaller. I did not check the >> other versions. >> >> And with java web start, the JNLP only downloads the native jar if it is >> new or changed. >> And it only downloads the native jar used for the target platform. >> >> Here is how the jnlp looks, FYI... >> > codebase="http://show.docjava.com:8086/book/cgij/code/jnlp/"> >> >> addbk.JAddressBook.Main >> DocJava, Inc. >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > >> >> > > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> I have been playing around with "eager" and "lazy" directives, >> but I can't really tell the difference. >> >> Cheers! >> - Doug > >That is a nice sollution. > >Is there a tag for the architecture too becouse now you assume i386 and that >is of course not necesairy true. >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Sun Jul 23 10:38:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 23 Jul 2006 11:38:50 -0500 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607221843.27765.pascal@quies.net> References: <44C252BF.6040404@cox.net> <200607221843.27765.pascal@quies.net> Message-ID: <44C3A61A.3060706@cox.net> Pascal S. de Kloe wrote: > Op zaterdag 22 juli 2006 18:30, schreef Gregg Wonderly: >>I have several applications that run with a security policy. In these >>applications, native library loading will require an appropriate >>FilePermission that should be known about ahead of time. The current >>native library implementation will require the native library to be >>extracted from the jar and written to disk, requiring a >>FilePermission("...","write") for that file, and then will also require >>read access to load the library. I personally don't want to give write >>access to a JVM for a shared library which can provide a point of abuse by >>errant code. > That's indeed a pitty limitation. It creates a lot of possible exceptions too. > > On the other hand, any native lib passes the securiy model. Applications who > can access hardware ports can be expected to create files, right? The use of an appropriate security policy is a deployment time configuration. There needs to be appropriate limits that confine the software to its intended tasks. Gregg Wonderly From gergg at cox.net Sun Jul 23 10:56:39 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 23 Jul 2006 11:56:39 -0500 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607221920.20096.pascal@quies.net> <200607222048.16215.pascal@quies.net> Message-ID: <44C3AA47.4060003@cox.net> Dr. Douglas Lyon wrote: > The Class.forName is a static method. Therefore > myClass.forName Should be Class.forName and > myClass becomes an unused parameter. Or better yet, make that parameter a context classloader and call Class.forName( classname, classloader); so that the location of the codebase for loading classes can be separate from the applications classpath. Gregg Wonderly From tjarvi at qbang.org Sun Jul 23 20:26:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 20:26:04 -0600 (MDT) Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: I do not see a point of having CommAPI do much more than basic termios interfaces and possibly parallel ports. The kernels can deliver that interface just fine for USB and other types. One problem with the current implementation for USB and IrDA is hotplug. There is a HAL daemon that can send connect and disconnect events which should probably be added to a new API. Sun is also working on a HAL port for Solaris. It is hackish but I saw at the Linux symposium that it will be getting attention and improving. The point being that these events could be included not that HAL is the end of all problems. It would appear to me that anything further in USB space should be done with the/a USB API to avoid duplication of efforts. USB is only one of many low level options for termios interfaces. On Sat, 22 Jul 2006, Joachim Buechse wrote: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. > > It is clear that javax.comm can never provide a way to talk to all > USB devices, simply because some USB devices have several endpoints. > But it could provide a means of talking to devices that function as a > bidirectional-pipe (ie any USB to serial bridge). > > Regards, > Joachim > > On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > >> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>> Pascal S. de Kloe wrote: >>>>>> I am also not sure if >>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>> single >>>>>> port. >>>>> >>>>> I think the API should hide low-level details like devicefiles. >>>> >>>> Not all ports have device files. It's long been my goal to add >>>> support >>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>> servers, for example integrating RFC2217. This means that the >>>> port name >>>> is some combination of an IP address and TCP port number. >>>> Nothing in >>>> /dev. >>> >>> What I think would make the most sense is a simple "device" >>> enumeration >>> Server Provider Interface that would bring port objects into the >>> JVM based >>> on the platform JVM providers knowledge of how to enumerate those >>> ports. >>> Application writers would provide a plugin using the SPI that >>> would codify >>> those devices into named entities that they are interested in. >>> >>> public interface HardwarePort { >>> public String getName(); >>> public String getHardwareID(); >>> public String getManufacturer(); >>> public List getCapabilities(); >>> public Object getImplementation(); >>> } >>> >>> public interface PortCapability { >>> public String getDescription(); >>> public CapabilityId getIdentifier(); >>> } >>> >>> public enum CapabilityId { >>> INPUT, // Can receive input >>> OUTPUT, // Can send output >>> ASYNCHRONOUS, // Can send and receive at the same time >>> SYNCHRONOUS, // No synchronous I/O >>> ADDRESSABLE // Port has an address associated >>> } >>> >>> Then, you might imagine that the enumerated capabilities had a >>> standardized/specified interface that you'd find implemented on >>> ports that >>> had such capabilities. >>> >>> The getImplementation() method would return the implementation class >>> provided by the JVM provider that had all of the interfaces tied >>> to it. >>> >>> These are just some quick thoughts, pick away at them. >>> >>> I am very interested in getting a new comm api in place which can >>> provide >>> the ability for all USB connected devices to have drivers provided >>> as 100% >>> java for all non-timing critical types of device interfaces. >>> >>> The JVM provider should have an SPI to write to which will enable >>> them to >>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>> something >>> that we can talk 100% java to. >>> >>> That's my big desire. Starting with something simple which gives >>> a good >>> start in that direction would be great! >> >> That was exactly my wish too. >> >> The point people brought up was: >> 1) It's too complex. >> 2) What does it solve? >> >> In both facts they are right. It'll take a *long* time to plan such >> a thing >> right but if it works you have a product. Anyway, I'd like to join. ;) >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jul 23 20:31:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 20:31:45 -0600 (MDT) Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607231412.34078.pascal@quies.net> References: <200607221843.27765.pascal@quies.net> <200607231412.34078.pascal@quies.net> Message-ID: On Sun, 23 Jul 2006, Pascal S. de Kloe wrote: > Op zondag 23 juli 2006 12:54, schreef Dr. Douglas Lyon: >> Hi All, >> Perhaps Java web start can address Gregg's concerns. >> The native libs are placed into a signed jar for distribution. >> As to the assertion that serial-port based programs need file io >> abilities, that seems true, to me. Particularly for /dev/ttyN type >> native libs or libs that use lock files. >> The question of how to obtain a signed application that is given >> file-io authority may be settled by using a signing technology. >> >> Even applets can be signed, to enable improved access to the file >> system. >> >> What else can we try? Any ideas? > > It might be a good idea to use a more optimized version for youre networked > applications. These native libraries are huge for some reason. > Can you build a "downloader"? It may be that the binaries are not stripped. "strip librtxserial.so" for instance. That will remove the symbols which are not usually needed in production. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jul 23 20:49:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 20:49:16 -0600 (MDT) Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607240210.45992.pascal@quies.net> References: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> <200607232134.17451.pascal@quies.net> <200607240210.45992.pascal@quies.net> Message-ID: On Mon, 24 Jul 2006, Pascal S. de Kloe wrote: > Hello gentleman, > > The CommunicationAPI class / utility is almost ready. > Could you please have a final look and give your opinion? > > > Does anybody know how the SunOS and the Solaris os.name is used? > > Sun uses just sparc as the description for os.arch. Is it safe to use the > 32-bit binaries? > > > > @Gregg > You can extract the necessary libraries during the installation with the > extractNativeLibraries method to the application directory so they get loaded > automatically. Is that good enough? > > @Trent > Would you include this class afther any possible comments in the distribution? > Hi Pascal, It would appear to me that this is a tool for using the API, not an API. So perhaps the classname is not the best choice. The class also has a main which would not make a great deal of sense to include in the library to me. It would make a nice example for the contrib directory or a new utility directory though. Documentation of its availability in the main document could make it stand out from the other contrib files. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jul 23 21:27:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 21:27:48 -0600 (MDT) Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> Message-ID: On Sat, 22 Jul 2006, Joachim Buechse wrote: > I just discovered a strange error in RXTX on OSX. SerialDemo.java > manages to corrupt the event_info_structure by a simple > OpenPort,ClosePort - this could be in relation to the deadlock > problem that was reported recently. > > Could anyone try to reproduce this on Solaris or some other system > which is neither WIN32 nor Linux (ie which uses a drain thread). > > In SerialImp.c : RXTXPort(interruptEventLoop) > > Apparently the event_info_structure gets corrupted shortly after > > pthread_kill(index->drain_tid, SIGABRT); > > In particular, the index->closing flag gets overwritten by a pointer > value. > > > **** Adding the following debugging code: > > pthread_kill(index->drain_tid, SIGABRT); > sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ > usleep(50 * 1000); > sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > > **** gives me: > > 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 > > **** Modifying SerialImp.h : event_info_struct by moving the > prev*, next* pointers > > jmethodID checkMonitorThread; > struct event_info_struct *dummy, *dummy2; > fd_set rfds; > struct timeval tv_sleep; > int closing; > struct event_info_struct *next, *prev; > > *** (ie replacing their original position with dummys and moving them > *** behind the closing flag) results in this: > > 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 > > > *** I was not able to track down the problem. If anyone could check > wether this happens on other platforms as well, we may get closer to > a fix. > Hi Joachim Interesting. I did run many tests with that code on may OSs. To be fair, the tests are just starting to get into good shape again. I'm still tagging releases with a bit of feel and not enough process. I'll look at this some more tomorrow night. The SIGABRT was added recently as part of the close speedups. Thats from memory. I can provide the exact patch that introduced that tomorrow. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jul 23 22:22:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 22:22:26 -0600 (MDT) Subject: [Rxtx] clarification Message-ID: It should be clear that doug is the maintainer of rxtx.org now. I'll be running around very fast trying to make that easier for him but if you want something in rxtx, it is doug that does that. There are some things doug isnt very good at. He needs some help there. If he asks others for their opinion, thats his call. If he asks others for help, thats his call. This was setup to help the community. I hope everyone makes good use of it as they are now. I'm very happy with what I see but I want to make it clear that nobody should be asking me to be in rxtx. I have interests but they may not always be yours. -- Trent Jarvi tjarvi at qbang.org From guille at sms.nl Mon Jul 24 00:32:26 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Mon, 24 Jul 2006 08:32:26 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <7.0.1.0.0.20060724082455.038aa518@sms.nl> At 18:31 20/07/2006, Trent Jarvi wrote: > > PROJECT SCOPE: > > ------------- > > > > Also, we should think carefully about what the scope of > > this project would be. Should it be javax."comm" which > > handles both serial and parallel (is parallel going by the > > wayside). Should it be split into two project: > > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > > > > Should we differentiate between single-ended serial > > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > > quasi-multidrop and full multidrop busses such as > > EIA422, EIA432 and EIA485? If we really were to > > add I2C support to the API, we'd have to delve into > > the semantics more, because there could be some > > implicit decoding of the bus the API users would > > want to see. > > > >Hi Paul > >The way RXTX works, which is a fair representation of the people using the >API, is complete support for RIA232, minimal support for IEEE1284. From >what I understand, Sun was going along the same lines. If we combined >both projects, we would have half a parallel port implementation. I see >maybe 4 requests for features not in the parallel support a year. > >The other protocols should not be limited by a JSR which is going to be >focused upon serial port interests. The IEA485 hacks in RXTX along with >I2C and Raw should _not_ be considered a strong basis for extending the >API to cover these protocols. If people want to do real implementations, >they should not face a 'standard' which wasnt really focused upon their >interests. I think we understand the parallel port issues fairly well but >have not implemented many features and I don't know if we would. I agree with all of this. API requirements for I2C, SPI, etc. are very different from those for RS232/485/422. Our embedded Java platform has APIs for all of these and more and they don't share a lot apart from the fact that they all use Input/OutputStreams (and in the case of SPI you still need to cater with the fact that every time you want to read you must also write to the device.) If I was to design javax.comm from scratch, I think I would focus on serial ports exclusively (== whatever the underlying OS represents as serial ports). Even parallel is a bit out of place IMHO, although I understand it needs to stay for backwards compatibility. >So a versatile API is favorable but I do not think we have the proper >community to represent much more than Serial. Yes, I think the same. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From joachim at buechse.de Mon Jul 24 01:33:14 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 24 Jul 2006 09:33:14 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607231412.34078.pascal@quies.net> <200607231555.52419.pascal@quies.net> Message-ID: <106C7BEC-EC26-4A05-8E94-61E2C9F2A54E@buechse.de> Or you put your project on Sourceforge and use this: http://sourceforge.net/docs/compile_farm#hosts On 24.07.2006, at 02:14, Dr. Douglas Lyon wrote: > Hi All, > The present JNLP distro that I use: >>> >>> >> download="eager" /> >>> >> > > Works for Macs using G3 and G4's. I have not tested > this with an i386 mac, as I do not have one. And it only works > with i386 based linux... > > As far as architecture goes: > > > > Allows for a chip arch, and this might address your question. > > The real bottleneck is that you need one of everything to test a > deployment, > or you have to know a bunch of people (like on this list!) to do a > proper test. > > Cheers! > - Doug > > >> Op zondag 23 juli 2006 14:58, schreef Dr. Douglas Lyon: >>> Hi All, >>> Yes, I do have a download, as to the question of "huge": >>> ls -al native.jar >>> -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar >>> 28kbytes is not really huge, right? >>> In fact, if you uncompress the jar, you get: >>> -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so >>> -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so >>> Which is almost 80kbytes, so the jar is 40% of the native libs >>> size, and >>> it is signed. >>> At least on the Linux version, it is smaller. I did not check the >>> other versions. >>> >>> And with java web start, the JNLP only downloads the native jar >>> if it is >>> new or changed. >>> And it only downloads the native jar used for the target platform. >>> >>> Here is how the jnlp looks, FYI... >>> >> codebase="http://show.docjava.com:8086/book/cgij/code/ >>> jnlp/"> >>> >>> addbk.JAddressBook.Main >>> DocJava, Inc. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> download="eager" /> >>> >>> >>> >>> >>> >> download="lazy" /> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I have been playing around with "eager" and "lazy" directives, >>> but I can't really tell the difference. >>> >>> Cheers! >>> - Doug >> >> That is a nice sollution. >> >> Is there a tag for the architecture too becouse now you assume >> i386 and that >> is of course not necesairy true. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jul 24 02:13:15 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 24 Jul 2006 10:13:15 +0200 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> Message-ID: <939306BB-2AEE-4D20-906E-9A9B40C76125@buechse.de> The pthread_kill is followed by a sleep. When the sleep returns the structure is damaged. I did not find the source that overwrites the closing field - it is correctly set by the exiting drain thread. But something overwrites it afterwards. I currently believe that this existed for some time but was never seen because the previous versions did not rely on the structure to be in good shape when tearing down connections. However I may be completely wrong and it is an OSX problem. To help me find the source, it would be nice to get some indications what the 2 debug lines I suggested return on other platforms. Joachim On 24.07.2006, at 05:27, Trent Jarvi wrote: > On Sat, 22 Jul 2006, Joachim Buechse wrote: > >> I just discovered a strange error in RXTX on OSX. SerialDemo.java >> manages to corrupt the event_info_structure by a simple >> OpenPort,ClosePort - this could be in relation to the deadlock >> problem that was reported recently. >> >> Could anyone try to reproduce this on Solaris or some other system >> which is neither WIN32 nor Linux (ie which uses a drain thread). >> >> In SerialImp.c : RXTXPort(interruptEventLoop) >> >> Apparently the event_info_structure gets corrupted shortly after >> >> pthread_kill(index->drain_tid, SIGABRT); >> >> In particular, the index->closing flag gets overwritten by a pointer >> value. > > Hi Joachim > > Interesting. I did run many tests with that code on may OSs. To > be fair, > the tests are just starting to get into good shape again. I'm still > tagging releases with a bit of feel and not enough process. I'll > look at > this some more tomorrow night. > > The SIGABRT was added recently as part of the close speedups. > Thats from > memory. I can provide the exact patch that introduced that tomorrow. > > -- > Trent Jarvi > tjarvi at qbang.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Mon Jul 24 05:58:21 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 13:58:21 +0200 Subject: [Rxtx] =?iso-8859-1?q?NativeLibraryManager_-_A_general_solution_a?= =?iso-8859-1?q?n_to_old=09problem=2E?= In-Reply-To: <44C3AA47.4060003@cox.net> References: <44C3AA47.4060003@cox.net> Message-ID: <200607241358.21366.pascal@quies.net> Op zondag 23 juli 2006 18:56, schreef Gregg Wonderly: > Dr. Douglas Lyon wrote: > > The Class.forName is a static method. Therefore > > myClass.forName Should be Class.forName and > > myClass becomes an unused parameter. > > Or better yet, make that parameter a context classloader and call > > Class.forName( classname, classloader); > > so that the location of the codebase for loading classes can be separate > from the applications classpath. I agree. -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 10719 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060724/693f269d/CommunicationAPI-0338.bin From pascal at quies.net Mon Jul 24 06:05:53 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 14:05:53 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607240210.45992.pascal@quies.net> Message-ID: <200607241405.53456.pascal@quies.net> Op maandag 24 juli 2006 04:49, schreef Trent Jarvi: > > @Trent > > Would you include this class afther any possible comments in the > > distribution? > > Hi Pascal, > > It would appear to me that this is a tool for using the API, not an API. > So perhaps the classname is not the best choice. > > The class also has a main which would not make a great deal of sense to > include in the library to me. It would make a nice example for the > contrib directory or a new utility directory though. Documentation of its > availability in the main document could make it stand out from the other > contrib files. The name-change and the removal of main() would ofcourse be no problem. You really don't want to distribute binaries, huh? How can the developers of RXTX know whether it works on a machine they don't have? Anyway, I don't see anotherway to get a version of the extension "that just works" than to build my own distribution. :@ I also can't believe that nobody on this list has binaries for official supported platforms like Windows IA64 and Windows x86_64 unless the build fails on these platforms (which would be nice to know). http://java.sun.com/j2se/1.4.2/system-configurations.html http://java.sun.com/j2se/1.5.0/system-configurations.html From pascal at quies.net Mon Jul 24 06:08:45 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 14:08:45 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <106C7BEC-EC26-4A05-8E94-61E2C9F2A54E@buechse.de> References: <106C7BEC-EC26-4A05-8E94-61E2C9F2A54E@buechse.de> Message-ID: <200607241408.45956.pascal@quies.net> Op maandag 24 juli 2006 09:33, schreef Joachim Buechse: > Or you put your project on Sourceforge and use this: > > http://sourceforge.net/docs/compile_farm#hosts That's nice. :) I'll host a distribution on Sourceforge real soon. HP also has a such a facility for PA-RISC and IA64 architectures at http://www.testdrive.hp.com/ The other day I was thinking about building a big bittorrent with Qemu images for developers. The number of platforms seems impressive: http://qemu.org/status.html With each image compressed with bzip2 a clean installation of OpenBSD and FreeBSD and a Debian Woody + gmake + gcc for each Qemu platform will take about 1.5GB. From lyon at docjava.com Mon Jul 24 07:07:02 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 24 Jul 2006 09:07:02 -0400 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060724082455.038aa518@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: Hi All, There has been a lot of discussion regarding RS485. Let me see if I can summarize this, please correct me if I am wrong; I am deliberately ignoring connector and electrical issues, focusing, instead, on protocol and software issues. Also, I have never used RS485, and I don't know much about it. 1. Serial ports that claim RS232 are typically used in the data link layer of the OSI model of networking. Basically, this means that they work with a point-to-point protocol and are meant to connect two devices. 2. Within the RS232 standard there are framing bits (start and stop bits) and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. Thats' it. 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) you do it in software, not in the RS232 standard. 4. RS485 is different from RS232 in that it is in the Network Layer of the OSI model of networking. 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in a factory). RS-485 is similar to RS-422, but RS-422 allows just one driver with multiple receivers whereas RS-485 supports multiple drivers and receivers. 6. RS-485 is a serial bus with multiple nodes and thus must handle network link layer protocols. By using high-impedance receivers, you can have as many as 256 nodes. 7. The RS-485 can be implemented with RXTX in the core and a layer of software on top to handle media access control (MAC sublayer). There are also hardware converters. http://www.rs485.com/pconverters.html for example. However, some of these require software control. There is some support in the form of the Rs485.java class, in RXTX. 8. The RS-485 specification will add to the size of the JSR 9. Javax.comm specification, version 2.0 (the Real OLD version) says: This version of the Java communications API contains support for RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not mentioned. 10. DO people want to add RS485 to a new JSR? Would it make sense for the RS-485 people to speak up now? Please let me know if you think my summary is wrong. Thanks! - Doug >At 18:31 20/07/2006, Trent Jarvi wrote: >> > PROJECT SCOPE: >> > ------------- >> > >> > Also, we should think carefully about what the scope of >> > this project would be. Should it be javax."comm" which >> > handles both serial and parallel (is parallel going by the >> > wayside). Should it be split into two project: >> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >> > >> > Should we differentiate between single-ended serial >> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >> > quasi-multidrop and full multidrop busses such as >> > EIA422, EIA432 and EIA485? If we really were to >> > add I2C support to the API, we'd have to delve into >> > the semantics more, because there could be some >> > implicit decoding of the bus the API users would >> > want to see. >> > >> >>Hi Paul >> >>The way RXTX works, which is a fair representation of the people using the >>API, is complete support for RIA232, minimal support for IEEE1284. From >>what I understand, Sun was going along the same lines. If we combined >>both projects, we would have half a parallel port implementation. I see >>maybe 4 requests for features not in the parallel support a year. >> >>The other protocols should not be limited by a JSR which is going to be >>focused upon serial port interests. The IEA485 hacks in RXTX along with >>I2C and Raw should _not_ be considered a strong basis for extending the >>API to cover these protocols. If people want to do real implementations, >>they should not face a 'standard' which wasnt really focused upon their >>interests. I think we understand the parallel port issues fairly well but >>have not implemented many features and I don't know if we would. > >I agree with all of this. API requirements for I2C, SPI, etc. are very >different from those for RS232/485/422. Our embedded Java platform has >APIs for all of these and more and they don't share a lot apart from the >fact that they all use Input/OutputStreams (and in the case of SPI you >still need to cater with the fact that every time you want to read you >must also write to the device.) > >If I was to design javax.comm from scratch, I think I would focus on >serial ports exclusively (== whatever the underlying OS represents as >serial ports). Even parallel is a bit out of place IMHO, although I >understand it needs to stay for backwards compatibility. > > >>So a versatile API is favorable but I do not think we have the proper >>community to represent much more than Serial. > >Yes, I think the same. > >Guillermo >-- >Guillermo Rodriguez Garcia > >Snijder Micro Systems phone +31-493-351020 >G. Rodriguez Garcia fax +31-493-351530 >Visser 25 email guille at sms.nl >NL5751 BL Deurne >The Netherlands http://www.snijder.com > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Mon Jul 24 07:46:55 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Mon, 24 Jul 2006 10:46:55 -0300 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: <44C4CF4F.1080706@gmail.com> Doug: I do not think that RS485 is a must by now. I do think we must make a JSR to standarize a bit Serial Ports accessing. Maybe we can make a JSR just for serial ports, and then start trying with other kind of ports and make others JSR. Or try to expand our first JSR, but I trully do not know if that can be made. About other ports besides RS485, the others I2C, SPI, etc, run at a very low level, maybe too close to the processor for Java. I do not know if Java is fast enough to access this ports, even more as this ports depends directly from the architecture, the write once run every way of Java is somekind useless at this level, so I do not think this is suitable for us. Regards, Manuel > Hi All, > There has been a lot of discussion regarding RS485. > > Let me see if I can summarize this, please correct me if I am wrong; > I am deliberately ignoring connector and electrical issues, focusing, > instead, on protocol and software issues. Also, I have never used > RS485, and I don't know much about it. > > 1. Serial ports that claim RS232 are typically used in > the data link layer of the OSI model of networking. Basically, this means > that they work with a point-to-point protocol and are meant to connect two > devices. > > 2. Within the RS232 standard there are framing bits (start and stop bits) > and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. > Thats' it. > > 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) > you do it in software, not in the RS232 standard. > > 4. RS485 is different from RS232 in that it is in the Network Layer of > the OSI model of networking. > > 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > a factory). > RS-485 is similar to RS-422, but RS-422 allows just one driver with > multiple receivers whereas RS-485 supports multiple drivers and > receivers. > > 6. RS-485 is a serial bus with multiple nodes and thus must handle network > link layer protocols. By using high-impedance receivers, you can have > as many as 256 nodes. > > 7. The RS-485 can be implemented with RXTX in the core and a layer of software > on top to handle media access control (MAC sublayer). There are also > hardware converters. > http://www.rs485.com/pconverters.html for example. However, some of > these require software control. There is some support in the form of > the Rs485.java class, > in RXTX. > > 8. The RS-485 specification will add to the size of the JSR > > 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > This version of the Java communications API contains support for > RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > mentioned. > > 10. DO people want to add RS485 to a new JSR? > > Would it make sense for the RS-485 people to speak up now? > Please let me know if you think my summary is wrong. > > Thanks! > - Doug > > > > > > >> At 18:31 20/07/2006, Trent Jarvi wrote: >> >>> > PROJECT SCOPE: >>> > ------------- >>> > >>> > Also, we should think carefully about what the scope of >>> > this project would be. Should it be javax."comm" which >>> > handles both serial and parallel (is parallel going by the >>> > wayside). Should it be split into two project: >>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>> > >>> > Should we differentiate between single-ended serial >>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>> > quasi-multidrop and full multidrop busses such as >>> > EIA422, EIA432 and EIA485? If we really were to >>> > add I2C support to the API, we'd have to delve into >>> > the semantics more, because there could be some >>> > implicit decoding of the bus the API users would >>> > want to see. >>> > >>> >>> Hi Paul >>> >>> The way RXTX works, which is a fair representation of the people using the >>> API, is complete support for RIA232, minimal support for IEEE1284. From >>> what I understand, Sun was going along the same lines. If we combined >>> both projects, we would have half a parallel port implementation. I see >>> maybe 4 requests for features not in the parallel support a year. >>> >>> The other protocols should not be limited by a JSR which is going to be >>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>> I2C and Raw should _not_ be considered a strong basis for extending the >>> API to cover these protocols. If people want to do real implementations, >>> they should not face a 'standard' which wasnt really focused upon their >>> interests. I think we understand the parallel port issues fairly well but >>> have not implemented many features and I don't know if we would. >>> >> I agree with all of this. API requirements for I2C, SPI, etc. are very >> different from those for RS232/485/422. Our embedded Java platform has >> APIs for all of these and more and they don't share a lot apart from the >> fact that they all use Input/OutputStreams (and in the case of SPI you >> still need to cater with the fact that every time you want to read you >> must also write to the device.) >> >> If I was to design javax.comm from scratch, I think I would focus on >> serial ports exclusively (== whatever the underlying OS represents as >> serial ports). Even parallel is a bit out of place IMHO, although I >> understand it needs to stay for backwards compatibility. >> >> >> >>> So a versatile API is favorable but I do not think we have the proper >>> community to represent much more than Serial. >>> >> Yes, I think the same. >> >> Guillermo >> -- >> Guillermo Rodriguez Garcia >> >> Snijder Micro Systems phone +31-493-351020 >> G. Rodriguez Garcia fax +31-493-351530 >> Visser 25 email guille at sms.nl >> NL5751 BL Deurne >> The Netherlands http://www.snijder.com >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From gergg at cox.net Mon Jul 24 07:51:53 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 08:51:53 -0500 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607240210.45992.pascal@quies.net> References: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> <200607232134.17451.pascal@quies.net> <200607240210.45992.pascal@quies.net> Message-ID: <44C4D079.80609@cox.net> Pascal S. de Kloe wrote: > @Gregg > You can extract the necessary libraries during the installation with the > extractNativeLibraries method to the application directory so they get loaded > automatically. Is that good enough? If you start the JVM with -Djava.security.manager what permissions are required? Can you send me a policy that is applicable so that I can review what permissions are being required? Gregg Wonderly From gergg at cox.net Mon Jul 24 07:54:22 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 08:54:22 -0500 Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: <44C4D10E.50604@cox.net> Joachim Buechse wrote: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. Sorry for the late reply here. My intent was this. That there could be a low level port/device SPI that could be put in place once, and then overtime we could layer other APIs, including an updated javax.comm which would make use of this SPI. Gregg Wonderly From cmalan at lhar.co.za Mon Jul 24 08:04:01 2006 From: cmalan at lhar.co.za (Christo Malan) Date: Mon, 24 Jul 2006 16:04:01 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: <44C4D351.603@lhar.co.za> Hi I don't think RS-485 belong in rxtx, the scope of the spec is not wide enough as it only specify the electrical layer. Their is no data protocol recommended or defined. This mean that we have no idea when to sample for a bit, how long is a bit and how many bits before we can say new data is available. Christo Dr. Douglas Lyon wrote: > Hi All, > There has been a lot of discussion regarding RS485. > > Let me see if I can summarize this, please correct me if I am wrong; > I am deliberately ignoring connector and electrical issues, focusing, > instead, on protocol and software issues. Also, I have never used > RS485, and I don't know much about it. > > 1. Serial ports that claim RS232 are typically used in > the data link layer of the OSI model of networking. Basically, this means > that they work with a point-to-point protocol and are meant to connect two > devices. > > 2. Within the RS232 standard there are framing bits (start and stop bits) > and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. > Thats' it. > > 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) > you do it in software, not in the RS232 standard. > > 4. RS485 is different from RS232 in that it is in the Network Layer of > the OSI model of networking. > > 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > a factory). > RS-485 is similar to RS-422, but RS-422 allows just one driver with > multiple receivers whereas RS-485 supports multiple drivers and > receivers. > > 6. RS-485 is a serial bus with multiple nodes and thus must handle network > link layer protocols. By using high-impedance receivers, you can have > as many as 256 nodes. > > 7. The RS-485 can be implemented with RXTX in the core and a layer of software > on top to handle media access control (MAC sublayer). There are also > hardware converters. > http://www.rs485.com/pconverters.html for example. However, some of > these require software control. There is some support in the form of > the Rs485.java class, > in RXTX. > > 8. The RS-485 specification will add to the size of the JSR > > 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > This version of the Java communications API contains support for > RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > mentioned. > > 10. DO people want to add RS485 to a new JSR? > > Would it make sense for the RS-485 people to speak up now? > Please let me know if you think my summary is wrong. > > Thanks! > - Doug > > > > > > >> At 18:31 20/07/2006, Trent Jarvi wrote: >> >>> > PROJECT SCOPE: >>> > ------------- >>> > >>> > Also, we should think carefully about what the scope of >>> > this project would be. Should it be javax."comm" which >>> > handles both serial and parallel (is parallel going by the >>> > wayside). Should it be split into two project: >>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>> > >>> > Should we differentiate between single-ended serial >>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>> > quasi-multidrop and full multidrop busses such as >>> > EIA422, EIA432 and EIA485? If we really were to >>> > add I2C support to the API, we'd have to delve into >>> > the semantics more, because there could be some >>> > implicit decoding of the bus the API users would >>> > want to see. >>> > >>> >>> Hi Paul >>> >>> The way RXTX works, which is a fair representation of the people using the >>> API, is complete support for RIA232, minimal support for IEEE1284. From >>> what I understand, Sun was going along the same lines. If we combined >>> both projects, we would have half a parallel port implementation. I see >>> maybe 4 requests for features not in the parallel support a year. >>> >>> The other protocols should not be limited by a JSR which is going to be >>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>> I2C and Raw should _not_ be considered a strong basis for extending the >>> API to cover these protocols. If people want to do real implementations, >>> they should not face a 'standard' which wasnt really focused upon their >>> interests. I think we understand the parallel port issues fairly well but >>> have not implemented many features and I don't know if we would. >>> >> I agree with all of this. API requirements for I2C, SPI, etc. are very >> different from those for RS232/485/422. Our embedded Java platform has >> APIs for all of these and more and they don't share a lot apart from the >> fact that they all use Input/OutputStreams (and in the case of SPI you >> still need to cater with the fact that every time you want to read you >> must also write to the device.) >> >> If I was to design javax.comm from scratch, I think I would focus on >> serial ports exclusively (== whatever the underlying OS represents as >> serial ports). Even parallel is a bit out of place IMHO, although I >> understand it needs to stay for backwards compatibility. >> >> >> >>> So a versatile API is favorable but I do not think we have the proper >>> community to represent much more than Serial. >>> >> Yes, I think the same. >> >> Guillermo >> -- >> Guillermo Rodriguez Garcia >> >> Snijder Micro Systems phone +31-493-351020 >> G. Rodriguez Garcia fax +31-493-351530 >> Visser 25 email guille at sms.nl >> NL5751 BL Deurne >> The Netherlands http://www.snijder.com >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > From pascal at quies.net Mon Jul 24 08:19:03 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 16:19:03 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <44C4D079.80609@cox.net> References: <200607240210.45992.pascal@quies.net> <44C4D079.80609@cox.net> Message-ID: <200607241619.04053.pascal@quies.net> Op maandag 24 juli 2006 15:51, schreef Gregg Wonderly: > Pascal S. de Kloe wrote: > > @Gregg > > You can extract the necessary libraries during the installation with the > > extractNativeLibraries method to the application directory so they get > > loaded automatically. Is that good enough? > > If you start the JVM with -Djava.security.manager what permissions are > required? Can you send me a policy that is applicable so that I can review > what permissions are being required? Just look at the javadoc in CommunicationAPI.java for SecurityExceptions. ;) From gergg at cox.net Mon Jul 24 08:21:49 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 09:21:49 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4CF4F.1080706@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> Message-ID: <44C4D77D.5080200@cox.net> Manuel Francisco Naranjo wrote: > Doug: > I do not think that RS485 is a must by now. I do think we must make a > JSR to standarize a bit Serial Ports accessing. Maybe we can make a JSR > just for serial ports, and then start trying with other kind of ports > and make others JSR. Or try to expand our first JSR, but I trully do > not know if that can be made. I think that anyone aimed at the javax.comm space should be interested in creating a hardware access SPI first. This is the predominate stumbling block for java having access to various hardware devices. The more we can promote as a standard, the more we can expect consistency and availability! > About other ports besides RS485, the others I2C, SPI, etc, run at a very > low level, maybe too close to the processor for Java. SPI (not service provider interface) is a great protocol for disparet systems because the clocking is synchronous based on the fastest speed available at each end. This means that you can do SPI, today, in java by connecting serial port signal lines, or parallel port data lines to an SPI device, and bit banging the protocol. It won't be lightening fast, but it will be very much functional. What would make the most since is the ability for applications to designate various signalling line sources such as serial signaling lines and parallel port data lines as SPI data, slave select and clock signals, and plug those into an existing API. public class SPISlaveSelectLine { public SPISlaveSelectLine( int slave, SignalPort sp ) { ... } } public class SPIClockLine { public SPIClockLine( SignalPort sp ) { ... } } public class SPIDataLine { public SPIDataLine( SignalPort sp ) { ... } } I'd really like to see the embedded systems community take up this task and push these kinds of things forward. Having standard APIs would make it possible to run your software on aJile's AJ processors, the Muvium PIC environment, javacard, J2ME, etc. Imagine being able to plug a cellphone into the wall, attach a cable which has signalling lines and presto a remote terminal for monitoring and control. Data collection is a very needed capability as the next wave of technology evolution. The Java platform is not enabled with APIs to do this trivially yet. So, it doesn't look viable to many... Gregg Wonderly From guille at sms.nl Mon Jul 24 08:37:21 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 16:37:21 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: <1153751841.44c4db21de4bb@webmail.eatserver.nl> Hi Doug, Some comments below. Quoting "Dr. Douglas Lyon" : > Hi All, > There has been a lot of discussion regarding RS485. > > Let me see if I can summarize this, please correct me if I am wrong; > I am deliberately ignoring connector and electrical issues, focusing, > instead, on protocol and software issues. Also, I have never used > RS485, and I don't know much about it. > > 1. Serial ports that claim RS232 are typically used in > the data link layer of the OSI model of networking. Basically, this means > that they work with a point-to-point protocol and are meant to connect two > devices. It is actually physical + link (layers 1 and 2 of the OSI model), but yes, this is essentially right. > > 2. Within the RS232 standard there are framing bits (start and stop bits) > and error control bits (parity). The flow control is xon-xoff or DTR, CTS, > RTS. Thats' it. I'm not even sure that the RS232 standard talks about xon-xoff and such, I think it does not do much more than defining the electrical signals. Also note that RS232 was originally defined for the DTE-DCE interface (e.g. a device such as a modem connected to a computer). The current use of RS232 as a "general purpose" point to point link is a generalization of the RS232 standard. > > 3. If you want more than that from RS232 (forward error correction, ARQ, > etc.) > you do it in software, not in the RS232 standard. > > 4. RS485 is different from RS232 in that it is in the Network Layer of > the OSI model of networking. I would not put it that way. RS485 is very similar to RS232 with three main differences: - Only tx/rx, no extra signals such as DTR, RTS, CTS, etc (but then many "RS232" serial ports don't have them either) - Different electrical specs (which do not concern us here) - Multidrop and only one node talks at a given time (half duplex) But it does not define addresses (many RS485-based protocol use addresses for the nodes but that's not part of the RS485 standard), routing, etc. For software developers it still looks like a serial port (which it is!) except for the half-duplex part. More on this below. So RS485 is still about layers 1 and 2, same as RS232. I think all of this could be easier if we talk about UARTs instead of "RS232/RS485/RS422". All of these three are typically UARTs with some sort of buffer to get the electrical levels right: RS232 interface == UART + RS232 buffer/transceiver RS485 interface == UART + RS485 buffer/transceiver RS422 interface == UART + RS422 buffer/transceiver > > 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > a factory). > RS-485 is similar to RS-422, but RS-422 allows just one driver with > multiple receivers whereas RS-485 supports multiple drivers and > receivers. RS422 is exactly the same as RS485 except that it uses 4 wires instead of 2 wires so it can be full duplex again (but again this depends on the protocol you layer on top) > > 6. RS-485 is a serial bus with multiple nodes and thus must handle network > link layer protocols. By using high-impedance receivers, you can have > as many as 256 nodes. > > 7. The RS-485 can be implemented with RXTX in the core and a layer of > software > on top to handle media access control (MAC sublayer). There are also > hardware converters. > http://www.rs485.com/pconverters.html for example. However, some of > these require software control. There is some support in the form of > the Rs485.java class, > in RXTX. > > 8. The RS-485 specification will add to the size of the JSR > > 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > This version of the Java communications API contains support for > RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > mentioned. > > 10. DO people want to add RS485 to a new JSR? > > Would it make sense for the RS-485 people to speak up now? > Please let me know if you think my summary is wrong. Basically, for a software developer the only difference between RS485 and RS232 is the half-duplex nature of RS485, which means that you cannot receive and send at the same time. This has some implications depending on how RS485 is implemented in hardware, and on the (application) protocol defined on top of RS485. As I said, a RS485 interface is normally implemented using a standard UART plus a RS485 buffer/transceiver. RS485 buffers/transceivers can be in transmit mode or in receive mode. In a given RS485 bus, only one node should be in transmit mode at any given time, with the rest of the nodes 'listening' until it is their turn to transmit (and it is the application level protocol the one defines who should transmit next.) The RS485 chips used as buffers/transceivers normally have a control pin that is used to switch them into transmit or receive mode. There are typically three ways to handle this: 1. One of the control signals from the UART, such as RTS, DTR, etc. is connected to this control pin. The software must explicitly toggle this signal in order to switch the RS485 buffer/transceiver into transmit or receive mode. This puts a lot of burden on the software side and is sometimes unreliable because of complex timing issues as well as issues with buffering at the device driver level, but it is still a popular solution. 2. The UART itself knows about RS485 and can be configured to control the RS485 buffer/transceiver automatically, without any sort of software intervention. This is a very good solution since it is transparent to the software. However most UARTs don't know about RS485. 3. Standard UART + some custom hardware to control the direction pin. This is also transparent to the software. RS232/RS485 converters are an example of this approach. Implications for the software: For 3/ the software does not need to do anything special. For 2/ all you need is some sort of mechanism to tell the UART to enter RS485-mode (typically a ioctlex). For 1/ there is no simple solution. The timing issues make it difficult to implement this sort of mechanism in user space so it is often done at the device driver level. If this is the case, then all one needs is a mechanism to tell the driver to enter RS485-mode (again, a ioctlex). If this is NOT the case, then the application will need to take care. To do this more or less reliably, you would probably need a couple of things: - Some way to disable software buffering (and FIFOs if possible) - Some way to poll the UART's serial transmit register so that you can determine exactly when all data has been sent (many UARTs don't even support this) and switch to receive mode. - High resolution timers. - Real-time capabilities. Pretty strict requirements as you can see, which is why this approach never works very well except for very specific applications. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From naranjo.manuel at gmail.com Mon Jul 24 08:39:15 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Mon, 24 Jul 2006 11:39:15 -0300 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D77D.5080200@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> Message-ID: <44C4DB93.8080008@gmail.com> Gregg: Thanks for taking me out of the dark ;). Trully I did not know that SPI was an underlaying level of Serial ports, and Parallel ports. I give back what I said. I also would like to see my cell phone plug to every were, and be able to program it with java, is just that I do not know if we are going to get ourselves in a very almost unfinishable task. Regards, Manuel > Manuel Francisco Naranjo wrote: > >> Doug: >> I do not think that RS485 is a must by now. I do think we must make a >> JSR to standarize a bit Serial Ports accessing. Maybe we can make a JSR >> > > just for serial ports, and then start trying with other kind of ports > > and make others JSR. Or try to expand our first JSR, but I trully do > > not know if that can be made. > > I think that anyone aimed at the javax.comm space should be interested in > creating a hardware access SPI first. This is the predominate stumbling > block for java having access to various hardware devices. The more we can > promote as a standard, the more we can expect consistency and availability! > > >> About other ports besides RS485, the others I2C, SPI, etc, run at a very >> low level, maybe too close to the processor for Java. >> > > SPI (not service provider interface) is a great protocol for disparet systems > because the clocking is synchronous based on the fastest speed available at each > end. This means that you can do SPI, today, in java by connecting serial port > signal lines, or parallel port data lines to an SPI device, and bit banging the > protocol. It won't be lightening fast, but it will be very much functional. > What would make the most since is the ability for applications to designate > various signalling line sources such as serial signaling lines and parallel port > data lines as SPI data, slave select and clock signals, and plug those into an > existing API. > > public class SPISlaveSelectLine { > public SPISlaveSelectLine( int slave, SignalPort sp ) { > ... > } > } > > public class SPIClockLine { > public SPIClockLine( SignalPort sp ) { > ... > } > } > > public class SPIDataLine { > public SPIDataLine( SignalPort sp ) { > ... > } > } > > I'd really like to see the embedded systems community take up this task and push > these kinds of things forward. Having standard APIs would make it possible to > run your software on aJile's AJ processors, the Muvium PIC environment, > javacard, J2ME, etc. Imagine being able to plug a cellphone into the wall, > attach a cable which has signalling lines and presto a remote terminal for > monitoring and control. > > Data collection is a very needed capability as the next wave of technology > evolution. The Java platform is not enabled with APIs to do this trivially yet. > So, it doesn't look viable to many... > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From guille at sms.nl Mon Jul 24 08:41:21 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 16:41:21 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D351.603@lhar.co.za> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: <1153752081.44c4dc11eedf3@webmail.eatserver.nl> Quoting Christo Malan : > Hi > > I don't think RS-485 belong in rxtx, the scope of the spec is not wide > enough as it only specify the electrical layer. Their is no data > protocol recommended or defined. RS485 is exactly at the same level as RS232, no more and no less. > This mean that we have no idea when to > sample for a bit, how long is a bit and how many bits before we can say > new data is available. A "RS485 serial port" is just a UART whose output complies with the RS485 electrical spec, just as a "RS232 serial port" is just a UART whose output complies with the RS232 electrical spec. Bit times, sampling intervals, character structure etc. are the same for both protocols... Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From tjarvi at qbang.org Mon Jul 24 08:44:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 24 Jul 2006 08:44:53 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D351.603@lhar.co.za> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: A JSR/JCP would not just involve RXTX. In fact it would be very nice to have others with expertise in various areas like I2C, IrDA, RS485, RS422, ... involved. Within the RXTX community, I do not think we have enough depth to tackle RS485 alone. I'm aware of some of the low level issues but to be honest, I've never actually used it. The RS485 classes in RXTX are more like notes to myself about the issues involved without hardware solutions. In operating systems like Linux, this may be much less of an issue in the future. Linux is putting realtime patches now in the kernels which could make RS485 over EIA232 possible. This is probably the last chance RS485 has to get into a published spec for a long time though. Right now, I do not think its reasonable to include it in the process. Others could make that less of a problem. On Mon, 24 Jul 2006, Christo Malan wrote: > Hi > > I don't think RS-485 belong in rxtx, the scope of the spec is not wide > enough as it only specify the electrical layer. Their is no data > protocol recommended or defined. This mean that we have no idea when to > sample for a bit, how long is a bit and how many bits before we can say > new data is available. > > Christo > > Dr. Douglas Lyon wrote: >> Hi All, >> There has been a lot of discussion regarding RS485. >> >> Let me see if I can summarize this, please correct me if I am wrong; >> I am deliberately ignoring connector and electrical issues, focusing, >> instead, on protocol and software issues. Also, I have never used >> RS485, and I don't know much about it. >> >> 1. Serial ports that claim RS232 are typically used in >> the data link layer of the OSI model of networking. Basically, this means >> that they work with a point-to-point protocol and are meant to connect two >> devices. >> >> 2. Within the RS232 standard there are framing bits (start and stop bits) >> and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. >> Thats' it. >> >> 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) >> you do it in software, not in the RS232 standard. >> >> 4. RS485 is different from RS232 in that it is in the Network Layer of >> the OSI model of networking. >> >> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in >> a factory). >> RS-485 is similar to RS-422, but RS-422 allows just one driver with >> multiple receivers whereas RS-485 supports multiple drivers and >> receivers. >> >> 6. RS-485 is a serial bus with multiple nodes and thus must handle network >> link layer protocols. By using high-impedance receivers, you can have >> as many as 256 nodes. >> >> 7. The RS-485 can be implemented with RXTX in the core and a layer of software >> on top to handle media access control (MAC sublayer). There are also >> hardware converters. >> http://www.rs485.com/pconverters.html for example. However, some of >> these require software control. There is some support in the form of >> the Rs485.java class, >> in RXTX. >> >> 8. The RS-485 specification will add to the size of the JSR >> >> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: >> This version of the Java communications API contains support for >> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not >> mentioned. >> >> 10. DO people want to add RS485 to a new JSR? >> >> Would it make sense for the RS-485 people to speak up now? >> Please let me know if you think my summary is wrong. >> >> Thanks! >> - Doug >> >> >> >> >> >> >>> At 18:31 20/07/2006, Trent Jarvi wrote: >>> >>>> > PROJECT SCOPE: >>>> > ------------- >>>> > >>>> > Also, we should think carefully about what the scope of >>>> > this project would be. Should it be javax."comm" which >>>> > handles both serial and parallel (is parallel going by the >>>> > wayside). Should it be split into two project: >>>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>>> > >>>> > Should we differentiate between single-ended serial >>>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>>> > quasi-multidrop and full multidrop busses such as >>>> > EIA422, EIA432 and EIA485? If we really were to >>>> > add I2C support to the API, we'd have to delve into >>>> > the semantics more, because there could be some >>>> > implicit decoding of the bus the API users would >>>> > want to see. >>>> > >>>> >>>> Hi Paul >>>> >>>> The way RXTX works, which is a fair representation of the people using the >>>> API, is complete support for RIA232, minimal support for IEEE1284. From >>>> what I understand, Sun was going along the same lines. If we combined >>>> both projects, we would have half a parallel port implementation. I see >>>> maybe 4 requests for features not in the parallel support a year. >>>> >>>> The other protocols should not be limited by a JSR which is going to be >>>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>>> I2C and Raw should _not_ be considered a strong basis for extending the >>>> API to cover these protocols. If people want to do real implementations, >>>> they should not face a 'standard' which wasnt really focused upon their >>>> interests. I think we understand the parallel port issues fairly well but >>>> have not implemented many features and I don't know if we would. >>>> >>> I agree with all of this. API requirements for I2C, SPI, etc. are very >>> different from those for RS232/485/422. Our embedded Java platform has >>> APIs for all of these and more and they don't share a lot apart from the >>> fact that they all use Input/OutputStreams (and in the case of SPI you >>> still need to cater with the fact that every time you want to read you >>> must also write to the device.) >>> >>> If I was to design javax.comm from scratch, I think I would focus on >>> serial ports exclusively (== whatever the underlying OS represents as >>> serial ports). Even parallel is a bit out of place IMHO, although I >>> understand it needs to stay for backwards compatibility. >>> >>> >>> >>>> So a versatile API is favorable but I do not think we have the proper >>>> community to represent much more than Serial. >>>> >>> Yes, I think the same. >>> >>> Guillermo >>> -- >>> Guillermo Rodriguez Garcia >>> >>> Snijder Micro Systems phone +31-493-351020 >>> G. Rodriguez Garcia fax +31-493-351530 >>> Visser 25 email guille at sms.nl >>> NL5751 BL Deurne >>> The Netherlands http://www.snijder.com >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From guille at sms.nl Mon Jul 24 08:47:47 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 16:47:47 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D77D.5080200@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> Message-ID: <1153752467.44c4dd93c08f7@webmail.eatserver.nl> Hi Gregg, Quoting Gregg Wonderly : > SPI (not service provider interface) is a great protocol for disparet systems > > because the clocking is synchronous based on the fastest speed available at > each > end. This means that you can do SPI, today, in java by connecting serial > port > signal lines, or parallel port data lines to an SPI device, and bit banging > the > protocol. It won't be lightening fast, but it will be very much functional. [...] > I'd really like to see the embedded systems community take up this task and > push > these kinds of things forward. Having standard APIs would make it possible > to > run your software on aJile's AJ processors, the Muvium PIC environment, > javacard, J2ME, etc. Imagine being able to plug a cellphone into the wall, > attach a cable which has signalling lines and presto a remote terminal for > monitoring and control. As an embedded Java vendor, SNIJDER Micro Systems certainly sees the value of standardized APIs to talk to different types of communication buses including SPI, I2C, 1-Wire, etc., for embedded applications. However we think this has nothing to do with javax.comm. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From guille at sms.nl Mon Jul 24 09:05:22 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 17:05:22 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4DB93.8080008@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <44C4DB93.8080008@gmail.com> Message-ID: <1153753522.44c4e1b24f2e1@webmail.eatserver.nl> Quoting Manuel Francisco Naranjo : > Gregg: > Thanks for taking me out of the dark ;). Trully I did not know that SPI > was an underlaying level of Serial ports, and Parallel ports. In fact it isn't; it is just another serial protocol, just like I2C. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From jredman at ergotech.com Mon Jul 24 09:29:10 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 09:29:10 -0600 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: <44C4E746.8070808@ergotech.com> Folks, The RS232/485/422/etc. etc. is a complete red herring (http://en.wikipedia.org/wiki/Red_herring in case you don't know the expression). The differences between the two are at the electrical level, not at the RXTX level. I'll provide a concrete example and see if we can get away from this issue. There's an industrial serial communications standard - Modbus. Modbus capable devices are very common and can be purchased, generally, with an RS232 or a 485 or a 422 - you decide when you buy it. Some actually provide both 232 and 485 on the same connector. Now, within our environment you configure a Modbus JavaBean. One of the parameters is the "Station Number". The station number is required for both RS232 and RS485 devices - the protocol doesn't change based on the electrical requirements of the device. Now I can configure an application talking to, say, station 2 and station 7. I can add an RS485 converter to the computer serial port and put two physical devices there, configured as station 2 and station 7 and everything works fine. HOWEVER, over RS232 some devices will respond to both station 2 and station 7. So THE SAME APPLICATION will work with both 232 and 485. The only changes are hardware related. This same behavior is true of a number of 485 "networks" and many industrial devices that have 485 interfaces have 232 as an option using the same protocol. Jim Trent Jarvi wrote: > A JSR/JCP would not just involve RXTX. In fact it would be very nice to > have others with expertise in various areas like I2C, IrDA, RS485, RS422, > ... involved. > > Within the RXTX community, I do not think we have enough depth to tackle > RS485 alone. I'm aware of some of the low level issues but to be honest, > I've never actually used it. The RS485 classes in RXTX are more like > notes to myself about the issues involved without hardware solutions. In > operating systems like Linux, this may be much less of an issue in the > future. Linux is putting realtime patches now in the kernels which could > make RS485 over EIA232 possible. > > This is probably the last chance RS485 has to get into a published spec > for a long time though. Right now, I do not think its reasonable to > include it in the process. Others could make that less of a problem. > > On Mon, 24 Jul 2006, Christo Malan wrote: > >> Hi >> >> I don't think RS-485 belong in rxtx, the scope of the spec is not wide >> enough as it only specify the electrical layer. Their is no data >> protocol recommended or defined. This mean that we have no idea when to >> sample for a bit, how long is a bit and how many bits before we can say >> new data is available. >> >> Christo >> >> Dr. Douglas Lyon wrote: >>> Hi All, >>> There has been a lot of discussion regarding RS485. >>> >>> Let me see if I can summarize this, please correct me if I am wrong; >>> I am deliberately ignoring connector and electrical issues, focusing, >>> instead, on protocol and software issues. Also, I have never used >>> RS485, and I don't know much about it. >>> >>> 1. Serial ports that claim RS232 are typically used in >>> the data link layer of the OSI model of networking. Basically, this means >>> that they work with a point-to-point protocol and are meant to connect two >>> devices. >>> >>> 2. Within the RS232 standard there are framing bits (start and stop bits) >>> and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. >>> Thats' it. >>> >>> 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) >>> you do it in software, not in the RS232 standard. >>> >>> 4. RS485 is different from RS232 in that it is in the Network Layer of >>> the OSI model of networking. >>> >>> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in >>> a factory). >>> RS-485 is similar to RS-422, but RS-422 allows just one driver with >>> multiple receivers whereas RS-485 supports multiple drivers and >>> receivers. >>> >>> 6. RS-485 is a serial bus with multiple nodes and thus must handle network >>> link layer protocols. By using high-impedance receivers, you can have >>> as many as 256 nodes. >>> >>> 7. The RS-485 can be implemented with RXTX in the core and a layer of software >>> on top to handle media access control (MAC sublayer). There are also >>> hardware converters. >>> http://www.rs485.com/pconverters.html for example. However, some of >>> these require software control. There is some support in the form of >>> the Rs485.java class, >>> in RXTX. >>> >>> 8. The RS-485 specification will add to the size of the JSR >>> >>> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: >>> This version of the Java communications API contains support for >>> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not >>> mentioned. >>> >>> 10. DO people want to add RS485 to a new JSR? >>> >>> Would it make sense for the RS-485 people to speak up now? >>> Please let me know if you think my summary is wrong. >>> >>> Thanks! >>> - Doug >>> >>> >>> >>> >>> >>> >>>> At 18:31 20/07/2006, Trent Jarvi wrote: >>>> >>>>>> PROJECT SCOPE: >>>>>> ------------- >>>>>> >>>>>> Also, we should think carefully about what the scope of >>>>>> this project would be. Should it be javax."comm" which >>>>>> handles both serial and parallel (is parallel going by the >>>>>> wayside). Should it be split into two project: >>>>>> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>>>>> >>>>>> Should we differentiate between single-ended serial >>>>>> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>>>>> quasi-multidrop and full multidrop busses such as >>>>>> EIA422, EIA432 and EIA485? If we really were to >>>>>> add I2C support to the API, we'd have to delve into >>>>>> the semantics more, because there could be some >>>>>> implicit decoding of the bus the API users would >>>>>> want to see. >>>>>> >>>>> Hi Paul >>>>> >>>>> The way RXTX works, which is a fair representation of the people using the >>>>> API, is complete support for RIA232, minimal support for IEEE1284. From >>>>> what I understand, Sun was going along the same lines. If we combined >>>>> both projects, we would have half a parallel port implementation. I see >>>>> maybe 4 requests for features not in the parallel support a year. >>>>> >>>>> The other protocols should not be limited by a JSR which is going to be >>>>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>>>> I2C and Raw should _not_ be considered a strong basis for extending the >>>>> API to cover these protocols. If people want to do real implementations, >>>>> they should not face a 'standard' which wasnt really focused upon their >>>>> interests. I think we understand the parallel port issues fairly well but >>>>> have not implemented many features and I don't know if we would. >>>>> >>>> I agree with all of this. API requirements for I2C, SPI, etc. are very >>>> different from those for RS232/485/422. Our embedded Java platform has >>>> APIs for all of these and more and they don't share a lot apart from the >>>> fact that they all use Input/OutputStreams (and in the case of SPI you >>>> still need to cater with the fact that every time you want to read you >>>> must also write to the device.) >>>> >>>> If I was to design javax.comm from scratch, I think I would focus on >>>> serial ports exclusively (== whatever the underlying OS represents as >>>> serial ports). Even parallel is a bit out of place IMHO, although I >>>> understand it needs to stay for backwards compatibility. >>>> >>>> >>>> >>>>> So a versatile API is favorable but I do not think we have the proper >>>>> community to represent much more than Serial. >>>>> >>>> Yes, I think the same. >>>> >>>> Guillermo >>>> -- >>>> Guillermo Rodriguez Garcia >>>> >>>> Snijder Micro Systems phone +31-493-351020 >>>> G. Rodriguez Garcia fax +31-493-351530 >>>> Visser 25 email guille at sms.nl >>>> NL5751 BL Deurne >>>> The Netherlands http://www.snijder.com >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From jredman at ergotech.com Mon Jul 24 09:50:21 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 09:50:21 -0600 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D77D.5080200@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> Message-ID: <44C4EC3D.6010204@ergotech.com> Jim, How about we go back to basics and define a serial port. Under Java, I can open /dev/ttyS0, COM1:, etc and read/write a serial port. So what does RXTX bring to the table? If we can define what we need from the product at a high level (functional spec.) then we can look at what's wrong underneath (design requirements). I can do this fairly easily. Functionally, I want support for SerialPort - a superset of that would be fine. SerialPort provides an abstraction that provides everything I need for accessing serial devices. At the design level, I'd like a "pluggable" architecture. That is, I'd like to able to accommodate anything that it makes sense to implement in terms of the SerialPort interface. An obvious plugin is one that supports the current RXTX serial port access - through device files. But _I'd_ like a plugin for serial ports over Ethernet, serial ports over BlueTooth (including discovery), etc. I'm sure others could think of modules they'd like i2c, SPI, etc. etc. I'm not sure that ANY of these should be part of the spec. although perhaps the device file based version could be part of a reference implementation. I don't know that this is really much different from the existing architecture. I doubt that much code could be shared between, for example, a BlueTooth serial port and a /dev/ttyS0 serial port, but perhaps those more familiar with the code could comment. I suspect some cleanup of registration, etc. would be needed to formalize plugins, but I doubt it's too great. Some time ago I learnt the definition of a "Goal". It should be concrete, winnable and build unity. So, I have laid out a concrete goal, build to a superset of the SerialPort interface, it's winnable because it's not a complete rewrite of RXTX and it builds unity because anyone's pet electrical specification can be added. A simplistic view, tell me where I went wrong. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From lyon at docjava.com Mon Jul 24 10:06:40 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 24 Jul 2006 12:06:40 -0400 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4E746.8070808@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> Message-ID: >Hi All, Wow, what an informed and interesting debate from my most innocent and well-intentioned of e-mails. I must say that I am learning a great deal from this list! When I speak about RS232 I wanted to focus on the protocol, not the connector shape or pin-out or electrical issues. Issues like that are addressed by the rs232c standard. The RS232 is a really loaded term! The C revision of the standard was issued in 1969 in part to accommodate electrical characteristics. Revision D was issued in 1986. The current revision is TIA-232-F Interface Between Data Terminal Equipment and Data Circuit-Terminating Equipment Employing Serial Binary Data Interchange, issued in 1997. None of this is of any particular relevance to the basic underlying question: Should the next JSR attempt to address the multi-drop abilities of RS-485? Thanks! - Doug >Folks, > >The RS232/485/422/etc. etc. is a complete red herring >(http://en.wikipedia.org/wiki/Red_herring in case you don't know the >expression). The differences between the two are at the electrical >level, not at the RXTX level. I'll provide a concrete example and see >if we can get away from this issue. > >There's an industrial serial communications standard - Modbus. Modbus >capable devices are very common and can be purchased, generally, with an >RS232 or a 485 or a 422 - you decide when you buy it. Some actually >provide both 232 and 485 on the same connector. Now, within our >environment you configure a Modbus JavaBean. One of the parameters is >the "Station Number". The station number is required for both RS232 and >RS485 devices - the protocol doesn't change based on the electrical >requirements of the device. Now I can configure an application talking >to, say, station 2 and station 7. I can add an RS485 converter to the >computer serial port and put two physical devices there, configured as >station 2 and station 7 and everything works fine. HOWEVER, over RS232 >some devices will respond to both station 2 and station 7. So THE SAME >APPLICATION will work with both 232 and 485. The only changes are >hardware related. This same behavior is true of a number of 485 >"networks" and many industrial devices that have 485 interfaces have 232 >as an option using the same protocol. > >Jim > > >Trent Jarvi wrote: >> A JSR/JCP would not just involve RXTX. In fact it would be very nice to >> have others with expertise in various areas like I2C, IrDA, RS485, RS422, >> ... involved. >> >> Within the RXTX community, I do not think we have enough depth to tackle >> RS485 alone. I'm aware of some of the low level issues but to be honest, >> I've never actually used it. The RS485 classes in RXTX are more like >> notes to myself about the issues involved without hardware solutions. In >> operating systems like Linux, this may be much less of an issue in the >> future. Linux is putting realtime patches now in the kernels which could >> make RS485 over EIA232 possible. >> >> This is probably the last chance RS485 has to get into a published spec >> for a long time though. Right now, I do not think its reasonable to >> include it in the process. Others could make that less of a problem. >> >> On Mon, 24 Jul 2006, Christo Malan wrote: >> >>> Hi >>> >>> I don't think RS-485 belong in rxtx, the scope of the spec is not wide >>> enough as it only specify the electrical layer. Their is no data >>> protocol recommended or defined. This mean that we have no idea when to >>> sample for a bit, how long is a bit and how many bits before we can say >>> new data is available. >>> >>> Christo >>> >>> Dr. Douglas Lyon wrote: >>>> Hi All, >>>> There has been a lot of discussion regarding RS485. >>>> >>>> Let me see if I can summarize this, please correct me if I am wrong; >>>> I am deliberately ignoring connector and electrical issues, focusing, >>>> instead, on protocol and software issues. Also, I have never used >>>> RS485, and I don't know much about it. > >>> >>>> 1. Serial ports that claim RS232 are typically used in >>>> the data link layer of the OSI model of networking. Basically, this means >>>> that they work with a point-to-point protocol and are meant to connect two > >>> devices. >>>> >>>> 2. Within the RS232 standard there are framing bits (start and stop bits) >>>> and error control bits (parity). The flow control is xon-xoff or >>>>DTR, CTS, RTS. >>>> Thats' it. >>>> >>>> 3. If you want more than that from RS232 (forward error >>>>correction, ARQ, etc.) >>>> you do it in software, not in the RS232 standard. >>>> >>>> 4. RS485 is different from RS232 in that it is in the Network Layer of >>>> the OSI model of networking. >>>> >>>> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in >>>> a factory). >>>> RS-485 is similar to RS-422, but RS-422 allows just one driver with >>>> multiple receivers whereas RS-485 supports multiple drivers and >>>> receivers. >>>> >>>> 6. RS-485 is a serial bus with multiple nodes and thus must handle network >>>> link layer protocols. By using high-impedance receivers, you can have >>>> as many as 256 nodes. >>>> >>>> 7. The RS-485 can be implemented with RXTX in the core and a >>>>layer of software >>>> on top to handle media access control (MAC sublayer). There are also >>>> hardware converters. >>>> http://www.rs485.com/pconverters.html for example. However, some of >>>> these require software control. There is some support in the form of >>>> the Rs485.java class, >>>> in RXTX. >>>> >>>> 8. The RS-485 specification will add to the size of the JSR >>>> >>>> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: >>>> This version of the Java communications API contains support for >>>> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not >>>> mentioned. >>>> >>>> 10. DO people want to add RS485 to a new JSR? >>>> >>>> Would it make sense for the RS-485 people to speak up now? >>>> Please let me know if you think my summary is wrong. >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>> >>>> >>>> >>>> >>>>> At 18:31 20/07/2006, Trent Jarvi wrote: >>>>> >>>>>>> PROJECT SCOPE: >>>>>>> ------------- >>>>>>> >>>>>>> Also, we should think carefully about what the scope of >>>>>>> this project would be. Should it be javax."comm" which >>>>>>> handles both serial and parallel (is parallel going by the >>>>>>> wayside). Should it be split into two project: >>>>>>> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>>>>>> >>>>>>> Should we differentiate between single-ended serial >>>>>>> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>>>>>> quasi-multidrop and full multidrop busses such as >>>>>>> EIA422, EIA432 and EIA485? If we really were to >>>>>>> add I2C support to the API, we'd have to delve into >>>>>>> the semantics more, because there could be some >>>>>>> implicit decoding of the bus the API users would >>>>>>> want to see. >>>>>>> >>>>>> Hi Paul >>>>>> >>>>>> The way RXTX works, which is a fair representation of the >>>>>>people using the >>>>>> API, is complete support for RIA232, minimal support for IEEE1284. From >>>>>> what I understand, Sun was going along the same lines. If we combined >>>>>> both projects, we would have half a parallel port implementation. I see >>>>>> maybe 4 requests for features not in the parallel support a year. >>>>>> >>>>>> The other protocols should not be limited by a JSR which is going to be >>>>>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>>>>> I2C and Raw should _not_ be considered a strong basis for extending the >>>>>> API to cover these protocols. If people want to do real >>>>>>implementations, >>>>>> they should not face a 'standard' which wasnt really focused upon their >>>>>> interests. I think we understand the parallel port issues >>>>>>fairly well but >>>>>> have not implemented many features and I don't know if we would. >>>>>> >>>>> I agree with all of this. API requirements for I2C, SPI, etc. are very >>>>> different from those for RS232/485/422. Our embedded Java platform has >>>>> APIs for all of these and more and they don't share a lot apart from the >>>>> fact that they all use Input/OutputStreams (and in the case of SPI you > >>>> still need to cater with the fact that every time you want to read you >>>>> must also write to the device.) >>>>> >>>>> If I was to design javax.comm from scratch, I think I would focus on >>>>> serial ports exclusively (== whatever the underlying OS represents as > >>>> serial ports). Even parallel is a bit out of place IMHO, although I >>>>> understand it needs to stay for backwards compatibility. >>>>> >>>>> >>>>> >>>>>> So a versatile API is favorable but I do not think we have the proper >>>>>> community to represent much more than Serial. >>>>>> >>>>> Yes, I think the same. >>>>> >>>>> Guillermo >>>>> -- >>>>> Guillermo Rodriguez Garcia >>>>> >>>>> Snijder Micro Systems phone +31-493-351020 >>>>> G. Rodriguez Garcia fax +31-493-351530 >>>>> Visser 25 email guille at sms.nl >>>>> NL5751 BL Deurne >>>>> The Netherlands http://www.snijder.com >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >-- >Jim Redman >(505) 662 5156 x85 >http://www.ergotech.com >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Mon Jul 24 10:16:44 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 18:16:44 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> Message-ID: <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> Hi Doug, Quoting "Dr. Douglas Lyon" : > >Hi All, > > > Wow, what an informed and interesting debate from my most > innocent and well-intentioned of e-mails. > > I must say that I am learning a great deal from this list! > > When I speak about > RS232 I wanted to focus on the protocol, not the connector shape or > pin-out or electrical issues. Issues like that are addressed by the > rs232c standard. > The RS232 is a really loaded term! Right. Maybe we should be talking about "serial ports" instead. At the functional level it does not make any difference whether it is RS232, RS485, or RS422... except maybe for the direction control in the case of RS485 ports. [...] > > None of this is of any particular relevance to the basic underlying > question: > > Should the next JSR attempt to address the multi-drop abilities of RS-485? What I would suggest is to just add a new 'ioctlex'-like method to the SerialPort API: A method that you'd use to pass platform- or implementation-specific info to the underlying driver or OS to do things such as "enabling RS485 mode" or "disable FIFOs" or "poll the TSR register". No need to define any function codes. This is for stuff that is platform- or implementation-specific and as such cannot be easily abstracted anyway. The goal is to accomodate hat those systems that have serial ports with special, non-standard capabilities without forcing developers to leave javax.comm. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From Paul.Klissner at Sun.COM Mon Jul 24 10:45:33 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Mon, 24 Jul 2006 09:45:33 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> Message-ID: <44C4F92D.6090807@sun.com> >> None of this is of any particular relevance to the basic underlying >> question: >> >> Should the next JSR attempt to address the multi-drop abilities of RS-485? > > What I would suggest is to just add a new 'ioctlex'-like method > to the SerialPort API: A method that you'd use to pass platform- > or implementation-specific info to the underlying driver or OS > to do things such as "enabling RS485 mode" or "disable FIFOs" or > "poll the TSR register". > > No need to define any function codes. This is for stuff that is > platform- or implementation-specific and as such cannot be easily > abstracted anyway. Detrimental to platform independence. Paul From berkland at spamcop.net Mon Jul 24 11:07:58 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 24 Jul 2006 13:07:58 -0400 Subject: [Rxtx] jcp and jsr In-Reply-To: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> Message-ID: <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> Gregg Wonderly wrote: > That there could be a low level port/device SPI > that could be put in place once, and then overtime > we could layer other APIs, including an updated > javax.comm which would make use of this SPI. I think there is great merit in this suggestion. I would like to see the ability to register a new "port" along with a custom handler in the Java client code before attempting to access the port. e.g . CommManager.getInstance().registerPortImpl("USB1:", new HidPortAdapter(/*vendorId=*/ "1234", /*deviceId=*/ "4321"); CommManager.getInstance().registerPortImpl("Ether1:", new InetPortAdapter(/*ipAndPort=*/ "192.168.1.101:8088"); It would allow other protocols that this group doesn't have depth in to be developed by someone who does on an "as needed" basis. Additionally, the value of this would be with some devices that implement basically the same protocol that was initially used over RS232 for a USB (via an HID) or Ethernet interface. There are a number of these in POS hardware. The existing JavaPOS driver written against JavaCOMM 2.0 could be reused by plugging in an HID or IP adapter before attempting to access the device. It might also be valuable to use something like an extended version of the portmapping file found in JavaCOMM 3.0. A configuration file could allow this definition to take place outside of any Java client code. Such a mapping file wouldn't even need to be part of the JSR API or reference implementation. It could be handled in a specific implementation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060724/7f51342e/attachment-0337.html From guille at sms.nl Mon Jul 24 11:14:54 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 19:14:54 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4F92D.6090807@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> Message-ID: <1153761294.44c5000ec1360@webmail.eatserver.nl> Quoting Paul Klissner : > >> None of this is of any particular relevance to the basic underlying > >> question: > >> > >> Should the next JSR attempt to address the multi-drop abilities of > RS-485? > > > > What I would suggest is to just add a new 'ioctlex'-like method > > to the SerialPort API: A method that you'd use to pass platform- > > or implementation-specific info to the underlying driver or OS > > to do things such as "enabling RS485 mode" or "disable FIFOs" or > > "poll the TSR register". > > > > No need to define any function codes. This is for stuff that is > > platform- or implementation-specific and as such cannot be easily > > abstracted anyway. > > Detrimental to platform independence. Yes, it is. But as you go closer and closer to the hardware level some things are by nature platform-dependent, and sometimes just cannot be solved in a platform-independent way. In these cases, is it better to have no solution at all than having one that is less than perfect? Put it another way, would you prefer having people say "I just cannot do this in Java; I'll go somewhere else" rather than "I can do this in Java -- only not in a platform-independent way" ? Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From gergg at cox.net Mon Jul 24 11:34:00 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 12:34:00 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153752467.44c4dd93c08f7@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> Message-ID: <44C50488.1040508@cox.net> Guillermo Rodriguez wrote: > As an embedded Java vendor, SNIJDER Micro Systems certainly sees the > value of standardized APIs to talk to different types of communication > buses including SPI, I2C, 1-Wire, etc., for embedded applications. > However we think this has nothing to do with javax.comm. I don't think this is only about javax.comm. Certainly that's important. I'm just wading into this conversation mainstream and trying to say: If you are going to do anything about "fixing" javax.comm to work on all platforms, please, please, please start with a hardware port SPI definition that lets you get to serial ports, and then provide the existing javax.com API and whatever new API you think is necessary (I don't have any really issues with the existing API directly). Then, there will be a place for others interesting in SPI, i2C, USB and other things to get started with providing access to devices that are also interesting in Java applications, and directly, in embedded Java applications. Gregg Wonderly From Paul.Klissner at Sun.COM Mon Jul 24 11:41:51 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Mon, 24 Jul 2006 10:41:51 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153761294.44c5000ec1360@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> Message-ID: <44C5065F.3060802@sun.com> Guillermo Rodriguez wrote: > Quoting Paul Klissner : > >>>> None of this is of any particular relevance to the basic underlying >>>> question: >>>> >>>> Should the next JSR attempt to address the multi-drop abilities of >> RS-485? >>> What I would suggest is to just add a new 'ioctlex'-like method >>> to the SerialPort API: A method that you'd use to pass platform- >>> or implementation-specific info to the underlying driver or OS >>> to do things such as "enabling RS485 mode" or "disable FIFOs" or >>> "poll the TSR register". >>> >>> No need to define any function codes. This is for stuff that is >>> platform- or implementation-specific and as such cannot be easily >>> abstracted anyway. >> Detrimental to platform independence. > > Yes, it is. But as you go closer and closer to the hardware level some > things are by nature platform-dependent, and sometimes just cannot be > solved in a platform-independent way. In these cases, is it better to > have no solution at all than having one that is less than perfect? > > Put it another way, would you prefer having people say "I just cannot > do this in Java; I'll go somewhere else" rather than "I can do this > in Java -- only not in a platform-independent way" ? If there isn't a reasonable way to abstract it out, then why use Java? The whole idea is platform neutrality, otherwise, what is the huge advantage of adopting a standardized Java API? I think it is wrong to subvert the API. I think we have to arrive at some sort of consensus about the scope of the API and do our best to engineer a robust API in terms of that scope using abstraction. There may be outliers, but the outliers probably aren't portable, and probably would do just as well to not use java for that particular application. If this was a JSR, if we found some compelling problem that kept cropping up the API could be reved so as not to just orphan cases with legitimate requests. If someone really needs to do funky things with the hardware, why wouldn't that be put in the native back end? Couldn't some of this be addressed by the multiple SPI layer that I recommended as one of the two changes I'd like to see made to javax.comm (the other being a port mapping plugin layer)? Paul From jredman at ergotech.com Mon Jul 24 11:49:46 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 11:49:46 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> Message-ID: <44C5083A.6090902@ergotech.com> A thought for later since we haven't really reached this level of detail, but since this type of approach seems likely... If a configuration file is mandatory, can we specify what the file is called and what the format of the options are (mandatory?, and optional) without limiting extensions. This just adds consistency across platforms/implementations. Jim Doug Berkland wrote: > Gregg Wonderly wrote: > > That there could be a low level port/device SPI > > that could be put in place once, and then overtime > > we could layer other APIs, including an updated > > javax.comm which would make use of this SPI. > > I think there is great merit in this suggestion. I would like to see > the ability to register a new "port" along with a custom handler in the > Java client code before attempting to access the port. > e.g . > CommManager.getInstance().registerPortImpl("USB1:", new > HidPortAdapter(/*vendorId=*/ "1234", /*deviceId=*/ "4321"); > CommManager.getInstance().registerPortImpl("Ether1:", new > InetPortAdapter(/*ipAndPort=*/ " 192.168.1.101:8088 > "); > > It would allow other protocols that this group doesn't have depth in to > be developed by someone who does on an "as needed" basis. > > Additionally, the value of this would be with some devices that > implement basically the same protocol that was initially used over RS232 > for a USB (via an HID) or Ethernet interface. There are a number of > these in POS hardware. The existing JavaPOS driver written against > JavaCOMM 2.0 could be reused by plugging in an HID or IP adapter before > attempting to access the device. > > It might also be valuable to use something like an extended version of > the portmapping file found in JavaCOMM 3.0. A configuration file could > allow this definition to take place outside of any Java client code. > Such a mapping file wouldn't even need to be part of the JSR API or > reference implementation. It could be handled in a specific > implementation. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From mtnvega at yahoo.com.br Mon Jul 24 11:51:40 2006 From: mtnvega at yahoo.com.br (mtnvega) Date: Mon, 24 Jul 2006 14:51:40 -0300 Subject: [Rxtx] Serial Read/Write Details Message-ID: <44C508AC.7060103@yahoo.com.br> Hello, I'm have being flirting with RXTX for a while since I'm working on a college project where I will need to communicate with a microcontroller using USART. Now is the time to start using it! But I have some doubts and I hope you can help-me. I will need to both send and receive data from the serial port. First I will need to send some command bytes then wait for some data that will be returned from the microcontroller. And I would like to know which is the best way to do that. I'm mean, of course send and receive data is the purpose of the serial port and RXTX but I'm looking for some details since there will be no package control but just a fixed command format and confirmation messages from the microcontroller side. I would like to know if I should open and close the port or if I can just open it once. I read that upon writing to output the input buffer are filled with the same data, is it right? If yes, isn't it a problem since I'm waiting for data back in a very small time? Thank you, Luiz _______________________________________________________ Voc? quer respostas para suas perguntas? Ou voc? sabe muito e quer compartilhar seu conhecimento? Experimente o Yahoo! Respostas ! http://br.answers.yahoo.com/ From jredman at ergotech.com Mon Jul 24 12:45:50 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 12:45:50 -0600 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C50488.1040508@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> Message-ID: <44C5155E.7080105@ergotech.com> Gregg, Is SPI applicable to a SerialPort interface over Ethernet (or Bluetooth)? I've assumed that it's specific to directly-connected-UART-based serial ports - something similar to I2C. I'm starting to think that I'm opposed to having hardware definitions (transport layer?) in the JavaComm spec., but then what's left? Jim Gregg Wonderly wrote: > Guillermo Rodriguez wrote: >> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the >> value of standardized APIs to talk to different types of communication >> buses including SPI, I2C, 1-Wire, etc., for embedded applications. >> However we think this has nothing to do with javax.comm. > > I don't think this is only about javax.comm. Certainly that's important. I'm > just wading into this conversation mainstream and trying to say: > > If you are going to do anything about "fixing" javax.comm to work on all > platforms, please, please, please start with a hardware port SPI definition that > lets you get to serial ports, and then provide the existing javax.com API and > whatever new API you think is necessary (I don't have any really issues with the > existing API directly). > > Then, there will be a place for others interesting in SPI, i2C, USB and other > things to get started with providing access to devices that are also interesting > in Java applications, and directly, in embedded Java applications. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Mon Jul 24 13:15:19 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 14:15:19 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C5155E.7080105@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <44C5155E.7080105@ergotech.com> Message-ID: <44C51C47.90409@cox.net> Jim Redman wrote: > Is SPI applicable to a SerialPort interface over Ethernet (or > Bluetooth)? I've assumed that it's specific to > directly-connected-UART-based serial ports - something similar to I2C. SPI is a simple 2 line (clock and data) plus slave select bi-directional, full duplex data transfer mechanism. It has nothing to do, directly with serial ports, but could be implemented using serial port signalling lines. > I'm starting to think that I'm opposed to having hardware definitions > (transport layer?) in the JavaComm spec., but then what's left? Jim, there are multiple conversations going on, on the list. There is a group of people that just want a standard serial port mechanism in Java, apparently NOW! They are going back and forth about that. There is another conversation about doing a JSR to make the serial port interfaces a standard, since Sun's original implementation was never a Java standard. There is a small group saying if you're going to do a JSR for serial ports, why not provide a nice foundation for serial ports which might also support other kinds of "ports" and associated protocols. And there are a couple of other conversations about Pascal's stuff. It's this last group that I am the most interested in. I think that it is possible to create a simple Service Provider Interface for 'hardware interfacing' that covers serial ports and also includes expandability to cover other types of hardware. We want to find the level of abstraction that the most number of OSes provide in their user level APIs, and create a matching SPI at that level which will allow a JVM vendor to provide access to the types of hardware that is common on their OSes/hardware. Then, third parties might add some value by providing some good abstrations for particular types of protocols or particular vendors' hardware (ports which can be switched between RS232 and RS485 for example). Finally, we can create an implementation of the javax.comm API which uses this SPI to provide exactly the same API as today, but with an approved foundation for hardware access from java using 100% java code. Gregg Wonderly From mark at mdsh.com Mon Jul 24 16:03:38 2006 From: mark at mdsh.com (Mark Himsley) Date: Mon, 24 Jul 2006 23:03:38 +0100 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: I don't see how any Java app is going to know the difference between an RS232, RS422, or RS485 port. I regularly use RXTX controlling RS422 devices (controlling VTRs) and I can use an RS232 port with bodged wiring (for short distances) or RS232 port with a media converted - either of which may be built into the PC or may be a USB device - or an RS422 USB device. They are just 'serial port' devices. Please don't get hung up on higher layer stuff - that's for application developers to add on top of a rock-solid multi platform 'serial port' driver implementations. On 24 July 2006 08:44 -0600 Trent Jarvi wrote: > > A JSR/JCP would not just involve RXTX. In fact it would be very nice to > have others with expertise in various areas like I2C, IrDA, RS485, RS422, > ... involved. > > Within the RXTX community, I do not think we have enough depth to tackle > RS485 alone. I'm aware of some of the low level issues but to be honest, > I've never actually used it. The RS485 classes in RXTX are more like > notes to myself about the issues involved without hardware solutions. In > operating systems like Linux, this may be much less of an issue in the > future. Linux is putting realtime patches now in the kernels which could > make RS485 over EIA232 possible. > > This is probably the last chance RS485 has to get into a published spec > for a long time though. Right now, I do not think its reasonable to > include it in the process. Others could make that less of a problem. > > On Mon, 24 Jul 2006, Christo Malan wrote: > > > Hi > > > > I don't think RS-485 belong in rxtx, the scope of the spec is not wide > > enough as it only specify the electrical layer. Their is no data > > protocol recommended or defined. This mean that we have no idea when to > > sample for a bit, how long is a bit and how many bits before we can say > > new data is available. > > > > Christo > > > > Dr. Douglas Lyon wrote: > >> Hi All, > >> There has been a lot of discussion regarding RS485. > >> > >> Let me see if I can summarize this, please correct me if I am wrong; > >> I am deliberately ignoring connector and electrical issues, focusing, > >> instead, on protocol and software issues. Also, I have never used > >> RS485, and I don't know much about it. > >> > >> 1. Serial ports that claim RS232 are typically used in > >> the data link layer of the OSI model of networking. Basically, this > >> means that they work with a point-to-point protocol and are meant to > >> connect two devices. > >> > >> 2. Within the RS232 standard there are framing bits (start and stop > >> bits) and error control bits (parity). The flow control is xon-xoff or > >> DTR, CTS, RTS. Thats' it. > >> > >> 3. If you want more than that from RS232 (forward error correction, > >> ARQ, etc.) you do it in software, not in the RS232 standard. > >> > >> 4. RS485 is different from RS232 in that it is in the Network Layer of > >> the OSI model of networking. > >> > >> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > >> a factory). > >> RS-485 is similar to RS-422, but RS-422 allows just one driver with > >> multiple receivers whereas RS-485 supports multiple drivers and > >> receivers. > >> > >> 6. RS-485 is a serial bus with multiple nodes and thus must handle > >> network link layer protocols. By using high-impedance receivers, you > >> can have as many as 256 nodes. > >> > >> 7. The RS-485 can be implemented with RXTX in the core and a layer of > >> software on top to handle media access control (MAC sublayer). There > >> are also hardware converters. > >> http://www.rs485.com/pconverters.html for example. However, some of > >> these require software control. There is some support in the form of > >> the Rs485.java class, > >> in RXTX. > >> > >> 8. The RS-485 specification will add to the size of the JSR > >> > >> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > >> This version of the Java communications API contains support for > >> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > >> mentioned. > >> > >> 10. DO people want to add RS485 to a new JSR? > >> > >> Would it make sense for the RS-485 people to speak up now? > >> Please let me know if you think my summary is wrong. > >> > >> Thanks! > >> - Doug > >> > >> > >> > >> > >> > >> > >>> At 18:31 20/07/2006, Trent Jarvi wrote: > >>> > >>>> > PROJECT SCOPE: > >>>> > ------------- > >>>> > > >>>> > Also, we should think carefully about what the scope of > >>>> > this project would be. Should it be javax."comm" which > >>>> > handles both serial and parallel (is parallel going by the > >>>> > wayside). Should it be split into two project: > >>>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > >>>> > > >>>> > Should we differentiate between single-ended serial > >>>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > >>>> > quasi-multidrop and full multidrop busses such as > >>>> > EIA422, EIA432 and EIA485? If we really were to > >>>> > add I2C support to the API, we'd have to delve into > >>>> > the semantics more, because there could be some > >>>> > implicit decoding of the bus the API users would > >>>> > want to see. > >>>> > > >>>> > >>>> Hi Paul > >>>> > >>>> The way RXTX works, which is a fair representation of the people > >>>> using the API, is complete support for RIA232, minimal support for > >>>> IEEE1284. From what I understand, Sun was going along the same > >>>> lines. If we combined both projects, we would have half a parallel > >>>> port implementation. I see maybe 4 requests for features not in the > >>>> parallel support a year. > >>>> > >>>> The other protocols should not be limited by a JSR which is going to > >>>> be focused upon serial port interests. The IEA485 hacks in RXTX > >>>> along with I2C and Raw should _not_ be considered a strong basis for > >>>> extending the API to cover these protocols. If people want to do > >>>> real implementations, they should not face a 'standard' which wasnt > >>>> really focused upon their interests. I think we understand the > >>>> parallel port issues fairly well but have not implemented many > >>>> features and I don't know if we would. > >>>> > >>> I agree with all of this. API requirements for I2C, SPI, etc. are very > >>> different from those for RS232/485/422. Our embedded Java platform has > >>> APIs for all of these and more and they don't share a lot apart from > >>> the fact that they all use Input/OutputStreams (and in the case of > >>> SPI you still need to cater with the fact that every time you want to > >>> read you must also write to the device.) > >>> > >>> If I was to design javax.comm from scratch, I think I would focus on > >>> serial ports exclusively (== whatever the underlying OS represents as > >>> serial ports). Even parallel is a bit out of place IMHO, although I > >>> understand it needs to stay for backwards compatibility. > >>> > >>> > >>> > >>>> So a versatile API is favorable but I do not think we have the proper > >>>> community to represent much more than Serial. > >>>> > >>> Yes, I think the same. > >>> > >>> Guillermo > >>> -- > >>> Guillermo Rodriguez Garcia > >>> > >>> Snijder Micro Systems phone +31-493-351020 > >>> G. Rodriguez Garcia fax +31-493-351530 > >>> Visser 25 email guille at sms.nl > >>> NL5751 BL Deurne > >>> The Netherlands http://www.snijder.com > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> > >> > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Mark Himsley From berkland at spamcop.net Mon Jul 24 16:55:18 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 24 Jul 2006 18:55:18 -0400 Subject: [Rxtx] jcp and jsr In-Reply-To: <44C5083A.6090902@ergotech.com> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> <44C5083A.6090902@ergotech.com> Message-ID: <269e40090607241555g281c7f24s5577b86e35d27eab@mail.gmail.com> I'm sorry, I keep reading SPI as "Service Provider Interface" instead of "Serial Peripheral Interface". (See http://en.wikipedia.org/wiki/Serial_Peripheral_Interface.) What I thought was being suggested was a pluggable implementation like that found in javax.security. (The SPI there actually stands for "Security Provider Interface" not "Service Provider Interface" like I had thought.) I guess that might be a CPI (Comm Provider Interface) or PPI (Port Provider Interface.) At any rate what I would like to see is a JSR with (in order of priority) - compatible API for code written against current javax.comm 2.0 classes - ability to register or "force" a port by providing a name and implementation (not have to rely completely on the "auto-discovery") - nothing precluding the use of a portmapping in a given implementation - ability to register port implementations On 7/24/06, Jim Redman wrote: > > A thought for later since we haven't really reached this level of > detail, but since this type of approach seems likely... > > If a configuration file is mandatory, can we specify what the file is > called and what the format of the options are (mandatory?, and optional) > without limiting extensions. > > This just adds consistency across platforms/implementations. > > Jim > > Doug Berkland wrote: > > Gregg Wonderly wrote: > > > That there could be a low level port/device SPI > > > that could be put in place once, and then overtime > > > we could layer other APIs, including an updated > > > javax.comm which would make use of this SPI. > > > > I think there is great merit in this suggestion. I would like to see > > the ability to register a new "port" along with a custom handler in the > > Java client code before attempting to access the port. > > e.g . > > CommManager.getInstance().registerPortImpl("USB1:", new > > HidPortAdapter(/*vendorId=*/ "1234", /*deviceId=*/ "4321"); > > CommManager.getInstance().registerPortImpl("Ether1:", new > > InetPortAdapter(/*ipAndPort=*/ " 192.168.1.101:8088 > > "); > > > > It would allow other protocols that this group doesn't have depth in to > > be developed by someone who does on an "as needed" basis. > > > > Additionally, the value of this would be with some devices that > > implement basically the same protocol that was initially used over RS232 > > for a USB (via an HID) or Ethernet interface. There are a number of > > these in POS hardware. The existing JavaPOS driver written against > > JavaCOMM 2.0 could be reused by plugging in an HID or IP adapter before > > attempting to access the device. > > > > It might also be valuable to use something like an extended version of > > the portmapping file found in JavaCOMM 3.0. A configuration file could > > allow this definition to take place outside of any Java client code. > > Such a mapping file wouldn't even need to be part of the JSR API or > > reference implementation. It could be handled in a specific > > implementation. > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060724/02c50e6a/attachment-0337.html From tjarvi at qbang.org Mon Jul 24 18:44:54 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 24 Jul 2006 18:44:54 -0600 (MDT) Subject: [Rxtx] Serial Read/Write Details In-Reply-To: <44C508AC.7060103@yahoo.com.br> References: <44C508AC.7060103@yahoo.com.br> Message-ID: On Mon, 24 Jul 2006, mtnvega wrote: > Hello, > > I'm have being flirting with RXTX for a while since I'm working on a > college project where I will > need to communicate with a microcontroller using USART. > > Now is the time to start using it! But I have some doubts and I hope you > can help-me. > > I will need to both send and receive data from the serial port. First I > will need to send some command > bytes then wait for some data that will be returned from the > microcontroller. And I would like > to know which is the best way to do that. I'm mean, of course send and > receive data is the purpose > of the serial port and RXTX but I'm looking for some details since there > will be no package control > but just a fixed command format and confirmation messages from the > microcontroller side. > > I would like to know if I should open and close the port or if I can > just open it once. > I read that upon writing to output the input buffer are filled with the > same data, is it right? > If yes, isn't it a problem since I'm waiting for data back in a very > small time? > Hi Luiz Unless you want to use the port with a second application, just open the port once and close it when you exit the application. The input will not be filled with the data you write. The API has events to let you know when data is available and when your data has gone out the port. You can look in the contrib directory that comes with the source for crude examples of event notification. I think there is an example on the wiki too. I don't think you will have any problems. -- Trent Jarvi tjarvi at qbang.org From guille at sms.nl Tue Jul 25 00:26:12 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 08:26:12 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C50488.1040508@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> Message-ID: <7.0.1.0.0.20060725082124.036309e0@sms.nl> At 19:34 24/07/2006, Gregg Wonderly wrote: >Guillermo Rodriguez wrote: > > As an embedded Java vendor, SNIJDER Micro Systems certainly sees the > > value of standardized APIs to talk to different types of communication > > buses including SPI, I2C, 1-Wire, etc., for embedded applications. > > However we think this has nothing to do with javax.comm. > >I don't think this is only about javax.comm. Certainly that's >important. I'm >just wading into this conversation mainstream and trying to say: > >If you are going to do anything about "fixing" javax.comm to work on all >platforms, please, please, please start with a hardware port SPI >definition that >lets you get to serial ports, and then provide the existing javax.com API and >whatever new API you think is necessary (I don't have any really >issues with the >existing API directly). > >Then, there will be a place for others interesting in SPI, i2C, USB and other >things to get started with providing access to devices that are also >interesting >in Java applications, and directly, in embedded Java applications. I do agree that the best a hardware port SPI definition (where SPI = Service Provider Interface, not the SPI protocol) is a good thing to have to support serial ports layered over other transports. However these are still serial ports at the end. I still don't think the javax.comm API is well suited to "any" serial bus such as I2C, SPI, etc. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 00:41:46 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 08:41:46 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C5065F.3060802@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> Message-ID: <7.0.1.0.0.20060725082630.036d2d10@sms.nl> At 19:41 24/07/2006, Paul Klissner wrote: >Guillermo Rodriguez wrote: >>Quoting Paul Klissner : >> >>>>>None of this is of any particular relevance to the basic underlying >>>>>question: >>>>> >>>>>Should the next JSR attempt to address the multi-drop abilities of >>>RS-485? >>>>What I would suggest is to just add a new 'ioctlex'-like method >>>>to the SerialPort API: A method that you'd use to pass platform- >>>>or implementation-specific info to the underlying driver or OS >>>>to do things such as "enabling RS485 mode" or "disable FIFOs" or >>>>"poll the TSR register". >>>> >>>>No need to define any function codes. This is for stuff that is >>>>platform- or implementation-specific and as such cannot be easily >>>>abstracted anyway. >>>Detrimental to platform independence. >>Yes, it is. But as you go closer and closer to the hardware level some >>things are by nature platform-dependent, and sometimes just cannot be >>solved in a platform-independent way. In these cases, is it better to >>have no solution at all than having one that is less than perfect? >>Put it another way, would you prefer having people say "I just cannot >>do this in Java; I'll go somewhere else" rather than "I can do this >>in Java -- only not in a platform-independent way" ? > >If there isn't a reasonable way to abstract it out, then >why use Java? If an application can be 99% platform independent with small bits being not portable, why *not* use Java? I'd prefer to see people using Java to write non-portable applications than having them use C instead. I believe that Java should promote platform neutrality, but that does not necessarily mean precluding the use of anything that is NOT platform independent. And let's face it, if you are using javax.comm to talk to some serial device directly, then chances are you are already tied to some specific hardware anyway. Also, some people (myself included) think that Java can also be used as a systems programming language, not only for applications. For many embedded platforms this is certainly the case. In our platform we even write device drivers directly in Java. I would imagine the Sun SPOT team (www.sunspotworld.com) supports a similar view. If people needs to do non-portable stuff and wants to do it in Java I'd rather have them do it in Java than tell them to do it in C instead. >The whole idea is platform neutrality, otherwise, what is the >huge advantage of adopting a standardized Java API? I think >it is wrong to subvert the API. I think we have to arrive at >some sort of consensus about the scope of the API and do our >best to engineer a robust API in terms of that scope using >abstraction. > >There may be outliers, but the outliers probably aren't portable, >and probably would do just as well to not use java for that >particular application. The cases I have in mind is more like portable applications with very small bits of non portable code. I can imagine lots of portable applications that need access to RS485, specially in the industrial process control and factory automation fields. As I said in an earlier mail RS485 is half- duplex, but there is standard way to do RS485 direction control from software. Does it mean that the whole application should not be written in Java, only because some small bits of code related to RS485 direction control are not completely portable? > If this was a JSR, if we found some >compelling problem that kept cropping up the API could be >reved so as not to just orphan cases with legitimate requests. > >If someone really needs to do funky things with the hardware, >why wouldn't that be put in the native back end? But nobody said the functionality can't be implemented in the native back end. However you still need an application level API to enable/disable it. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 00:44:43 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 08:44:43 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <269e40090607241555g281c7f24s5577b86e35d27eab@mail.gmail.co m> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> <44C5083A.6090902@ergotech.com> <269e40090607241555g281c7f24s5577b86e35d27eab@mail.gmail.com> Message-ID: <7.0.1.0.0.20060725084431.036d0700@sms.nl> At 00:55 25/07/2006, Doug Berkland wrote: >I'm sorry, I keep reading SPI as "Service Provider Interface" >instead of "Serial Peripheral Interface". (See >http://en.wikipedia.org/wiki/Serial_Peripheral_Interface. >) > >What I thought was being suggested was a pluggable implementation >like that found in javax.security. (The SPI there actually stands >for "Security Provider Interface" not "Service Provider Interface" >like I had thought.) I guess that might be a CPI (Comm Provider >Interface) or PPI (Port Provider Interface.) > >At any rate what I would like to see is a JSR with (in order of priority) >- compatible API for code written against current javax.comm 2.0 classes >- ability to register or "force" a port by providing a name and >implementation (not have to rely completely on the "auto-discovery") >- nothing precluding the use of a portmapping in a given implementation >- ability to register port implementations That sounds very good to me. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From tjarvi at qbang.org Tue Jul 25 01:21:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 01:21:53 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725082124.036309e0@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> Message-ID: On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: > At 19:34 24/07/2006, Gregg Wonderly wrote: >> Guillermo Rodriguez wrote: >>> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the >>> value of standardized APIs to talk to different types of communication >>> buses including SPI, I2C, 1-Wire, etc., for embedded applications. >>> However we think this has nothing to do with javax.comm. >> >> I don't think this is only about javax.comm. Certainly that's >> important. I'm >> just wading into this conversation mainstream and trying to say: >> >> If you are going to do anything about "fixing" javax.comm to work on all >> platforms, please, please, please start with a hardware port SPI >> definition that >> lets you get to serial ports, and then provide the existing javax.com API and >> whatever new API you think is necessary (I don't have any really >> issues with the >> existing API directly). >> >> Then, there will be a place for others interesting in SPI, i2C, USB and other >> things to get started with providing access to devices that are also >> interesting >> in Java applications, and directly, in embedded Java applications. > > I do agree that the best a hardware port SPI definition (where SPI = Service > Provider Interface, not the SPI protocol) is a good thing to have to support > serial ports layered over other transports. However these are still serial > ports at the end. I still don't think the javax.comm API is well suited to > "any" serial bus such as I2C, SPI, etc. > Perhaps the javax.com namespace is just wrong. I think thats a larger issue we are not well prepared to answer. We do have a larger group participating so there is interest beyond our current solution. My concern is getting into blue sky efforts that never materialize. We have a very concrete solution that just needs a few modifications to make current java users happy. This solution is more or less supporting POSIX termios on all platforms including windows. This solution does not ask deep questions like is it USB or RS485 or IrDA. Smart kernel people worry about that. Thats what works. When the fun goes away and I'm fixing spam on slow mail-lists, thats what will continue to work. Thats what will be tested on hundreds of machines every six months. I don't want to remind people of JSR80 windows support but you should keep that in mind while getting too far from the crusty roman roads. I'd love to move off to the side in the namespace and leave javax.com for a great effort unifying the time space continuum to be announced at a later date. Beyond that, we would need serious commitment from people in the community to get more working. Both rxtx.org and Sun are about maxed out right now. -- Trent Jarvi tjarvi at qbang.org From martin at jopdesign.com Tue Jul 25 01:32:22 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 09:32:22 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> Message-ID: <005b01c6afbc$794fc060$0202a8c0@luna> >>> None of this is of any particular relevance to the basic underlying >>> question: >>> >>> Should the next JSR attempt to address the multi-drop abilities of RS-485? I would vote for a strong yes. >> >> What I would suggest is to just add a new 'ioctlex'-like method >> to the SerialPort API: A method that you'd use to pass platform- >> or implementation-specific info to the underlying driver or OS >> to do things such as "enabling RS485 mode" or "disable FIFOs" or >> "poll the TSR register". >> >> No need to define any function codes. This is for stuff that is >> platform- or implementation-specific and as such cannot be easily >> abstracted anyway. > > Detrimental to platform independence. We can model it platform independent with two methods: enterTransmit() and extiTransmit() to do whatever is necessary on the underlying platform to switch to RS485 transmit mode and back. Martin From guille at sms.nl Tue Jul 25 01:45:53 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 09:45:53 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <005b01c6afbc$794fc060$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> Message-ID: <7.0.1.0.0.20060725094317.0363b390@sms.nl> Hi Martin, At 09:32 25/07/2006, Martin Schoeberl wrote: > >>> None of this is of any particular relevance to the basic underlying > >>> question: > >>> > >>> Should the next JSR attempt to address the multi-drop abilities > of RS-485? > >I would vote for a strong yes. > > >> > >> What I would suggest is to just add a new 'ioctlex'-like method > >> to the SerialPort API: A method that you'd use to pass platform- > >> or implementation-specific info to the underlying driver or OS > >> to do things such as "enabling RS485 mode" or "disable FIFOs" or > >> "poll the TSR register". > >> > >> No need to define any function codes. This is for stuff that is > >> platform- or implementation-specific and as such cannot be easily > >> abstracted anyway. > > > > Detrimental to platform independence. > >We can model it platform independent with two methods: > >enterTransmit() and extiTransmit() to do whatever is necessary >on the underlying platform to switch to RS485 transmit mode and >back. Tempting as it is, I don't think this covers all cases. For example, in those cases where RS485 direction control must be done 100% in software, the software needs to have a way to flush (sync) software buffers, poll the hardware FIFOs and TSR (not THR), etc. Or, for example, for those UARTs that do automatic RS485 direction control with a configurable turnaround delay, how would you configure this turnaround delay from the application? Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 01:48:10 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 09:48:10 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> Message-ID: <7.0.1.0.0.20060725094602.036cec00@sms.nl> Hi Trent, At 09:21 25/07/2006, Trent Jarvi wrote: >On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: > > > At 19:34 24/07/2006, Gregg Wonderly wrote: > >> Guillermo Rodriguez wrote: > >>> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the > >>> value of standardized APIs to talk to different types of communication > >>> buses including SPI, I2C, 1-Wire, etc., for embedded applications. > >>> However we think this has nothing to do with javax.comm. > >> > >> I don't think this is only about javax.comm. Certainly that's > >> important. I'm > >> just wading into this conversation mainstream and trying to say: > >> > >> If you are going to do anything about "fixing" javax.comm to work on all > >> platforms, please, please, please start with a hardware port SPI > >> definition that > >> lets you get to serial ports, and then provide the existing > javax.com API and > >> whatever new API you think is necessary (I don't have any really > >> issues with the > >> existing API directly). > >> > >> Then, there will be a place for others interesting in SPI, i2C, > USB and other > >> things to get started with providing access to devices that are also > >> interesting > >> in Java applications, and directly, in embedded Java applications. > > > > I do agree that the best a hardware port SPI definition (where > SPI = Service > > Provider Interface, not the SPI protocol) is a good thing to have > to support > > serial ports layered over other transports. However these are still serial > > ports at the end. I still don't think the javax.comm API is well suited to > > "any" serial bus such as I2C, SPI, etc. > > > >Perhaps the javax.com namespace is just wrong. I think thats a larger >issue we are not well prepared to answer. We do have a larger group >participating so there is interest beyond our current solution. My concern was not about the name specifically, but about the idea that a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, IrDA, etc. Looking from a distance all of these may look similar but the fact is, they have little to do with each other (apart from being 'communication protocols' or 'buses') Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From Paul.Klissner at Sun.COM Tue Jul 25 01:51:26 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Tue, 25 Jul 2006 00:51:26 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725082630.036d2d10@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> Message-ID: <44C5CD7E.9030903@sun.com> Guillermo Rodriguez Garcia wrote: > At 19:41 24/07/2006, Paul Klissner wrote: >> Guillermo Rodriguez wrote: >>> Quoting Paul Klissner : >>> >>>>>> None of this is of any particular relevance to the basic underlying >>>>>> question: >>>>>> >>>>>> Should the next JSR attempt to address the multi-drop abilities of >>>> RS-485? >>>>> What I would suggest is to just add a new 'ioctlex'-like method >>>>> to the SerialPort API: A method that you'd use to pass platform- >>>>> or implementation-specific info to the underlying driver or OS >>>>> to do things such as "enabling RS485 mode" or "disable FIFOs" or >>>>> "poll the TSR register". >>>>> >>>>> No need to define any function codes. This is for stuff that is >>>>> platform- or implementation-specific and as such cannot be easily >>>>> abstracted anyway. >>>> Detrimental to platform independence. >>> Yes, it is. But as you go closer and closer to the hardware level some >>> things are by nature platform-dependent, and sometimes just cannot be >>> solved in a platform-independent way. In these cases, is it better to >>> have no solution at all than having one that is less than perfect? >>> Put it another way, would you prefer having people say "I just cannot >>> do this in Java; I'll go somewhere else" rather than "I can do this >>> in Java -- only not in a platform-independent way" ? >> If there isn't a reasonable way to abstract it out, then >> why use Java? > > If an application can be 99% platform independent with small bits > being not portable, why *not* use Java? I'd prefer to see people > using Java to write non-portable applications than having them > use C instead. > > I believe that Java should promote platform neutrality, but that > does not necessarily mean precluding the use of anything that is > NOT platform independent. And let's face it, if you are using > javax.comm to talk to some serial device directly, then chances > are you are already tied to some specific hardware anyway. > > Also, some people (myself included) think that Java can also be > used as a systems programming language, not only for applications. > For many embedded platforms this is certainly the case. In our > platform we even write device drivers directly in Java. I would > imagine the Sun SPOT team (www.sunspotworld.com) supports a > similar view. > > If people needs to do non-portable stuff and wants to do it in > Java I'd rather have them do it in Java than tell them to do it > in C instead. That sounds a bit evangelizing. I think C is perfectly viable for some jobs, and might even be preferable in some cases, for example in some cases where performance or space is a factor. I feel it isn't right to corrupt an API with hacks for the goal of enticing users to Java, even for all the 'right' reasons. >> If someone really needs to do funky things with the hardware, >> why wouldn't that be put in the native back end? > > But nobody said the functionality can't be implemented in the > native back end. However you still need an application level API > to enable/disable it. Sure, but the functions, if really along the lines of the defined standard, can be abstracted, rather than cheat with a general purpose hack-all ioctl-like interface that just begs to be abused, lending itself to a litany of non-portable applications. I maintain we should scope the project appropriately, then take our best shot at a reasonably complete set of abstract functions, and improve it if necessary over time (alpha and beta, release candidates? And then update the API in a backward-compatible way based on feedback after FCS if necessary), rather than add an everything-but-the-kitchen-sink escape clause method. A determined programmer facing a corner case can figure out a way to accomplish the goal in most cases. Even if the API doesn't provide an ioctl call, it is possible to create implementation classes that mak methods visible outsidethe scope of the API-defined methods. For example, if I am implementing class Foo in FooImpl.java, And Foo.java defines interface methods a(), b() and c(), FooImpl.java can also have public methods d(), e() and f(), which can be accessed from the application by casting a Foo object into a FooImpl object. This is one way to provide a back door without compromising the core API itself to do it. This puts the responsibility of breaking platform independence on the developers and not on the designers. Paul From tjarvi at qbang.org Tue Jul 25 02:57:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 02:57:28 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725094602.036cec00@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> Message-ID: On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: > Hi Trent, > > At 09:21 25/07/2006, Trent Jarvi wrote: >> On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: >> >>> At 19:34 24/07/2006, Gregg Wonderly wrote: >>>> Guillermo Rodriguez wrote: >>>>> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the >>>>> value of standardized APIs to talk to different types of communication >>>>> buses including SPI, I2C, 1-Wire, etc., for embedded applications. >>>>> However we think this has nothing to do with javax.comm. >>>> >>>> I don't think this is only about javax.comm. Certainly that's >>>> important. I'm >>>> just wading into this conversation mainstream and trying to say: >>>> >>>> If you are going to do anything about "fixing" javax.comm to work on all >>>> platforms, please, please, please start with a hardware port SPI >>>> definition that >>>> lets you get to serial ports, and then provide the existing >> javax.com API and >>>> whatever new API you think is necessary (I don't have any really >>>> issues with the >>>> existing API directly). >>>> >>>> Then, there will be a place for others interesting in SPI, i2C, >> USB and other >>>> things to get started with providing access to devices that are also >>>> interesting >>>> in Java applications, and directly, in embedded Java applications. >>> >>> I do agree that the best a hardware port SPI definition (where >> SPI = Service >>> Provider Interface, not the SPI protocol) is a good thing to have >> to support >>> serial ports layered over other transports. However these are still serial >>> ports at the end. I still don't think the javax.comm API is well suited to >>> "any" serial bus such as I2C, SPI, etc. >>> >> >> Perhaps the javax.com namespace is just wrong. I think thats a larger >> issue we are not well prepared to answer. We do have a larger group >> participating so there is interest beyond our current solution. > > My concern was not about the name specifically, but about the idea that > a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, > IrDA, etc. Looking from a distance all of these may look similar but > the fact is, they have little to do with each other (apart from being > 'communication protocols' or 'buses') > Hi Guillermo Interesting name. Fair enough. My thoughts are that if it can't be unified in the kernel we are out of our skulls trying to do it in user space. Hacks trying to do such will sure to be in open solaris or linux symposiums about why user space sucks. But there is a minimal bit that overlapps that is what most users want. If we limit the scope, it isnt that hard of a problem. By limiting the scope we also limit our deliverables. If you have an interest in a specific area it will probably not be enough. -- Trent Jarvi tjarvi at qbang.org From martin at jopdesign.com Tue Jul 25 03:25:38 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 11:25:38 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> Message-ID: <001901c6afcc$4bcf64f0$0c28a8c0@luna> >> >> >> >> What I would suggest is to just add a new 'ioctlex'-like method >> >> to the SerialPort API: A method that you'd use to pass platform- >> >> or implementation-specific info to the underlying driver or OS >> >> to do things such as "enabling RS485 mode" or "disable FIFOs" or >> >> "poll the TSR register". >> >> >> >> No need to define any function codes. This is for stuff that is >> >> platform- or implementation-specific and as such cannot be easily >> >> abstracted anyway. >> > >> > Detrimental to platform independence. >> >>We can model it platform independent with two methods: >> >>enterTransmit() and extiTransmit() to do whatever is necessary >>on the underlying platform to switch to RS485 transmit mode and >>back. > > Tempting as it is, I don't think this covers all cases. For example, > in those cases where RS485 direction control must be done 100% in > software, the software needs to have a way to flush (sync) software > buffers, poll the hardware FIFOs and TSR (not THR), etc. I just meant to hide those low-level issues you mention in the enter/exitTransmit modes. > > Or, for example, for those UARTs that do automatic RS485 direction > control with a configurable turnaround delay, how would you configure > this turnaround delay from the application? Mmh, perhaps in a similar way as you configure timeouts? Isn't this 'just' a timeout value? Martin From guille at sms.nl Tue Jul 25 04:05:29 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 12:05:29 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <001901c6afcc$4bcf64f0$0c28a8c0@luna> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> Message-ID: <7.0.1.0.0.20060725115736.03706a38@sms.nl> At 11:25 25/07/2006, Martin Schoeberl wrote: > >> >> > >> >> What I would suggest is to just add a new 'ioctlex'-like method > >> >> to the SerialPort API: A method that you'd use to pass platform- > >> >> or implementation-specific info to the underlying driver or OS > >> >> to do things such as "enabling RS485 mode" or "disable FIFOs" or > >> >> "poll the TSR register". > >> >> > >> >> No need to define any function codes. This is for stuff that is > >> >> platform- or implementation-specific and as such cannot be easily > >> >> abstracted anyway. > >> > > >> > Detrimental to platform independence. > >> > >>We can model it platform independent with two methods: > >> > >>enterTransmit() and extiTransmit() to do whatever is necessary > >>on the underlying platform to switch to RS485 transmit mode and > >>back. > > > > Tempting as it is, I don't think this covers all cases. For example, > > in those cases where RS485 direction control must be done 100% in > > software, the software needs to have a way to flush (sync) software > > buffers, poll the hardware FIFOs and TSR (not THR), etc. > >I just meant to hide those low-level issues you mention in the >enter/exitTransmit modes. If the system has dedicated RS485 hardware then the underlying kernel or device driver may know about it and all of the hassle can be conveniently encapsulated in some enter/exitTransmit methods -- but in this case you can also skip these and just have the driver enable transmit mode as long as it has data to transmit, and stay in receive mode otherwise. If the system has a UART that can be configured as RS232 or RS485 then you may need to tell the kernel or device driver to enter RS485 mode explicitly. Your approach may work there as well. If the system does not have dedicated RS485 hardware and you are using an external RS232-RS485 protocol converter (a very common case) then the driver and kernel probably don't know about that and you have to take care at the application level (javax.comm doesn't even need to know this converter exists), and in order to that you may need to do different things depending on the specific converter you're using. > > > > Or, for example, for those UARTs that do automatic RS485 direction > > control with a configurable turnaround delay, how would you configure > > this turnaround delay from the application? > >Mmh, perhaps in a similar way as you configure timeouts? >Isn't this 'just' a timeout value? Yes, but this is just a specific parameter that you can configure in a specific type of UART (an EXAR UART). Other UARTs might be different. The point I'm trying to make is that there are just too many parameters to have an API for each specific case. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 04:12:31 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 12:12:31 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C5CD7E.9030903@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> <44C5CD7E.9030903@sun.com> Message-ID: <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> At 09:51 25/07/2006, Paul Klissner wrote: >Guillermo Rodriguez Garcia wrote: > > At 19:41 24/07/2006, Paul Klissner wrote: > >> Guillermo Rodriguez wrote: > >>> Quoting Paul Klissner : > >>> > >>>>>> None of this is of any particular relevance to the basic underlying > >>>>>> question: > >>>>>> > >>>>>> Should the next JSR attempt to address the multi-drop abilities of > >>>> RS-485? > >>>>> What I would suggest is to just add a new 'ioctlex'-like method > >>>>> to the SerialPort API: A method that you'd use to pass platform- > >>>>> or implementation-specific info to the underlying driver or OS > >>>>> to do things such as "enabling RS485 mode" or "disable FIFOs" or > >>>>> "poll the TSR register". > >>>>> > >>>>> No need to define any function codes. This is for stuff that is > >>>>> platform- or implementation-specific and as such cannot be easily > >>>>> abstracted anyway. > >>>> Detrimental to platform independence. > >>> Yes, it is. But as you go closer and closer to the hardware level some > >>> things are by nature platform-dependent, and sometimes just cannot be > >>> solved in a platform-independent way. In these cases, is it better to > >>> have no solution at all than having one that is less than perfect? > >>> Put it another way, would you prefer having people say "I just cannot > >>> do this in Java; I'll go somewhere else" rather than "I can do this > >>> in Java -- only not in a platform-independent way" ? > >> If there isn't a reasonable way to abstract it out, then > >> why use Java? > > > > If an application can be 99% platform independent with small bits > > being not portable, why *not* use Java? I'd prefer to see people > > using Java to write non-portable applications than having them > > use C instead. > > > > I believe that Java should promote platform neutrality, but that > > does not necessarily mean precluding the use of anything that is > > NOT platform independent. And let's face it, if you are using > > javax.comm to talk to some serial device directly, then chances > > are you are already tied to some specific hardware anyway. > > > > Also, some people (myself included) think that Java can also be > > used as a systems programming language, not only for applications. > > For many embedded platforms this is certainly the case. In our > > platform we even write device drivers directly in Java. I would > > imagine the Sun SPOT team (www.sunspotworld.com) supports a > > similar view. > > > > If people needs to do non-portable stuff and wants to do it in > > Java I'd rather have them do it in Java than tell them to do it > > in C instead. > >That sounds a bit evangelizing. Could be, but then what's wrong with that? As I said there is people that thinks that Java can be perfectly adequate for system level programming -- especially for embedded platforms. I guess the whole issue is whether it is better to have no solution at all for a specific problem than a solution that is not perfect (in this context a "perfect" solution is one that is portable and platform-independent). I think a solution that is not perfect is better than no solution. If I understand correctly you say that you prefer to have no Java solution (and have people use C) rather than one that is not portable. >I think C is perfectly viable >for some jobs, and might even be preferable in some cases, for example >in some cases where performance or space is a factor. I feel it isn't >right to corrupt an API with hacks for the goal of enticing users >to Java, even for all the 'right' reasons. > > >> If someone really needs to do funky things with the hardware, > >> why wouldn't that be put in the native back end? > > > > But nobody said the functionality can't be implemented in the > > native back end. However you still need an application level API > > to enable/disable it. > >Sure, but the functions, if really along the lines of the defined >standard, can be abstracted, rather than cheat with a general >purpose hack-all ioctl-like interface that just begs to be abused, >lending itself to a litany of non-portable applications. Well, I didn't specifically say there's no way to abstract these functions. I only said that it is not easy, and that I don't know of any reasonable way to do it. But if others can find a way, that is fine of course. >I maintain we should scope the project appropriately, then take >our best shot at a reasonably complete set of abstract functions, >and improve it if necessary over time (alpha and beta, release >candidates? And then update the API in a backward-compatible way >based on feedback after FCS if necessary), rather than add an >everything-but-the-kitchen-sink escape clause method. > >A determined programmer facing a corner case can figure out a way >to accomplish the goal in most cases. Even if the API doesn't provide >an ioctl call, it is possible to create implementation classes that >mak methods visible outsidethe scope of the API-defined methods. > >For example, if I am implementing class Foo in FooImpl.java, >And Foo.java defines interface methods a(), b() and c(), >FooImpl.java can also have public methods d(), e() and f(), which can >be accessed from the application by casting a Foo object into >a FooImpl object. This is one way to provide a back door without >compromising the core API itself to do it. This puts the >responsibility of breaking platform independence on the developers >and not on the designers. Yes, that may be a good way to do it. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 04:21:31 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 12:21:31 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> Message-ID: <7.0.1.0.0.20060725121958.03714668@sms.nl> Hi Trent, At 10:57 25/07/2006, Trent Jarvi wrote: > >> Perhaps the javax.com namespace is just wrong. I think thats a larger > >> issue we are not well prepared to answer. We do have a larger group > >> participating so there is interest beyond our current solution. > > > > My concern was not about the name specifically, but about the idea that > > a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, > > IrDA, etc. Looking from a distance all of these may look similar but > > the fact is, they have little to do with each other (apart from being > > 'communication protocols' or 'buses') > > > >Hi Guillermo > >Interesting name. > >Fair enough. My thoughts are that if it can't be unified in the kernel we >are out of our skulls trying to do it in user space. Hacks trying to do >such will sure to be in open solaris or linux symposiums about why user >space sucks. > >But there is a minimal bit that overlapps that is what most users want. >If we limit the scope, it isnt that hard of a problem. By limiting the >scope we also limit our deliverables. If you have an interest in a >specific area it will probably not be enough. Yes, you are right. But isn't this 'minimal bit that overlaps' what we have already? (basically support for UART-based serial ports plus minimal support for parallel ports) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From lyon at docjava.com Tue Jul 25 05:44:43 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 25 Jul 2006 07:44:43 -0400 Subject: [Rxtx] 7 RS485 questions... In-Reply-To: <7.0.1.0.0.20060725115736.03706a38@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: Hi All, 1. Does anyone have a sense for how much larger the JSR would be if it embraced a multi-drop protocol, like RS485? 2. Do we address collision detection and addressing in RS485? 3. How would collision detection and addressing impact the size of the specification? 4. Would JSR80 (and, perhaps a RS485-USB converter) be the more appropriate place for RS485 support? 5. Is RS485 Transmission controlled by RTS, and the TxD line? 6. How tight is the windows timing on control of the RTS line? 7. Does an RTS controlled RS485 converter work well at high baud rates under windows? Thanks! - Doug From naranjo.manuel at gmail.com Tue Jul 25 06:29:45 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Tue, 25 Jul 2006 09:29:45 -0300 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725094602.036cec00@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> Message-ID: <44C60EB9.5000803@gmail.com> Guillermo Rodriguez Garcia escribi?: > My concern was not about the name specifically, but about the idea that > a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, > IrDA, etc. Looking from a distance all of these may look similar but > the fact is, they have little to do with each other (apart from being > 'communication protocols' or 'buses') > I think Guillermo is right, all ports has in common that they are buses. A stupid idea but why don't declarate the package javax.bus and make javax.comm a dedicated namespace to rs232 and parallell to mantain backward compatibility, obviously the classes at javax.comm should extend classes from javax.bus. Regards, Manuel From j.a.horsmeier at wanadoo.nl Tue Jul 25 07:00:17 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Tue, 25 Jul 2006 15:00:17 +0200 Subject: [Rxtx] 7 RS485 questions... In-Reply-To: Message-ID: <05a701c6afea$47002e00$0a01a8c0@CALVIN> Douglas Lyon wrote: > 1. Does anyone have a sense for how much larger the JSR would > be if it embraced a multi-drop protocol, like RS485? The RS485 multidrop capability all resides on top of the communication layer, i.e. all transmitters but one are disabled (all devices are just listening). When the message has been sent at most one device answers (see 2) > 2. Do we address collision detection and addressing in RS485? Addressing a device is also implemented on top of the communication layer. If/when two devices happen to have the same address it would be disastrous. An address is defined by the protocol, e.g. modbus allows for 250 or so different addresses but another protocol might allow for 2^32 different devices hooked up on one two wire cable. > 3. How would collision detection and addressing impact the size of > the specification? IMHO it's none of rxtx's business, it's a configuration error on the devices if that happens. > 4. Would JSR80 (and, perhaps a RS485-USB converter) be the > more appropriate place for RS485 support? Don't know. > 5. Is RS485 Transmission controlled by RTS, and the TxD line? Two wire RS485 doesn't have a RTS line. It's all in the timing. The half duplex protocol is extremely simple: one master sends, all devices listen, after that at most one device enables its transmitter and sends something back. > 6. How tight is the windows timing on control of the RTS line? Before a device enables its transmitter it should wait a bit because of cable lengths and the other device that must *disable* its transmitter. It's all up to the devices and rxtx can do nothing about it. > 7. Does an RTS controlled RS485 converter work well at high baud > rates under windows? Baud rates aren't the problem; cable lengths are the problem, sensitivity for distortion are the problem. The wait time between en/disabling transmitters can be configured in the devices and can be software controlled on the pc. kind regards, Jos From tjarvi at qbang.org Tue Jul 25 07:08:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 07:08:53 -0600 (MDT) Subject: [Rxtx] 7 RS485 questions... In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: > 5. Is RS485 Transmission controlled by RTS, and the TxD line? This is done when using EIA232 to drive RS485 with no adaptor. This is the RS485 hack that is in RXTX 2.1 that never went anyplace. I discovered no typical kernel will openly support this line of thought. It is not maintainable. There are hardware solutions. Off the top of my head it required < 10 ms responses and typical kernels + java do 10 ms responses. Realtime kernels or special kernel drivers are required. It is possible but not supportable. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Tue Jul 25 07:46:52 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 08:46:52 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <005b01c6afbc$794fc060$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> Message-ID: <44C620CC.6090901@cox.net> Martin Schoeberl wrote: > We can model it platform independent with two methods: > > enterTransmit() and extiTransmit() to do whatever is necessary > on the underlying platform to switch to RS485 transmit mode and > back. Or, do what is typically done, and use a single write operation as the indication of a 'packet' that will let the underlying RS-485/422 driver assert the appropriate signalling. Gregg Wonderly From guille at sms.nl Tue Jul 25 07:48:04 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 15:48:04 +0200 Subject: [Rxtx] 7 RS485 questions... In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: <7.0.1.0.0.20060725154329.036deb18@sms.nl> Hi Doug, Some answers below. At 13:44 25/07/2006, Dr. Douglas Lyon wrote: >Hi All, > >1. Does anyone have a sense for how much larger the JSR would be >if it embraced a multi-drop protocol, like RS485? As I've said in other mails RS485 is in essence just a UART-based serial port interface just like RS232. The only functional difference is that it is multi-drop and half-duplex so there must be a way for nodes to switch between transmit and receive modes but then the RS485 standard does not tell you when or how you should do that -- this depends on the upper layer protocols (for example Modbus) >2. Do we address collision detection and addressing in RS485? Collision detection and addressing are not defined by the RS485 standard. Upper layer protocols such as Modbus take care of that. >3. How would collision detection and addressing impact the size of >the specification? See above. >4. Would JSR80 (and, perhaps a RS485-USB converter) be the more appropriate >place for RS485 support? I don't think so. As I said RS485 is just a serial port like RS232 is. >5. Is RS485 Transmission controlled by RTS, and the TxD line? Some RS232-RS485 protocol converters use the RTS line as a control signal to switch between transmit and receive modes. Others use DTR. Others do not use any of them. >6. How tight is the windows timing on control of the RTS line? Depends on the upper layer protocols, e.g. Modbus. Not defined by RS485. >7. Does an RTS controlled RS485 converter work well at high baud >rates under windows? Depends on how tight the timing is. For some applications it may work well but for many probably won't. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 09:22:09 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Tue, 25 Jul 2006 17:22:09 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C620CC.6090901@cox.net> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> Message-ID: <1153840929.44c6372186f67@webmail.eatserver.nl> Hi Gregg, Quoting Gregg Wonderly : > Martin Schoeberl wrote: > > We can model it platform independent with two methods: > > > > enterTransmit() and extiTransmit() to do whatever is necessary > > on the underlying platform to switch to RS485 transmit mode and > > back. > > Or, do what is typically done, and use a single write operation as the > indication of a 'packet' that will let the underlying RS-485/422 driver > assert > the appropriate signalling. The problem with this is that there is no guarantee that a single call to the write method of the OutputStream associated with a javax.comm SerialPort will translate to a single write to the underlying device driver -- this depends on the javax.comm implementation. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From Paul.Klissner at Sun.COM Tue Jul 25 09:35:19 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Tue, 25 Jul 2006 08:35:19 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C60EB9.5000803@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> <44C60EB9.5000803@gmail.com> Message-ID: <44C63A37.8080406@sun.com> Manuel Francisco Naranjo wrote: > Guillermo Rodriguez Garcia escribi?: >> My concern was not about the name specifically, but about the idea that >> a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, >> IrDA, etc. Looking from a distance all of these may look similar but >> the fact is, they have little to do with each other (apart from being >> 'communication protocols' or 'buses') >> > I think Guillermo is right, all ports has in common that they are buses. > A stupid idea but why don't declarate the package javax.bus and make > javax.comm a dedicated namespace to rs232 and parallell to mantain > backward compatibility, obviously the classes at javax.comm should > extend classes from javax.bus. I like the initial sound of that idea too and was starting to think along those lines myself. But what would be the points of commonality to extend? Device mapping, ownership? Read, write, type, status? Too late for javax.usb (JSR80) very complex Bus and for the most part cast in stone. And 'bus' has such a wide scope. Also that would imply two downloads to install any given bus support, which might not be the end of the world. And maybe two JSRs? Paul From martin at jopdesign.com Tue Jul 25 09:37:12 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 17:37:12 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> Message-ID: <00c801c6b000$33a68f00$0c28a8c0@luna> >> Martin Schoeberl wrote: >> > We can model it platform independent with two methods: >> > >> > enterTransmit() and extiTransmit() to do whatever is necessary >> > on the underlying platform to switch to RS485 transmit mode and >> > back. >> >> Or, do what is typically done, and use a single write operation as the >> indication of a 'packet' that will let the underlying RS-485/422 driver >> assert >> the appropriate signalling. > > The problem with this is that there is no guarantee that a single call > to the write method of the OutputStream associated with a javax.comm > SerialPort will translate to a single write to the underlying device > driver -- this depends on the javax.comm implementation. > I completely agree - it's still a stream and not a packet. This is similar to a single write to a TCP/IP socket. There is no guarantee that you get this data as a single packet/single read on the other side. However, I've seen a lot of programs assuming that this happens ;-) Martin From gergg at cox.net Tue Jul 25 10:15:41 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 11:15:41 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725082124.036309e0@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> Message-ID: <44C643AD.6020604@cox.net> Guillermo Rodriguez Garcia wrote: > At 19:34 24/07/2006, Gregg Wonderly wrote: >>Then, there will be a place for others interesting in SPI, i2C, USB and other >>things to get started with providing access to devices that are also >>interesting >>in Java applications, and directly, in embedded Java applications. > > I do agree that the best a hardware port SPI definition (where SPI = Service > Provider Interface, not the SPI protocol) is a good thing to have to support > serial ports layered over other transports. However these are still serial > ports at the end. I still don't think the javax.comm API is well suited to > "any" serial bus such as I2C, SPI, etc. Yes, absolutely these other wire protocols are different. As I tried to say before, I think that the javax.comm API works fine for my needs. I think that we need to keep it around, no matter what else happens. So, for me, there are a few choices. 1. Create a new JSR to formalize the existing API and include some hardwired JNI code to provide port enumeration and access. 2. Create a new JSR to create a port abstraction SPI to allow JVM providers to enumerate all kinds of port/circuit based hardware to the JVM. Create an implementation of the existing javax.comm API that uses this SPI. 3. Just implement some JNI and Java libraries post them on sourceforge/java.net and let people have at them. For 1 and 2, you'll have to get the JCP to approve that the JSR is worth making a standard. Option 3 doesn't really solve a problem as much as it creates a new way to deal with an existing problem. I think 2 is the most desireable way to go. It really will open the door for more access to hardware from Java! Gregg Wonderly From joachim at buechse.de Tue Jul 25 10:17:07 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 25 Jul 2006 18:17:07 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <00c801c6b000$33a68f00$0c28a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: Just trigger writing on flush(). It is perfectly legal for an Outputstream implementation to do do nothing until flush is called and the documentation of OutputStream.flush reads: "Flushes this output stream and forces any buffered output bytes to be written out. The general contract of flush is that calling it is an indication that, if any bytes previously written have been buffered by the implementation of the output stream, such bytes should immediately be written to their intended destination." As RS485 is a "dont speak up unless requested" protocol, a mandatory flush after write seems like the way to go to me No client can prevent another client from writing, so there is no point in keeping the output-drivers enabled after all data currently buffered has been written. So flush() should trigger "enterTransmit, writePacket[s], exitTransmit". If the service provider (ie concrete implementation of the flush method) decides that the write is inapropriate at the moment (ie because of a higher level arbitration protocol that might be implemented by the service provider) it will simply block the flush or throw an IOException (preferably after some sort of timeout). Regards, Joachim PS: It is great to see all the motivation that is brought forward on this list regarding the future. It would be great if only 10% of that motivation could be transformed into a cleanup and extension of the existing code. The current code access model seems rather inappropriate for the prototyping of the ideas beeing presented. Trent can we get a "contributions" branch with "free" access. On 25.07.2006, at 17:37, Martin Schoeberl wrote: >>> Martin Schoeberl wrote: >>>> We can model it platform independent with two methods: >>>> >>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>> on the underlying platform to switch to RS485 transmit mode and >>>> back. >>> >>> Or, do what is typically done, and use a single write operation >>> as the >>> indication of a 'packet' that will let the underlying RS-485/422 >>> driver >>> assert >>> the appropriate signalling. >> >> The problem with this is that there is no guarantee that a single >> call >> to the write method of the OutputStream associated with a javax.comm >> SerialPort will translate to a single write to the underlying device >> driver -- this depends on the javax.comm implementation. >> > I completely agree - it's still a stream and not a packet. > > This is similar to a single write to a TCP/IP socket. There > is no guarantee that you get this data as a single packet/single > read on the other side. However, I've seen a lot of programs > assuming that this happens ;-) > > Martin > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Tue Jul 25 10:34:59 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Tue, 25 Jul 2006 18:34:59 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <1153845299.44c64833920bd@webmail.eatserver.nl> Hi Joachim, That is a very nice approach which I think would work well as far as the underlying device driver knows about RS485. However it still does not solve the problem with external protocol converters where the device driver only knows about regular UARTs and RTS or DTR must be used to toggle direction of the converter. Guillermo Quoting Joachim Buechse : > Just trigger writing on flush(). It is perfectly legal for an > Outputstream implementation to do do nothing until flush is called > and the documentation of OutputStream.flush reads: > > "Flushes this output stream and forces any buffered output bytes to > be written out. The general contract of flush is that calling it is > an indication that, if any bytes previously written have been > buffered by the implementation of the output stream, such bytes > should immediately be written to their intended destination." > > As RS485 is a "dont speak up unless requested" protocol, a mandatory > flush after write seems like the way to go to me > > No client can prevent another client from writing, so there is no > point in keeping the output-drivers enabled after all data currently > buffered has been written. So flush() should trigger "enterTransmit, > writePacket[s], exitTransmit". If the service provider (ie concrete > implementation of the flush method) decides that the write is > inapropriate at the moment (ie because of a higher level arbitration > protocol that might be implemented by the service provider) it will > simply block the flush or throw an IOException (preferably after some > sort of timeout). > > Regards, > Joachim > > PS: It is great to see all the motivation that is brought forward on > this list regarding the future. It would be great if only 10% of that > motivation could be transformed into a cleanup and extension of the > existing code. The current code access model seems rather > inappropriate for the prototyping of the ideas beeing presented. > Trent can we get a "contributions" branch with "free" access. > > > On 25.07.2006, at 17:37, Martin Schoeberl wrote: > > >>> Martin Schoeberl wrote: > >>>> We can model it platform independent with two methods: > >>>> > >>>> enterTransmit() and extiTransmit() to do whatever is necessary > >>>> on the underlying platform to switch to RS485 transmit mode and > >>>> back. > >>> > >>> Or, do what is typically done, and use a single write operation > >>> as the > >>> indication of a 'packet' that will let the underlying RS-485/422 > >>> driver > >>> assert > >>> the appropriate signalling. > >> > >> The problem with this is that there is no guarantee that a single > >> call > >> to the write method of the OutputStream associated with a javax.comm > >> SerialPort will translate to a single write to the underlying device > >> driver -- this depends on the javax.comm implementation. > >> > > I completely agree - it's still a stream and not a packet. > > > > This is similar to a single write to a TCP/IP socket. There > > is no guarantee that you get this data as a single packet/single > > read on the other side. However, I've seen a lot of programs > > assuming that this happens ;-) > > > > Martin > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- http://www.snijder.com/ SNIJDER Micro Systems From guille at sms.nl Tue Jul 25 10:44:56 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Tue, 25 Jul 2006 18:44:56 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C643AD.6020604@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <44C643AD.6020604@cox.net> Message-ID: <1153845896.44c64a8890968@webmail.eatserver.nl> Hi Gregg, Quoting Gregg Wonderly : > Guillermo Rodriguez Garcia wrote: > > At 19:34 24/07/2006, Gregg Wonderly wrote: > >>Then, there will be a place for others interesting in SPI, i2C, USB and > other > >>things to get started with providing access to devices that are also > >>interesting > >>in Java applications, and directly, in embedded Java applications. > > > > I do agree that the best a hardware port SPI definition (where SPI = > Service > > Provider Interface, not the SPI protocol) is a good thing to have to > support > > serial ports layered over other transports. However these are still serial > > ports at the end. I still don't think the javax.comm API is well suited to > > "any" serial bus such as I2C, SPI, etc. > > Yes, absolutely these other wire protocols are different. As I tried to say > > before, I think that the javax.comm API works fine for my needs. I think > that > we need to keep it around, no matter what else happens. So, for me, there > are a > few choices. > > 1. Create a new JSR to formalize the existing API and include some hardwired > JNI > code to provide port enumeration and access. > > 2. Create a new JSR to create a port abstraction SPI to allow JVM providers > to > enumerate all kinds of port/circuit based hardware to the JVM. Create an > implementation of the existing javax.comm API that uses this SPI. As an embedded Java vendor we work very close to the hardware level and have to deal daily with dozens of different types of ports and communication buses and protocols. Based on our experience I think that a SPI for "all kinds of port/circuit based hardware" is just too generic and not really practical. I think having a Service Provider Interface within javax.comm so that custom serial port implementations can be plugged in is a very good idea. However I don't think it is convenient to have it as a separate JSR and then with such a broad scope. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From joachim at buechse.de Tue Jul 25 10:56:12 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 25 Jul 2006 18:56:12 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <1153845299.44c64833920bd@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> <1153845299.44c64833920bd@webmail.eatserver.nl> Message-ID: In this case you need to configure your port with a different device driver. You may optionally take an existing port, wrap it up in a "wrapping device driver" implemented in Java and add it to the list of ports as a new port... In any case the core application should not care. On 25.07.2006, at 18:34, Guillermo Rodriguez wrote: > Hi Joachim, > > That is a very nice approach which I think would work well as far > as the underlying device driver knows about RS485. > > However it still does not solve the problem with external protocol > converters where the device driver only knows about regular UARTs > and RTS or DTR must be used to toggle direction of the converter. > > Guillermo > > Quoting Joachim Buechse : > >> Just trigger writing on flush(). It is perfectly legal for an >> Outputstream implementation to do do nothing until flush is called >> and the documentation of OutputStream.flush reads: >> >> "Flushes this output stream and forces any buffered output bytes to >> be written out. The general contract of flush is that calling it is >> an indication that, if any bytes previously written have been >> buffered by the implementation of the output stream, such bytes >> should immediately be written to their intended destination." >> >> As RS485 is a "dont speak up unless requested" protocol, a mandatory >> flush after write seems like the way to go to me >> >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). >> >> Regards, >> Joachim >> >> PS: It is great to see all the motivation that is brought forward on >> this list regarding the future. It would be great if only 10% of that >> motivation could be transformed into a cleanup and extension of the >> existing code. The current code access model seems rather >> inappropriate for the prototyping of the ideas beeing presented. >> Trent can we get a "contributions" branch with "free" access. >> >> >> On 25.07.2006, at 17:37, Martin Schoeberl wrote: >> >>>>> Martin Schoeberl wrote: >>>>>> We can model it platform independent with two methods: >>>>>> >>>>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>>>> on the underlying platform to switch to RS485 transmit mode and >>>>>> back. >>>>> >>>>> Or, do what is typically done, and use a single write operation >>>>> as the >>>>> indication of a 'packet' that will let the underlying RS-485/422 >>>>> driver >>>>> assert >>>>> the appropriate signalling. >>>> >>>> The problem with this is that there is no guarantee that a single >>>> call >>>> to the write method of the OutputStream associated with a >>>> javax.comm >>>> SerialPort will translate to a single write to the underlying >>>> device >>>> driver -- this depends on the javax.comm implementation. >>>> >>> I completely agree - it's still a stream and not a packet. >>> >>> This is similar to a single write to a TCP/IP socket. There >>> is no guarantee that you get this data as a single packet/single >>> read on the other side. However, I've seen a lot of programs >>> assuming that this happens ;-) >>> >>> Martin >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > > -- > http://www.snijder.com/ > SNIJDER Micro Systems > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From martin at jopdesign.com Tue Jul 25 11:13:10 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 19:13:10 +0200 Subject: [Rxtx] JSR Direction; packetizing writes References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com><005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net><1153840929.44c6372186f67@webmail.eatserver.nl><00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <000f01c6b00d$9bcc51c0$0202a8c0@luna> > No client can prevent another client from writing, so there is no > point in keeping the output-drivers enabled after all data currently > buffered has been written. So flush() should trigger "enterTransmit, > writePacket[s], exitTransmit". If the service provider (ie concrete > implementation of the flush method) decides that the write is > inapropriate at the moment (ie because of a higher level arbitration > protocol that might be implemented by the service provider) it will > simply block the flush or throw an IOException (preferably after some > sort of timeout). Not only flush() would mean enterTransmit(). With your idea each write should enable the driver, but only flush() can disable the driver after the last byte is written. RS485 is a beast. E.g. some driver chips need a few us (100us for a Maxim 1480B!) from output enable till output low/high. On a different application we had to wait a little bit before disabling the output driver to have a clear '1' on the bus as it took too long for the termination resistors to force the bus to 1. I can imagine that this is not really funny with general RS232/RS485 converters. Martin From joachim at buechse.de Tue Jul 25 11:42:18 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 25 Jul 2006 19:42:18 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <000f01c6b00d$9bcc51c0$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com><005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net><1153840929.44c6372186f67@webmail.eatserver.nl><00c801c6b000$33a68f00$0c28a8c0@luna> <000f01c6b00d$9bcc51c0$0202a8c0@luna> Message-ID: Simple answer: NO. You can not control the timing of the Java VM (especially not on ME) and hence you do not want to enable the outputs before you have all data collected. The timings you mention are all in the implementation space of the device driver. The core application should not care, neither should the javax.comm api in my opinion. Should I happen to be the pour soul that tries to implement an RS485 device driver reference implementation I will try to remember your email and add appropriate properties. Regards, Joachim On 25.07.2006, at 19:13, Martin Schoeberl wrote: >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). > > Not only flush() would mean enterTransmit(). With your idea each > write should enable the driver, but only flush() can disable > the driver after the last byte is written. > > RS485 is a beast. E.g. some driver chips need a few us (100us > for a Maxim 1480B!) from output enable till output low/high. > > On a different application we had to wait a little bit before > disabling the output driver to have a clear '1' on the bus as it took > too long for the termination resistors to force the bus to 1. > > I can imagine that this is not really funny with general > RS232/RS485 converters. > > Martin > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Tue Jul 25 12:50:20 2006 From: jredman at ergotech.com (Jim Redman) Date: Tue, 25 Jul 2006 12:50:20 -0600 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <44C667EC.2070602@ergotech.com> The horror! This would be terribly inefficient. Especially in serial protocols you need to start getting bits on the wire as soon as possible. It could also have some timeout implications. Jim Joachim Buechse wrote: > Just trigger writing on flush(). It is perfectly legal for an > Outputstream implementation to do do nothing until flush is called > and the documentation of OutputStream.flush reads: > > "Flushes this output stream and forces any buffered output bytes to > be written out. The general contract of flush is that calling it is > an indication that, if any bytes previously written have been > buffered by the implementation of the output stream, such bytes > should immediately be written to their intended destination." > > As RS485 is a "dont speak up unless requested" protocol, a mandatory > flush after write seems like the way to go to me > > No client can prevent another client from writing, so there is no > point in keeping the output-drivers enabled after all data currently > buffered has been written. So flush() should trigger "enterTransmit, > writePacket[s], exitTransmit". If the service provider (ie concrete > implementation of the flush method) decides that the write is > inapropriate at the moment (ie because of a higher level arbitration > protocol that might be implemented by the service provider) it will > simply block the flush or throw an IOException (preferably after some > sort of timeout). > > Regards, > Joachim > > PS: It is great to see all the motivation that is brought forward on > this list regarding the future. It would be great if only 10% of that > motivation could be transformed into a cleanup and extension of the > existing code. The current code access model seems rather > inappropriate for the prototyping of the ideas beeing presented. > Trent can we get a "contributions" branch with "free" access. > > > On 25.07.2006, at 17:37, Martin Schoeberl wrote: > >>>> Martin Schoeberl wrote: >>>>> We can model it platform independent with two methods: >>>>> >>>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>>> on the underlying platform to switch to RS485 transmit mode and >>>>> back. >>>> Or, do what is typically done, and use a single write operation >>>> as the >>>> indication of a 'packet' that will let the underlying RS-485/422 >>>> driver >>>> assert >>>> the appropriate signalling. >>> The problem with this is that there is no guarantee that a single >>> call >>> to the write method of the OutputStream associated with a javax.comm >>> SerialPort will translate to a single write to the underlying device >>> driver -- this depends on the javax.comm implementation. >>> >> I completely agree - it's still a stream and not a packet. >> >> This is similar to a single write to a TCP/IP socket. There >> is no guarantee that you get this data as a single packet/single >> read on the other side. However, I've seen a lot of programs >> assuming that this happens ;-) >> >> Martin >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From jredman at ergotech.com Tue Jul 25 12:53:02 2006 From: jredman at ergotech.com (Jim Redman) Date: Tue, 25 Jul 2006 12:53:02 -0600 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <000f01c6b00d$9bcc51c0$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com><005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net><1153840929.44c6372186f67@webmail.eatserver.nl><00c801c6b000$33a68f00$0c28a8c0@luna> <000f01c6b00d$9bcc51c0$0202a8c0@luna> Message-ID: <44C6688E.8040202@ergotech.com> Since we now seem to have entered a discussion of how to switch receive/transmit on 485 lines, I can tell you from experience that you cannot reliably do this from Java. Java just is not fast enough. I spend some time trying to get this to work with RXTX and it would work _most_ of the time, but you need to be able to guarantee ms level response which you can't do in any system that doesn't have real-time capabilities. Jim Martin Schoeberl wrote: >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). > > Not only flush() would mean enterTransmit(). With your idea each > write should enable the driver, but only flush() can disable > the driver after the last byte is written. > > RS485 is a beast. E.g. some driver chips need a few us (100us > for a Maxim 1480B!) from output enable till output low/high. > > On a different application we had to wait a little bit before > disabling the output driver to have a clear '1' on the bus as it took > too long for the termination resistors to force the bus to 1. > > I can imagine that this is not really funny with general > RS232/RS485 converters. > > Martin > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Tue Jul 25 13:37:14 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 14:37:14 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725115736.03706a38@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: <44C672EA.1080604@cox.net> Guillermo Rodriguez Garcia wrote: > At 11:25 25/07/2006, Martin Schoeberl wrote: >>Mmh, perhaps in a similar way as you configure timeouts? >>Isn't this 'just' a timeout value? > > Yes, but this is just a specific parameter that you can configure in a > specific type of UART (an EXAR UART). Other UARTs might be different. The > point I'm trying to make is that there are just too many parameters to > have an API for each specific case. In my earlier example/proposal, I included the ability for attributes of a port to be expressed as a collection of enumeration values for standard things. That would be fine for simple things like Input, Output, Sync, Async etc. When there are specific attributes of specific hardware, the vendor is going to have to provide a way to configure those attributes. One of the primary mechanisms in Java to do this is the JavaBean pattern that can be manifested in a Map type object when an API needs to preexist. So, we can provide an mechanism for propagating random attributes using a Map argument to a method such as public void setConfig( Map params ) throws IOException; public Map getConfig() throws IOException; Then, there is a conduit in and out of the driver that the user can use without needing more standards/spec'd code/API. This isn't much different than an ioctl(2) like mechanism, but it feels more Java like. A URL like mechanism, such as that which JDBC drivers use, could also be attractive. I've also wanted to replace java.net with the J2ME connection based mechanism as well. We might consider looking at the J2ME connector architecture to see if there is any gain in using some of that experience. Gregg Wonderly From gergg at cox.net Tue Jul 25 13:38:42 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 14:38:42 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> <44C5CD7E.9030903@sun.com> <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> Message-ID: <44C67342.9020402@cox.net> Guillermo Rodriguez Garcia wrote: > At 09:51 25/07/2006, Paul Klissner wrote: >>For example, if I am implementing class Foo in FooImpl.java, >>And Foo.java defines interface methods a(), b() and c(), >>FooImpl.java can also have public methods d(), e() and f(), which can >>be accessed from the application by casting a Foo object into >>a FooImpl object. This is one way to provide a back door without >>compromising the core API itself to do it. This puts the >>responsibility of breaking platform independence on the developers >>and not on the designers. > > Yes, that may be a good way to do it. The J2ME connector architecture is an example of a place where this is done. Gregg Wonderly From Paul.Klissner at Sun.COM Tue Jul 25 14:02:40 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Tue, 25 Jul 2006 13:02:40 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C67342.9020402@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> <44C5CD7E.9030903@sun.com> <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> <44C67342.9020402@cox.net> Message-ID: <44C678E0.90209@sun.com> Gregg Wonderly wrote: > Guillermo Rodriguez Garcia wrote: >> At 09:51 25/07/2006, Paul Klissner wrote: >>> For example, if I am implementing class Foo in FooImpl.java, >>> And Foo.java defines interface methods a(), b() and c(), >>> FooImpl.java can also have public methods d(), e() and f(), which can >>> be accessed from the application by casting a Foo object into >>> a FooImpl object. This is one way to provide a back door without >>> compromising the core API itself to do it. This puts the >>> responsibility of breaking platform independence on the developers >>> and not on the designers. >> Yes, that may be a good way to do it. > > The J2ME connector architecture is an example of a place where this is done. It's how I debugged my javax.usb implementations. Paul From Pawan.Kharbanda at dot.state.co.us Tue Jul 25 14:02:53 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 25 Jul 2006 14:02:53 -0600 Subject: [Rxtx] Strange error (show stopper) Message-ID: <939A619A756047469C41EE9BA51890FB0429DFA4@hqexchange3.dot.state.co.us> Joachim, I believe it's the same problem that I reported earlier (Thread deadlocks/Locked Ports), I am not a C person so don't know exactly whatz going in the native code but was able to find a workaround for right now by synchronizing the "interruptEventLoop" and "eventLoop" methods in the RXTXPort class. It helped but is not the right solution, I still find the deadlocks but not as often as I used too. A fix for this will be highly appreciated. I have some Test Classes that I have posted earlier to simulate the problem. ~pk -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Joachim Buechse Sent: Monday, July 24, 2006 2:13 AM To: RXTX Developers and Users Subject: Re: [Rxtx] Strange error (show stopper) The pthread_kill is followed by a sleep. When the sleep returns the structure is damaged. I did not find the source that overwrites the closing field - it is correctly set by the exiting drain thread. But something overwrites it afterwards. I currently believe that this existed for some time but was never seen because the previous versions did not rely on the structure to be in good shape when tearing down connections. However I may be completely wrong and it is an OSX problem. To help me find the source, it would be nice to get some indications what the 2 debug lines I suggested return on other platforms. Joachim On 24.07.2006, at 05:27, Trent Jarvi wrote: > On Sat, 22 Jul 2006, Joachim Buechse wrote: > >> I just discovered a strange error in RXTX on OSX. SerialDemo.java >> manages to corrupt the event_info_structure by a simple >> OpenPort,ClosePort - this could be in relation to the deadlock >> problem that was reported recently. >> >> Could anyone try to reproduce this on Solaris or some other system >> which is neither WIN32 nor Linux (ie which uses a drain thread). >> >> In SerialImp.c : RXTXPort(interruptEventLoop) >> >> Apparently the event_info_structure gets corrupted shortly after >> >> pthread_kill(index->drain_tid, SIGABRT); >> >> In particular, the index->closing flag gets overwritten by a pointer >> value. > > Hi Joachim > > Interesting. I did run many tests with that code on may OSs. To be > fair, the tests are just starting to get into good shape again. I'm > still tagging releases with a bit of feel and not enough process. > I'll look at this some more tomorrow night. > > The SIGABRT was added recently as part of the close speedups. > Thats from > memory. I can provide the exact patch that introduced that tomorrow. > > -- > Trent Jarvi > tjarvi at qbang.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Jul 25 17:42:23 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 18:42:23 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153840929.44c6372186f67@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> Message-ID: <44C6AC5F.3060107@cox.net> Guillermo Rodriguez wrote: > The problem with this is that there is no guarantee that a single call > to the write method of the OutputStream associated with a javax.comm > SerialPort will translate to a single write to the underlying device > driver -- this depends on the javax.comm implementation. More specifically, it depends on a software layer that would targeted specifically at solving this problem for RS-485 and other transports which have blocking or packetizing issues. There are many. In amatuer radio, we have TNCs (radio modems) which will block things using newline separators in some modes, and 0xc0 in others. Gregg Wonderly From gergg at cox.net Tue Jul 25 17:46:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 18:46:11 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C63A37.8080406@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> <44C60EB9.5000803@gmail.com> <44C63A37.8080406@sun.com> Message-ID: <44C6AD43.1090302@cox.net> Paul Klissner wrote: > Also that would imply two downloads to install any given > bus support, which might not be the end of the world. > And maybe two JSRs? Why are we hovering around this "downloads" issue? If we create a JSR that covers everything needed for javax.comm compatibility, does that still imply that it would be an unincluded, optional part of the JVM? If that is still something that people will tolerate, I'm a little lost for words. Still today, I can use the old javax.comm support. If we're just going to recreate the same concerns, issues and limitations, then what's the point? Gregg Wonderly From gergg at cox.net Tue Jul 25 17:48:42 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 18:48:42 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <00c801c6b000$33a68f00$0c28a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <44C6ADDA.5040208@cox.net> Martin Schoeberl wrote: > I completely agree - it's still a stream and not a packet. > > This is similar to a single write to a TCP/IP socket. There > is no guarantee that you get this data as a single packet/single > read on the other side. However, I've seen a lot of programs > assuming that this happens ;-) For nearly forever, serialport drivers have operated in the mode that they send either everything up to the divider char, or a single char. This was specifically done for protocols such as modbus which have 1 1/2 bit time delays indicating end of packet. This kind of thing is something that needs to be maintained for serial protocols to work. A user has to have a way to send a single "packet" of data and make sure that it flows out of the uart uninterrupted. Gregg Wonderly From gergg at cox.net Tue Jul 25 18:03:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 19:03:11 -0500 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <939A619A756047469C41EE9BA51890FB0429DFA4@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB0429DFA4@hqexchange3.dot.state.co.us> Message-ID: <44C6B13F.1000306@cox.net> Kharbanda, Pawan wrote: > Joachim, > I believe it's the same problem that I reported earlier (Thread > deadlocks/Locked Ports), I am not a C person so don't know exactly whatz > going in the native code but was able to find a workaround for right now > by synchronizing the "interruptEventLoop" and "eventLoop" methods in the > RXTXPort class. It helped but is not the right solution, I still find > the deadlocks but not as often as I used too. > > A fix for this will be highly appreciated. I have some Test Classes that > I have posted earlier to simulate the problem. You can send SIGQUIT (signal #3) to unix JVMs to get a stacktrace of where all the threads are at and who owns what locks. Also, on windows, you can run the JVM in a DOS window and use CTRL-BREAK to get the stack trace. This won't go beyond the native level, but it might expose what you need to know. Gregg Wonderly From tjarvi at qbang.org Tue Jul 25 22:21:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 22:21:22 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6AC5F.3060107@cox.net> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: On Tue, 25 Jul 2006, Gregg Wonderly wrote: > Guillermo Rodriguez wrote: >> The problem with this is that there is no guarantee that a single call >> to the write method of the OutputStream associated with a javax.comm >> SerialPort will translate to a single write to the underlying device >> driver -- this depends on the javax.comm implementation. > > More specifically, it depends on a software layer that would targeted > specifically at solving this problem for RS-485 and other transports which have > blocking or packetizing issues. There are many. In amatuer radio, we have TNCs > (radio modems) which will block things using newline separators in some modes, > and 0xc0 in others. > I had looked into RS-485 some. It is daunting without proper hardware. One option is to do a native local tcpip/udp server to remove most of the the 'java issues.' Realtime patches comming down the pipe make it tempting to jump into the tarpit of failures. Beyond that, we should be very explicit about what type of RS-485 hardware we do support and it should not involve things that we have to control DTR/RTS in almost realtime (<20 ms). There are going to be people wanting < $5/EURO winmodem type solutions that will be nothing but problems. Thats doable by hacking kernel drivers but it will never get into mainstream kernels. I do not think thats reasonable from java and is even questionable in typical C. It will work fine until you start oracle... It would be nice to get RS-485 support in. Things like controlling low cost devices in houses, ... But cutting out the hardware isn't a viable solution in java. -- Trent Jarvi tjarvi From tjarvi at qbang.org Tue Jul 25 22:40:36 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 22:40:36 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6AD43.1090302@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> <44C60EB9.5000803@gmail.com> <44C63A37.8080406@sun.com> <44C6AD43.1090302@cox.net> Message-ID: On Tue, 25 Jul 2006, Gregg Wonderly wrote: > Paul Klissner wrote: >> Also that would imply two downloads to install any given >> bus support, which might not be the end of the world. >> And maybe two JSRs? > > Why are we hovering around this "downloads" issue? If we create a JSR that > covers everything needed for javax.comm compatibility, does that still imply > that it would be an unincluded, optional part of the JVM? If that is still > something that people will tolerate, I'm a little lost for words. Still today, > I can use the old javax.comm support. If we're just going to recreate the same > concerns, issues and limitations, then what's the point? > I don't have a problem with Sun shipping rxtx or whatever it becomes. They may have some legacy issues :) Just poking fun. The current state does not work for java users. Not having w32 support means about 80+% of the users do not have support. The rxtx w32 support is heavily influenced by cygwin so it wont change license out of respect for that project. If you really hate life and the LGPL, you can do a w32 port and the rest will just fall into place while you chase windows bugs for 5 years. Anything that dances around w32 support is just an academic waste of time. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Tue Jul 25 22:41:21 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 23:41:21 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: <44C6F271.2020604@cox.net> Trent Jarvi wrote: > I had looked into RS-485 some. It is daunting without proper hardware. > One option is to do a native local tcpip/udp server to remove most of the > the 'java issues.' Realtime patches comming down the pipe make it tempting > to jump into the tarpit of failures. Trent, there is not a way for a non-realtime OS to drive 485 hardware without the hardware taking care of the timing issues. But, a non-realtime OS can support software APIs which let the developer express in an API the types of things that a piece of hardware is capable of. Then we can have an API, and the hardware people and the OS people will provide the solutions where possible. > It would be nice to get RS-485 support in. Things like controlling > low cost devices in houses, ... But cutting out the hardware isn't a > viable solution in java. The 485 hardware devices will have to have non-realtime requirements associated with the controlling mechanisms. There are some of those. I'm mostly interested in having a 485 API for realtime java and/or the aJile and other uC environments which can provide realtime environments. Gregg Wonderly From tjarvi at qbang.org Tue Jul 25 22:54:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 22:54:44 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6F271.2020604@cox.net> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <44C6F271.2020604@cox.net> Message-ID: On Tue, 25 Jul 2006, Gregg Wonderly wrote: > Trent Jarvi wrote: >> I had looked into RS-485 some. It is daunting without proper hardware. >> One option is to do a native local tcpip/udp server to remove most of the >> the 'java issues.' Realtime patches comming down the pipe make it tempting >> to jump into the tarpit of failures. > > Trent, there is not a way for a non-realtime OS to drive 485 hardware without > the hardware taking care of the timing issues. But, a non-realtime OS can > support software APIs which let the developer express in an API the types of > things that a piece of hardware is capable of. Then we can have an API, and the > hardware people and the OS people will provide the solutions where possible. > >> It would be nice to get RS-485 support in. Things like controlling >> low cost devices in houses, ... But cutting out the hardware isn't a >> viable solution in java. > > The 485 hardware devices will have to have non-realtime requirements associated > with the controlling mechanisms. There are some of those. I'm mostly > interested in having a 485 API for realtime java and/or the aJile and other uC > environments which can provide realtime environments. > Hi Gregg I do not disagree with you but I have a problem with this (realtime java and/or the aJile and other Uc environements) being something I may be hearing bugs about 5 years from now. Is this really something that should be in the API or is it something that would make a nice niche market for support and services? Do the two really go together? If you like that market and I think there is a niche market there, great. This is a good area for SPI type interfaces where you could support it but it was not provided by default. -- Trent Jarvi tjarvi at qbang.org From guille at sms.nl Wed Jul 26 00:39:47 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 08:39:47 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C672EA.1080604@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> Message-ID: <7.0.1.0.0.20060726083751.03633188@sms.nl> At 21:37 25/07/2006, Gregg Wonderly wrote: >Guillermo Rodriguez Garcia wrote: > > At 11:25 25/07/2006, Martin Schoeberl wrote: > >>Mmh, perhaps in a similar way as you configure timeouts? > >>Isn't this 'just' a timeout value? > > > > Yes, but this is just a specific parameter that you can configure in a > > specific type of UART (an EXAR UART). Other UARTs might be different. The > > point I'm trying to make is that there are just too many parameters to > > have an API for each specific case. > >In my earlier example/proposal, I included the ability for >attributes of a port >to be expressed as a collection of enumeration values for standard >things. That >would be fine for simple things like Input, Output, Sync, Async >etc. When there >are specific attributes of specific hardware, the vendor is going to have to >provide a way to configure those attributes. One of the primary >mechanisms in >Java to do this is the JavaBean pattern that can be manifested in a Map type >object when an API needs to preexist. So, we can provide an mechanism for >propagating random attributes using a Map argument to a method such as > >public void setConfig( Map params ) throws IOException; >public Map getConfig() throws IOException; > >Then, there is a conduit in and out of the driver that the user can >use without >needing more standards/spec'd code/API. > >This isn't much different than an ioctl(2) like mechanism, This is exactly what I was thinking while reading your mail :) >but it feels more Java like. It would do the job as well and I would be happy with that. However Paul's proposal where implementation classes extend the core API as necessary might be more elegant (for the same reason that it is more elegant than ioctl) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Wed Jul 26 00:41:40 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 08:41:40 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6AC5F.3060107@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: <7.0.1.0.0.20060726084016.03633040@sms.nl> At 01:42 26/07/2006, Gregg Wonderly wrote: >Guillermo Rodriguez wrote: > > The problem with this is that there is no guarantee that a single call > > to the write method of the OutputStream associated with a javax.comm > > SerialPort will translate to a single write to the underlying device > > driver -- this depends on the javax.comm implementation. > >More specifically, it depends on a software layer that would targeted >specifically at solving this problem for RS-485 and other transports >which have >blocking or packetizing issues. There are many. In amatuer radio, >we have TNCs >(radio modems) which will block things using newline separators in >some modes, >and 0xc0 in others. Right. I meant that in general one cannot assume that writes to a stream will translate 1:1 to writes in every layer of the protocol stack (this is most often not the case.) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Wed Jul 26 00:44:57 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 08:44:57 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6ADDA.5040208@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> <44C6ADDA.5040208@cox.net> Message-ID: <7.0.1.0.0.20060726084203.036cd2b8@sms.nl> At 01:48 26/07/2006, Gregg Wonderly wrote: >Martin Schoeberl wrote: > > I completely agree - it's still a stream and not a packet. > > > > This is similar to a single write to a TCP/IP socket. There > > is no guarantee that you get this data as a single packet/single > > read on the other side. However, I've seen a lot of programs > > assuming that this happens ;-) > >For nearly forever, serialport drivers have operated in the mode >that they send >either everything up to the divider char, or a single char. This was >specifically done for protocols such as modbus which have 1 1/2 bit >time delays >indicating end of packet. This kind of thing is something that needs to be >maintained for serial protocols to work. A user has to have a way to send a >single "packet" of data and make sure that it flows out of the uart >uninterrupted. Even that is sometimes difficult to achieve. If the whole packet does not fit in the UART FIFOs, then the driver may have a hard time making sure that all of the data flows out uninterrupted, unless 1/ you have a RTOS with a response time that is fast enough to refill the FIFO before it empties, and/or 2/ you can tolerate a 'stop the world' approach where ints are globally disabled while the packet is being sent (not nice) (just a side comment) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From tjarvi at qbang.org Wed Jul 26 00:48:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 26 Jul 2006 00:48:29 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060726084016.03633040@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <7.0.1.0.0.20060726084016.03633040@sms.nl> Message-ID: On Wed, 26 Jul 2006, Guillermo Rodriguez Garcia wrote: > At 01:42 26/07/2006, Gregg Wonderly wrote: >> Guillermo Rodriguez wrote: >>> The problem with this is that there is no guarantee that a single call >>> to the write method of the OutputStream associated with a javax.comm >>> SerialPort will translate to a single write to the underlying device >>> driver -- this depends on the javax.comm implementation. >> >> More specifically, it depends on a software layer that would targeted >> specifically at solving this problem for RS-485 and other transports >> which have >> blocking or packetizing issues. There are many. In amatuer radio, >> we have TNCs >> (radio modems) which will block things using newline separators in >> some modes, >> and 0xc0 in others. > > Right. I meant that in general one cannot assume that writes to a stream > will translate 1:1 to writes in every layer of the protocol stack (this is > most often not the case.) > Hi Guillermo This sounds like a dead end to me. People using commapi want a a write, an interrupt and data. The kernel being a big problem these days. There are _much_ better ways to do things like protocol stacks. This is not how EIA232 works in the real world. -- Trent Jarvi tjarvi From guille at sms.nl Wed Jul 26 01:02:09 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 09:02:09 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <7.0.1.0.0.20060726084016.03633040@sms.nl> Message-ID: <7.0.1.0.0.20060726090154.036dd708@sms.nl> At 08:48 26/07/2006, Trent Jarvi wrote: >On Wed, 26 Jul 2006, Guillermo Rodriguez Garcia wrote: > > > At 01:42 26/07/2006, Gregg Wonderly wrote: > >> Guillermo Rodriguez wrote: > >>> The problem with this is that there is no guarantee that a single call > >>> to the write method of the OutputStream associated with a javax.comm > >>> SerialPort will translate to a single write to the underlying device > >>> driver -- this depends on the javax.comm implementation. > >> > >> More specifically, it depends on a software layer that would targeted > >> specifically at solving this problem for RS-485 and other transports > >> which have > >> blocking or packetizing issues. There are many. In amatuer radio, > >> we have TNCs > >> (radio modems) which will block things using newline separators in > >> some modes, > >> and 0xc0 in others. > > > > Right. I meant that in general one cannot assume that writes to a stream > > will translate 1:1 to writes in every layer of the protocol stack (this is > > most often not the case.) > > > >Hi Guillermo > >This sounds like a dead end to me. People using commapi want a a write, >an interrupt and data. The kernel being a big problem these days. > >There are _much_ better ways to do things like protocol stacks. This is >not how EIA232 works in the real world. Yes, this is exactly what I'm saying. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From Luis.Moreira at jet.uk Wed Jul 26 01:34:42 2006 From: Luis.Moreira at jet.uk (Luis Moreira) Date: Wed, 26 Jul 2006 08:34:42 +0100 Subject: [Rxtx] Portability Message-ID: Hi Guys, I managed to get the RXTX package to work on my PC, but the question is, if I need to distribute my program to someone that does not know much about java how do I get the program to work on their System? Best regards Luis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/3e3c2058/attachment-0336.html From joachim at buechse.de Wed Jul 26 02:18:19 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 26 Jul 2006 10:18:19 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <44C667EC.2070602@ergotech.com> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> <44C667EC.2070602@ergotech.com> Message-ID: I may not have been very clear with my suggestion: The "mandatory" flush after write was only regarding RS485. If an application does not use flush after write (today), it is damned to fail anyway. The Outputstream interface makes no guarentee what so ever, that any data will be writen before you call flush. So in fact flush is already mandatory unless you dont care if your data is ever transmitted. I don't see how sending on flush for RS485 would be less efficient. If you are concerned about the additional function call you may want to specify on which platform/VM you are working. A function call in java even on slow PCs is in the microsecond range. So if your concern is, that writes should be forwarded as soon as possible, well then follow any write by a flush. I haven't done any JavaME serial programming, but from my experience with implementing Ymodem over RS232+USB, all I can say is this: Either you have your data ready when it is demanded and you can write it with a single write(+flush) or your application will be slow. So yes, you need to get data on the wire as quick as possible, the solutions are manyfold but an additional (flush) function call will hardly make your application slower. Regards, Joachim On 25.07.2006, at 20:50, Jim Redman wrote: > The horror! This would be terribly inefficient. Especially in serial > protocols you need to start getting bits on the wire as soon as > possible. It could also have some timeout implications. > > Jim > > Joachim Buechse wrote: >> Just trigger writing on flush(). It is perfectly legal for an >> Outputstream implementation to do do nothing until flush is called >> and the documentation of OutputStream.flush reads: >> >> "Flushes this output stream and forces any buffered output bytes to >> be written out. The general contract of flush is that calling it is >> an indication that, if any bytes previously written have been >> buffered by the implementation of the output stream, such bytes >> should immediately be written to their intended destination." >> >> As RS485 is a "dont speak up unless requested" protocol, a mandatory >> flush after write seems like the way to go to me >> >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). >> >> Regards, >> Joachim >> >> PS: It is great to see all the motivation that is brought forward on >> this list regarding the future. It would be great if only 10% of that >> motivation could be transformed into a cleanup and extension of the >> existing code. The current code access model seems rather >> inappropriate for the prototyping of the ideas beeing presented. >> Trent can we get a "contributions" branch with "free" access. >> >> >> On 25.07.2006, at 17:37, Martin Schoeberl wrote: >> >>>>> Martin Schoeberl wrote: >>>>>> We can model it platform independent with two methods: >>>>>> >>>>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>>>> on the underlying platform to switch to RS485 transmit mode and >>>>>> back. >>>>> Or, do what is typically done, and use a single write operation >>>>> as the >>>>> indication of a 'packet' that will let the underlying RS-485/422 >>>>> driver >>>>> assert >>>>> the appropriate signalling. >>>> The problem with this is that there is no guarantee that a single >>>> call >>>> to the write method of the OutputStream associated with a >>>> javax.comm >>>> SerialPort will translate to a single write to the underlying >>>> device >>>> driver -- this depends on the javax.comm implementation. >>>> >>> I completely agree - it's still a stream and not a packet. >>> >>> This is similar to a single write to a TCP/IP socket. There >>> is no guarantee that you get this data as a single packet/single >>> read on the other side. However, I've seen a lot of programs >>> assuming that this happens ;-) >>> >>> Martin >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Jul 26 04:28:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 26 Jul 2006 06:28:33 -0400 Subject: [Rxtx] Should we defer JSR support of RS485? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: Hi All, Would it make sense to focus the JSR on rock solid serial and parallel port support? Can the RS485 people live with unofficial support, at least until we get the JSR accepted and the implementation rock solid? Thanks! - Doug From gergg at cox.net Wed Jul 26 08:49:21 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 26 Jul 2006 09:49:21 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <44C6F271.2020604@cox.net> Message-ID: <44C780F1.8020506@cox.net> Trent Jarvi wrote: > I do not disagree with you but I have a problem with this (realtime java > and/or the aJile and other Uc environements) being something I may be > hearing bugs about 5 years from now. Is this really something that should > be in the API or is it something that would make a nice niche market for > support and services? Do the two really go together? The question is whether there needs to be two, three or five ways to do the same thing, or can we distill it down to one so that software working in one environment can work in all. > If you like that market and I think there is a niche market there, great. > This is a good area for SPI type interfaces where you could support it but > it was not provided by default. SPI is supported natively on the aJile processors. Systronix provides an API for using the SPI lines defined for that use. Adding extra slave selects is not part of their API. There are plenty of places where this stuff is getting used. In the C world of uC, there are 500 ways to do the same thing because everyone wants to be as close to the hardware as possible. The trumpet of the Java platform proclaims write once, run anywhere. Thats been a powerful impetus to me and others to use the language. I really do appreciate that I don't have to think about non-application related programming tasks as much as I did in C and C++. It's possible to pick a reasonable level of abstraction that provide opportunity to expand in the future while accounting for the small in the present. But, we have to all get together with a desire to accomplish this, have good constructive conversation and feedback, and get it done. Gregg Wonderly From gergg at cox.net Wed Jul 26 08:56:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 26 Jul 2006 09:56:11 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060726083751.03633188@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> Message-ID: <44C7828B.7040904@cox.net> Guillermo Rodriguez Garcia wrote: > It would do the job as well and I would be happy with that. However > Paul's proposal where implementation classes extend the core API as > necessary might be more elegant (for the same reason that it is more > elegant than ioctl) Right, but my argument was that this demanded that the classes preexist at the time I am writing the software. I have to be able to compile against them. The Map mechanism would allow me to write software that worked with any hardware. The person deploying my software into their environment with their hardware would then just provide a set of configuration values that my software would pass into the API. That's the point I'm trying to make. I'm on the fence about a Map vs a subclass with methods. I can see it both ways. But, as a JDBC user, I've learned to appreciate a single API with Properties passed in. As a Jini user I've learned to appreciate the Configuration mechanisms that Jini 2.x has. I can write code in my configuration file to instantiate and configure the system at deployment time! Gregg Wonderly From joachim at buechse.de Wed Jul 26 09:37:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 26 Jul 2006 17:37:27 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C7828B.7040904@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> <44C7828B.7040904@cox.net> Message-ID: <08E356DB-AC3F-46FC-952B-82D5ABB15926@buechse.de> Unless you are working with J2ME, you can just as well do what you describe using reflection (ie a JavaBean strategy). A Map can change at runtime, an interface can not. Regards, Joachim On 26.07.2006, at 16:56, Gregg Wonderly wrote: > Guillermo Rodriguez Garcia wrote: >> It would do the job as well and I would be happy with that. However >> Paul's proposal where implementation classes extend the core API as >> necessary might be more elegant (for the same reason that it is more >> elegant than ioctl) > > Right, but my argument was that this demanded that the classes > preexist at the > time I am writing the software. I have to be able to compile > against them. > > The Map mechanism would allow me to write software that worked with > any > hardware. The person deploying my software into their environment > with their > hardware would then just provide a set of configuration values that > my software > would pass into the API. > > That's the point I'm trying to make. I'm on the fence about a Map > vs a subclass > with methods. I can see it both ways. But, as a JDBC user, I've > learned to > appreciate a single API with Properties passed in. As a Jini user > I've learned > to appreciate the Configuration mechanisms that Jini 2.x has. I > can write code > in my configuration file to instantiate and configure the system at > deployment > time! > > config/ConfigurationFile.html> > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Paul.Klissner at Sun.COM Wed Jul 26 12:11:37 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 26 Jul 2006 11:11:37 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C780F1.8020506@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <44C6F271.2020604@cox.net> <44C780F1.8020506@cox.net> Message-ID: <44C7B059.1060302@sun.com> Gregg Wonderly wrote: > Trent Jarvi wrote: >> I do not disagree with you but I have a problem with this (realtime java >> and/or the aJile and other Uc environements) being something I may be >> hearing bugs about 5 years from now. Is this really something that should >> be in the API or is it something that would make a nice niche market for >> support and services? Do the two really go together? > > The question is whether there needs to be two, three or five ways to do the same > thing, or can we distill it down to one so that software working in one > environment can work in all. > >> If you like that market and I think there is a niche market there, great. >> This is a good area for SPI type interfaces where you could support it but >> it was not provided by default. > > SPI is supported natively on the aJile processors. Systronix provides an API > for using the SPI lines defined for that use. Adding extra slave selects is not > part of their API. > > There are plenty of places where this stuff is getting used. In the C world of > uC, there are 500 ways to do the same thing because everyone wants to be as > close to the hardware as possible. > > The trumpet of the Java platform proclaims write once, run anywhere. Thats been > a powerful impetus to me and others to use the language. I really do appreciate > that I don't have to think about non-application related programming tasks as > much as I did in C and C++. > > It's possible to pick a reasonable level of abstraction that provide opportunity > to expand in the future while accounting for the small in the present. > > But, we have to all get together with a desire to accomplish this, have good > constructive conversation and feedback, and get it done. I agree that whatever approach we take should involve settling on the scope and then seeking to create a reasonably complete set of abstractions to generalize and make platform independent, and then refine that list as corner cases appear. For whichever bus(ses) we support, it will be standards-based functionality we're trying to support, with device-specific functionality hidden in the driver and not passed through as direct driver-oriented commands via the API. Paul > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Paul.Klissner at Sun.COM Wed Jul 26 12:23:56 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 26 Jul 2006 11:23:56 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C7828B.7040904@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> <44C7828B.7040904@cox.net> Message-ID: <44C7B33C.8090005@sun.com> Gregg Wonderly wrote: > Guillermo Rodriguez Garcia wrote: >> It would do the job as well and I would be happy with that. However >> Paul's proposal where implementation classes extend the core API as >> necessary might be more elegant (for the same reason that it is more >> elegant than ioctl) > > Right, but my argument was that this demanded that the classes preexist at the > time I am writing the software. I have to be able to compile against them. > > The Map mechanism would allow me to write software that worked with any > hardware. The person deploying my software into their environment with their > hardware would then just provide a set of configuration values that my software > would pass into the API. > > That's the point I'm trying to make. I'm on the fence about a Map vs a subclass > with methods. I can see it both ways. But, as a JDBC user, I've learned to > appreciate a single API with Properties passed in. As a Jini user I've learned > to appreciate the Configuration mechanisms that Jini 2.x has. I can write code > in my configuration file to instantiate and configure the system at deployment > time! I don't think this is a problem as long as the implementation specific stuff is handled by controlling through vehicles outside the API. The application code layered over the API should be written such that it can run on any platform and with any generic device of the class the API claims to support. The problem with the ioctl is it's proneness for abuse and invitation to proliferate the space with non-portable applications. If the implementation requires a configuration file to be passed through the API then the application can run on platform A, B and C, which all have the same type of device, fine, and then with a different configuration file, could run on D, E and F with other hardware, that seems reasonable. What if there are multiple devices on a system of different types? There needs to be a way to get the right configuration file to associate with the right device, and the application should seamlessly work with either. The application code layered over the API should not have to be aware of the configuration file or the programmatic peculiarities of the underlying hardware. Paul From joachim at buechse.de Wed Jul 26 12:59:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 26 Jul 2006 20:59:06 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C7B33C.8090005@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> <44C7828B.7040904@cox.net> <44C7B33C.8090005@sun.com> Message-ID: <1A34B6D0-43B2-4F73-A39F-004B3D100CE9@buechse.de> Paul honestly I think you are to extreme - Often enough a USER is very well capable of indentifying which "config file" needs to be choosen to set up the device he owns. This file can be accepted from the application as a "configuration parameter" and passed on to the driver. One very typical example are AT-command sequences. Terminal programs know nothing about their meaning - still they happily pass them on to do their magic. Best regards, Joachim On 26.07.2006, at 20:23, Paul Klissner wrote: > Gregg Wonderly wrote: >> Guillermo Rodriguez Garcia wrote: >>> It would do the job as well and I would be happy with that. However >>> Paul's proposal where implementation classes extend the core API as >>> necessary might be more elegant (for the same reason that it is more >>> elegant than ioctl) >> >> Right, but my argument was that this demanded that the classes >> preexist at the >> time I am writing the software. I have to be able to compile >> against them. >> >> The Map mechanism would allow me to write software that worked >> with any >> hardware. The person deploying my software into their environment >> with their >> hardware would then just provide a set of configuration values >> that my software >> would pass into the API. >> >> That's the point I'm trying to make. I'm on the fence about a Map >> vs a subclass >> with methods. I can see it both ways. But, as a JDBC user, I've >> learned to >> appreciate a single API with Properties passed in. As a Jini user >> I've learned >> to appreciate the Configuration mechanisms that Jini 2.x has. I >> can write code >> in my configuration file to instantiate and configure the system >> at deployment >> time! > > I don't think this is a problem as long as the implementation specific > stuff is handled by controlling through vehicles outside the API. > The application code layered over the API should be written such that > it can run on any platform and with any generic device of the class > the API claims to support. > > The problem with the ioctl is it's proneness for abuse and invitation > to proliferate the space with non-portable applications. > > If the implementation requires a configuration file to be passed > through > the API then the application can run on platform A, B and C, which all > have the same type of device, fine, and then with a different > configuration > file, could run on D, E and F with other hardware, that seems > reasonable. > > What if there are multiple devices on a system of different types? > There needs to be a way to get the right configuration file to > associate > with the right device, and the application should seamlessly work > with either. > The application code layered over the API should not have to be aware > of the configuration file or the programmatic peculiarities of the > underlying hardware. > > Paul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From savagobr at yahoo.com Wed Jul 26 13:15:13 2006 From: savagobr at yahoo.com (Adenilson Cavalcanti) Date: Wed, 26 Jul 2006 12:15:13 -0700 (PDT) Subject: [Rxtx] Strange error (show stopper) - Fedora Core 5 is ok! Message-ID: <20060726191513.28407.qmail@web53802.mail.yahoo.com> Dear Joachim Buechse I'm pretty new to this list (actually, first post) but got curious about the issue that you reported. If a undertood the code correctly, SerialImp.c -> interruptEventLoop only calls pthread_kill when compiled for MacOSX. Anyway, I changed the code to print field values of structure object 'index' and got this results: 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 CLOSING=0 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 CLOSING=1 Which I think seems to be o.k. (I must also comment that I'm running FC5, kernel 2.6.15, gcc 4.1.1, jdk 1.5.0_06). Bellow you will find where in source code I printed the debug information. I was wondering why in Linux is not necessary to call pthread_kill (of course I did read the comments about "output buffer empty" but don't get it...). Any comments? Best regards Savago //---------------------------------------------------------------------------------------------- Changed code. //---------------------------------------------------------------------------------------------- /** XXX: DEBUG INFO*/ snprintf(message, sizeof(message), "1 interrupted thread for FD=%i PTR=%i CLOSING=%i\n", index->fd, index, index->closing ); report(message); #ifdef TIOCSERGETLSR index->closing=1; #endif /* TIOCSERGETLSR */ #ifdef WIN32 termios_interrupt_event_loop( index->fd, 1 ); #endif /* WIN32 */ #if !defined(TIOCSERGETLSR) && !defined(WIN32) . . . #endif /** XXX: DEBUG INFO*/ snprintf(message, sizeof(message), "2 interrupted thread for FD=%i PTR=%i CLOSING=%i\n", index->fd, index, index->closing ); report(message); report("interruptEventLoop: interrupted\n"); //---------------------------------------------------------------------------------------------- OUTPUT: 15:00:24:******* report_serial_events: sending DATA_AVAILABLE 15:00:24:******* reporting data available 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 CLOSING=0 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 CLOSING=1 15:00:24:******* interruptEventLoop: interrupted 15:00:24:******* eventLoop: got interrupt 15:00:24:******* setDTR( 0 ) 15:00:24:******* setDSR( 0 ) 15:00:24:******* >nativeClose pid 15:00:24:******* nativeClose: pid 15:00:24:******* nativeClose: discarding remaining datai (tcflush) 15:00:24:******* nativeClose: calling close 15:00:24:******* fhs_unlock: Removing LockFile 15:00:24:******* nativeClose: Delete jclazz 15:00:24:******* nativeClose: release filename 15:00:24:******* fhs_unlock: Removing LockFile //---------------------------------------------------------------------------------------------- --------------------------------- How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone call rates. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/ad116f14/attachment-0335.html From savagobr at yahoo.com Wed Jul 26 13:23:05 2006 From: savagobr at yahoo.com (Adenilson Cavalcanti) Date: Wed, 26 Jul 2006 12:23:05 -0700 (PDT) Subject: [Rxtx] Locked ports - to Kharbanda Message-ID: <20060726192305.23957.qmail@web53807.mail.yahoo.com> Dear Kharbanda I'm trying to reproduce the bug that you reported (the deadlock one) but dont get it. What I did was write a java app that continuously open/close a port (/dev/ttyS0) within 1 second for this operation. The program keeps running fine, no lock until now. I'm wondering if you could send me a sample app that could help me to reproduce this bug? Best regards Savago --------------------------------- Yahoo! Music Unlimited - Access over 1 million songs.Try it free. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/c56bc64a/attachment-0335.html From Pawan.Kharbanda at dot.state.co.us Wed Jul 26 13:41:13 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Wed, 26 Jul 2006 13:41:13 -0600 Subject: [Rxtx] Locked ports - to Kharbanda Message-ID: <939A619A756047469C41EE9BA51890FB0429E08B@hqexchange3.dot.state.co.us> Savago, I have attached the Test class that i wrote to replicate the locking/threading problem with RXTX in Redhat Linux. Please follow the following instructions to replicate the problem. I don't know if you will be able to replicate using one Serial port or not, i was able to reproduced it using 3 or 4 ports constantly. Instructions: In the TestOpenClosePort.java please change the Serial Ports names(Add the ports installed on your machine). Then compile your java file and run as "java TestOpenClosePort 100" (100 is the no of times you want to open and close the port in one single thread). I have tested this with the Digi Boxes and able to replicate this over and over in Single JVM. Thanks ~pk ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Adenilson Cavalcanti Sent: Wednesday, July 26, 2006 1:23 PM To: rxtx at qbang.org Subject: [Rxtx] Locked ports - to Kharbanda Dear Kharbanda I'm trying to reproduce the bug that you reported (the deadlock one) but dont get it. What I did was write a java app that continuously open/close a port (/dev/ttyS0) within 1 second for this operation. The program keeps running fine, no lock until now. I'm wondering if you could send me a sample app that could help me to reproduce this bug? Best regards Savago ________________________________ Yahoo! Music Unlimited - Access over 1 million songs. Try it free. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/c581de54/attachment-0335.html -------------- next part -------------- A non-text attachment was scrubbed... Name: TestOpenClosePort.java Type: application/octet-stream Size: 6038 bytes Desc: TestOpenClosePort.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/c581de54/TestOpenClosePort-0335.obj From joachim at buechse.de Wed Jul 26 16:01:31 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 27 Jul 2006 00:01:31 +0200 Subject: [Rxtx] Strange error (show stopper) - Fedora Core 5 is ok! In-Reply-To: <20060726191513.28407.qmail@web53802.mail.yahoo.com> References: <20060726191513.28407.qmail@web53802.mail.yahoo.com> Message-ID: Linux offers a feature (TIOCSERGETLSR) that allows to check if all data has been sent. This feature does not exist on OSX, BSD, Solaris and probably some other systems. For these systems RXTX uses a separate thread that calls tc_drain() - on return of this call all data has been written. The pthread_kill is used to guarantee that the drain thread has been canceled. On Linux there is no forced "wait" between the setting of the "closing" flag and the end of the procedure. The test should to be done on a BSD or Solaris system. But maybe you could add a usleep (50000) just before the second sprintf. This might in fact be helpful to see if the problem exists on Linux as well. Thanks, Joachim On 26.07.2006, at 21:15, Adenilson Cavalcanti wrote: > Dear Joachim Buechse > > I'm pretty new to this list (actually, first post) but got curious > about the issue that you reported. > > If a undertood the code correctly, SerialImp.c -> > interruptEventLoop only calls pthread_kill when compiled for MacOSX. > > Anyway, I changed the code to print field values of structure > object 'index' and got this results: > > 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 > CLOSING=0 > 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 > CLOSING=1 > > Which I think seems to be o.k. (I must also comment that I'm > running FC5, kernel 2.6.15, gcc 4.1.1, jdk 1.5.0_06). > > Bellow you will find where in source code I printed the debug > information. > > I was wondering why in Linux is not necessary to call pthread_kill > (of course I did read the comments about "output buffer empty" but > don't get it...). Any comments? > > Best regards > > Savago > > //-------------------------------------------------------------------- > -------------------------- > Changed code. > //-------------------------------------------------------------------- > -------------------------- > /** XXX: DEBUG INFO*/ > snprintf(message, sizeof(message), "1 interrupted thread for FD= > %i PTR=%i CLOSING=%i\n", > index->fd, index, index->closing ); > report(message); > > #ifdef TIOCSERGETLSR > index->closing=1; > #endif /* TIOCSERGETLSR */ > #ifdef WIN32 > termios_interrupt_event_loop( index->fd, 1 ); > #endif /* WIN32 */ > #if !defined(TIOCSERGETLSR) && !defined(WIN32) > . > . > . > #endif > /** XXX: DEBUG INFO*/ > snprintf(message, sizeof(message), "2 interrupted thread for FD= > %i PTR=%i CLOSING=%i\n", > index->fd, index, index->closing ); > report(message); > > report("interruptEventLoop: interrupted\n"); > > //-------------------------------------------------------------------- > -------------------------- > OUTPUT: > > 15:00:24:******* report_serial_events: sending DATA_AVAILABLE > 15:00:24:******* reporting data available > 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 > CLOSING=0 > 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 > CLOSING=1 > 15:00:24:******* interruptEventLoop: interrupted > 15:00:24:******* eventLoop: got interrupt > 15:00:24:******* setDTR( 0 ) > 15:00:24:******* setDSR( 0 ) > 15:00:24:******* >nativeClose pid > 15:00:24:******* nativeClose: pid > 15:00:24:******* nativeClose: discarding remaining datai (tcflush) > 15:00:24:******* nativeClose: calling close > 15:00:24:******* fhs_unlock: Removing LockFile > 15:00:24:******* nativeClose: Delete jclazz > 15:00:24:******* nativeClose: release filename > 15:00:24:******* fhs_unlock: Removing LockFile > //-------------------------------------------------------------------- > -------------------------- > > How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone > call rates. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jul 26 19:34:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 26 Jul 2006 19:34:11 -0600 (MDT) Subject: [Rxtx] Strange error (show stopper) - Fedora Core 5 is ok! In-Reply-To: References: <20060726191513.28407.qmail@web53802.mail.yahoo.com> Message-ID: It is also possible to undefine TIOCSERGETLSR on Linux. It would be nice if BSD and Solaris made the line status register available but it isn't really a standard. On Thu, 27 Jul 2006, Joachim Buechse wrote: > Linux offers a feature (TIOCSERGETLSR) that allows to check if all > data has been sent. This feature does not exist on OSX, BSD, Solaris > and probably some other systems. For these systems RXTX uses a > separate thread that calls tc_drain() - on return of this call all > data has been written. The pthread_kill is used to guarantee that the > drain thread has been canceled. > > On Linux there is no forced "wait" between the setting of the > "closing" flag and the end of the procedure. The test should to be > done on a BSD or Solaris system. But maybe you could add a usleep > (50000) just before the second sprintf. This might in fact be helpful > to see if the problem exists on Linux as well. > > Thanks, > Joachim > > > On 26.07.2006, at 21:15, Adenilson Cavalcanti wrote: > >> Dear Joachim Buechse >> >> I'm pretty new to this list (actually, first post) but got curious >> about the issue that you reported. >> >> If a undertood the code correctly, SerialImp.c -> >> interruptEventLoop only calls pthread_kill when compiled for MacOSX. >> >> Anyway, I changed the code to print field values of structure >> object 'index' and got this results: >> >> 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 >> CLOSING=0 >> 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 >> CLOSING=1 >> >> Which I think seems to be o.k. (I must also comment that I'm >> running FC5, kernel 2.6.15, gcc 4.1.1, jdk 1.5.0_06). >> >> Bellow you will find where in source code I printed the debug >> information. >> >> I was wondering why in Linux is not necessary to call pthread_kill >> (of course I did read the comments about "output buffer empty" but >> don't get it...). Any comments? >> >> Best regards >> >> Savago >> >> //-------------------------------------------------------------------- >> -------------------------- >> Changed code. >> //-------------------------------------------------------------------- >> -------------------------- >> /** XXX: DEBUG INFO*/ >> snprintf(message, sizeof(message), "1 interrupted thread for FD= >> %i PTR=%i CLOSING=%i\n", >> index->fd, index, index->closing ); >> report(message); >> >> #ifdef TIOCSERGETLSR >> index->closing=1; >> #endif /* TIOCSERGETLSR */ >> #ifdef WIN32 >> termios_interrupt_event_loop( index->fd, 1 ); >> #endif /* WIN32 */ >> #if !defined(TIOCSERGETLSR) && !defined(WIN32) >> . >> . >> . >> #endif >> /** XXX: DEBUG INFO*/ >> snprintf(message, sizeof(message), "2 interrupted thread for FD= >> %i PTR=%i CLOSING=%i\n", >> index->fd, index, index->closing ); >> report(message); >> >> report("interruptEventLoop: interrupted\n"); >> >> //-------------------------------------------------------------------- >> -------------------------- >> OUTPUT: >> >> 15:00:24:******* report_serial_events: sending DATA_AVAILABLE >> 15:00:24:******* reporting data available >> 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 >> CLOSING=0 >> 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 >> CLOSING=1 >> 15:00:24:******* interruptEventLoop: interrupted >> 15:00:24:******* eventLoop: got interrupt >> 15:00:24:******* setDTR( 0 ) >> 15:00:24:******* setDSR( 0 ) >> 15:00:24:******* >nativeClose pid >> 15:00:24:******* nativeClose: pid >> 15:00:24:******* nativeClose: discarding remaining datai (tcflush) >> 15:00:24:******* nativeClose: calling close >> 15:00:24:******* fhs_unlock: Removing LockFile >> 15:00:24:******* nativeClose: Delete jclazz >> 15:00:24:******* nativeClose: release filename >> 15:00:24:******* fhs_unlock: Removing LockFile >> //-------------------------------------------------------------------- >> -------------------------- >> >> How low will we go? Check out Yahoo! Messengers low PC-to-Phone >> call rates. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From guille at sms.nl Thu Jul 27 00:30:47 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 27 Jul 2006 08:30:47 +0200 Subject: [Rxtx] more RS485 (was: Strange error (show stopper) - Fedora Core 5 is ok!) In-Reply-To: References: <20060726191513.28407.qmail@web53802.mail.yahoo.com> Message-ID: <7.0.1.0.0.20060727082321.036f10d0@sms.nl> At 00:01 27/07/2006, Joachim Buechse wrote: >Linux offers a feature (TIOCSERGETLSR) that allows to check if all >data has been sent. Just a side note: This is one of the things that is useful when one needs to control external RS232 to RS485 converters with the RTS or DTR lines. The above lets you look at the transmit shift register to know if/when the last character has been completely shifted out ('transmit shift register empty' is a different thing than 'output FIFO empty' and than 'software output buffer empty'). This is something you currently cannot do from your application using rxtx. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From gergg at cox.net Thu Jul 27 11:08:32 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 27 Jul 2006 12:08:32 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C7B33C.8090005@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> <44C7828B.7040904@cox.net> <44C7B33C.8090005@sun.com> Message-ID: <44C8F310.2040107@cox.net> Paul Klissner wrote: > What if there are multiple devices on a system of different types? > There needs to be a way to get the right configuration file to associate > with the right device, and the application should seamlessly work with either. > The application code layered over the API should not have to be aware > of the configuration file or the programmatic peculiarities of the > underlying hardware. If the configuration mechanism is the standard and must be supported, then every device will have to have such a configuration object. The configuration object would be the per device mechanism with a real API on that object. I'll use the Jini ConfigurationFile syntax here as an example: com2 { driver = "name.of.device.driver.class"; config = new com.deviceco.rs485.Parameters( ... arguments to parameter construction ... ); } then the API would ask for the driver and configuration for device com2, and have all the things needed to make the correct device used with the correct configuration. Gregg Wonderly From fredm at alum.mit.edu Fri Jul 28 04:32:56 2006 From: fredm at alum.mit.edu (Fred G. Martin) Date: Fri, 28 Jul 2006 06:32:56 -0400 Subject: [Rxtx] precompiled for Intel Mac? Message-ID: Dear RXTX'ers, Would there be a precompiled binary of the older 2.0-7pre1 version (javax.comm namespace) rxtx for the Intel Mac platform? Would I just need the libSerial.jnilib file? Thank you, Fred From savagobr at yahoo.com Fri Jul 28 09:34:35 2006 From: savagobr at yahoo.com (Adenilson Cavalcanti) Date: Fri, 28 Jul 2006 08:34:35 -0700 (PDT) Subject: [Rxtx] Strange error (show stopper) - FC5 still ok! Message-ID: <20060728153435.41645.qmail@web53815.mail.yahoo.com> Friends I repeated the test, both undefining TIOCSERGETLSR in SerialImp.h as also adding a sleep in function 'interruptEventLoop' and it still is working fine. Later I can test it in pcbsd (based on FreeBSD 6) on my notebook. So far, I think that we can say that in Linux this error doesn't happen. Best regards Savago //------------------------------------------------------------------------ Result with #undef TIOCSERGETLSR 11:08:11:******* 1 interrupted thread for FD=51 PTR=-1321354040 CLOSING=0 11:08:11:******* 2 interrupted thread for FD=51 PTR=-1321354040 CLOSING=1 Result with usleep(50000) 11:14:57:******* 1 interrupted thread for FD=51 PTR=-1322914604 CLOSING=0 11:14:57:******* 2 interrupted thread for FD=51 PTR=-1322914604 CLOSING=1 --------------------------------- How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone call rates. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060728/acd6aec1/attachment-0333.html From joachim at buechse.de Fri Jul 28 12:48:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 28 Jul 2006 20:48:33 +0200 Subject: [Rxtx] precompiled for Intel Mac? In-Reply-To: References: Message-ID: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> There will be. However not before we have figured out some remaining issues. Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 28.07.2006, at 12:32, Fred G. Martin wrote: > Dear RXTX'ers, > > Would there be a precompiled binary of the older 2.0-7pre1 version > (javax.comm namespace) rxtx for the Intel Mac platform? > > Would I just need the libSerial.jnilib file? > > Thank you, > Fred > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From fredm at alum.mit.edu Fri Jul 28 15:30:38 2006 From: fredm at alum.mit.edu (Fred G. Martin) Date: Fri, 28 Jul 2006 17:30:38 -0400 Subject: [Rxtx] precompiled for Intel Mac? In-Reply-To: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> References: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> Message-ID: <4616ED35-24BC-4FD3-90FB-81CAA851FB08@alum.mit.edu> May I ask another way--- can it [easily] be built from the 2.0-7pre1 sources? Fred On Jul 28, 2006, at 2:48 PM, Joachim Buechse wrote: > There will be. However not before we have figured out some remaining > issues. > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 28.07.2006, at 12:32, Fred G. Martin wrote: > >> Dear RXTX'ers, >> >> Would there be a precompiled binary of the older 2.0-7pre1 version >> (javax.comm namespace) rxtx for the Intel Mac platform? >> >> Would I just need the libSerial.jnilib file? >> >> Thank you, >> Fred >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Fri Jul 28 21:04:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 28 Jul 2006 21:04:45 -0600 (MDT) Subject: [Rxtx] precompiled for Intel Mac? In-Reply-To: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> References: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> Message-ID: On Fri, 28 Jul 2006, Joachim Buechse wrote: > There will be. However not before we have figured out some remaining > issues. > Joachim > Joachim and I are trying to get together to work out the remaining issues. I'll be looking at some w32 issues this weekend - a lovely job everyone should do exactly once. There are a few details that need attention. The summer vacation schedual is keeping things at a slow pace. This will be the first free weekend I've had in a while. I'm also gathering a list of things to do on Linux and Solaris which so far isn't too big but there are some that can be problems depending upon your use. Bugzilla is also your friend for bugs that are not getting attention right away. All bugs are interesting but sometimes forgotten on the mail list. I do go through all the bugs in bugzilla one by one now and then. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jul 29 05:18:25 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 29 Jul 2006 07:18:25 -0400 Subject: [Rxtx] The new JSR and RS485 - Moderator Ruling In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: Hi All, It has been several days since I asked the below question. There has not been much in the way of response. Therefore, I am using my new-age radioactive mutant moderator super-powers to make a (non-final) decision that: 1. We can live with unofficial RS485 support for a while, 2. The JSR specification that we embark upon will focus on serial and parallel ports and 3. We may revisit the RS485 question, in the future. Thanks! - Doug Date: Wed, 26 Jul 2006 06:28:33 -0400 From: "Dr. Douglas Lyon" Subject: Should we defer JSR support of RS485? To: RXTX Developers and Users , lyon at docjava.com Original-recipient: rfc822;dlyon at optonline.net Hi All, Would it make sense to focus the JSR on rock solid serial and parallel port support? Can the RS485 people live with unofficial support, at least until we get the JSR accepted and the implementation rock solid? Thanks! - Doug From naranjo.manuel at gmail.com Sat Jul 29 07:59:10 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Sat, 29 Jul 2006 10:59:10 -0300 Subject: [Rxtx] The new JSR and RS485 - Moderator Ruling In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: <44CB69AE.8030104@gmail.com> +1 Totally agree, Manuel > Hi All, > > It has been several days since I asked the below question. > There has not been much in the way of response. > Therefore, I am using my new-age radioactive > mutant moderator super-powers to > make a (non-final) decision that: > 1. We can live with unofficial RS485 support for a while, > 2. The JSR specification that we embark upon will focus on > serial and parallel ports and > 3. We may revisit the RS485 question, in the future. > > Thanks! > - Doug > > > Date: Wed, 26 Jul 2006 06:28:33 -0400 > From: "Dr. Douglas Lyon" > Subject: Should we defer JSR support of RS485? > To: RXTX Developers and Users , lyon at docjava.com > Original-recipient: rfc822;dlyon at optonline.net > > Hi All, > > Would it make sense to focus the JSR on rock solid > serial and parallel port support? > > Can the RS485 people live with unofficial support, at least until > we get the JSR accepted and the implementation rock solid? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Sat Jul 29 14:21:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 29 Jul 2006 14:21:32 -0600 (MDT) Subject: [Rxtx] The new JSR and RS485 - Moderator Ruling In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: Hi Doug At this time, I agree. RS485 is interesting and I would be intested in participating in future discussions/plans with RS485. On Sat, 29 Jul 2006, Dr. Douglas Lyon wrote: > Hi All, > > It has been several days since I asked the below question. > There has not been much in the way of response. > Therefore, I am using my new-age radioactive > mutant moderator super-powers to > make a (non-final) decision that: > 1. We can live with unofficial RS485 support for a while, > 2. The JSR specification that we embark upon will focus on > serial and parallel ports and > 3. We may revisit the RS485 question, in the future. > > Thanks! > - Doug > > > Date: Wed, 26 Jul 2006 06:28:33 -0400 > From: "Dr. Douglas Lyon" > Subject: Should we defer JSR support of RS485? > To: RXTX Developers and Users , lyon at docjava.com > Original-recipient: rfc822;dlyon at optonline.net > > Hi All, > > Would it make sense to focus the JSR on rock solid > serial and parallel port support? > > Can the RS485 people live with unofficial support, at least until > we get the JSR accepted and the implementation rock solid? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Sun Jul 30 04:28:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 30 Jul 2006 06:28:49 -0400 Subject: [Rxtx] interfaces vs. abstract classes Message-ID: Hi All, I was thinking that the new JSR might be more interface oriented and less abstract class oriented. For example, instead of subclassing CommPort, perhaps we should implement a CommPortInterface. How would this look? I don't know. But, perhaps, it would look something like this: package gnu.io; import java.io.InputStream; import java.io.IOException; import java.io.OutputStream; /** * User: lyon * Date: Jul 30, 2006 * Time: 5:19:55 AM * Copyright DocJava, Inc. 2005. */ public interface CommPortInterface { void enableReceiveFraming(int f) throws UnsupportedCommOperationException; void disableReceiveFraming(); boolean isReceiveFramingEnabled(); int getReceiveFramingByte(); void disableReceiveTimeout(); void enableReceiveTimeout(int time) throws UnsupportedCommOperationException; boolean isReceiveTimeoutEnabled(); int getReceiveTimeout(); void enableReceiveThreshold(int thresh) throws UnsupportedCommOperationException; void disableReceiveThreshold(); int getReceiveThreshold(); boolean isReceiveThresholdEnabled(); void setInputBufferSize(int size); int getInputBufferSize(); void setOutputBufferSize(int size); int getOutputBufferSize(); void close(); InputStream getInputStream() throws IOException; OutputStream getOutputStream() throws IOException; String getName(); } Then, we can use: /** * CommPort */ public abstract class CommPort implements CommPortInterface And replace uses of CommPort with uses of CommPortInterface.... package gnu.io; import java.io.FileDescriptor; /** * User: lyon * Date: Jul 30, 2006 * Time: 5:40:20 AM * Copyright DocJava, Inc. 2005. */ public interface CommPortIdentifierInterface { int PORT_SERIAL = 1; int PORT_PARALLEL = 2; int PORT_I2C = 3; int PORT_RS485 = 4; int PORT_RAW = 5; void addPortOwnershipListener(CommPortOwnershipListener c); String getCurrentOwner(); String getName(); int getPortType(); boolean isCurrentlyOwned(); CommPortInterface open(FileDescriptor f) throws UnsupportedCommOperationExce ption; CommPortInterface open(String TheOwner, int i) throws PortInUseException; void removePortOwnershipListener(CommPortOwnershipListener c); } If we continue in this vain, the SerialPort should have an interface that it implements, called (due to my lack of imagination) the SerialPortInterface package gnu.io; import java.util.TooManyListenersException; /** * User: lyon * Date: Jul 30, 2006 * Time: 5:56:35 AM * Copyright DocJava, Inc. 2005. */ public interface SerialPortInterface extends CommPortInterface { int DATABITS_5 = 5; int DATABITS_6 = 6; int DATABITS_7 = 7; int DATABITS_8 = 8; int PARITY_NONE = 0; int PARITY_ODD = 1; int PARITY_EVEN = 2; int PARITY_MARK = 3; int PARITY_SPACE = 4; int STOPBITS_1 = 1; int STOPBITS_2 = 2; int STOPBITS_1_5 = 3; int FLOWCONTROL_NONE = 0; int FLOWCONTROL_RTSCTS_IN = 1; int FLOWCONTROL_RTSCTS_OUT = 2; int FLOWCONTROL_XONXOFF_IN = 4; int FLOWCONTROL_XONXOFF_OUT = 8; void setSerialPortParams(int b, int d, int s, int p) throws UnsupportedCommOperationException; int getBaudRate(); int getDataBits(); int getStopBits(); int getParity(); void setFlowControlMode(int flowcontrol) throws UnsupportedCommOperationException; int getFlowControlMode(); boolean isDTR(); void setDTR(boolean state); void setRTS(boolean state); boolean isCTS(); boolean isDSR(); boolean isCD(); boolean isRI(); boolean isRTS(); void sendBreak(int duration); void addEventListener(SerialPortEventListener lsnr) throws TooManyListenersException; void removeEventListener(); void notifyOnDataAvailable(boolean enable); void notifyOnOutputEmpty(boolean enable); void notifyOnCTS(boolean enable); void notifyOnDSR(boolean enable); void notifyOnRingIndicator(boolean enable); void notifyOnCarrierDetect(boolean enable); void notifyOnOverrunError(boolean enable); void notifyOnParityError(boolean enable); void notifyOnFramingError(boolean enable); void notifyOnBreakInterrupt(boolean enable); byte getParityErrorChar() throws UnsupportedCommOperationException; boolean setParityErrorChar(byte b) throws UnsupportedCommOperationException; byte getEndOfInputChar() throws UnsupportedCommOperationException; boolean setEndOfInputChar(byte b) throws UnsupportedCommOperationException; boolean setUARTType(String type, boolean test) throws UnsupportedCommOperationException; String getUARTType() throws UnsupportedCommOperationException; boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException; int getBaudBase() throws UnsupportedCommOperationException; boolean setDivisor(int Divisor) throws UnsupportedCommOperationException; int getDivisor() throws UnsupportedCommOperationException; boolean setLowLatency() throws UnsupportedCommOperationException; boolean getLowLatency() throws UnsupportedCommOperationException; boolean setCallOutHangup(boolean NoHup) throws UnsupportedCommOperationException; boolean getCallOutHangup() throws UnsupportedCommOperationException; } And, of course, you need a parallel port: package gnu.io; import java.util.TooManyListenersException; /** * User: lyon * Date: Jul 30, 2006 * Time: 6:14:02 AM * Copyright DocJava, Inc. 2005. */ public interface ParallelPortInterface extends CommPortInterface { int LPT_MODE_ANY = 0; int LPT_MODE_SPP = 1; int LPT_MODE_PS2 = 2; int LPT_MODE_EPP = 3; int LPT_MODE_ECP = 4; int LPT_MODE_NIBBLE = 5; int getMode(); int setMode(int mode) throws UnsupportedCommOperationException; void restart(); void suspend(); boolean isPaperOut(); boolean isPrinterBusy(); boolean isPrinterError(); boolean isPrinterSelected(); boolean isPrinterTimedOut(); int getOutputBufferFree(); void addEventListener(ParallelPortEventListener lsnr) throws TooManyListenersException; void removeEventListener(); void notifyOnError(boolean enable); void notifyOnBuffer(boolean enable); } Now, I have refactored my code to take advantage of these interfaces. And have done very limited testing. The problem is that we have some static methods in classes like CommPortIdentifier that don't refactor into interfaces cleanly. I don't know what to do about that... What do people think about the idea of using interfaces rather than abstract classes for making the system a little more component oriented? Thanks! - Doug From tjarvi at qbang.org Sun Jul 30 10:13:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 30 Jul 2006 10:13:06 -0600 (MDT) Subject: [Rxtx] interfaces vs. abstract classes In-Reply-To: References: Message-ID: Hi Doug, I don't see a big advantage one way or another for the interfaces. One thing that should be added but not supported initially on all platforms is event notification of devices becomming physically available and vanishing. This is not the same as digging into USB. If the OS can provide a clean event driven method and provides a proper interface, it is of great use to people dealing with USB and Serial and Parallel Dongles. On Sun, 30 Jul 2006, Dr. Douglas Lyon wrote: > Hi All, > I was thinking that the new JSR might be more > interface oriented and less abstract class oriented. > > For example, instead of subclassing CommPort, perhaps > we should implement a CommPortInterface. > > How would this look? > > I don't know. But, perhaps, it would look something like this: > package gnu.io; > > import java.io.InputStream; > import java.io.IOException; > import java.io.OutputStream; > > /** > * User: lyon > * Date: Jul 30, 2006 > * Time: 5:19:55 AM > * Copyright DocJava, Inc. 2005. > */ > public interface CommPortInterface { > void enableReceiveFraming(int f) > throws UnsupportedCommOperationException; > > void disableReceiveFraming(); > > boolean isReceiveFramingEnabled(); > > int getReceiveFramingByte(); > > void disableReceiveTimeout(); > > void enableReceiveTimeout(int time) > throws UnsupportedCommOperationException; > > boolean isReceiveTimeoutEnabled(); > > int getReceiveTimeout(); > > void enableReceiveThreshold(int thresh) > throws UnsupportedCommOperationException; > > void disableReceiveThreshold(); > > int getReceiveThreshold(); > > boolean isReceiveThresholdEnabled(); > > void setInputBufferSize(int size); > > int getInputBufferSize(); > > void setOutputBufferSize(int size); > > int getOutputBufferSize(); > > void close(); > > InputStream getInputStream() throws IOException; > > OutputStream getOutputStream() throws IOException; > > String getName(); > } > > Then, we can use: > /** > * CommPort > */ > public abstract class CommPort implements CommPortInterface > > And replace uses of CommPort with uses of CommPortInterface.... > package gnu.io; > > import java.io.FileDescriptor; > > /** > * User: lyon > * Date: Jul 30, 2006 > * Time: 5:40:20 AM > * Copyright DocJava, Inc. 2005. > */ > public interface CommPortIdentifierInterface { > int PORT_SERIAL = 1; > int PORT_PARALLEL = 2; > int PORT_I2C = 3; > int PORT_RS485 = 4; > int PORT_RAW = 5; > > void addPortOwnershipListener(CommPortOwnershipListener c); > > String getCurrentOwner(); > > String getName(); > > int getPortType(); > > boolean isCurrentlyOwned(); > > CommPortInterface open(FileDescriptor f) throws > UnsupportedCommOperationExce > ption; > > CommPortInterface open(String TheOwner, int i) > throws PortInUseException; > > void removePortOwnershipListener(CommPortOwnershipListener c); > } > > If we continue in this vain, the SerialPort should have an interface that > it implements, called (due to my lack of imagination) the SerialPortInterface > > package gnu.io; > > import java.util.TooManyListenersException; > > /** > * User: lyon > * Date: Jul 30, 2006 > * Time: 5:56:35 AM > * Copyright DocJava, Inc. 2005. > */ > public interface SerialPortInterface extends CommPortInterface { > int DATABITS_5 = 5; > int DATABITS_6 = 6; > int DATABITS_7 = 7; > int DATABITS_8 = 8; > int PARITY_NONE = 0; > int PARITY_ODD = 1; > int PARITY_EVEN = 2; > int PARITY_MARK = 3; > int PARITY_SPACE = 4; > int STOPBITS_1 = 1; > int STOPBITS_2 = 2; > int STOPBITS_1_5 = 3; > int FLOWCONTROL_NONE = 0; > int FLOWCONTROL_RTSCTS_IN = 1; > int FLOWCONTROL_RTSCTS_OUT = 2; > int FLOWCONTROL_XONXOFF_IN = 4; > int FLOWCONTROL_XONXOFF_OUT = 8; > > void setSerialPortParams(int b, int d, int s, int p) > throws UnsupportedCommOperationException; > > int getBaudRate(); > > int getDataBits(); > > int getStopBits(); > > int getParity(); > > void setFlowControlMode(int flowcontrol) > throws UnsupportedCommOperationException; > > int getFlowControlMode(); > > boolean isDTR(); > > void setDTR(boolean state); > > void setRTS(boolean state); > > boolean isCTS(); > > boolean isDSR(); > > boolean isCD(); > > boolean isRI(); > > boolean isRTS(); > > void sendBreak(int duration); > > void addEventListener(SerialPortEventListener lsnr) > throws TooManyListenersException; > > void removeEventListener(); > > void notifyOnDataAvailable(boolean enable); > > void notifyOnOutputEmpty(boolean enable); > > void notifyOnCTS(boolean enable); > > void notifyOnDSR(boolean enable); > > void notifyOnRingIndicator(boolean enable); > > void notifyOnCarrierDetect(boolean enable); > > void notifyOnOverrunError(boolean enable); > > void notifyOnParityError(boolean enable); > > void notifyOnFramingError(boolean enable); > > void notifyOnBreakInterrupt(boolean enable); > > byte getParityErrorChar() > throws UnsupportedCommOperationException; > > boolean setParityErrorChar(byte b) > throws UnsupportedCommOperationException; > > byte getEndOfInputChar() > throws UnsupportedCommOperationException; > > boolean setEndOfInputChar(byte b) > throws UnsupportedCommOperationException; > > boolean setUARTType(String type, boolean test) > throws UnsupportedCommOperationException; > > String getUARTType() > throws UnsupportedCommOperationException; > > boolean setBaudBase(int BaudBase) > throws UnsupportedCommOperationException; > > int getBaudBase() > throws UnsupportedCommOperationException; > > boolean setDivisor(int Divisor) > throws UnsupportedCommOperationException; > > int getDivisor() > throws UnsupportedCommOperationException; > > boolean setLowLatency() > throws UnsupportedCommOperationException; > > boolean getLowLatency() > throws UnsupportedCommOperationException; > > boolean setCallOutHangup(boolean NoHup) > throws UnsupportedCommOperationException; > > boolean getCallOutHangup() > throws UnsupportedCommOperationException; > } > > And, of course, you need a parallel port: > package gnu.io; > > import java.util.TooManyListenersException; > > /** > * User: lyon > * Date: Jul 30, 2006 > * Time: 6:14:02 AM > * Copyright DocJava, Inc. 2005. > */ > public interface ParallelPortInterface extends CommPortInterface { > int LPT_MODE_ANY = 0; > int LPT_MODE_SPP = 1; > int LPT_MODE_PS2 = 2; > int LPT_MODE_EPP = 3; > int LPT_MODE_ECP = 4; > int LPT_MODE_NIBBLE = 5; > > int getMode(); > > int setMode(int mode) > throws UnsupportedCommOperationException; > > void restart(); > > void suspend(); > > boolean isPaperOut(); > > boolean isPrinterBusy(); > > boolean isPrinterError(); > > boolean isPrinterSelected(); > > boolean isPrinterTimedOut(); > > int getOutputBufferFree(); > > void addEventListener(ParallelPortEventListener lsnr) > throws TooManyListenersException; > > void removeEventListener(); > > void notifyOnError(boolean enable); > > void notifyOnBuffer(boolean enable); > } > > Now, I have refactored my code to take advantage of these interfaces. > And have done very limited testing. The problem is that we have some > static methods in > classes like CommPortIdentifier that don't refactor into interfaces cleanly. > > I don't know what to do about that... > > What do people think about the idea of using interfaces rather than > abstract classes for making the system a little more component oriented? > > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From berkland at spamcop.net Sun Jul 30 15:15:59 2006 From: berkland at spamcop.net (Doug Berkland) Date: Sun, 30 Jul 2006 17:15:59 -0400 Subject: [Rxtx] interfaces vs. abstract classes In-Reply-To: <269e40090607301408q41759906k6e45f0dd33618655@mail.gmail.com> References: <269e40090607301408q41759906k6e45f0dd33618655@mail.gmail.com> Message-ID: <269e40090607301415p3238e51eyce4b124f385c1918@mail.gmail.com> I think the interfaces are a good idea. They will allow more flexibility if someone needs to create a modified implementation. I just hope that all of this will end up in the javax.comm package instead of gnu.io. From gergg at cox.net Sun Jul 30 16:30:37 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 30 Jul 2006 17:30:37 -0500 Subject: [Rxtx] interfaces vs. abstract classes In-Reply-To: <269e40090607301415p3238e51eyce4b124f385c1918@mail.gmail.com> References: <269e40090607301408q41759906k6e45f0dd33618655@mail.gmail.com> <269e40090607301415p3238e51eyce4b124f385c1918@mail.gmail.com> Message-ID: <44CD330D.20608@cox.net> Doug Berkland wrote: > I think the interfaces are a good idea. They will allow more > flexibility if someone needs to create a modified implementation. I > just hope that all of this will end up in the javax.comm package > instead of gnu.io. You can provide an abstract class that implements the interface, but defers on the implementation details to allow porting parties the ability to reuse common code with less variations on the behavior that users experience. Please don't include anything in the interface that can't be described in 100% accuracy and perform identically on all possible ports, or throw a well described compatibility exception. Gregg Wonderly From lyon at docjava.com Sun Jul 30 17:27:13 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 30 Jul 2006 19:27:13 -0400 Subject: [Rxtx] interfaces vs abstract classes Message-ID: Hi All, If you ever want to use serial ports with RMI, a nice set of interfaces will be required. On the other hand, perhaps nobody wants that. On the other, other hand, there are some areas where we could really use some API clean-up. This could be a chance to shape the JSR with really clean interfaces with well defined semantics and some good Javadoc. For example: I2CPort, RS485Port and SerialPort all begin with duplicate code. We can put all the constants in a nice interface, as appears below. I have added a little Javadoc. Would someone like to finish it up? So far, I have not added any new features, other than documentation and refactoring. >More importantly is the philosophical start point for a >specification in a JSR; >that is speaking to the future: >Interfaces describe capabilities; >Classes implement capabilities; Methods execute capabilities. >In the long run, a plug-in based system can be used to substitute >implementation >but retain the use of the interface. > >So, use inheritance for internal code reuse and interfaces for >contract definition. > >As the famous GoF book says: > >Prefer interfaces over inheritance. > >Use interfaces as a design-time resource when you are planning your system. >It is almost always useful to define a contract of functionality for >a given set of features. Clients of such a contract should never >have to bother with details of actual implementations. - DL public interface SerialPortInterface extends CommPortInterface { int DATABITS_5 = 5; int DATABITS_6 = 6; int DATABITS_7 = 7; int DATABITS_8 = 8; int PARITY_NONE = 0; int PARITY_ODD = 1; int PARITY_EVEN = 2; int PARITY_MARK = 3; int PARITY_SPACE = 4; int STOPBITS_1 = 1; int STOPBITS_2 = 2; int STOPBITS_1_5 = 3; int FLOWCONTROL_NONE = 0; int FLOWCONTROL_RTSCTS_IN = 1; int FLOWCONTROL_RTSCTS_OUT = 2; int FLOWCONTROL_XONXOFF_IN = 4; int FLOWCONTROL_XONXOFF_OUT = 8; /** * @return true if the DTR bit is set. * * @see #setDTR */ boolean isCTS(); /** * @return true if the DTR bit is set. * */ boolean isDSR(); /** * @return true if the CD bit is set. * */ boolean isCD(); /** * @return true if the RI bit is set. * */ boolean isRI(); /** * @return true if the RTS bit is set. * * @see #setRTS */ boolean isRTS(); /** would someone like to write some nice javadoc for the following? */ void addEventListener(SerialPortEventListener lsnr) throws TooManyListenersException; void removeEventListener(); void notifyOnDataAvailable(boolean enable); void notifyOnOutputEmpty(boolean enable); void notifyOnCTS(boolean enable); void notifyOnDSR(boolean enable); void notifyOnRingIndicator(boolean enable); void notifyOnCarrierDetect(boolean enable); void notifyOnOverrunError(boolean enable); void notifyOnParityError(boolean enable); void notifyOnFramingError(boolean enable); void notifyOnBreakInterrupt(boolean enable); byte getParityErrorChar() throws UnsupportedCommOperationException; boolean setParityErrorChar(byte b) throws UnsupportedCommOperationException; byte getEndOfInputChar() throws UnsupportedCommOperationException; boolean setEndOfInputChar(byte b) throws UnsupportedCommOperationException; boolean setUARTType(String type, boolean test) throws UnsupportedCommOperationException; String getUARTType() throws UnsupportedCommOperationException; boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException; int getBaudBase() throws UnsupportedCommOperationException; boolean setDivisor(int Divisor) throws UnsupportedCommOperationException; int getDivisor() throws UnsupportedCommOperationException; boolean setLowLatency() throws UnsupportedCommOperationException; boolean getLowLatency() throws UnsupportedCommOperationException; boolean setCallOutHangup(boolean NoHup) throws UnsupportedCommOperationException; boolean getCallOutHangup() throws UnsupportedCommOperationException; /** * @return the current baud rate */ int getBaudRate(); /** * @return the current number of data bits: DATABITS_5, DATABITS_6, * DATABITS_7, or DATABITS_8. */ int getDataBits(); /** * @return the current number of stop bits: STOPBITS_1, STOPBITS_2, or * STOPBITS_1_5. */ int getStopBits(); /** * @return the current parity scheme: PARITY_NONE, PARITY_ODD, * PARITY_EVEN, PARITY_MARK or PARITY_SPACE. */ int getParity(); /** * Sends a break of the specified duration. * * @param millis the duration in milliseconds */ void sendBreak(int millis); /** * Sets the flow control mode. * * @param flowcontrol a bitmask combination of FLOWCONTROL_NONE, * FLOWCONTROL_RTSCTS_IN, FLOWCONTROL_RTSCTS_OUT, * FLOWCONTROL_XONXOFF_IN, and/or FLOWCONTROL_XONXOFF_OUT. */ void setFlowControlMode(int flowcontrol); /** * @return the current flow control mode as a bitmask of * FLOWCONTROL_NONE, FLOWCONTROL_RTSCTS_IN, FLOWCONTROL_RTSCTS_OUT, * FLOWCONTROL_XONXOFF_IN, and/or FLOWCONTROL_XONXOFF_OUT. */ int getFlowControlMode(); /** * Set the Receive Fifo trigger level. * If the UART has a FIFO and if it can have programmable trigger * levels, then this method will cause the UART to raise an interrupt * after trigger bytes have been received. * * @param trigger the trigger level * @deprecated */ void setRcvFifoTrigger(int trigger); /** * Sets the serial port parameters. * * @param baudRate the baud rate * @param dataBits the number of data bits: DATABITS_5, * DATABITS_6, DATABITS_7, or DATABITS_8 * @param stopBits the number of stop bits: STOPBITS_1, * STOPBITS_2, or STOPBITS_1_5 * @param parity the parity schema: PARITY_NONE, PARITY_ODD, * PARITY_EVEN, PARITY_MARK or PARITY_SPACE * @throws UnsupportedCommOperationException */ void setSerialPortParams(int baudRate, int dataBits, int stopBits, int parity) throws UnsupportedCommOperationException; /** * Sets or clears the DTR bit in the UART. * * @param dtr the Data Terminal Ready bit value * @see #isDTR */ void setDTR(boolean dtr); /** * @return true if the DTR bit is set. * * @see #setDTR */ boolean isDTR(); /** * Sets or clears the RTS bit in the UART. * * @param rts the Request To Send bit value */ void setRTS(boolean rts); } Here is the CommPortInterface: public interface CommPortInterface { /** * @return the name of this port. * */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is disabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } From tjarvi at qbang.org Sun Jul 30 17:43:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 30 Jul 2006 17:43:13 -0600 (MDT) Subject: [Rxtx] RMI In-Reply-To: References: Message-ID: On Sun, 30 Jul 2006, Dr. Douglas Lyon wrote: > Hi All, > > If you ever want to use serial ports with RMI, > a nice set of interfaces will be required. > So this would eventually lead to j2ee beans and such. The security model would have to be examined for this. Often there are tens of thousands of dollars in instrumentation or even cash drawers/POS sitting on the other end of the cable. A serial port should be no less secure than a hard drive. I think security is going to be OK but then we are opening up for a bunch of questions about how to get it working. That puts us in a position of answering how to bypass security with RMI to access hard drives [or serial ports]. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Jul 30 21:48:01 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 30 Jul 2006 22:48:01 -0500 Subject: [Rxtx] RMI In-Reply-To: References: Message-ID: <44CD7D71.2080306@cox.net> Trent Jarvi wrote: > On Sun, 30 Jul 2006, Dr. Douglas Lyon wrote: >>If you ever want to use serial ports with RMI, >>a nice set of interfaces will be required. > > So this would eventually lead to j2ee beans and such. > > The security model would have to be examined for this. Often there are > tens of thousands of dollars in instrumentation or even cash drawers/POS > sitting on the other end of the cable. > > A serial port should be no less secure than a hard drive. I think > security is going to be OK but then we are opening up for a bunch of > questions about how to get it working. > > That puts us in a position of answering how to bypass security with RMI to > access hard drives [or serial ports]. This really depends on whether you want those streams to be visible remotely, directly or not. I think that it is poor engineering practice for any Remote access to directly expose the raw hardware/stream/data. You need to have choices on how to transport and encapsulate data streams. This is the power of the RMI programming model. Mobile code can put computational activities on the client instead of the server. The next generation of RMI, with all of the security features you need was developed by the original RMI team and some others, and is the Jini Extensible Remote Invocation (JERI) stack that is available in Jini 2.0 and later versions (http://www.jini.org and http://starterkit.dev.java.net). One of the primary things that JERI provides is an authentication and authorization mechanism that is activated at deployment time, instead of being coded into the libraries. Gregg Wonderly From guille at sms.nl Mon Jul 31 03:17:29 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Mon, 31 Jul 2006 11:17:29 +0200 Subject: [Rxtx] interfaces vs. abstract classes In-Reply-To: References: Message-ID: <7.0.1.0.0.20060731111659.0363b620@sms.nl> At 12:28 30/07/2006, Dr. Douglas Lyon wrote: >Hi All, >I was thinking that the new JSR might be more >interface oriented and less abstract class oriented. > >For example, instead of subclassing CommPort, perhaps >we should implement a CommPortInterface. > >How would this look? Will it break backwards compatibility? Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From lyon at docjava.com Mon Jul 31 04:57:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 31 Jul 2006 06:57:39 -0400 Subject: [Rxtx] Rxtx RMI/SSL In-Reply-To: <44CD7D71.2080306@cox.net> References: <44CD7D71.2080306@cox.net> Message-ID: Hi All, Networked based serial ports are a nice option for java clients that do not need (or want) native method drivers installed. Applications include web-controlled robotics, network-based modems, auto-dialing addressbooks (remote dialers), remote sensing, etc. If you are behind a firewall, you may not feel the need for RMI/SSL security. After all, hacking into a serial port behind a firewall does seem a bit over-the-top. On the other hand, for those who feel they want to go over the Internet; I have been playing around with RMI over SSL. Here is a paper on the topic: http://show.docjava.com:8086/pub/document/jot/rjs.pdf Remote Job Submission Security by Pawel Krepstzul and Douglas A. Lyon, in Journal of Object Technology, vol. 5, no. 1, Janurary-February 2006, pp. 13-29. From the programmer point-of-view the SSL part is not quite transparent, but, given proper diligence, can be made somewhat secure. Naturally, you can put the exchange in a high-level of abstraction. I guess it really depends on the application. The question of how level-of-abstraction impacts security, remains open. You may observe a trend toward RMI based API's by looking at JAI (Java Advanced Imaging). Cheers! - Doug >Trent Jarvi wrote: >> On Sun, 30 Jul 2006, Dr. Douglas Lyon wrote: >>>If you ever want to use serial ports with RMI, >>>a nice set of interfaces will be required. >> >> So this would eventually lead to j2ee beans and such. >> >> The security model would have to be examined for this. Often there are >> tens of thousands of dollars in instrumentation or even cash drawers/POS >> sitting on the other end of the cable. >> >> A serial port should be no less secure than a hard drive. I think >> security is going to be OK but then we are opening up for a bunch of >> questions about how to get it working. >> >> That puts us in a position of answering how to bypass security with RMI to >> access hard drives [or serial ports]. > >This really depends on whether you want those streams to be visible remotely, >directly or not. I think that it is poor engineering practice for any Remote >access to directly expose the raw hardware/stream/data. You need to have >choices on how to transport and encapsulate data streams. This is >the power of >the RMI programming model. Mobile code can put computational >activities on the >client instead of the server. > >The next generation of RMI, with all of the security features you need was >developed by the original RMI team and some others, and is the Jini Extensible >Remote Invocation (JERI) stack that is available in Jini 2.0 and >later versions >(http://www.jini.org and http://starterkit.dev.java.net). > >One of the primary things that JERI provides is an authentication and >authorization mechanism that is activated at deployment time, instead of being >coded into the libraries. > >Gregg Wonderly >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Mon Jul 31 07:16:51 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 31 Jul 2006 15:16:51 +0200 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> Message-ID: <1154351811.44ce02c3a5539@webmail.eatserver.nl> Hi Doug, I understand. Note that we are not only concerned about source compatibility, but also about binary compatibility (which would be preserved as well with this approach if I understood correctly) Best regards, Guillermo Quoting "Dr. Douglas Lyon" : > Hi All, > At present I have a prototype version of the libraries that I am > testing that contains the Interfaces, with growing Javadoc. > I have been refactoring my code to take advantage of these > interfaces, but, in the interest of backward compatibility, > have left the abstract classes, for those who want to continue > to use and test them. So there is 100% backward compatibility. > > My goal is to identify the features of the class specification and > provide good documentation for them. I think this is seen most clearly in > the below code. This has ZERO impact on existing code that > seeks to make use of the CommPort class. > > I am adding interfaces and documentation to arrive at a specification. > Abstract methods and constants move from the abstract class into the > interface, but then the abstract class implements the interface. > > To the API user, it should have no effect. > > Cheers! > - Doug > > > public interface CommPortIdentifierInterface { > > int PORT_I2C = 3; > int PORT_RS485 = 4; > int PORT_RAW = 5; > /** > * RS-232 serial port. > */ > int PORT_SERIAL = 1; > /** > * IEEE 1284 parallel port. > */ > int PORT_PARALLEL = 2; > > > > /** > * @return the port name, typically an OS-dependent hardware label. > * > */ > String getName(); > > /** > * @return the port type, PORT_SERIAL or PORT_PARALLEL. > */ > int getPortType() > ; > > /** > * @return the current owner of this port. > */ > String getCurrentOwner() > ; > > /** > * @return true if this port is currently owned. > */ > boolean isCurrentlyOwned() ; > > /** > * @return communications port. > * If the port is in use by another application, it will be notified > * with a PORT_OWNERSHIP_REQUESTED event. If the current owner closes > * the port, then this method will succeed. Otherwise a > * PortInUseException will be thrown. > * @param appName the name of the application requesting the port > * @param timeout number of miliseconds to wait for the port to open > * @throws PortInUseException > */ > CommPortInterface open(String appName, int timeout) > throws PortInUseException; > > /** > * @return a port using a file descriptor. > * @param fd the file descriptor > * @exception UnsupportedCommOperationException if the platform does > not > * support this functionality > */ > CommPortInterface open(FileDescriptor fd) > throws UnsupportedCommOperationException; > > /** > * Adds the specified listener to the list of ownership listeners for > * this port. > * @param listener the ownership listener to add > */ > void addPortOwnershipListener(CommPortOwnershipListener listener); > > /** > * Removes the specified listener from the list of ownership listeners > for > * this port. > * @param listener the ownership listener to remove > */ > void removePortOwnershipListener(CommPortOwnershipListener listener); > } > public abstract class CommPort implements CommPortInterface { > protected String name; > private final static boolean debug = false; > > public void close() { > if (debug) System.out.println("CommPort:close()"); > > try { > CommPortIdentifierInterface cp = > CommPortIdentifier.getPortIdentifier(this); > if (cp != null) > > CommPortIdentifier.getPortIdentifier(this).internalClosePort(); > } > catch (NoSuchPortException e) { > e.printStackTrace(); > } > } > > public String getName() { > if (debug) System.out.println("CommPort:getName()"); > return (name); > } > > public String toString() { > if (debug) System.out.println("CommPort:toString()"); > return (name); > } > } > >At 12:28 30/07/2006, Dr. Douglas Lyon wrote: > >>Hi All, > >>I was thinking that the new JSR might be more > >>interface oriented and less abstract class oriented. > >> > >>For example, instead of subclassing CommPort, perhaps > >>we should implement a CommPortInterface. > >> > >>How would this look? > > > >Will it break backwards compatibility? > > > >Guillermo > >-- > >Guillermo Rodriguez Garcia > > > >Snijder Micro Systems phone +31-493-351020 > >G. Rodriguez Garcia fax +31-493-351530 > >Visser 25 email guille at sms.nl > >NL5751 BL Deurne > >The Netherlands http://www.snijder.com > > -- http://www.snijder.com/ SNIJDER Micro Systems From lyon at docjava.com Mon Jul 31 07:44:29 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 31 Jul 2006 09:44:29 -0400 Subject: [Rxtx] Do interfaces break backwards BINARY compatibility? Welcome to the serial ports of tomorrow! In-Reply-To: <1154351811.44ce02c3a5539@webmail.eatserver.nl> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> Message-ID: Hi All, The jar file, comm.jar, will change in the sense that there will be new byte codes for Interfaces and the abstract classes byte codes will change. However, the native methods are left unchanged. The goal is to specify "what is" via interfaces, minimizing the impact on the API. This enables RXTX to be a reference implementation of the interface specification. If the JSR is accepted and the interfaces become a part of the javax.comm package, then rxtx could implement the javax.comm specification. Thus, my VISION of the FUTURE (ta da): javax.comm programmers code to the javax.comm interfaces and use a factory method to get an RXTX-based driver. Does that sort of make sense? Thanks! - Doug >Hi Doug, > >I understand. Note that we are not only concerned about source >compatibility, but also about binary compatibility (which would be >preserved as well with this approach if I understood correctly) > >Best regards, >Guillermo > >Quoting "Dr. Douglas Lyon" : > >> Hi All, >> At present I have a prototype version of the libraries that I am >> testing that contains the Interfaces, with growing Javadoc. >> I have been refactoring my code to take advantage of these >> interfaces, but, in the interest of backward compatibility, >> have left the abstract classes, for those who want to continue >> to use and test them. So there is 100% backward compatibility. >> >> My goal is to identify the features of the class specification and >> provide good documentation for them. I think this is seen most clearly in >> the below code. This has ZERO impact on existing code that >> seeks to make use of the CommPort class. >> >> I am adding interfaces and documentation to arrive at a specification. >> Abstract methods and constants move from the abstract class into the >> interface, but then the abstract class implements the interface. >> >> To the API user, it should have no effect. >> >> Cheers! >> - Doug >> >> >> public interface CommPortIdentifierInterface { >> >> int PORT_I2C = 3; >> int PORT_RS485 = 4; >> int PORT_RAW = 5; >> /** >> * RS-232 serial port. >> */ >> int PORT_SERIAL = 1; >> /** >> * IEEE 1284 parallel port. >> */ >> int PORT_PARALLEL = 2; >> >> >> >> /** >> * @return the port name, typically an OS-dependent hardware label. >> * >> */ >> String getName(); >> >> /** >> * @return the port type, PORT_SERIAL or PORT_PARALLEL. >> */ >> int getPortType() >> ; >> >> /** >> * @return the current owner of this port. >> */ >> String getCurrentOwner() >> ; >> >> /** >> * @return true if this port is currently owned. >> */ >> boolean isCurrentlyOwned() ; >> >> /** >> * @return communications port. >> * If the port is in use by another application, it will be notified >> * with a PORT_OWNERSHIP_REQUESTED event. If the current owner closes >> * the port, then this method will succeed. Otherwise a >> * PortInUseException will be thrown. >> * @param appName the name of the application requesting the port >> * @param timeout number of miliseconds to wait for the port to open >> * @throws PortInUseException >> */ >> CommPortInterface open(String appName, int timeout) >> throws PortInUseException; >> >> /** >> * @return a port using a file descriptor. >> * @param fd the file descriptor >> * @exception UnsupportedCommOperationException if the platform does >> not >> * support this functionality >> */ >> CommPortInterface open(FileDescriptor fd) >> throws UnsupportedCommOperationException; >> >> /** >> * Adds the specified listener to the list of ownership listeners for >> * this port. >> * @param listener the ownership listener to add >> */ >> void addPortOwnershipListener(CommPortOwnershipListener listener); > > >> /** >> * Removes the specified listener from the list of ownership listeners >> for >> * this port. >> * @param listener the ownership listener to remove >> */ >> void removePortOwnershipListener(CommPortOwnershipListener listener); >> } >> public abstract class CommPort implements CommPortInterface { >> protected String name; >> private final static boolean debug = false; >> >> public void close() { >> if (debug) System.out.println("CommPort:close()"); >> >> try { >> CommPortIdentifierInterface cp = >> CommPortIdentifier.getPortIdentifier(this); >> if (cp != null) >>???????????????? >> CommPortIdentifier.getPortIdentifier(this).internalClosePort(); >> } >> catch (NoSuchPortException e) { >> e.printStackTrace(); >> } >> } >> >> public String getName() { >> if (debug) System.out.println("CommPort:getName()"); >> return (name); >> } >> >> public String toString() { >> if (debug) System.out.println("CommPort:toString()"); >> return (name); >> } >> } >> >At 12:28 30/07/2006, Dr. Douglas Lyon wrote: >> >>Hi All, >> >>I was thinking that the new JSR might be more >> >>interface oriented and less abstract class oriented. >> >> >> >>For example, instead of subclassing CommPort, perhaps >> >>we should implement a CommPortInterface. >> >> >> >>How would this look? >> > >> >Will it break backwards compatibility? >> > >> >Guillermo >> >-- >> >Guillermo Rodriguez Garcia >> > >> >Snijder Micro Systems phone +31-493-351020 >> >G. Rodriguez Garcia fax +31-493-351530 >> >Visser 25 email guille at sms.nl >> >NL5751 BL Deurne >> >The Netherlands http://www.snijder.com >> >> > > >-- >http://www.snijder.com/ >SNIJDER Micro Systems From berkland at spamcop.net Mon Jul 31 07:57:50 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 31 Jul 2006 09:57:50 -0400 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <1154351811.44ce02c3a5539@webmail.eatserver.nl> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> Message-ID: <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> Adding interfaces does not break any kind of compatibility. Java is more forgiving when it comes to this kind of change than languages that are compiled into native code. As long as the implementing class has the same name, same package, and all of the same methods (with the same signatures) you can add on anything you wish, including implementing additional interfaces. On 7/31/06, Guillermo Rodriguez wrote: > Hi Doug, > > I understand. Note that we are not only concerned about source > compatibility, but also about binary compatibility (which would be > preserved as well with this approach if I understood correctly) > > Best regards, > Guillermo From gergg at cox.net Mon Jul 31 08:12:20 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 31 Jul 2006 09:12:20 -0500 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> Message-ID: <44CE0FC4.9010307@cox.net> Doug Berkland wrote: > Adding interfaces does not break any kind of compatibility. Java is > more forgiving when it comes to this kind of change than languages > that are compiled into native code. As long as the implementing class > has the same name, same package, and all of the same methods (with the > same signatures) you can add on anything you wish, including > implementing additional interfaces. Check the Serialization compatibility guidelines for more information on exactly what binary compatibility requires, and what things can change in an interface and/or class which won't break things. Gregg Wonderly From berkland at spamcop.net Mon Jul 31 09:13:00 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 31 Jul 2006 11:13:00 -0400 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <44CE0FC4.9010307@cox.net> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> <44CE0FC4.9010307@cox.net> Message-ID: <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> As far as I can tell, nothing in either RXTX or Sun's JavaCOMM implements Serializable. Therefore, there are no worries from that either. (I can't think of a reason anything in JavaCOMM should implement Serializable either.) On 7/31/06, Gregg Wonderly wrote: > Doug Berkland wrote: > > Adding interfaces does not break any kind of compatibility. Java is > > more forgiving when it comes to this kind of change than languages > > that are compiled into native code. As long as the implementing class > > has the same name, same package, and all of the same methods (with the > > same signatures) you can add on anything you wish, including > > implementing additional interfaces. > > Check the Serialization compatibility guidelines for more information on exactly > what binary compatibility requires, and what things can change in an interface > and/or class which won't break things. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From berkland at spamcop.net Mon Jul 31 09:20:48 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 31 Jul 2006 11:20:48 -0400 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> <44CE0FC4.9010307@cox.net> <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> Message-ID: <269e40090607310820s15f2eee8j903e077917d7fc72@mail.gmail.com> Correction: Nothing except the classes extending Exception and Event implement Serializable. On 7/31/06, Doug Berkland wrote: > As far as I can tell, nothing in either RXTX or Sun's JavaCOMM > implements Serializable. Therefore, there are no worries from that > either. (I can't think of a reason anything in JavaCOMM should > implement Serializable either.) > > On 7/31/06, Gregg Wonderly wrote: > > Doug Berkland wrote: > > > Adding interfaces does not break any kind of compatibility. Java is > > > more forgiving when it comes to this kind of change than languages > > > that are compiled into native code. As long as the implementing class > > > has the same name, same package, and all of the same methods (with the > > > same signatures) you can add on anything you wish, including > > > implementing additional interfaces. > > > > Check the Serialization compatibility guidelines for more information on exactly > > what binary compatibility requires, and what things can change in an interface > > and/or class which won't break things. > > > > Gregg Wonderly > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > From gergg at cox.net Mon Jul 31 11:21:19 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 31 Jul 2006 12:21:19 -0500 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> <44CE0FC4.9010307@cox.net> <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> Message-ID: <44CE3C0F.3080408@cox.net> Doug Berkland wrote: > As far as I can tell, nothing in either RXTX or Sun's JavaCOMM > implements Serializable. Therefore, there are no worries from that > either. (I can't think of a reason anything in JavaCOMM should > implement Serializable either.) Any interface in javax.comm can become implemented by a serializable object. Thus, if someone wants to provide remote access to a serial port, then they might (and I think this is not wise) choose to subclass and add Serializable to the interface list. It's that kind of Serialization compatibility that I'm talking about. Gregg Wonderly From rwelty at suespammers.org Mon Jul 31 19:53:12 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 31 Jul 2006 21:53:12 -0400 Subject: [Rxtx] Application Name? Message-ID: <44CEB408.7040407@suespammers.org> trying to get my app running on a Mac OS X powerbook, when the following is executed as the first thing inside the run method of a Thread: try { port = (SerialPort) selectedPort.open( this.getClass().getName(), 2000); } catch ( PortInUseException ex){ ex.printStackTrace(); return; } i get the following: gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at com.krusty_motorsports.scale.monitor.ScaleWatcher.run(ScaleWatcher.java:143) i've not seen any documentation suggesting that rxtx would be finicky about application names... thanks for any suggestions, richard From stevebeemonkey at monkey-media.co.uk Wed Jul 5 05:59:02 2006 From: stevebeemonkey at monkey-media.co.uk (steve@monkey-media.co.uk) Date: Wed, 5 Jul 2006 04:59:02 -0700 Subject: [Rxtx] No output on WinXP Message-ID: <1152100742.44aba986565e7@www.webmail.ezpublishing.com> Hi there, I've installed RXTX 2.1.7 under Win XP, copying the .jar and .dll files according to the instructions given. I've changed the javax.comm import to gnu.io, but when I run the following code the only output I get is: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Then the program ends, without listing any of the ports. What am I doing wrong? Cheers, Steve Here's my code: ---------------------------------------- import gnu.io.*; import java.util.*; public class PortList { public static void main(String [] args) { Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while(portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); if( portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("Serial port: " + portId.getName()); } else if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { System.out.println("Parallel port: " + portId.getName()); } else System.out.println("Other port: " + portId.getName()); } } } ------------------------------- From tjarvi at qbang.org Wed Jul 5 07:57:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 5 Jul 2006 07:57:22 -0600 (MDT) Subject: [Rxtx] No output on WinXP In-Reply-To: <1152100742.44aba986565e7@www.webmail.ezpublishing.com> References: <1152100742.44aba986565e7@www.webmail.ezpublishing.com> Message-ID: On Wed, 5 Jul 2006, steve at monkey-media.co.uk wrote: > > > Hi there, > > I've installed RXTX 2.1.7 under Win XP, copying the .jar and .dll files > according to the instructions given. > > I've changed the javax.comm import to gnu.io, but when I run the following code > the only output I get is: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Then the program ends, without listing any of the ports. > > What am I doing wrong? > > Cheers, > > Steve > > Here's my code: > > ---------------------------------------- > > import gnu.io.*; > import java.util.*; > > public class PortList > { > public static void main(String [] args) > { > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > while(portList.hasMoreElements()) { > CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); > if( portId.getPortType() == > CommPortIdentifier.PORT_SERIAL) > { > System.out.println("Serial port: " + > portId.getName()); > } else if (portId.getPortType() == > CommPortIdentifier.PORT_PARALLEL) > { > System.out.println("Parallel port: " + > portId.getName()); > } else > System.out.println("Other port: " + > portId.getName()); > } > } > } > > ------------------------------- > If you have a port open with another terminal such as hyperterminal or even another copy of your application using rxtx, the port will not be enumerated. rxtx enumerates ports by opening prospective ports and doing a timed out read. If the port is open by another application, the open will fail. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Wed Jul 5 15:44:05 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Wed, 5 Jul 2006 15:44:05 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EA89@hqexchange3.dot.state.co.us> Trent, I did put some debug statements and the "index" returned to me in the while loop is "0" (see the code below) and it gets into the infinite loop, I can put a break statement but don't know the ramifications of it. Can you explain in what scenarios the index can be "0" or are we somehow in the native code loosing refrences to the indexes? Thanks Again Pawan Kharbanda while( searching ) { index = master_index; if( index ) { while( index->fd != fd && index->next ) index = index->next; if ( index->fd == fd ) searching = 0; } else report("Index"+index"x"); <<<<<< The code gets to this statement and index is returned as "0" and I don't see anyway to break out of this looop after. if( searching ) { report("@"); usleep(1000); } } -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, June 29, 2006 6:21 AM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports > Here is how you can test if you have resources/ test environment. > Write a program and try to open/close different ports(I will say have > a minimum of four) randomly and very frequently(may be 30 seconds), I > am pretty sure you will see the deadlocks and it happens in the native > call to interrptEventLoop in RXTXPort.java in removeEventListener() > method call. Hi Pawan I'll try to find a way to reproduce this. One thing to note is that you are using different kernel drivers (digi) to perform this task. So I probably will not be able to reproduce the exact same environment. In general, multiport kernel drivers have been tested far less than typical serial drivers. This may or may not be an issue. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Wed Jul 5 18:50:01 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Wed, 5 Jul 2006 18:50:01 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EA96@hqexchange3.dot.state.co.us> Trent, Sorry for so many emails, but as I mentioned earlier I will write a test to replicate the Locking problem. I am attaching a Java file to replicate the problem. You need atleast 4-5 ports to simulate the problem. Here is how to run the program. In the TestOpenClosePort.java please change the Serial Ports names(Add the ports installed on your machine). Then compile your java file and run as "java TestOpenClosePort 100" (100 is the no of times you want to open and close the port in one single thread). I have tested this with the Digi Boxes and able to replicate this over and over in Single JVM. Hope this test helps track down the problem. Thanks Pawan Kharbanda -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, June 29, 2006 6:21 AM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports > Here is how you can test if you have resources/ test environment. > Write a program and try to open/close different ports(I will say have > a minimum of four) randomly and very frequently(may be 30 seconds), I > am pretty sure you will see the deadlocks and it happens in the native > call to interrptEventLoop in RXTXPort.java in removeEventListener() > method call. Hi Pawan I'll try to find a way to reproduce this. One thing to note is that you are using different kernel drivers (digi) to perform this task. So I probably will not be able to reproduce the exact same environment. In general, multiport kernel drivers have been tested far less than typical serial drivers. This may or may not be an issue. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: TestOpenClosePort.java Type: application/octet-stream Size: 6038 bytes Desc: TestOpenClosePort.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060705/82f8488f/TestOpenClosePort-0357.obj From tjarvi at qbang.org Wed Jul 5 22:48:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 5 Jul 2006 22:48:52 -0600 (MDT) Subject: [Rxtx] Locked Ports In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3EA89@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03F3EA89@hqexchange3.dot.state.co.us> Message-ID: On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did put some debug statements and the "index" returned to me in > the while loop is "0" (see the code below) and it gets into the infinite > loop, I can put a break statement but don't know the ramifications of > it. Can you explain in what scenarios the index can be "0" or are we > somehow in the native code loosing refrences to the indexes? > > Thanks Again > Pawan Kharbanda > > while( searching ) > { > index = master_index; > > if( index ) > { > while( index->fd != fd && > index->next ) index = index->next; > if ( index->fd == fd ) searching = 0; > } > else > report("Index"+index"x"); <<<<<< The code gets > to this statement and index is returned as "0" and I don't see anyway to > break out of this looop after. > if( searching ) > { > report("@"); > usleep(1000); > } > } > Hi Pawan I am reading with interest :) So it sounds like this is a thread safe problem. The thing I don't understand here is open and close are synchronized in RXTXPort.java. I thought that would prevent any thread problems with the linked list. Looking closer, the linked list is actually populated in eventLoop/MonitorThread which is not synchronized. So you may be able to synchronize on an object in RXTXPort.java. A seperate native call would probably be required for the initalization to prevent a deadlock. A solution might involve making finalize_event_info_struct() and initialise_event_info_struct() [uk spelling?] thread safe with glib. http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads.html#id2786034 glib also has more robust linked lists which could be used. Thats the indirectly the problem found in termios.c for windows. The disadvantage is we would require linking to glib which is another step for systems that don't come with it. The advantage would be reduced code size we have to maintain. We could borrow bits of glib as the licenses are the same. Another solution might be to just use pthread_mutex_lock and unlock. http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html I don't think that would work on windows though. It would require linking cygwin.dll which would not work with nonGPL projects in practice. -- Trent Jarvi tjarvi From neville_seed at yahoo.com Thu Jul 6 06:42:29 2006 From: neville_seed at yahoo.com (neville seed) Date: Thu, 6 Jul 2006 05:42:29 -0700 (PDT) Subject: [Rxtx] port to palm OS? Message-ID: <20060706124230.55790.qmail@web51015.mail.yahoo.com> hello. Has rxtx been ported to PalmOS? regards neville __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From neville_seed at yahoo.com Thu Jul 6 06:43:44 2006 From: neville_seed at yahoo.com (neville seed) Date: Thu, 6 Jul 2006 05:43:44 -0700 (PDT) Subject: [Rxtx] example code Message-ID: <20060706124344.5063.qmail@web51013.mail.yahoo.com> hello. Could anyone provide me with example code of how to read from the serial port. regards neville __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From naranjo.manuel at gmail.com Thu Jul 6 06:48:20 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Thu, 06 Jul 2006 09:48:20 -0300 Subject: [Rxtx] port to palm OS? In-Reply-To: <20060706124230.55790.qmail@web51015.mail.yahoo.com> References: <20060706124230.55790.qmail@web51015.mail.yahoo.com> Message-ID: <44AD0694.1090703@gmail.com> neville seed wrote: > hello. > > Has rxtx been ported to PalmOS? > > regards > neville > I'm interested on this. Do you need rxtx ported to J2ME or to Superwaba?. Superwaba has it owns implementation of a serial port, but it is not rxtx. Regards, Manuel From joachim at buechse.de Thu Jul 6 07:20:57 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 6 Jul 2006 15:20:57 +0200 Subject: [Rxtx] port to palm OS? In-Reply-To: <20060706124230.55790.qmail@web51015.mail.yahoo.com> References: <20060706124230.55790.qmail@web51015.mail.yahoo.com> Message-ID: Which version of PalmOS are you targeting? I have been doing some Java on PalmOS programming for the Palm Vx using the JVM from Esmertec. The problem there was, that PalmOS can only process one kernel call at a time (it is (was?) not a multithreading OS). Threads were implemented by the VM. In a situation like this, any kind of "abort" mechanism is very difficult to handle - from what I know about the RXTX code and the way close() would have to be implemented it's the same as rewriting RXTX. Newer versions of PalmOS might have improved in this respect... Best regards, Joachim On 06.07.2006, at 14:42, neville seed wrote: > hello. > > Has rxtx been ported to PalmOS? > > regards > neville > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From neville_seed at yahoo.com Thu Jul 6 08:23:29 2006 From: neville_seed at yahoo.com (neville seed) Date: Thu, 6 Jul 2006 07:23:29 -0700 (PDT) Subject: [Rxtx] port to palm OS? In-Reply-To: Message-ID: <20060706142329.91625.qmail@web51005.mail.yahoo.com> The palmOS would be version 5.x however i am new to both palm and java. As such I would have to find out any questions. --- Joachim Buechse wrote: > Which version of PalmOS are you targeting? > > I have been doing some Java on PalmOS programming > for the Palm Vx > using the JVM from Esmertec. The problem there was, > that PalmOS can > only process one kernel call at a time (it is (was?) > not a > multithreading OS). Threads were implemented by the > VM. In a > situation like this, any kind of "abort" mechanism > is very difficult > to handle - from what I know about the RXTX code and > the way close() > would have to be implemented it's the same as > rewriting RXTX. Newer > versions of PalmOS might have improved in this > respect... > > Best regards, > Joachim > > On 06.07.2006, at 14:42, neville seed wrote: > > > hello. > > > > Has rxtx been ported to PalmOS? > > > > regards > > neville > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From jhaysonn at gmail.com Thu Jul 6 08:58:07 2006 From: jhaysonn at gmail.com (jhaysonn pathak) Date: Thu, 6 Jul 2006 10:58:07 -0400 Subject: [Rxtx] RXTX install (jhaysonn pathak) Message-ID: Thanks for the install tip. I figured out how to do the cvs update, but in my MACOSX_IDE dir I didn't have any Xcode folders and searching my computer, I only have 3 Xcode folders (one for application support, one for Max/MSP and one in developer tools). I have tried building each of the different *.xcodeproj files and in eachone they have little toolbox looking items that are in red (i assume that means it can't find them). Some of them I manage to locate but some of them just aren't on my computer. In any event, I still can't find the libserial.jnilib. After the update I read the README.OSX and it did make it seem a lot easier, but for the future, if I finally create a libserial.jnilib I don't know what the 'JavaVM' is in reference to this line "Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required)." PS - How do I uninstall everything RXTX so that I can try and re-download and re-install everything? From joachim at buechse.de Thu Jul 6 09:12:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 6 Jul 2006 17:12:24 +0200 Subject: [Rxtx] RXTX install (jhaysonn pathak) In-Reply-To: References: Message-ID: <98F15662-544D-41B5-8229-BB1DB6B6FD43@buechse.de> The Java VM ist the Java Virtual Machine. It runs your application. For the rest of your message ... your description is much to unprecise to help. To start, you could describe what IS in the MACOSX_IDE folder and its subfolders. On 06.07.2006, at 16:58, jhaysonn pathak wrote: > Thanks for the install tip. I figured out how to do the cvs update, > but in my MACOSX_IDE dir I didn't have any Xcode folders and searching > my computer, I only have 3 Xcode folders (one for application support, > one for Max/MSP and one in developer tools). I have tried building > each of the different *.xcodeproj files and in eachone they have > little toolbox looking items that are in red (i assume that means it > can't find them). Some of them I manage to locate but some of them > just aren't on my computer. In any event, I still can't find the > libserial.jnilib. > > After the update I read the README.OSX and it did make it seem a lot > easier, but for the future, if I finally create a libserial.jnilib I > don't know what the 'JavaVM' is in reference to this line > > "Put > libSerial.jnilib > in the directory of the application (the JavaVM will find it > there). Add > RXTXComm.jar > to the application classpath or include the classes in the > application jar. > (Some applications already include the RXTX classes in their > application jar, > in which case only the file libSerial.jnilib is required)." > > PS - How do I uninstall everything RXTX so that I can try and > re-download and re-install everything? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jul 6 09:20:16 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 6 Jul 2006 17:20:16 +0200 Subject: [Rxtx] RXTX install (jhaysonn pathak) In-Reply-To: References: Message-ID: <8F03CA0E-44F4-434F-AA7E-3A8B5054AA6F@buechse.de> Rethinking about your problem... I think you should try a cvs up -d Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 06.07.2006, at 16:58, jhaysonn pathak wrote: > Thanks for the install tip. I figured out how to do the cvs update, > but in my MACOSX_IDE dir I didn't have any Xcode folders and searching > my computer, I only have 3 Xcode folders (one for application support, > one for Max/MSP and one in developer tools). I have tried building > each of the different *.xcodeproj files and in eachone they have > little toolbox looking items that are in red (i assume that means it > can't find them). Some of them I manage to locate but some of them > just aren't on my computer. In any event, I still can't find the > libserial.jnilib. > > After the update I read the README.OSX and it did make it seem a lot > easier, but for the future, if I finally create a libserial.jnilib I > don't know what the 'JavaVM' is in reference to this line > > "Put > libSerial.jnilib > in the directory of the application (the JavaVM will find it > there). Add > RXTXComm.jar > to the application classpath or include the classes in the > application jar. > (Some applications already include the RXTX classes in their > application jar, > in which case only the file libSerial.jnilib is required)." > > PS - How do I uninstall everything RXTX so that I can try and > re-download and re-install everything? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Thu Jul 6 10:19:17 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Thu, 06 Jul 2006 13:19:17 -0300 Subject: [Rxtx] port to palm OS? In-Reply-To: <20060706142329.91625.qmail@web51005.mail.yahoo.com> References: <20060706142329.91625.qmail@web51005.mail.yahoo.com> Message-ID: <44AD3805.3010609@gmail.com> neville seed wrote: > The palmOS would be version 5.x however i am new to > both palm and java. As such I would have to find out > any questions. > Hello if you are new you could use Superwaba, url: www.superwaba.com, which is not exactly Java but works great, and has a serial port. If you need any more info please let me know. Manuel From Pawan.Kharbanda at dot.state.co.us Thu Jul 6 12:49:50 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 6 Jul 2006 12:49:50 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EB11@hqexchange3.dot.state.co.us> Trent, I did made the eventLoop() call in the Monitor Thread synchronized, it improved but still see the same problem. Your comment > A solution might involve making finalize_event_info_struct() and > initialise_event_info_struct() [uk spelling?] thread safe with glib. I didn't follow this how I can implement this. I am not a C guy, can you help me understand how I can implement this? Thanks Pawan Kharbanda -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, July 05, 2006 10:49 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did put some debug statements and the "index" returned to me in > the while loop is "0" (see the code below) and it gets into the > infinite loop, I can put a break statement but don't know the > ramifications of it. Can you explain in what scenarios the index can > be "0" or are we somehow in the native code loosing refrences to the indexes? > > Thanks Again > Pawan Kharbanda > > while( searching ) > { > index = master_index; > > if( index ) > { > while( index->fd != fd && > index->next ) index = index->next; > if ( index->fd == fd ) searching = 0; > } > else > report("Index"+index"x"); <<<<<< The code gets to this statement > and index is returned as "0" and I don't see anyway to break out of > this looop after. > if( searching ) > { > report("@"); > usleep(1000); > } > } > Hi Pawan I am reading with interest :) So it sounds like this is a thread safe problem. The thing I don't understand here is open and close are synchronized in RXTXPort.java. I thought that would prevent any thread problems with the linked list. Looking closer, the linked list is actually populated in eventLoop/MonitorThread which is not synchronized. So you may be able to synchronize on an object in RXTXPort.java. A seperate native call would probably be required for the initalization to prevent a deadlock. A solution might involve making finalize_event_info_struct() and initialise_event_info_struct() [uk spelling?] thread safe with glib. http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. html#id2786034 glib also has more robust linked lists which could be used. Thats the indirectly the problem found in termios.c for windows. The disadvantage is we would require linking to glib which is another step for systems that don't come with it. The advantage would be reduced code size we have to maintain. We could borrow bits of glib as the licenses are the same. Another solution might be to just use pthread_mutex_lock and unlock. http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html I don't think that would work on windows though. It would require linking cygwin.dll which would not work with nonGPL projects in practice. -- Trent Jarvi tjarvi _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From zhanglong at adventnet.com Wed Jul 5 20:44:18 2006 From: zhanglong at adventnet.com (zhanglong) Date: Thu, 06 Jul 2006 10:44:18 +0800 Subject: [Rxtx] rxtx can not read data from serialport Message-ID: <44AC7902.8070407@adventnet.com> Dear sir, When I use rxrx2.1-7-bin-r2?I can write data into serialport,But can not read data from serialport on windowsXP. I can not write and read data from serialport on Redhat Linux9.0. I can get serialport list on my machine.And no error with open serialport. I can get and read data from serialport on windowsXP with SUN's javacomm20-win32.zip. How can I read data on windows and write,read data on Linux with rxtx? Best Regards, Zhanglong From tjarvi at qbang.org Thu Jul 6 19:07:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 19:07:13 -0600 (MDT) Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: <44AC7902.8070407@adventnet.com> References: <44AC7902.8070407@adventnet.com> Message-ID: On Thu, 6 Jul 2006, zhanglong wrote: > Dear sir, > > When I use rxrx2.1-7-bin-r2??I can write data into serialport,But can > not read data from serialport on windowsXP. > I can not write and read data from serialport on Redhat Linux9.0. > I can get serialport list on my machine.And no error with open serialport. > > I can get and read data from serialport on windowsXP with SUN's > javacomm20-win32.zip. > > How can I read data on windows and write,read data on Linux with rxtx? > > Hi Zhanglong Make sure that you specify the flow control, timeout and threshold that you want. The defaults may vary between rxtx and Sun. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jul 6 19:10:25 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 19:10:25 -0600 (MDT) Subject: [Rxtx] Controlling Individual Signals DTR and RTS In-Reply-To: References: Message-ID: On Thu, 29 Jun 2006, Chris Pine wrote: > Dear Moussa Ba, > I hope I am not being too forward, but we are having the exact same > issue with needing to control DTR from RXTX in Linux. Did you ever have any > luck figuring it out? > > Thank you very much for your time, > Hi Chris Are you using an unusual serial port? It could be that the port does not support DTR/RTS. Especially if its an inexpensive USB->Serial dongle. I'll double check Linux tomorrow but I'm fairly sure it works. I have verified windows after a questions like yours. Some multiport cards and usb dongles do not support everything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jul 6 19:17:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 19:17:09 -0600 (MDT) Subject: [Rxtx] Locked Ports In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3EB11@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03F3EB11@hqexchange3.dot.state.co.us> Message-ID: Hi Pawan There is an example of doing this in the link I provided below. They make a pointer to the function they want to be thread safe and then use that with the glib functions. I'm not ready to just toss out a quick hack because I'd like to think through this a bit to make sure I understand what types of problems we may run into. The code still hung in the same place after synchronizing the eventLoop? I think that eventLoop needs to be refactored to pull out the initialization code so people do not need to run the monitor. On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did made the eventLoop() call in the Monitor Thread synchronized, it > improved but still see the same problem. > > Your comment >> A solution might involve making finalize_event_info_struct() and >> initialise_event_info_struct() [uk spelling?] thread safe with glib. > > I didn't follow this how I can implement this. I am not a C guy, can you > help me understand how I can implement this? > > Thanks > Pawan Kharbanda > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Wednesday, July 05, 2006 10:49 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] Locked Ports > > On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > >> Trent, >> I did put some debug statements and the "index" returned to me in >> the while loop is "0" (see the code below) and it gets into the >> infinite loop, I can put a break statement but don't know the >> ramifications of it. Can you explain in what scenarios the index can >> be "0" or are we somehow in the native code loosing refrences to the > indexes? >> >> Thanks Again >> Pawan Kharbanda >> >> while( searching ) >> { >> index = master_index; >> >> if( index ) >> { >> while( index->fd != fd && >> index->next ) index = index->next; >> if ( index->fd == fd ) searching = 0; >> } >> else >> report("Index"+index"x"); <<<<<< The code gets > to this statement >> and index is returned as "0" and I don't see anyway to break out of >> this looop after. >> if( searching ) >> { >> report("@"); >> usleep(1000); >> } >> } >> > > Hi Pawan > > I am reading with interest :) > > So it sounds like this is a thread safe problem. > > The thing I don't understand here is open and close are synchronized in > RXTXPort.java. I thought that would prevent any thread problems with > the linked list. Looking closer, the linked list is actually populated > in eventLoop/MonitorThread which is not synchronized. > > So you may be able to synchronize on an object in RXTXPort.java. A > seperate native call would probably be required for the initalization to > prevent a deadlock. > > A solution might involve making finalize_event_info_struct() and > initialise_event_info_struct() [uk spelling?] thread safe with glib. > > http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. > html#id2786034 > > glib also has more robust linked lists which could be used. Thats the > indirectly the problem found in termios.c for windows. The disadvantage > is we would require linking to glib which is another step for systems > that don't come with it. The advantage would be reduced code size we > have to maintain. We could borrow bits of glib as the licenses are the > same. > > Another solution might be to just use pthread_mutex_lock and unlock. > > http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html > > I don't think that would work on windows though. It would require > linking cygwin.dll which would not work with nonGPL projects in > practice. > > -- > Trent Jarvi > tjarvi > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Pawan.Kharbanda at dot.state.co.us Thu Jul 6 21:46:08 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 6 Jul 2006 21:46:08 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EB35@hqexchange3.dot.state.co.us> Trent, Just curious to know if you were able to replicate the problem with my example? Pawan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, July 06, 2006 7:17 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports Hi Pawan There is an example of doing this in the link I provided below. They make a pointer to the function they want to be thread safe and then use that with the glib functions. I'm not ready to just toss out a quick hack because I'd like to think through this a bit to make sure I understand what types of problems we may run into. The code still hung in the same place after synchronizing the eventLoop? I think that eventLoop needs to be refactored to pull out the initialization code so people do not need to run the monitor. On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did made the eventLoop() call in the Monitor Thread synchronized, > it improved but still see the same problem. > > Your comment >> A solution might involve making finalize_event_info_struct() and >> initialise_event_info_struct() [uk spelling?] thread safe with glib. > > I didn't follow this how I can implement this. I am not a C guy, can > you help me understand how I can implement this? > > Thanks > Pawan Kharbanda > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Wednesday, July 05, 2006 10:49 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] Locked Ports > > On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > >> Trent, >> I did put some debug statements and the "index" returned to me in >> the while loop is "0" (see the code below) and it gets into the >> infinite loop, I can put a break statement but don't know the >> ramifications of it. Can you explain in what scenarios the index can >> be "0" or are we somehow in the native code loosing refrences to the > indexes? >> >> Thanks Again >> Pawan Kharbanda >> >> while( searching ) >> { >> index = master_index; >> >> if( index ) >> { >> while( index->fd != fd && >> index->next ) index = index->next; >> if ( index->fd == fd ) searching = 0; >> } >> else >> report("Index"+index"x"); <<<<<< The code gets > to this statement >> and index is returned as "0" and I don't see anyway to break out of >> this looop after. >> if( searching ) >> { >> report("@"); >> usleep(1000); >> } >> } >> > > Hi Pawan > > I am reading with interest :) > > So it sounds like this is a thread safe problem. > > The thing I don't understand here is open and close are synchronized > in RXTXPort.java. I thought that would prevent any thread problems > with the linked list. Looking closer, the linked list is actually > populated in eventLoop/MonitorThread which is not synchronized. > > So you may be able to synchronize on an object in RXTXPort.java. A > seperate native call would probably be required for the initalization > to prevent a deadlock. > > A solution might involve making finalize_event_info_struct() and > initialise_event_info_struct() [uk spelling?] thread safe with glib. > > http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. > html#id2786034 > > glib also has more robust linked lists which could be used. Thats the > indirectly the problem found in termios.c for windows. The > disadvantage is we would require linking to glib which is another step > for systems that don't come with it. The advantage would be reduced > code size we have to maintain. We could borrow bits of glib as the > licenses are the same. > > Another solution might be to just use pthread_mutex_lock and unlock. > > http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html > > I don't think that would work on windows though. It would require > linking cygwin.dll which would not work with nonGPL projects in > practice. > > -- > Trent Jarvi > tjarvi > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jul 6 21:53:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 21:53:49 -0600 (MDT) Subject: [Rxtx] Locked Ports In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3EB35@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03F3EB35@hqexchange3.dot.state.co.us> Message-ID: Pawan: I'm sure I can reproduce the problem. What you have described makes very good sense and has changed how I think about rxtx. 64 ports. Take your design specs and write 'open source' on them. On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > Trent, > Just curious to know if you were able to replicate the problem > with my example? > > Pawan > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Thursday, July 06, 2006 7:17 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] Locked Ports > > > Hi Pawan > > There is an example of doing this in the link I provided below. They > make a pointer to the function they want to be thread safe and then use > that with the glib functions. > > I'm not ready to just toss out a quick hack because I'd like to think > through this a bit to make sure I understand what types of problems we > may run into. > > The code still hung in the same place after synchronizing the eventLoop? > > > > > I think that eventLoop needs to be refactored to pull out the > initialization code so people do not need to run the monitor. > > On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > >> Trent, >> I did made the eventLoop() call in the Monitor Thread synchronized, >> it improved but still see the same problem. >> >> Your comment >>> A solution might involve making finalize_event_info_struct() and >>> initialise_event_info_struct() [uk spelling?] thread safe with glib. >> >> I didn't follow this how I can implement this. I am not a C guy, can >> you help me understand how I can implement this? >> >> Thanks >> Pawan Kharbanda >> >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > >> Of Trent Jarvi >> Sent: Wednesday, July 05, 2006 10:49 PM >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] Locked Ports >> >> On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: >> >>> Trent, >>> I did put some debug statements and the "index" returned to me in >>> the while loop is "0" (see the code below) and it gets into the >>> infinite loop, I can put a break statement but don't know the >>> ramifications of it. Can you explain in what scenarios the index can >>> be "0" or are we somehow in the native code loosing refrences to the >> indexes? >>> >>> Thanks Again >>> Pawan Kharbanda >>> >>> while( searching ) >>> { >>> index = master_index; >>> >>> if( index ) >>> { >>> while( index->fd != fd && >>> index->next ) index = index->next; >>> if ( index->fd == fd ) searching = 0; >>> } >>> else >>> report("Index"+index"x"); <<<<<< The code gets >> to this statement >>> and index is returned as "0" and I don't see anyway to break out of >>> this looop after. >>> if( searching ) >>> { >>> report("@"); >>> usleep(1000); >>> } >>> } >>> >> >> Hi Pawan >> >> I am reading with interest :) >> >> So it sounds like this is a thread safe problem. >> >> The thing I don't understand here is open and close are synchronized >> in RXTXPort.java. I thought that would prevent any thread problems >> with the linked list. Looking closer, the linked list is actually >> populated in eventLoop/MonitorThread which is not synchronized. >> >> So you may be able to synchronize on an object in RXTXPort.java. A >> seperate native call would probably be required for the initalization >> to prevent a deadlock. >> >> A solution might involve making finalize_event_info_struct() and >> initialise_event_info_struct() [uk spelling?] thread safe with glib. >> >> > http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. >> html#id2786034 >> >> glib also has more robust linked lists which could be used. Thats the > >> indirectly the problem found in termios.c for windows. The >> disadvantage is we would require linking to glib which is another step > >> for systems that don't come with it. The advantage would be reduced >> code size we have to maintain. We could borrow bits of glib as the >> licenses are the same. >> >> Another solution might be to just use pthread_mutex_lock and unlock. >> >> http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html >> >> I don't think that would work on windows though. It would require >> linking cygwin.dll which would not work with nonGPL projects in >> practice. >> >> -- >> Trent Jarvi >> tjarvi >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pascal at quies.net Fri Jul 7 08:45:59 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Fri, 7 Jul 2006 16:45:59 +0200 Subject: [Rxtx] Java installer Message-ID: <200607071645.59765.pascal@quies.net> Hello everybody, We need a *simple* installer for the RXTX extension. I'm working on a pure Java installer right now. Let's get this thing working over the weekend. The license of choise is the modified BSD license. My plan is to make a JAR with: * the RXTX binaries * a simple API to detect any installed version * a simple Swing installer * a executeable detector: java -jar communicationapi.jar detect javax.comm * a executable installer: java -jar communicationapi.jar install gnu.io * Java 1.2 compatible Comments? _The Java API_: class CommunicationAPI { CommunicationAPI() CommunicationAPI(String path) boolean available() boolean supportsRS232() boolean supportsRS485() boolean supportsI2C() boolean supportsIEEE1280() static void main(String[] args) static boolean installRXTX(boolean headless) } Comments? To get this working we need binaries. Who is having what? The package from the official site has the following: * Linux: i686, x86_64, ia64 * Solaris: sparc32, sparc64 * Windows: i386 Now that's a start. I had to modify the code (what a mess!) to get it working on OpenBSD but I don't have the time to get it working for every platform. Any help here? From j.a.horsmeier at wanadoo.nl Fri Jul 7 09:11:24 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Fri, 7 Jul 2006 17:11:24 +0200 Subject: [Rxtx] Java installer In-Reply-To: <200607071645.59765.pascal@quies.net> Message-ID: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> > Pascal S. de Kloe wrote: > We need a *simple* installer for the RXTX extension. > I'm working on a pure Java installer right now. Let's get > this thing working > over the weekend. The license of choise is the modified BSD license. > > My plan is to make a JAR with: > * the RXTX binaries > * a simple API to detect any installed version > * a simple Swing installer > * a executeable detector: java -jar communicationapi.jar > detect javax.comm > * a executable installer: java -jar communicationapi.jar > install gnu.io > * Java 1.2 compatible > > Comments? Have a look at IzPack: http://www.izforge.com/izpack/ I use it all the time to install rxtx as part of our application. kind regards, Jos From brian at mbari.org Fri Jul 7 10:01:27 2006 From: brian at mbari.org (Brian Schlining) Date: Fri, 7 Jul 2006 09:01:27 -0700 Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: <44AC7902.8070407@adventnet.com> References: <44AC7902.8070407@adventnet.com> Message-ID: On Jul 5, 2006, at 7:44 PM, zhanglong wrote: > Dear sir, > > When I use rxrx2.1-7-bin-r2?I can write data into serialport,But can > not read data from serialport on windowsXP. > I can not write and read data from serialport on Redhat Linux9.0. > I can get serialport list on my machine.And no error with open > serialport. > > I can get and read data from serialport on windowsXP with SUN's > javacomm20-win32.zip. > > How can I read data on windows and write,read data on Linux with rxtx? On windows, if all else fails you may need to use this flow control: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_IN); Also, for some command/response applications that I've tried with RXTX, I find that if I write to the serialport and then immediately try to read from it I get byte arrays filled with zeros, no matter what I set the recieveTimeout to (this has occurred on both Mac OS X and Windows). The workaround that I found was to very briefly put the I/O thread to sleep, like so: // DO set up and get I/O streams //in = serialPort.getInputStream(); //out = serialPort.getOutputStream(); out.write(someByteArray); try { Thread.sleep(10); catch (InterruptedException e) { // handle exception } in.read(anotherByteArray); Note: I've never had to put the thread to sleep using Java comm, only with RXTX. Anyone know why this might be? Cheers B Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060707/f0799573/attachment-0355.html From pascal at quies.net Fri Jul 7 16:55:03 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 00:55:03 +0200 Subject: [Rxtx] Java installer In-Reply-To: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> Message-ID: <200607080055.04501.pascal@quies.net> Op vrijdag 7 juli 2006 17:11, schreef Jos A. Horsmeier: > > Pascal S. de Kloe wrote: > > > > We need a *simple* installer for the RXTX extension. > > I'm working on a pure Java installer right now. Let's get > > this thing working > > over the weekend. The license of choise is the modified BSD license. > > > > My plan is to make a JAR with: > > * the RXTX binaries > > * a simple API to detect any installed version > > * a simple Swing installer > > * a executeable detector: java -jar communicationapi.jar > > detect javax.comm > > * a executable installer: java -jar communicationapi.jar > > install gnu.io > > * Java 1.2 compatible > > > > Comments? > > Have a look at IzPack: http://www.izforge.com/izpack/ > I use it all the time to install rxtx as part of our application. Hello Jos, Thanks for the idea. Could you publish the IzPack configuration and the binaries? That would be very helpful since the current installation procedure is somewhat "unprofessional". ;) IzPack is great but this API is a little more than that. It allows java applications who require the extension to detect available versions and install RXTX on the fly if needed. Is Izpack: * able to install binaries for the right platform (os + hardware architecture)? * Java 1.2 compatible * able to run from the command line? I need as many pre-compiled binaries as possible. Could you help me with that? The detection system already works. Thanks again, Pascal PS Is the gnu.io namespace still necessary? I couldn't find the problem. From naranjo.manuel at gmail.com Fri Jul 7 17:04:31 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 07 Jul 2006 20:04:31 -0300 Subject: [Rxtx] Java installer In-Reply-To: <200607080055.04501.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: <44AEE87F.60202@gmail.com> Pascal: I will be a little short with my answer but very informative :) > Could you publish the IzPack configuration and the binaries? That would be > very helpful since the current installation procedure is > somewhat "unprofessional". ;) > > IzPack is great but this API is a little more than that. It allows java > applications who require the extension to detect available versions and > install RXTX on the fly if needed. > > Is Izpack: > * able to install binaries for the right platform (os + hardware > architecture)? Yes. > * Java 1.2 compatible Yes of course > * able to run from the command line? Yes, and can run from command line detecting which is the underlaying os. I have attached an old version of one of my installer, I can't find the last one, but it is like this one. In this you will see how to detect the OS and architecture and install binaries for that plataform. Regards, Manuel -------------- next part -------------- A non-text attachment was scrubbed... Name: installer.xml Type: text/xml Size: 4683 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060707/fbc3be3c/installer-0355.xml From pascal at quies.net Fri Jul 7 18:35:29 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 02:35:29 +0200 Subject: [Rxtx] Java installer In-Reply-To: <44AEE87F.60202@gmail.com> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <44AEE87F.60202@gmail.com> Message-ID: <200607080235.29486.pascal@quies.net> Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: > > Is Izpack: > > * able to install binaries for the right platform (os + hardware > > architecture)? > > Yes. > > > * Java 1.2 compatible > > Yes of course > > > * able to run from the command line? > > Yes, and can run from command line detecting which is the underlaying os. > I have attached an old version of one of my installer, I can't find the > last one, but it is like this one. In this you will see how to detect > the OS and architecture and install binaries for that plataform. > Regards, > Manuel You are right. IzPack looks like the right tool for this job. As far as I can see there is no commandline support but I'll get over it. ;) I'll link my detection system to the IzPack installation procedure and publish the results. From tjarvi at qbang.org Fri Jul 7 19:00:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 7 Jul 2006 19:00:56 -0600 (MDT) Subject: [Rxtx] Controlling Individual Signals DTR and RTS In-Reply-To: References: Message-ID: On Thu, 6 Jul 2006, Trent Jarvi wrote: > On Thu, 29 Jun 2006, Chris Pine wrote: > >> Dear Moussa Ba, >> I hope I am not being too forward, but we are having the exact same >> issue with needing to control DTR from RXTX in Linux. Did you ever have any >> luck figuring it out? >> >> Thank you very much for your time, >> > > Hi Chris > > Are you using an unusual serial port? It could be that the port does not > support DTR/RTS. Especially if its an inexpensive USB->Serial dongle. > > I'll double check Linux tomorrow but I'm fairly sure it works. I have > verified windows after a questions like yours. Some multiport cards and > usb dongles do not support everything. > I double checked that DTR and RTS are working. The system was a 64 bit opteron with an inexexpensive dual port serial card. Suse 9.3 rxtx 2.1-7 (final). I just used the demo SerialBlackBox that used to come with commapi modified to use rxtx 2.1. The serial card was a NetMos PCI NM9835CV with a 16C550 high speed UART dual port. These are not expensive cards. Everything worked fine. I could see the voltage flipping back and forth on the scope for both DTR(pin 4) and CTS(pin 7). You are not the first to report problems. But everytime I try to reproduce the problem, it appears to work. I suspect it is either hardware or kernel driver related and not specific to RXTX. Note that playing with RTS and DTR with hardware flow control enabled does not make sense as those pins are used for the flow control. I've not looked at many USB serial dongles but I have noticed that some are not as good as others. I think one lacked DTR/CTS support. Another one appeared to be fully functional. The one I noticed no issues with was the Hawking Tech HUC232S on windows. I did not test it on Mac OS X or Linux. The same variability can be observed with multiport serial cards. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jul 7 19:15:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 7 Jul 2006 19:15:06 -0600 (MDT) Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: References: <44AC7902.8070407@adventnet.com> Message-ID: On Fri, 7 Jul 2006, Brian Schlining wrote: > Also, for some command/response applications that I've tried with RXTX, I > find that if I write to the serialport and then immediately try to read from > it I get byte arrays filled with zeros, no matter what I set the > recieveTimeout to (this has occurred on both Mac OS X and Windows). The > workaround that I found was to very briefly put the I/O thread to sleep, like > so: > > // DO set up and get I/O streams > //in = serialPort.getInputStream(); > //out = serialPort.getOutputStream(); > > out.write(someByteArray); > try { > Thread.sleep(10); > catch (InterruptedException e) { > // handle exception > } > in.read(anotherByteArray); > > Note: I've never had to put the thread to sleep using Java comm, only with > RXTX. Anyone know why this might be? Hi Brian Interesting. Is this something that can be reproduced with a loopback connection or something commonly available? I was unaware of this behavior. Is it restricted to something that quickly opens, writes, reads and closes the port by chance? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jul 7 19:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 7 Jul 2006 19:39:37 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607080055.04501.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > Is the gnu.io namespace still necessary? I couldn't find the problem. Hi Pascal CommAPI is a little different in that it was grandfathered into the javax namespace with its own license at the time. It is my understanding that if CommAPI went through the JSR process, anyone would _clearly_ be able to implement a javax.comm package and RXTX would then be one of the first to do so. I believe Doug has expressed some interest in RXTX trying to work with the JSR process. Besides the license questions, there is the fact that RXTX has extensions to CommAPI which could cause confusion in the namespace. Not being a lawyer and *really* not liking to talk to lawyers in my free time, it is better to be safe than sorry. The lawyers tend to come in wolf packs when they do come. There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay there as long as we are just geeks trying to figure out if a license does or does not allow us to implement in the javax.comm namespace. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Sat Jul 8 05:30:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 13:30:24 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: <200607081330.24381.pascal@quies.net> Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > > Is the gnu.io namespace still necessary? I couldn't find the problem. > > Hi Pascal > > CommAPI is a little different in that it was grandfathered into the javax > namespace with its own license at the time. > > It is my understanding that if CommAPI went through the JSR process, > anyone would _clearly_ be able to implement a javax.comm package and RXTX > would then be one of the first to do so. I believe Doug has expressed > some interest in RXTX trying to work with the JSR process. > > Besides the license questions, there is the fact that RXTX has extensions > to CommAPI which could cause confusion in the namespace. Not being a > lawyer and *really* not liking to talk to lawyers in my free time, it is > better to be safe than sorry. The lawyers tend to come in wolf packs > when they do come. > > There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay > there as long as we are just geeks trying to figure out if a license does > or does not allow us to implement in the javax.comm namespace. Nicely said. :) The whole point of namespaces is to create a universal registry of, in this case, classes. This gnu.io namespace is very inconvenient. We feel the same way about lawyers. However I'd like to go into the details of the license (see attachment) if you don't mind? The first license does not apply since RXTX does not use the software. The second one at point 3 specifies our options. > 3. You may not modify the Java Platform Interface ("JPI", identified as > classes contained within the "java" package or any subpackages of the > "java" package), by creating additional classes within the JPI or otherwise > causing the addition to or modification of the classes in the JPI. RXTX is a extension. > In the event that you create an additional class and associated API(s) > which (i) extends the functionality of the Java platform, and (ii) is > exposed to third party software developers for the purpose of developing > additional software which invokes such additional API, you must promptly > publish broadly an accurate specification for such API for free use by all > developers. That's the way we operate. :) > You may not create, or authorize your licensees to create additional > classes, interfaces, or subpackages that are in any way identified as > "java", "javax", "sun" or similar convention as specified by Sun in any > naming convention designation. They don't want additional components in the Communication API since they don't want a mess in theire namespace. So we *can* use javax.comm for the core: javax.comm.CommDriver javax.comm.CommPort javax.comm.CommPortIdentifier javax.comm.CommPortOwnershipListener javax.comm.NoSuchPortException javax.comm.PortInUseException javax.comm.UnsupportedCommOperationException ...and for the default hardware support: javax.comm.SerialPort javax.comm.SerialPortEvent javax.comm.SerialPortEventListener javax.comm.ParralelPort javax.comm.ParralelPortEvent javax.comm.ParralelPortEventListener ...but RXTX aditional hardware support has to go somewhere else like: org.rxtx.RS485Port org.rxtx.RS485PortEvent org.rxtx.RS485PortEventListener org.rxtx.I2CPort org.rxtx.I2CPortEvent org.rxtx.I2CPortEventListener Right? -------------- next part -------------- Sun Microsystems, Inc. Binary Code License Agreement READ THE TERMS OF THIS AGREEMENT AND ANY PROVIDED SUPPLEMENTAL LICENSE TERMS (COLLECTIVELY "AGREEMENT") CAREFULLY BEFORE OPENING THE SOFTWARE MEDIA PACKAGE. BY OPENING THE SOFTWARE MEDIA PACKAGE, YOU AGREE TO THE TERMS OF THIS AGREEMENT. IF YOU ARE ACCESSING THE SOFTWARE ELECTRONICALLY, INDICATE YOUR ACCEPTANCE OF THESE TERMS BY SELECTING THE "ACCEPT" BUTTON AT THE END OF THIS AGREEMENT. IF YOU DO NOT AGREE TO ALL THESE TERMS, PROMPTLY RETURN THE UNUSED SOFTWARE TO YOUR PLACE OF PURCHASE FOR A REFUND OR, IF THE SOFTWARE IS ACCESSED ELECTRONICALLY, SELECT THE "DECLINE" BUTTON AT THE END OF THIS AGREEMENT. 1. LICENSE TO USE. Sun grants you a non-exclusive and non-transferable license for the internal use only of the accompanying software and documentation and any error corrections provided by Sun (collectively "Software"), by the number of users and the class of computer hardware for which the corresponding fee has been paid. 2. RESTRICTIONS. Software is confidential and copyrighted. Title to Software and all associated intellectual property rights is retained by Sun and/or its licensors. Except as specifically authorized in any Supplemental License Terms, you may not make copies of Software, other than a single copy of Software for archival purposes. Unless enforcement is prohibited by applicable law, you may not modify, decompile, or reverse engineer Software. Licensee acknowledges that Licensed Software is not designed or intended for use in the design, construction, operation or maintenance of any nuclear facility. Sun Microsystems, Inc. disclaims any express or implied warranty of fitness for such uses. No right, title or interest in or to any trademark, service mark, logo or trade name of Sun or its licensors is granted under this Agreement. 3. LIMITED WARRANTY. Sun warrants to you that for a period of ninety (90) days from the date of purchase, as evidenced by a copy of the receipt, the media on which Software is furnished (if any) will be free of defects in materials and workmanship under normal use. Except for the foregoing, Software is provided "AS IS". Your exclusive remedy and Sun's entire liability under this limited warranty will be at Sun's option to replace Software media or refund the fee paid for Software. 4. DISCLAIMER OF WARRANTY. UNLESS SPECIFIED IN THIS AGREEMENT, ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT THESE DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. 5.LIMITATION OF LIABILITY. TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF OR RELATED TO THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. In no event will Sun's liability to you, whether in contract, tort (including negligence), or otherwise, exceed the amount paid by you for Software under this Agreement. The foregoing limitations will apply even if the above stated warranty fails of its essential purpose. 6. TERMINATION. This Agreement is effective until terminated. You may terminate this Agreement at any time by destroying all copies of Software. This Agreement will terminate immediately without notice from Sun if you fail to comply with any provision of this Agreement. Upon Termination, you must destroy all copies of Software. 7. EXPORT REGULATIONS. All Software and technical data delivered under this Agreement are subject to US export control laws and may be subject to export or import regulations in other countries. You agree to comply strictly with all such laws and regulations and acknowledge that you have the responsibility to obtain such licenses to export, re-export, or import as may be required after delivery to you. 8. U.S. GOVERNMENT RESTRICTED RIGHTS. If Software is being acquired by or on behalf of the U.S. Government or by a U.S. Government prime contractor or subcontractor (at any tier), then the Government's rights in Software and accompanying documentation will be only as set forth in this Agreement; this is in accordance with 48 CFR 227.7201 through 227.7202-4 (for Department of Defense (DOD) acquisitions) and with 48 CFR 2.101 and 12.212 (for non-DOD acquisitions). 9. GOVERNING LAW. Any action related to this Agreement will be governed by California law and controlling U.S. federal law. No choice of law rules of any jurisdiction will apply. 10, SEVERABILITY. If any provision of this Agreement is held to be unenforceable, this Agreement will remain in effect with the provision omitted, unless omission would frustrate the intent of the parties, in which case this Agreement will immediately terminate. 11. INTEGRATION This Agreement is the entire agreement between you and Sun relating to its subject matter. It supersedes all prior or contemporaneous oral or written communications, proposals, representations and warranties and prevails over any conflicting or additional terms of any quote, order, acknowledgment, or other communication between the parties relating to its subject matter during the term of this Agreement. No modification of this Agreement will be binding, unless in writing and signed by an authorized representative of each party. JAVA OPTIONAL PACKAGE JAVAX.COMM 3.0 SUPPLEMENTAL LICENSE TERMS These supplemental license terms ("Supplemental Terms") add to or modify the terms of the Binary Code License Agreement (collectively, the "Agreement"). Capitalized terms not defined in these Supplemental Terms shall have the same meanings ascribed to them in the Agreement. These Supplemental Terms shall supersede any inconsistent or conflicting terms in the Agreement, or in any license contained within the Software. 1. Software Internal Use and Development License Grant. Subject to the terms and conditions of this Agreement, including, but not limited to Section 3 (Java(TM) Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce internally and use internally the binary form of the Software, complete and unmodified, for the sole purpose of designing, developing and testing your Java applets and applications ("Programs"). 2. License to Distribute Software. In addition to the license granted in Section 1 (Software Internal Use and Development License Grant) of these Supplemental Terms, subject to the terms and conditions of this Agreement, including but not limited to, Section 3 (Java Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce and distribute the Software in binary code form only, provided that you (i) distribute the Software complete and unmodified and only bundled as part of your Programs, (ii) do not distribute additional software intended to replace any component(s) of the Software, (iii) do not remove or alter any proprietary legends or notices contained in the Software, (iv) only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (v) agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software. 3. Java Technology Restrictions. You may not modify the Java Platform Interface ("JPI", identified as classes contained within the "java" package or any subpackages of the "java" package), by creating additional classes within the JPI or otherwise causing the addition to or modification of the classes in the JPI. In the event that you create an additional class and associated API(s) which (i) extends the functionality of the Java platform, and (ii) is exposed to third party software developers for the purpose of developing additional software which invokes such additional API, you must promptly publish broadly an accurate specification for such API for free use by all developers. You may not create, or authorize your licensees to create additional classes, interfaces, or subpackages that are in any way identified as "java", "javax", "sun" or similar convention as specified by Sun in any naming convention designation. 4. Trademarks and Logos. You acknowledge and agree as between you and Sun that Sun owns the SUN, SOLARIS, JAVA, JINI, FORTE, and iPLANET trademarks and all SUN, SOLARIS, JAVA, JINI, FORTE, and iPLANET-related trademarks, service marks, logos and other brand designations ("Sun Marks"), and you agree to comply with the Sun Trademark and Logo Usage Requirements currently located at http://www.sun.com/policies/trademarks. Any use you make of the Sun Marks inures to Sun's benefit. 5. Source Code. Software may contain source code that is provided solely for reference purposes pursuant to the terms of this Agreement. Source code may not be redistributed unless expressly provided for in this Agreement. 6. Termination for Infringement. Either party may terminate this Agreement immediately should any Software become, or in either party's opinion be likely to become, the subject of a claim of infringement of any intellectual property right. For inquiries please contact: Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, California 95054. (LFI#143217/Form ID#011801) From tjarvi at qbang.org Sat Jul 8 10:12:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 10:12:55 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607081330.24381.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <200607081330.24381.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> Is the gnu.io namespace still necessary? I couldn't find the problem. >> >> Hi Pascal >> >> CommAPI is a little different in that it was grandfathered into the javax >> namespace with its own license at the time. >> >> It is my understanding that if CommAPI went through the JSR process, >> anyone would _clearly_ be able to implement a javax.comm package and RXTX >> would then be one of the first to do so. I believe Doug has expressed >> some interest in RXTX trying to work with the JSR process. >> >> Besides the license questions, there is the fact that RXTX has extensions >> to CommAPI which could cause confusion in the namespace. Not being a >> lawyer and *really* not liking to talk to lawyers in my free time, it is >> better to be safe than sorry. The lawyers tend to come in wolf packs >> when they do come. >> >> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay >> there as long as we are just geeks trying to figure out if a license does >> or does not allow us to implement in the javax.comm namespace. > > Nicely said. :) > > The whole point of namespaces is to create a universal registry of, in this > case, classes. This gnu.io namespace is very inconvenient. > > We feel the same way about lawyers. However I'd like to go into the details of > the license (see attachment) if you don't mind? > > The first license does not apply since RXTX does not use the software. The > second one at point 3 specifies our options. > >> 3. You may not modify the Java Platform Interface ("JPI", identified as >> classes contained within the "java" package or any subpackages of the >> "java" package), by creating additional classes within the JPI or otherwise >> causing the addition to or modification of the classes in the JPI. > > RXTX is a extension. > >> In the event that you create an additional class and associated API(s) >> which (i) extends the functionality of the Java platform, and (ii) is >> exposed to third party software developers for the purpose of developing >> additional software which invokes such additional API, you must promptly >> publish broadly an accurate specification for such API for free use by all >> developers. > > That's the way we operate. :) > >> You may not create, or authorize your licensees to create additional >> classes, interfaces, or subpackages that are in any way identified as >> "java", "javax", "sun" or similar convention as specified by Sun in any >> naming convention designation. > > They don't want additional components in the Communication API since they > don't want a mess in theire namespace. > > So we *can* use javax.comm for the core: > javax.comm.CommDriver > javax.comm.CommPort > javax.comm.CommPortIdentifier > javax.comm.CommPortOwnershipListener > javax.comm.NoSuchPortException > javax.comm.PortInUseException > javax.comm.UnsupportedCommOperationException > > ...and for the default hardware support: > javax.comm.SerialPort > javax.comm.SerialPortEvent > javax.comm.SerialPortEventListener > javax.comm.ParralelPort > javax.comm.ParralelPortEvent > javax.comm.ParralelPortEventListener > > ...but RXTX aditional hardware support has to go somewhere else like: > org.rxtx.RS485Port > org.rxtx.RS485PortEvent > org.rxtx.RS485PortEventListener > org.rxtx.I2CPort > org.rxtx.I2CPortEvent > org.rxtx.I2CPortEventListener > > Right? > I do not disagree with anything you said :) RXTX and Sun agree with each other almost completely but not exactly. I think there are three uses of CommAPI and Sun is mainly interested in one. 1) Point of sale. This is the direction Sun is going with limited resources thats causing some problems. They would obviously cause fewer problems with more resources just like rxtx would work with them better with more resources. I'm sure if you talk to people in this area they are very optimitsic about what CommAPI could be. 2) Instrument Control. This is my area of interest as its my job too. I'm still formulating opinions here and it is far to early to say much but I'm very optimistic about what CommAPI could be. 3) Hobby and other hardware control. Circuts, road signs, rxtx in cell phones controlling TVs, you name it. People asking about palm, wince, embeded hardware. This is why I thought it was important to open source rxtx in the beginning and still find it my primary motive to read rxtx email every morning and evening. The optimism here is abundant and self explained. Nothing would make me happier than having someone get a working demo of controlling LEDs with parallel ports that could be used by people learning. So everyone agrees with almost everything. Nobody is looking for conflicts. But these various interests have not been _clearly_ formalized. Licenses are tools for manipulating behavior. Until the above is clearly in line with each other, the license will be a tool for lawyers to cause problems for people working for free. This is why I support a move to go through the JSR process and formalize the relationship. My concern is not really Sun comming after RXTX with Lawyers. I have a great deal of respect for Sun going back to their sunsite project. My concern is how lawyers think. They look at the intent which is not all in line. Then I get what feels like insane conference calls that cost companies over $2000 an hour which pisses me off to no end. Companies paying lawyers to take time from developers for free. This really does happen when a fortune 50 company developer asks their legal department if they can use rxtx. I don't have enough bullets for that. The way you avoid this is formalize everones intent so lawyers don't make conference call meetings in outlook. I want to put those lawyers out of work and if it takes a little discomfort, thats perfectly fine. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Sat Jul 8 11:44:40 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 19:44:40 +0200 Subject: [Rxtx] Fwd: Re: Java installer Message-ID: <200607081944.41123.pascal@quies.net> For some reason the first mail failed... ---------- Doorgestuurd bericht ---------- Subject: Re: [Rxtx] Java installer Date: zaterdag 8 juli 2006 17:18 From: "Pascal S. de Kloe" To: RXTX Developers and Users Hello Manuel, In case of a JDK the installation goes into the "jre" directory. I can't find a simple way to get this information into a variable of IzPack. (see attachment) Do you have a idea? Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: > Pascal: > I will be a little short with my answer but very informative :) > > > Could you publish the IzPack configuration and the binaries? That would > > be very helpful since the current installation procedure is > > somewhat "unprofessional". ;) > > > > IzPack is great but this API is a little more than that. It allows java > > applications who require the extension to detect available versions and > > install RXTX on the fly if needed. > > > > Is Izpack: > > * able to install binaries for the right platform (os + hardware > > architecture)? > > Yes. > > > * Java 1.2 compatible > > Yes of course > > > * able to run from the command line? > > Yes, and can run from command line detecting which is the underlaying os. > I have attached an old version of one of my installer, I can't find the > last one, but it is like this one. In this you will see how to detect > the OS and architecture and install binaries for that plataform. > Regards, > Manuel ------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: izpack.xml Type: text/xml Size: 1401 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060708/413315d2/izpack-0354.xml From joachim at buechse.de Sat Jul 8 10:02:18 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 8 Jul 2006 18:02:18 +0200 Subject: [Rxtx] Java installer In-Reply-To: <200607080055.04501.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: <7D4FA261-44FA-4A6E-8EB9-7A7B0116BB2C@buechse.de> Hello Pascal, as soon as the 2.1.8 version is "released" I'll happily provide you with a precompiled library for Mac OSX. The currently tagged version is 2.17 which has a non standard implementation for OSX. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 08.07.2006, at 00:55, Pascal S. de Kloe wrote: > > I need as many pre-compiled binaries as possible. > Could you help me with that? > > The detection system already works. > > Thanks again, > > Pascal > > > PS > Is the gnu.io namespace still necessary? I couldn't find the problem. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 8 09:18:09 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 17:18:09 +0200 Subject: [Rxtx] Java installer In-Reply-To: <44AEE87F.60202@gmail.com> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <44AEE87F.60202@gmail.com> Message-ID: <200607081718.09605.pascal@quies.net> Hello Manuel, In case of a JDK the installation goes into the "jre" directory. I can't find a simple way to get this information into a variable of IzPack. (see attachment) Do you have a idea? Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: > Pascal: > I will be a little short with my answer but very informative :) > > > Could you publish the IzPack configuration and the binaries? That would > > be very helpful since the current installation procedure is > > somewhat "unprofessional". ;) > > > > IzPack is great but this API is a little more than that. It allows java > > applications who require the extension to detect available versions and > > install RXTX on the fly if needed. > > > > Is Izpack: > > * able to install binaries for the right platform (os + hardware > > architecture)? > > Yes. > > > * Java 1.2 compatible > > Yes of course > > > * able to run from the command line? > > Yes, and can run from command line detecting which is the underlaying os. > I have attached an old version of one of my installer, I can't find the > last one, but it is like this one. In this you will see how to detect > the OS and architecture and install binaries for that plataform. > Regards, > Manuel -------------- next part -------------- A non-text attachment was scrubbed... Name: izpack.xml Type: text/xml Size: 1401 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060708/fa6f5a81/izpack-0354.xml From naranjo.manuel at gmail.com Sat Jul 8 12:52:23 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 15:52:23 -0300 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607081944.41123.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> Message-ID: <44AFFEE7.3090306@gmail.com> Pascal: I can't get exactly your point, but my installer was to avoid modifying the users JDK or JRE. Download this app made by me, and you will get my point: http://www.aircable.net/downloads/AIRcable_Configuration_Utility_v0.2_ALPHA_1.zip, this app bundles RXTX library inside the zip file, and does not need RXTX installed on the Users system. Manuel > For some reason the first mail failed... > > > ---------- Doorgestuurd bericht ---------- > > Subject: Re: [Rxtx] Java installer > Date: zaterdag 8 juli 2006 17:18 > From: "Pascal S. de Kloe" > To: RXTX Developers and Users > > Hello Manuel, > > In case of a JDK the installation goes into the "jre" directory. > I can't find a simple way to get this information into a variable of IzPack. > (see attachment) > > Do you have a idea? > > Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: >> Pascal: >> I will be a little short with my answer but very informative :) >> >>> Could you publish the IzPack configuration and the binaries? That would >>> be very helpful since the current installation procedure is >>> somewhat "unprofessional". ;) >>> >>> IzPack is great but this API is a little more than that. It allows java >>> applications who require the extension to detect available versions and >>> install RXTX on the fly if needed. >>> >>> Is Izpack: >>> * able to install binaries for the right platform (os + hardware >>> architecture)? >> Yes. >> >>> * Java 1.2 compatible >> Yes of course >> >>> * able to run from the command line? >> Yes, and can run from command line detecting which is the underlaying os. >> I have attached an old version of one of my installer, I can't find the >> last one, but it is like this one. In this you will see how to detect >> the OS and architecture and install binaries for that plataform. >> Regards, >> Manuel > > ------------------------------------------------------- > > > ------------------------------------------------------------------------ > > > > > RXTX > 2... > http://www.rxtx.org/ > 1.2 > uninstallRXTX > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Jul 8 12:53:32 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 15:53:32 -0300 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607081944.41123.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> Message-ID: <44AFFF2C.8090005@gmail.com> Even more, the variable ${CURRENT_JRE} referees to the actuall JVM as far as I know, so you will have no difference in installing towards a JDK. > For some reason the first mail failed... > > > ---------- Doorgestuurd bericht ---------- > > Subject: Re: [Rxtx] Java installer > Date: zaterdag 8 juli 2006 17:18 > From: "Pascal S. de Kloe" > To: RXTX Developers and Users > > Hello Manuel, > > In case of a JDK the installation goes into the "jre" directory. > I can't find a simple way to get this information into a variable of IzPack. > (see attachment) > > Do you have a idea? > > Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: >> Pascal: >> I will be a little short with my answer but very informative :) >> >>> Could you publish the IzPack configuration and the binaries? That would >>> be very helpful since the current installation procedure is >>> somewhat "unprofessional". ;) >>> >>> IzPack is great but this API is a little more than that. It allows java >>> applications who require the extension to detect available versions and >>> install RXTX on the fly if needed. >>> >>> Is Izpack: >>> * able to install binaries for the right platform (os + hardware >>> architecture)? >> Yes. >> >>> * Java 1.2 compatible >> Yes of course >> >>> * able to run from the command line? >> Yes, and can run from command line detecting which is the underlaying os. >> I have attached an old version of one of my installer, I can't find the >> last one, but it is like this one. In this you will see how to detect >> the OS and architecture and install binaries for that plataform. >> Regards, >> Manuel > > ------------------------------------------------------- > > > ------------------------------------------------------------------------ > > > > > RXTX > 2... > http://www.rxtx.org/ > 1.2 > uninstallRXTX > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Jul 8 12:54:22 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 15:54:22 -0300 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <200607081330.24381.pascal@quies.net> Message-ID: <44AFFF5E.50603@gmail.com> > > I do not disagree with anything you said :) > > RXTX and Sun agree with each other almost completely but not exactly. I > think there are three uses of CommAPI and Sun is mainly interested in one. > > 1) Point of sale. This is the direction Sun is going with limited > resources thats causing some problems. They would obviously cause fewer > problems with more resources just like rxtx would work with them better > with more resources. I'm sure if you talk to people in this area they are > very optimitsic about what CommAPI could be. > > 2) Instrument Control. This is my area of interest as its my job too. I'm > still formulating opinions here and it is far to early to say much but I'm > very optimistic about what CommAPI could be. > > 3) Hobby and other hardware control. Circuts, road signs, rxtx in cell > phones controlling TVs, you name it. People asking about palm, wince, > embeded hardware. This is why I thought it was important to open source > rxtx in the beginning and still find it my primary motive to read rxtx > email every morning and evening. The optimism here is abundant and self > explained. Nothing would make me happier than having someone get a > working demo of controlling LEDs with parallel ports that could be used by > people learning. > > So everyone agrees with almost everything. Nobody is looking for > conflicts. But these various interests have not been _clearly_ > formalized. Licenses are tools for manipulating behavior. Until the > above is clearly in line with each other, the license will be a tool for > lawyers to cause problems for people working for free. This is why I > support a move to go through the JSR process and formalize the > relationship. > > My concern is not really Sun comming after RXTX with Lawyers. I have a > great deal of respect for Sun going back to their sunsite project. My > concern is how lawyers think. They look at the intent which is not all in > line. Then I get what feels like insane conference calls that cost > companies over $2000 an hour which pisses me off to no end. Companies > paying lawyers to take time from developers for free. This really does > happen when a fortune 50 company developer asks their legal department if > they can use rxtx. I don't have enough bullets for that. > > The way you avoid this is formalize everones intent so lawyers don't > make conference call meetings in outlook. I want to put those lawyers out > of work and if it takes a little discomfort, thats perfectly fine. > > -- > Trent Jarvi > tjarvi at qbang.org > > Trent: GREAT MAIL, I hate lawyers too. From naranjo.manuel at gmail.com Sat Jul 8 07:52:47 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 10:52:47 -0300 Subject: [Rxtx] Java installer In-Reply-To: <200607080235.29486.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <44AEE87F.60202@gmail.com> <200607080235.29486.pascal@quies.net> Message-ID: <44AFB8AF.50403@gmail.com> > > You are right. IzPack looks like the right tool for this job. > > As far as I can see there is no commandline support but I'll get over it. ;) Actually there is a way to execute native app in the Underlaying OS. Check out the JavaDOC and all the documentation given by them. If you need to also generate warper around the jar files, check this projects out: http://launch4j.sourceforge.net and http://jsmooth.sourceforge.net/ I have been able to make and exe with jsmooth that does not need to have RXTX installed if you want I can send the source of it. But it is simple. Do not put the jar inside the exe file, and add to the classpath relative paths to rxtx jar and then your jar file, and then add to the JVM command line (I can't remeber the actual name of it :P) -Djava.library.path=bin\ (Or were ever you installed the binary package). I have tryied doing the same with Java Comm from Sun but it actually is imposible, the main difference to me that make me move to RXTX, was that there is no need to have the javax.comm.properties file, which gave me lot of headaches. Regards, Manuel. From naranjo.manuel at gmail.com Sat Jul 8 08:03:58 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 11:03:58 -0300 Subject: [Rxtx] License question. Message-ID: <44AFBB4E.70808@gmail.com> Hi: I have a question, haven't you ever thought about changing RXTX license from GNU/GPL to a more open license like Apache v2 or BSD like?. As far as I understand if I make an application that uses RXTX libraries, I must release my app under the GNU/GPL. I have no problem with that in fact I'm an Open Source user and defender. The fact is that in same cases the applications made by one, could get into hands of a company that needs to release a Closed Source app. I understand that using GNU/GPL do not give you the power to do this, but a more "open" license like Apache does. By "open" I mean that the license respects the Open Source license, but also lives the user the opportunity to use the library in closed source programs. I have seen that there is an exception to the license that applies to RXTX v2.0-5 and above, the only problem with it is that Java Comm Api (the jar file) needs the file javax.comm.properties installed correctly, which in lot of cases is a headache. RXTX jar does not need this, actually I think that RXTX is more user friendly than Java Comm. Maybe there has been a discussion like this before, but I just wanted to ask, and to get an answer that is adequate to our time. Regards, Manuel From pascal at quies.net Sat Jul 8 14:03:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:03:13 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <44AFFF2C.8090005@gmail.com> References: <200607081944.41123.pascal@quies.net> <44AFFF2C.8090005@gmail.com> Message-ID: <200607082203.13696.pascal@quies.net> Op zaterdag 8 juli 2006 20:53, schreef Manuel Naranjo: > Even more, the variable ${CURRENT_JRE} referees to the actuall JVM as > far as I know, so you will have no difference in installing towards a JDK. As far as the installation instructions go the location of the libraries is the following. Windows * JRE: $JAVA_HOME/bin/ * JDK: $JAVA_HOME/jre/bin/ UNIX * JRE: $JAVA_HOME/lib/ * JRE: $JAVA_HOME/jre/lib/ From pascal at quies.net Sat Jul 8 14:04:50 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:04:50 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <44AFFEE7.3090306@gmail.com> References: <200607081944.41123.pascal@quies.net> <44AFFEE7.3090306@gmail.com> Message-ID: <200607082204.50712.pascal@quies.net> Op zaterdag 8 juli 2006 20:52, schreef Manuel Naranjo: > Pascal: > I can't get exactly your point, but my installer was to avoid modifying > the users JDK or JRE. Download this app made by me, and you will get my > point: > http://www.aircable.net/downloads/AIRcable_Configuration_Utility_v0.2_ALPHA >_1.zip, this app bundles RXTX library inside the zip file, and does not need > RXTX installed on the Users system. > Manuel I didn't get the point indeed and I still don't get it. :$ The installation instructions state that RXTX.jar must be in the classpath and the libraries should go as my previous mail stated. Do you have another way? I don't have Windows so i can't run that EXE. From pascal at quies.net Sat Jul 8 14:05:40 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:05:40 +0200 Subject: [Rxtx] Java installer In-Reply-To: <7D4FA261-44FA-4A6E-8EB9-7A7B0116BB2C@buechse.de> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <7D4FA261-44FA-4A6E-8EB9-7A7B0116BB2C@buechse.de> Message-ID: <200607082205.40527.pascal@quies.net> Op zaterdag 8 juli 2006 18:02, schreef Joachim Buechse: > as soon as the 2.1.8 version is "released" I'll happily provide you ? > with a precompiled library for Mac OSX. The currently tagged version ? > is 2.17 which has a non standard implementation for OSX. Perfect! :) Do you have a idea when that will be? Like this month? From pascal at quies.net Sat Jul 8 14:14:44 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:14:44 +0200 Subject: [Rxtx] Java installer In-Reply-To: <44AFB8AF.50403@gmail.com> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080235.29486.pascal@quies.net> <44AFB8AF.50403@gmail.com> Message-ID: <200607082214.45115.pascal@quies.net> Op zaterdag 8 juli 2006 15:52, schreef Manuel Naranjo: > > You are right. IzPack looks like the right tool for this job. > > > > As far as I can see there is no commandline support but I'll get over it. > > ;) > > Actually there is a way to execute native app in the Underlaying OS. > Check out the JavaDOC and all the documentation given by them. > If you need to also generate warper around the jar files, check this > projects out: > http://launch4j.sourceforge.net and http://jsmooth.sourceforge.net/ > I have been able to make and exe with jsmooth that does not need to > have RXTX installed if you want I can send the source of it. But it is > simple. > Do not put the jar inside the exe file, and add to the classpath > relative paths to rxtx jar and then your jar file, and then add to the > JVM command line (I can't remeber the actual name of it :P) > -Djava.library.path=bin\ (Or were ever you installed the binary package). > I have tryied doing the same with Java Comm from Sun but it actually is > imposible, the main difference to me that make me move to RXTX, was that > there is no need to have the javax.comm.properties file, which gave me > lot of headaches. > Regards, > Manuel. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Those are verry interresting and impressive tools for Windows. However, I wanted (and still do) a universal installer for all supported platforms as a single JAR. IzPack seemed quite suitable but it is limited and not well written so I'me still searching... Thanks for the help though. :) From pascal at quies.net Sat Jul 8 14:19:59 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:19:59 +0200 Subject: [Rxtx] License question. In-Reply-To: <44AFBB4E.70808@gmail.com> References: <44AFBB4E.70808@gmail.com> Message-ID: <200607082219.59514.pascal@quies.net> I thought of the same thing. The modified BSD license would certainly make it more eazy and acceptable for Sun to include RXTX in theire products. Unfortunately in general people who chose GPL don't like other licenses. ;) Op zaterdag 8 juli 2006 16:03, schreef Manuel Naranjo: > Hi: > I have a question, haven't you ever thought about changing RXTX license > from GNU/GPL to a more open license like Apache v2 or BSD like?. > As far as I understand if I make an application that uses RXTX > libraries, I must release my app under the GNU/GPL. I have no problem > with that in fact I'm an Open Source user and defender. > The fact is that in same cases the applications made by one, could get > into hands of a company that needs to release a Closed Source app. I > understand that using GNU/GPL do not give you the power to do this, but > a more "open" license like Apache does. By "open" I mean that the > license respects the Open Source license, but also lives the user the > opportunity to use the library in closed source programs. > I have seen that there is an exception to the license that applies to > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > (the jar file) needs the file javax.comm.properties installed correctly, > which in lot of cases is a headache. RXTX jar does not need this, > actually I think that RXTX is more user friendly than Java Comm. > Maybe there has been a discussion like this before, but I just wanted to > ask, and to get an answer that is adequate to our time. > Regards, > Manuel > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jul 8 15:30:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 15:30:31 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <44AFBB4E.70808@gmail.com> References: <44AFBB4E.70808@gmail.com> Message-ID: On Sat, 8 Jul 2006, Manuel Naranjo wrote: > Hi: > I have a question, haven't you ever thought about changing RXTX license > from GNU/GPL to a more open license like Apache v2 or BSD like?. > As far as I understand if I make an application that uses RXTX > libraries, I must release my app under the GNU/GPL. I have no problem > with that in fact I'm an Open Source user and defender. > The fact is that in same cases the applications made by one, could get > into hands of a company that needs to release a Closed Source app. I > understand that using GNU/GPL do not give you the power to do this, but > a more "open" license like Apache does. By "open" I mean that the > license respects the Open Source license, but also lives the user the > opportunity to use the library in closed source programs. > I have seen that there is an exception to the license that applies to > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > (the jar file) needs the file javax.comm.properties installed correctly, > which in lot of cases is a headache. RXTX jar does not need this, > actually I think that RXTX is more user friendly than Java Comm. > Maybe there has been a discussion like this before, but I just wanted to > ask, and to get an answer that is adequate to our time. > Regards, > Manuel Hi Manuel As one of the primary copyright 'owners' and a representative of all the people who have worked on RXTX I feel very compelled to comment on this. I often observe this misconception and just ignore it. RXTX is very commercial friendly both in open and closed source. The license is LGPL not GPL. This allows for linking to any application you like without sharing yoru application code. It is not unlike Apache or BSD in that sense. I like the BSD license but not in this case. The difference is you can not keep your changes to rxtx itself if your product is distributed in practice. To me this makes no sense and is a basic flaw in BSD licensing for libraries. I have _no_ intentions of "competing" with various incarnations of RXTX. If you use RXTX in your commercial application, I hope for two things. First I want you to do well for using rxtx even if you somehow compete with me in the commercial world. Second I want to see changes to RXTX come back to RXTX so we all do well for choosing RXTX. This is not possible with the BSD, MIT ... licenses. They result in multiple forks from the code and this is used to disrupt 'standards' by companies you would recognize (I no longer mention any company when saying bad things without fair notice). Your code is your code. Thats how the LGPL works. But don't take RXTX and fork it where I or anyone else that has worked on RXTX can see it. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Sat Jul 8 16:06:17 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 00:06:17 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> Message-ID: <200607090006.18197.pascal@quies.net> Op zaterdag 8 juli 2006 23:30, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Manuel Naranjo wrote: > > Hi: > > I have a question, haven't you ever thought about changing RXTX license > > from GNU/GPL to a more open license like Apache v2 or BSD like?. > > As far as I understand if I make an application that uses RXTX > > libraries, I must release my app under the GNU/GPL. I have no problem > > with that in fact I'm an Open Source user and defender. > > The fact is that in same cases the applications made by one, could get > > into hands of a company that needs to release a Closed Source app. I > > understand that using GNU/GPL do not give you the power to do this, but > > a more "open" license like Apache does. By "open" I mean that the > > license respects the Open Source license, but also lives the user the > > opportunity to use the library in closed source programs. > > I have seen that there is an exception to the license that applies to > > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > > (the jar file) needs the file javax.comm.properties installed correctly, > > which in lot of cases is a headache. RXTX jar does not need this, > > actually I think that RXTX is more user friendly than Java Comm. > > Maybe there has been a discussion like this before, but I just wanted to > > ask, and to get an answer that is adequate to our time. > > Regards, > > Manuel > > Hi Manuel > > As one of the primary copyright 'owners' and a representative of all the > people who have worked on RXTX I feel very compelled to comment on this. > I often observe this misconception and just ignore it. > > RXTX is very commercial friendly both in open and closed source. The > license is LGPL not GPL. This allows for linking to any application you > like without sharing yoru application code. It is not unlike Apache or > BSD in that sense. I like the BSD license but not in this case. > > The difference is you can not keep your changes to rxtx itself if your > product is distributed in practice. To me this makes no sense and is a > basic flaw in BSD licensing for libraries. I have _no_ intentions of > "competing" with various incarnations of RXTX. If you use RXTX in your > commercial application, I hope for two things. First I want you to do > well for using rxtx even if you somehow compete with me in the commercial > world. Second I want to see changes to RXTX come back to RXTX so we all > do well for choosing RXTX. > > This is not possible with the BSD, MIT ... licenses. They result in > multiple forks from the code and this is used to disrupt 'standards' by > companies you would recognize (I no longer mention any company when > saying bad things without fair notice). > > Your code is your code. Thats how the LGPL works. But don't take RXTX > and fork it where I or anyone else that has worked on RXTX can see it. > > -- > Trent Jarvi Hallo Trent, The BSD license wants to give and GPL wants to improve the public available content. What do you prefer? If you build the code to provide everyone a better experience then the BSD license would be suitable since the business acceptance is much higher. If you see this as a crucial component to build a complete free Java infrastructure that has no place for commerce then the GPL would be better In both situations RXTX will be free. I say that the chance a company would not contribute does not outweight the chance that the API is less available to the users. The entire API is a dead end. Mustang has USB support. Please let's make this as good as it gets. From tjarvi at qbang.org Sat Jul 8 16:09:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 16:09:31 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <200607082219.59514.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > I thought of the same thing. The modified BSD license would certainly make it > more eazy and acceptable for Sun to include RXTX in theire products. > > Unfortunately in general people who chose GPL don't like other licenses. ;) > If Sun can not accept the license, thats their problem. I have no problem with Sun distributing RXTX and working with the community. I've even stepped down as then primary and given that power to Doug to facilitate different opinions. For licensing changes, I am the primary copyright owner and have very strong opinions though I have a great deal of respect for everyone that has contributed to RXTX. Sun has their process and we have our process - screwy but a process and real. RXTX is not going to rubber stamp into any company without process that gives major power to the contributors to RXTX. There is a community here and it is not Sun's. (It isn't "gnu" either; the license is closest) This isn't about Trent. He is a wierd guy you should fear. That said, I'm not fundamentally against Sun distributing RXTX and changing package names. What I am fundametally against is multiple RXTXs. There isnt enough space for that game. -- Trent Jarvi tarvi at qbang.org From pascal at quies.net Sat Jul 8 16:25:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 00:25:24 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> Message-ID: <200607090025.24884.pascal@quies.net> Op zondag 9 juli 2006 00:09, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > > I thought of the same thing. The modified BSD license would certainly > > make it more eazy and acceptable for Sun to include RXTX in theire > > products. > > > > Unfortunately in general people who chose GPL don't like other licenses. > > ;) > > If Sun can not accept the license, thats their problem. > > I have no problem with Sun distributing RXTX and working with the > community. I've even stepped down as then primary and given that power to > Doug to facilitate different opinions. For licensing changes, I am the > primary copyright owner and have very strong opinions though I have a > great deal of respect for everyone that has contributed to RXTX. > > Sun has their process and we have our process - screwy but a process and > real. RXTX is not going to rubber stamp into any company without process > that gives major power to the contributors to RXTX. There is a community > here and it is not Sun's. (It isn't "gnu" either; the license is closest) > This isn't about Trent. He is a wierd guy you should fear. Hahaha, I found him very reasonable. The LGPL is not going to prevent forks. Any company which would take the code and keep little improvements to theirselves is stupid since they throw away a great deal of support and they know it. RXTX works. It needs a huge cleanup and more strict platform definitions but that's just a matter of time. What do you have to loose? From tjarvi at qbang.org Sat Jul 8 16:33:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 16:33:32 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <200607090025.24884.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> <200607090025.24884.pascal@quies.net> Message-ID: On Sun, 9 Jul 2006, Pascal S. de Kloe wrote: > Op zondag 9 juli 2006 00:09, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> I thought of the same thing. The modified BSD license would certainly >>> make it more eazy and acceptable for Sun to include RXTX in theire >>> products. >>> >>> Unfortunately in general people who chose GPL don't like other licenses. >>> ;) >> >> If Sun can not accept the license, thats their problem. >> >> I have no problem with Sun distributing RXTX and working with the >> community. I've even stepped down as then primary and given that power to >> Doug to facilitate different opinions. For licensing changes, I am the >> primary copyright owner and have very strong opinions though I have a >> great deal of respect for everyone that has contributed to RXTX. >> >> Sun has their process and we have our process - screwy but a process and >> real. RXTX is not going to rubber stamp into any company without process >> that gives major power to the contributors to RXTX. There is a community >> here and it is not Sun's. (It isn't "gnu" either; the license is closest) >> This isn't about Trent. He is a wierd guy you should fear. > > Hahaha, I found him very reasonable. > > The LGPL is not going to prevent forks. No it will not, but it will allow for you or me to view forks and absorb them. It renders forks of RXTX useless at the price of whatever product is shipped. I would ask that you consider the larger picture here. Termios and DCB are almost dead but almost being used like a VISA interface. Everyone just wants it to work but it does not always. So your proposal is to make mulitiple deal protocols? -- Trent Jarvi tjarvi at qbang.org From naranjo.manuel at gmail.com Sat Jul 8 17:20:44 2006 From: naranjo.manuel at gmail.com (Naranjo Manuel Francisco) Date: Sat, 8 Jul 2006 20:20:44 -0300 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> Message-ID: <360bc8300607081620x4e5d0f23h88fef8d81e6b6a0b@mail.gmail.com> Sorry, my mistake then, I thought the license was GPL not LGPL, I guess I readed some thing badly. I have readed all the emails, and you are right, there is no need for a Fork of RXTX, I think it works right as it is. So I can make my app Apache v2 with out any worry, because RXTX is LGPL :), great then. From tjarvi at qbang.org Sat Jul 8 17:57:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 17:57:05 -0600 (MDT) Subject: [Rxtx] License question ver2. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> <200607090025.24884.pascal@quies.net> Message-ID: Are there any more questions relating to this subject? From tjarvi at qbang.org Sat Jul 8 21:14:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 21:14:09 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <200607090006.18197.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607090006.18197.pascal@quies.net> Message-ID: On Sun, 9 Jul 2006, Pascal S. de Kloe wrote: > Op zaterdag 8 juli 2006 23:30, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Manuel Naranjo wrote: >>> Hi: >>> I have a question, haven't you ever thought about changing RXTX license >>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>> As far as I understand if I make an application that uses RXTX >>> libraries, I must release my app under the GNU/GPL. I have no problem >>> with that in fact I'm an Open Source user and defender. >>> The fact is that in same cases the applications made by one, could get >>> into hands of a company that needs to release a Closed Source app. I >>> understand that using GNU/GPL do not give you the power to do this, but >>> a more "open" license like Apache does. By "open" I mean that the >>> license respects the Open Source license, but also lives the user the >>> opportunity to use the library in closed source programs. >>> I have seen that there is an exception to the license that applies to >>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>> (the jar file) needs the file javax.comm.properties installed correctly, >>> which in lot of cases is a headache. RXTX jar does not need this, >>> actually I think that RXTX is more user friendly than Java Comm. >>> Maybe there has been a discussion like this before, but I just wanted to >>> ask, and to get an answer that is adequate to our time. >>> Regards, >>> Manuel >> >> Hi Manuel >> >> As one of the primary copyright 'owners' and a representative of all the >> people who have worked on RXTX I feel very compelled to comment on this. >> I often observe this misconception and just ignore it. >> >> RXTX is very commercial friendly both in open and closed source. The >> license is LGPL not GPL. This allows for linking to any application you >> like without sharing yoru application code. It is not unlike Apache or >> BSD in that sense. I like the BSD license but not in this case. >> >> The difference is you can not keep your changes to rxtx itself if your >> product is distributed in practice. To me this makes no sense and is a >> basic flaw in BSD licensing for libraries. I have _no_ intentions of >> "competing" with various incarnations of RXTX. If you use RXTX in your >> commercial application, I hope for two things. First I want you to do >> well for using rxtx even if you somehow compete with me in the commercial >> world. Second I want to see changes to RXTX come back to RXTX so we all >> do well for choosing RXTX. >> >> This is not possible with the BSD, MIT ... licenses. They result in >> multiple forks from the code and this is used to disrupt 'standards' by >> companies you would recognize (I no longer mention any company when >> saying bad things without fair notice). >> >> Your code is your code. Thats how the LGPL works. But don't take RXTX >> and fork it where I or anyone else that has worked on RXTX can see it. >> >> -- >> Trent Jarvi > > Hallo Trent, > > The BSD license wants to give and GPL wants to improve the public available > content. What do you prefer? > > If you build the code to provide everyone a better experience then the BSD > license would be suitable since the business acceptance is much higher. > If you see this as a crucial component to build a complete free Java > infrastructure that has no place for commerce then the GPL would be better > In both situations RXTX will be free. > > I say that the chance a company would not contribute does not outweight the > chance that the API is less available to the users. > The entire API is a dead end. Mustang has USB support. Please let's make this > as good as it gets. Hi Pascal I can not speak for any company here. I just happen to have become interesting to companies. With RXTX, the intent has always been to improve functionality. I don't play between the two worlds except for borrowing a scope at late in the evening. Thats rxtx and there is nothing else going on. Note that the RXTX library is LGPL. I would be interested in knowing where the GPL confusion comes from. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Jul 9 04:46:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 09 Jul 2006 06:46:49 -0400 Subject: [Rxtx] Java installer In-Reply-To: <200607082214.45115.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080235.29486.pascal@quies.net> <44AFB8AF.50403@gmail.com> <200607082214.45115.pascal@quies.net> Message-ID: Hi All, The problem of improving Java's ability to install and configure applications is a topic of current research. Configuration is a loaded word. When I think of configuration, I think, discover the properties of the operating environment and configure the software to work within that environment. Properties may include, but are not limited to, number and kind of monitors, serial ports, JVM versions, native method libs, graphics cards, graphics libs, write access to directories, changing the default screen saver (a new research topic) etc. There are two deployment solutions I can think of, please correct me, if I have left something out: 1. A source code distro with build tools (i.e., make and or ant) that enable the user to do a build for the target platform. 2. A binary distro built for each platform. Now, Java (in theory), is compile once, run anywhere. This assumes you don't use native methods. Once you start using native methods, you end up with many builds of the libs (one for each supported platform). Assuming you want binary distros for each platform, then you are faced with how to deploy them. Here are two basic approaches I know: 1. Build an application installer 2. Build a web-start distribution Some would argue for the application installer, as this is what many people are used to. Others will argue for a web-start distro. For a JNI-based application, like one that makes use of RXTX, I don't know which approach is "better". To know, one must first establish what "better" means. I think there must be (at least) two properties here: 1. Minimal installation effort 2. Trust. For minimal installation effort, I think that I should be able to download software, on demand, and just run it. Updates are obtained with minimal effort. Everything just works. And on all platforms that I use. For trust, I want to make sure I know the author and am able to hold someone accountable for application creation. I need to be able to thwart man-in-the-middle attacks and assure my user-base that I have signed off on my software. I have been making use of web-start, as a multi-year experiment. I have had mixed results. Particularly with more complex installs that make use of Java3d. In my view, several open problems remain. And cross-platform testing is needed for each major new application, platform, or major native method revision. On the other hand, I have had some good results with Java web start and RXTX. I can cite: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Which is an address book program that should identify your serial port and enable dialing via the modem. The web start system seems to be able to adapt to multiple operating environments. The question of how well this deploys remains open. It should work on mac, windows and linux. If people want to try it and give me feedback, I would appreciate it. Deployment is semi-automatic using Project Initium. This is described in: http://show.docjava.com:8086/pub/document/jot/web.pdf and http://show.docjava.com:8086/pub/document/jot/initium.pdf Thanks! - Doug >Op zaterdag 8 juli 2006 15:52, schreef Manuel Naranjo: >> > You are right. IzPack looks like the right tool for this job. >> > >> > As far as I can see there is no commandline support but I'll get over it. >> > ;) >> >> Actually there is a way to execute native app in the Underlaying OS. >> Check out the JavaDOC and all the documentation given by them. >> If you need to also generate warper around the jar files, check this > > projects out: > > http://launch4j.sourceforge.net and http://jsmooth.sourceforge.net/ > > I have been able to make and exe with jsmooth that does not need to >> have RXTX installed if you want I can send the source of it. But it is >> simple. >> Do not put the jar inside the exe file, and add to the classpath >> relative paths to rxtx jar and then your jar file, and then add to the >> JVM command line (I can't remeber the actual name of it :P) > > -Djava.library.path=bin\ (Or were ever you installed the binary package). >> I have tryied doing the same with Java Comm from Sun but it actually is >> imposible, the main difference to me that make me move to RXTX, was that >> there is no need to have the javax.comm.properties file, which gave me >> lot of headaches. >> Regards, >> Manuel. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >Those are verry interresting and impressive tools for Windows. >However, I wanted (and still do) a universal installer for all supported >platforms as a single JAR. IzPack seemed quite suitable but it is limited and >not well written so I'me still searching... > >Thanks for the help though. :) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 9 05:15:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 13:15:13 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607090006.18197.pascal@quies.net> Message-ID: <200607091315.14053.pascal@quies.net> Op zondag 9 juli 2006 05:14, schreef Trent Jarvi: > Hi Pascal > > I can not speak for any company here. I just happen to have become > interesting to companies. > > With RXTX, the intent has always been to improve functionality. > > I don't play between the two worlds except for borrowing a scope at late > in the evening. Thats rxtx and there is nothing else going on. > > Note that the RXTX library is LGPL. I would be interested in knowing > where the GPL confusion comes from. Hi Trent, The license is stated clearly everywhere so don't worry. You are right that the LGPL should not be a problem for companies. The problem is, especially in larger companies, that the people who take the decissions think differend. When they hear about the demands of the license they rather spend "some" money on a commercial solution just to be sure because the trouble it might cause is not worth it. From pascal at quies.net Sun Jul 9 05:15:41 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 13:15:41 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607090025.24884.pascal@quies.net> Message-ID: <200607091315.41848.pascal@quies.net> Op zondag 9 juli 2006 00:33, schreef Trent Jarvi: > I would ask that you consider the larger picture here. Termios and DCB > are almost dead but almost being used like a VISA interface. Everyone > just wants it to work but it does not always. > > So your proposal is to make mulitiple deal protocols? No, nothing like that. Just use native calls where possible. I'll send you some things this week anyway. From pascal at quies.net Sun Jul 9 05:52:11 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 13:52:11 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607082214.45115.pascal@quies.net> Message-ID: <200607091352.11696.pascal@quies.net> Op zondag 9 juli 2006 12:46, schreef Dr. Douglas Lyon: > Hi All, > The problem of improving Java's ability to > install and configure applications is a topic of current research. > > Configuration is a loaded word. When I think of configuration, > I think, discover the properties of the operating environment and > configure the software to work within that environment. > > Properties may include, but are not limited to, number and > kind of monitors, serial ports, JVM versions, native method libs, > graphics cards, graphics libs, write access to directories, > changing the default screen saver (a new research topic) etc. > > There are two deployment solutions I can think of, > please correct me, if I have left something out: > 1. A source code distro with build tools (i.e., make and or ant) that > enable the user to do a build for the target platform. > 2. A binary distro built for each platform. > > Now, Java (in theory), is compile once, run anywhere. This assumes you > don't use native methods. Once you start using native methods, > you end up with many builds of the libs (one for each supported platform). > > Assuming you want binary distros for each platform, then you are faced with > how to deploy them. Here are two basic approaches I know: > 1. Build an application installer > 2. Build a web-start distribution > > Some would argue for the application installer, as this is what > many people are used to. Others will argue for a web-start distro. > > For a JNI-based application, like one that makes use of RXTX, > I don't know which approach is "better". To know, one must > first establish what "better" means. I think there must be (at least) two > properties here: > 1. Minimal installation effort > 2. Trust. > > For minimal installation effort, I think that I should be able to download > software, on demand, and just run it. Updates are obtained with minimal > effort. Everything just works. And on all platforms that I use. > > For trust, I want to make sure I know the author and am able to hold > someone accountable for application creation. I need to be able to thwart > man-in-the-middle > attacks and assure my user-base that I have signed off on my software. > > I have been making > use of web-start, as a multi-year experiment. > > I have had mixed results. Particularly with more complex installs > that make use of Java3d. In my view, several open problems remain. > And cross-platform testing is needed for each major new application, > platform, or major native method revision. > > On the other hand, I have had some good results with Java web start > and RXTX. I can cite: > http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jn >lp Which is an address book program that should identify your > serial port and enable dialing via the modem. > > The web start system seems to be able to adapt to multiple operating > environments. The question of how well this deploys remains open. > > It should work on mac, windows and linux. If people want to try it > and give me feedback, I would appreciate it. > > Deployment is semi-automatic using Project Initium. This is described in: > http://show.docjava.com:8086/pub/document/jot/web.pdf > and > http://show.docjava.com:8086/pub/document/jot/initium.pdf > > Thanks! > - Doug Hello Dough, We are bumping into the same problems. Youre web-based plan is definitely the way to go. I still didn't find a way to get around two IzPack problems without hacking into the code and it's taking too long so I started again on the inital plan. The CommunicationAPI class does leave the trust thing up to the implementation. This means that users can download and run the JAR and other applications can include the jar to install things if needed. If you could "Initum" this process then RXTX has no installating limits anymore. From joachim at buechse.de Sun Jul 9 07:13:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 9 Jul 2006 15:13:34 +0200 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44AFBB4E.70808@gmail.com> References: <44AFBB4E.70808@gmail.com> Message-ID: <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> Manuel, a simple way to avoid the javax.comm.properties file is to include a class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } into your application jar file and make sure, that you include the javax.comm jar after it. That's all you need. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 08.07.2006, at 16:03, Manuel Naranjo wrote: > Hi: > I have a question, haven't you ever thought about changing RXTX > license > from GNU/GPL to a more open license like Apache v2 or BSD like?. > As far as I understand if I make an application that uses RXTX > libraries, I must release my app under the GNU/GPL. I have no problem > with that in fact I'm an Open Source user and defender. > The fact is that in same cases the applications made by one, could get > into hands of a company that needs to release a Closed Source app. I > understand that using GNU/GPL do not give you the power to do this, > but > a more "open" license like Apache does. By "open" I mean that the > license respects the Open Source license, but also lives the user the > opportunity to use the library in closed source programs. > I have seen that there is an exception to the license that applies to > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > (the jar file) needs the file javax.comm.properties installed > correctly, > which in lot of cases is a headache. RXTX jar does not need this, > actually I think that RXTX is more user friendly than Java Comm. > Maybe there has been a discussion like this before, but I just > wanted to > ask, and to get an answer that is adequate to our time. > Regards, > Manuel > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Sun Jul 9 07:19:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 9 Jul 2006 15:19:43 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607082203.13696.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> <44AFFF2C.8090005@gmail.com> <200607082203.13696.pascal@quies.net> Message-ID: <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> Pascal, I would strongly suggest NOT to follow these installation instructions for OSX. It "poisons" the global Java VM with a specific implementation of RXTX. Plus: there is not one, but several Java VMs installed on every version of OSX. An application specific file and global preference pane defines which VM launches which application. There is really no good reason to install RXTX globally. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 08.07.2006, at 22:03, Pascal S. de Kloe wrote: > > As far as the installation instructions go the location of the > libraries is > the following. > > Windows > * JRE: $JAVA_HOME/bin/ > * JDK: $JAVA_HOME/jre/bin/ > > UNIX > * JRE: $JAVA_HOME/lib/ > * JRE: $JAVA_HOME/jre/lib/ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 9 09:01:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 17:01:24 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> References: <200607081944.41123.pascal@quies.net> <200607082203.13696.pascal@quies.net> <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> Message-ID: <200607091701.24661.pascal@quies.net> Op zondag 9 juli 2006 15:19, schreef Joachim Buechse: > Pascal, > > I would strongly suggest NOT to follow these installation > instructions for OSX. It "poisons" the global Java VM with a specific > implementation of RXTX. Plus: there is not one, but several Java VMs > installed on every version of OSX. An application specific file and > global preference pane defines which VM launches which application. > There is really no good reason to install RXTX globally. I see your points. How can you use the extension non-globally? I asked the same thing for Windows to Manuel. The system will allow you to detect any implementation. So the "poison" becomes a alternative. Applications can install the extension if needed to the current runtime with something like: CommunicationAPI comm = new CommunicationAPI(); if (! comm.available()) { if (comm.installRXTX()) restart(); else handleError("I need the extension!"); } From naranjo.manuel at gmail.com Sun Jul 9 10:36:21 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 09 Jul 2006 13:36:21 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> Message-ID: <44B13085.2000805@gmail.com> Joachim, Does that really work???? I will try it later, thanks :) Manuel > Manuel, > > a simple way to avoid the javax.comm.properties file is to include a > class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > into your application jar file and make sure, that you include the > javax.comm jar after it. That's all you need. > > Regards, > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 08.07.2006, at 16:03, Manuel Naranjo wrote: > >> Hi: >> I have a question, haven't you ever thought about changing RXTX >> license >> from GNU/GPL to a more open license like Apache v2 or BSD like?. >> As far as I understand if I make an application that uses RXTX >> libraries, I must release my app under the GNU/GPL. I have no problem >> with that in fact I'm an Open Source user and defender. >> The fact is that in same cases the applications made by one, could get >> into hands of a company that needs to release a Closed Source app. I >> understand that using GNU/GPL do not give you the power to do this, >> but >> a more "open" license like Apache does. By "open" I mean that the >> license respects the Open Source license, but also lives the user the >> opportunity to use the library in closed source programs. >> I have seen that there is an exception to the license that applies to >> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >> (the jar file) needs the file javax.comm.properties installed >> correctly, >> which in lot of cases is a headache. RXTX jar does not need this, >> actually I think that RXTX is more user friendly than Java Comm. >> Maybe there has been a discussion like this before, but I just >> wanted to >> ask, and to get an answer that is adequate to our time. >> Regards, >> Manuel >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jul 9 10:50:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Jul 2006 10:50:11 -0600 (MDT) Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44B13085.2000805@gmail.com> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> Message-ID: I won't prevent people from discussing this hack. You can discuss anything on the list including things I do not agree with. But I do not agree with that hack. That is not in line with the history of RXTX respecting all that contribute including Sun. If you do this, it is your own thing. Agreeing to disagree is fine and usually the default here :). I just want to make it clear I do disagree. On Sun, 9 Jul 2006, Manuel Naranjo wrote: > Joachim, > Does that really work???? I will try it later, thanks :) > Manuel > >> Manuel, >> >> a simple way to avoid the javax.comm.properties file is to include a >> class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> into your application jar file and make sure, that you include the >> javax.comm jar after it. That's all you need. >> >> Regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 08.07.2006, at 16:03, Manuel Naranjo wrote: >> >>> Hi: >>> I have a question, haven't you ever thought about changing RXTX >>> license >>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>> As far as I understand if I make an application that uses RXTX >>> libraries, I must release my app under the GNU/GPL. I have no problem >>> with that in fact I'm an Open Source user and defender. >>> The fact is that in same cases the applications made by one, could get >>> into hands of a company that needs to release a Closed Source app. I >>> understand that using GNU/GPL do not give you the power to do this, >>> but >>> a more "open" license like Apache does. By "open" I mean that the >>> license respects the Open Source license, but also lives the user the >>> opportunity to use the library in closed source programs. >>> I have seen that there is an exception to the license that applies to >>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>> (the jar file) needs the file javax.comm.properties installed >>> correctly, >>> which in lot of cases is a headache. RXTX jar does not need this, >>> actually I think that RXTX is more user friendly than Java Comm. >>> Maybe there has been a discussion like this before, but I just >>> wanted to >>> ask, and to get an answer that is adequate to our time. >>> Regards, >>> Manuel >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From naranjo.manuel at gmail.com Sun Jul 9 11:43:33 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 09 Jul 2006 14:43:33 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> Message-ID: <44B14045.9030601@gmail.com> Trent: Do you know any other way, to use Java Comm API with RXTX with out the javax.comm.properties?. Have any information about how is the JSR going? Regards, Manuel > > I won't prevent people from discussing this hack. You can discuss > anything on the list including things I do not agree with. > > But I do not agree with that hack. That is not in line with the history > of RXTX respecting all that contribute including Sun. If you do this, > it is your own thing. > > Agreeing to disagree is fine and usually the default here :). I just > want to make it clear I do disagree. > > On Sun, 9 Jul 2006, Manuel Naranjo wrote: > >> Joachim, >> Does that really work???? I will try it later, thanks :) >> Manuel >> >>> Manuel, >>> >>> a simple way to avoid the javax.comm.properties file is to include a >>> class >>> >>> package com.sun.comm; >>> public class SolarisDriver extends gnu.io.RXTXCommDriver { >>> } >>> >>> into your application jar file and make sure, that you include the >>> javax.comm jar after it. That's all you need. >>> >>> Regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich >>> >>> >>> On 08.07.2006, at 16:03, Manuel Naranjo wrote: >>> >>>> Hi: >>>> I have a question, haven't you ever thought about changing RXTX >>>> license >>>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>>> As far as I understand if I make an application that uses RXTX >>>> libraries, I must release my app under the GNU/GPL. I have no problem >>>> with that in fact I'm an Open Source user and defender. >>>> The fact is that in same cases the applications made by one, could get >>>> into hands of a company that needs to release a Closed Source app. I >>>> understand that using GNU/GPL do not give you the power to do this, >>>> but >>>> a more "open" license like Apache does. By "open" I mean that the >>>> license respects the Open Source license, but also lives the user the >>>> opportunity to use the library in closed source programs. >>>> I have seen that there is an exception to the license that applies to >>>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>>> (the jar file) needs the file javax.comm.properties installed >>>> correctly, >>>> which in lot of cases is a headache. RXTX jar does not need this, >>>> actually I think that RXTX is more user friendly than Java Comm. >>>> Maybe there has been a discussion like this before, but I just >>>> wanted to >>>> ask, and to get an answer that is adequate to our time. >>>> Regards, >>>> Manuel >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Jul 9 11:53:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Jul 2006 11:53:19 -0600 (MDT) Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44B14045.9030601@gmail.com> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> Message-ID: Hi Manuel I do not know of another way. If you look at rxtx.org, even the compiled version is hard to find, always late and not what you want. At rxtx.org we just worry about the source and do a minimal effort to provide binaries. I'd love nothing more than someone to start selling RXTX binaries or working with us like Doug is to deliver the problems solved to users. The Free here is Freedom. Not price. There is a need for services rxtx.org is not able to provide well. That said I do not ever expect to recieve anything. It just makes sense for everyone to work together and compete outside of the source. On Sun, 9 Jul 2006, Manuel Naranjo wrote: > Trent: > Do you know any other way, to use Java Comm API with RXTX with out the > javax.comm.properties?. > Have any information about how is the JSR going? > Regards, > Manuel >> >> I won't prevent people from discussing this hack. You can discuss >> anything on the list including things I do not agree with. >> >> But I do not agree with that hack. That is not in line with the history >> of RXTX respecting all that contribute including Sun. If you do this, >> it is your own thing. >> >> Agreeing to disagree is fine and usually the default here :). I just >> want to make it clear I do disagree. >> >> On Sun, 9 Jul 2006, Manuel Naranjo wrote: >> >>> Joachim, >>> Does that really work???? I will try it later, thanks :) >>> Manuel >>> >>>> Manuel, >>>> >>>> a simple way to avoid the javax.comm.properties file is to include a >>>> class >>>> >>>> package com.sun.comm; >>>> public class SolarisDriver extends gnu.io.RXTXCommDriver { >>>> } >>>> >>>> into your application jar file and make sure, that you include the >>>> javax.comm jar after it. That's all you need. >>>> >>>> Regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >>>> >>>> >>>> On 08.07.2006, at 16:03, Manuel Naranjo wrote: >>>> >>>>> Hi: >>>>> I have a question, haven't you ever thought about changing RXTX >>>>> license >>>>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>>>> As far as I understand if I make an application that uses RXTX >>>>> libraries, I must release my app under the GNU/GPL. I have no problem >>>>> with that in fact I'm an Open Source user and defender. >>>>> The fact is that in same cases the applications made by one, could get >>>>> into hands of a company that needs to release a Closed Source app. I >>>>> understand that using GNU/GPL do not give you the power to do this, >>>>> but >>>>> a more "open" license like Apache does. By "open" I mean that the >>>>> license respects the Open Source license, but also lives the user the >>>>> opportunity to use the library in closed source programs. >>>>> I have seen that there is an exception to the license that applies to >>>>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>>>> (the jar file) needs the file javax.comm.properties installed >>>>> correctly, >>>>> which in lot of cases is a headache. RXTX jar does not need this, >>>>> actually I think that RXTX is more user friendly than Java Comm. >>>>> Maybe there has been a discussion like this before, but I just >>>>> wanted to >>>>> ask, and to get an answer that is adequate to our time. >>>>> Regards, >>>>> Manuel >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From naranjo.manuel at gmail.com Sun Jul 9 12:04:28 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 09 Jul 2006 15:04:28 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> Message-ID: <44B1452C.60208@gmail.com> Trent Jarvi wrote: > > Hi Manuel > > I do not know of another way. If you look at rxtx.org, even the > compiled version is hard to find, always late and not what you want. At > rxtx.org we just worry about the source and do a minimal effort to > provide binaries. Then that probes my theory, RXTX is much better than Java comm :) > I'd love nothing more than someone to start selling RXTX binaries or > working with us like Doug is to deliver the problems solved to users. > The Free here is Freedom. Not price. There is a need for services > rxtx.org is not able to provide well. That said I do not ever expect to > recieve anything. It just makes sense for everyone to work together and > compete outside of the source. I would like to contribute with the project giving support, I have worked using JSmooth and IzPack, and been able to make things that make RXTX easier to use and install. I will try to debug them, and send them to the mailing list, so you can do what ever you want with this :). Regards, Manuel From tjarvi at qbang.org Sun Jul 9 22:15:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Jul 2006 22:15:28 -0600 (MDT) Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44B1452C.60208@gmail.com> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> <44B1452C.60208@gmail.com> Message-ID: On Sun, 9 Jul 2006, Manuel Naranjo wrote: > Trent Jarvi wrote: >> >> Hi Manuel >> >> I do not know of another way. If you look at rxtx.org, even the >> compiled version is hard to find, always late and not what you want. At >> rxtx.org we just worry about the source and do a minimal effort to >> provide binaries. > Then that probes my theory, RXTX is much better than Java comm :) > >> I'd love nothing more than someone to start selling RXTX binaries or >> working with us like Doug is to deliver the problems solved to users. >> The Free here is Freedom. Not price. There is a need for services >> rxtx.org is not able to provide well. That said I do not ever expect to >> recieve anything. It just makes sense for everyone to work together and >> compete outside of the source. > I would like to contribute with the project giving support, I have > worked using JSmooth and IzPack, and been able to make things that make > RXTX easier to use and install. I will try to debug them, and send them > to the mailing list, so you can do what ever you want with this :). > Regards, Hi Manuel This is interesting. There are some checks and balances that we do at rxtx.org to make sure random material does not get in. It isn't personal just a low bar that must be crossed. After you get your changes in, you will know that others must cross the same bar. The basic question asked is "Does this change reflect the intent and work of those that have contributed to RXTX." Perhaps Doug is the best person to be the bar here. I'm more than willing to admit my limitations and obviously this is a limitation I face. If Doug is willing to take this task, I'd be glad to give him CVS write access which is more than overdue as he is the official maintainer now :) He then could optionally give you write access if your changes are fine and you represent a bar for new changes. I trust Doug. We do take the bar seriously as you can see. But it is not intended to prevent fair use of RXTX or prevent facilitating new uses. If we don't manage expectations here, there will be all sorts of problems and issues. -- Trent Jarvi tjarvi at qbang.org From zhanglong at adventnet.com Mon Jul 10 02:02:20 2006 From: zhanglong at adventnet.com (zhanglong) Date: Mon, 10 Jul 2006 16:02:20 +0800 Subject: [Rxtx] rxtx can not read data from serialport Message-ID: <44B2098C.6050407@adventnet.com> Dear brian and tjarvi, Thank you! After I set flowcontrol as FLOWCONTROL_RTSCTS_IN serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_IN); Then I can read and write data from serial port on Windows. But On linux9.0,No response,no data. I can get serialport list on my machine.And no error when I open serialport. I use Wevecom GSM modem device.I install Linux in VWware Workstation. And VWware Workstation install on windowsXP,So windowsXP and redhat Linux9.0 are on the same PC. On windows,I use COM1 serialport. On Linux,I use /dev/ttyS0 serialport. I hava test with SerialPort.FLOWCONTROL_XONXOFF_IN flow control,But still no data. How to set flow control,timeout and threshold on linux9.0? Thanks & Regards, Zhanglong -------------- next part -------------- A non-text attachment was scrubbed... Name: ListPort.java Type: text/x-java Size: 1659 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060710/334802b0/ListPort-0353.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: listport return on Windows and Linux.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060710/334802b0/listportreturnonWindowsandLinux-0353.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: TwoWaySerialComm.java Type: text/x-java Size: 3516 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060710/334802b0/TwoWaySerialComm-0353.bin From joachim at buechse.de Mon Jul 10 02:53:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 10 Jul 2006 10:53:09 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607091701.24661.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> <200607082203.13696.pascal@quies.net> <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> <200607091701.24661.pascal@quies.net> Message-ID: <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> The problem is, that once the libraries are installed in JAVA_HOME/ lib they will be loaded in preference to classes in your application classpath. If all you want is to use RXTX, then: - put the native lib in your application directory - include the javax.comm classes and RXTX classes in your application classpath - add the little stub class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } before the javax.comm classes in your application classpath. Alternatively you could also include the native lib in your application jar, extract it at runtime to a temp file, load it with System.load(). This will work on Windows and OSX. I didn't test it on Linux, but it should work. Regards, Joachim On 09.07.2006, at 17:01, Pascal S. de Kloe wrote: > Op zondag 9 juli 2006 15:19, schreef Joachim Buechse: >> Pascal, >> >> I would strongly suggest NOT to follow these installation >> instructions for OSX. It "poisons" the global Java VM with a specific >> implementation of RXTX. Plus: there is not one, but several Java VMs >> installed on every version of OSX. An application specific file and >> global preference pane defines which VM launches which application. >> There is really no good reason to install RXTX globally. > > I see your points. > How can you use the extension non-globally? I asked the same thing > for Windows > to Manuel. > > The system will allow you to detect any implementation. So the > "poison" > becomes a alternative. Applications can install the extension if > needed to > the current runtime with something like: > > CommunicationAPI comm = new CommunicationAPI(); > if (! comm.available()) { > if (comm.installRXTX()) > restart(); > else > handleError("I need the extension!"); > } > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jul 10 06:07:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 10 Jul 2006 06:07:23 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607081330.24381.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <200607081330.24381.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> Is the gnu.io namespace still necessary? I couldn't find the problem. >> >> Hi Pascal >> >> CommAPI is a little different in that it was grandfathered into the javax >> namespace with its own license at the time. >> >> It is my understanding that if CommAPI went through the JSR process, >> anyone would _clearly_ be able to implement a javax.comm package and RXTX >> would then be one of the first to do so. I believe Doug has expressed >> some interest in RXTX trying to work with the JSR process. >> >> Besides the license questions, there is the fact that RXTX has extensions >> to CommAPI which could cause confusion in the namespace. Not being a >> lawyer and *really* not liking to talk to lawyers in my free time, it is >> better to be safe than sorry. The lawyers tend to come in wolf packs >> when they do come. >> >> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay >> there as long as we are just geeks trying to figure out if a license does >> or does not allow us to implement in the javax.comm namespace. > > Nicely said. :) > > The whole point of namespaces is to create a universal registry of, in this > case, classes. This gnu.io namespace is very inconvenient. > > We feel the same way about lawyers. However I'd like to go into the details of > the license (see attachment) if you don't mind? > > The first license does not apply since RXTX does not use the software. The > second one at point 3 specifies our options. > >> 3. You may not modify the Java Platform Interface ("JPI", identified as >> classes contained within the "java" package or any subpackages of the >> "java" package), by creating additional classes within the JPI or otherwise >> causing the addition to or modification of the classes in the JPI. > > RXTX is a extension. > >> In the event that you create an additional class and associated API(s) >> which (i) extends the functionality of the Java platform, and (ii) is >> exposed to third party software developers for the purpose of developing >> additional software which invokes such additional API, you must promptly >> publish broadly an accurate specification for such API for free use by all >> developers. > > That's the way we operate. :) > >> You may not create, or authorize your licensees to create additional >> classes, interfaces, or subpackages that are in any way identified as >> "java", "javax", "sun" or similar convention as specified by Sun in any >> naming convention designation. > > They don't want additional components in the Communication API since they > don't want a mess in theire namespace. > > So we *can* use javax.comm for the core: > javax.comm.CommDriver > javax.comm.CommPort > javax.comm.CommPortIdentifier > javax.comm.CommPortOwnershipListener > javax.comm.NoSuchPortException > javax.comm.PortInUseException > javax.comm.UnsupportedCommOperationException > > ...and for the default hardware support: > javax.comm.SerialPort > javax.comm.SerialPortEvent > javax.comm.SerialPortEventListener > javax.comm.ParralelPort > javax.comm.ParralelPortEvent > javax.comm.ParralelPortEventListener > > ...but RXTX aditional hardware support has to go somewhere else like: > org.rxtx.RS485Port > org.rxtx.RS485PortEvent > org.rxtx.RS485PortEventListener > org.rxtx.I2CPort > org.rxtx.I2CPortEvent > org.rxtx.I2CPortEventListener > > Right? > The one thing this discussion does not cover is in SerialPort.java. See the extensions to commapi listed after the following line: /* ---------------------- end of commapi ------------------------ */ The intent is not to break commapi but it could be perceived as so. The extensions added have been placed there as requested by users of RXTX. It would be nice to discuss these modifications with Sun and perhaps have some added to the final version of CommAPI. Some of them may not make sense while others do. Some can not be implemented in a platform neutral fashion. It would not make sense for RXTX to just bring these into Sun's namespace without due process. This is why I am fundamentally apposed to people "poisoning" Sun's namespace with RXTX 2.1 although I understand that is not their intent. These modifications are not advertised and their use is discouraged. But they are there. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Mon Jul 10 06:47:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 10 Jul 2006 14:47:24 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607081330.24381.pascal@quies.net> Message-ID: <200607101447.25071.pascal@quies.net> Op maandag 10 juli 2006 14:07, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > > Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: > >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > >>> Is the gnu.io namespace still necessary? I couldn't find the problem. > >> > >> Hi Pascal > >> > >> CommAPI is a little different in that it was grandfathered into the > >> javax namespace with its own license at the time. > >> > >> It is my understanding that if CommAPI went through the JSR process, > >> anyone would _clearly_ be able to implement a javax.comm package and > >> RXTX would then be one of the first to do so. I believe Doug has > >> expressed some interest in RXTX trying to work with the JSR process. > >> > >> Besides the license questions, there is the fact that RXTX has > >> extensions to CommAPI which could cause confusion in the namespace. Not > >> being a lawyer and *really* not liking to talk to lawyers in my free > >> time, it is better to be safe than sorry. The lawyers tend to come in > >> wolf packs when they do come. > >> > >> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay > >> there as long as we are just geeks trying to figure out if a license > >> does or does not allow us to implement in the javax.comm namespace. > > > > Nicely said. :) > > > > The whole point of namespaces is to create a universal registry of, in > > this case, classes. This gnu.io namespace is very inconvenient. > > > > We feel the same way about lawyers. However I'd like to go into the > > details of the license (see attachment) if you don't mind? > > > > The first license does not apply since RXTX does not use the software. > > The second one at point 3 specifies our options. > > > >> 3. You may not modify the Java Platform Interface ("JPI", identified as > >> classes contained within the "java" package or any subpackages of the > >> "java" package), by creating additional classes within the JPI or > >> otherwise causing the addition to or modification of the classes in the > >> JPI. > > > > RXTX is a extension. > > > >> In the event that you create an additional class and associated API(s) > >> which (i) extends the functionality of the Java platform, and (ii) is > >> exposed to third party software developers for the purpose of developing > >> additional software which invokes such additional API, you must promptly > >> publish broadly an accurate specification for such API for free use by > >> all developers. > > > > That's the way we operate. :) > > > >> You may not create, or authorize your licensees to create additional > >> classes, interfaces, or subpackages that are in any way identified as > >> "java", "javax", "sun" or similar convention as specified by Sun in any > >> naming convention designation. > > > > They don't want additional components in the Communication API since they > > don't want a mess in theire namespace. > > > > So we *can* use javax.comm for the core: > > javax.comm.CommDriver > > javax.comm.CommPort > > javax.comm.CommPortIdentifier > > javax.comm.CommPortOwnershipListener > > javax.comm.NoSuchPortException > > javax.comm.PortInUseException > > javax.comm.UnsupportedCommOperationException > > > > ...and for the default hardware support: > > javax.comm.SerialPort > > javax.comm.SerialPortEvent > > javax.comm.SerialPortEventListener > > javax.comm.ParralelPort > > javax.comm.ParralelPortEvent > > javax.comm.ParralelPortEventListener > > > > ...but RXTX aditional hardware support has to go somewhere else like: > > org.rxtx.RS485Port > > org.rxtx.RS485PortEvent > > org.rxtx.RS485PortEventListener > > org.rxtx.I2CPort > > org.rxtx.I2CPortEvent > > org.rxtx.I2CPortEventListener > > > > Right? > > The one thing this discussion does not cover is in SerialPort.java. See > the extensions to commapi listed after the following line: > > /* ---------------------- end of commapi ------------------------ */ > > The intent is not to break commapi but it could be perceived as so. The > extensions added have been placed there as requested by users of RXTX. It > would be nice to discuss these modifications with Sun and perhaps have > some added to the final version of CommAPI. > > Some of them may not make sense while others do. Some can not be > implemented in a platform neutral fashion. It would not make sense > for RXTX to just bring these into Sun's namespace without due process. > > This is why I am fundamentally apposed to people "poisoning" Sun's > namespace with RXTX 2.1 although I understand that is not their intent. > > These modifications are not advertised and their use is discouraged. But > they are there. Hi Trent, So you are saying that gnu.io.SerialPort has some aditional methods over javax.comm.SerialPort? That does not change the API at all but it would be a problem if people would start using those methods in the javax.comm namespace in the same way like some people use the com.sun namespace. Could wrapper classes at javax.comm do the job? In that way RXTX stays in its namespace, javadoc can notice the aditional methods and the Communication API will be available as expected. From pascal at quies.net Mon Jul 10 06:48:09 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 10 Jul 2006 14:48:09 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> References: <200607081944.41123.pascal@quies.net> <200607091701.24661.pascal@quies.net> <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> Message-ID: <200607101448.09594.pascal@quies.net> Op maandag 10 juli 2006 10:53, schreef Joachim Buechse: > If all you want is to use RXTX, then: > > - put the native lib in your application directory > - include the javax.comm classes and RXTX classes in your application > classpath > - add the little stub class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > before the javax.comm classes in your application classpath. > > Alternatively you could also include the native lib in your > application jar, extract it at runtime to a temp file, load it with > System.load(). So java will load the native libraries automaticly if they are in the same directory as the Java application? Why isn't this very interresting information noticed in the documentation or is that too obvious and I simply didn't knew? From naranjo.manuel at gmail.com Mon Jul 10 06:56:10 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Mon, 10 Jul 2006 09:56:10 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> <44B1452C.60208@gmail.com> Message-ID: <44B24E6A.1010805@gmail.com> Trent Jarvi wrote: > On Sun, 9 Jul 2006, Manuel Naranjo wrote: > >> Trent Jarvi wrote: >>> Hi Manuel >>> >>> I do not know of another way. If you look at rxtx.org, even the >>> compiled version is hard to find, always late and not what you want. At >>> rxtx.org we just worry about the source and do a minimal effort to >>> provide binaries. >> Then that probes my theory, RXTX is much better than Java comm :) >> >>> I'd love nothing more than someone to start selling RXTX binaries or >>> working with us like Doug is to deliver the problems solved to users. >>> The Free here is Freedom. Not price. There is a need for services >>> rxtx.org is not able to provide well. That said I do not ever expect to >>> recieve anything. It just makes sense for everyone to work together and >>> compete outside of the source. >> I would like to contribute with the project giving support, I have >> worked using JSmooth and IzPack, and been able to make things that make >> RXTX easier to use and install. I will try to debug them, and send them >> to the mailing list, so you can do what ever you want with this :). >> Regards, > > > Hi Manuel > > This is interesting. There are some checks and balances that we do at > rxtx.org to make sure random material does not get in. It isn't personal > just a low bar that must be crossed. After you get your changes in, you > will know that others must cross the same bar. The basic question asked > is "Does this change reflect the intent and work of those that have > contributed to RXTX." > > Perhaps Doug is the best person to be the bar here. I'm more than willing > to admit my limitations and obviously this is a limitation I face. > > If Doug is willing to take this task, I'd be glad to give him CVS write > access which is more than overdue as he is the official maintainer now :) > He then could optionally give you write access if your changes are fine > and you represent a bar for new changes. I trust Doug. > > We do take the bar seriously as you can see. But it is not intended to > prevent fair use of RXTX or prevent facilitating new uses. If we don't > manage expectations here, there will be all sorts of problems and issues. > > -- > Trent Jarvi > tjarvi at qbang.org > > Trent, What I want to send you is not a modification to rxtx, it just a developers helper if you want to put a name to it. I have make an IzPack installer, which installs RXTX binaries depending on underlaying OS. And make an JSmooth warper that launches my app with out the need to have rxtx installed on the host JVM folder, it only need the RXTX to be in the bin\ of my app. I think this is more useful for Wiki than to the main project. Another thing I have experience in PalmOS programming, when ever I have time, I will investigate about the JNI of J2ME and try to port RXTX to Palm, I do not know when I will start, because I have a lot of work now. Regards, Manuel From christopher.dawes at the-logic-group.com Mon Jul 10 08:00:15 2006 From: christopher.dawes at the-logic-group.com (christopher.dawes@the-logic-group.com) Date: Mon, 10 Jul 2006 15:00:15 +0100 Subject: [Rxtx] Chris Dawes/Retaillogic/NISABA is out of the office. Message-ID: I will be out of the office starting 10/07/2006 and will not return until 11/07/2008. Hello, unfortunately I no longer work for The Logic Group, if you're trying to contact me on a work related issue please contact Pete Avery (pete.avery at the-logic-group.com) however if it is a personal matter please e-mail root at ants.me.uk or phone 07899 842 759. Thanks Christopher Dawes From tjarvi at qbang.org Mon Jul 10 08:19:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 10 Jul 2006 08:19:52 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607101447.25071.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607081330.24381.pascal@quies.net> <200607101447.25071.pascal@quies.net> Message-ID: On Mon, 10 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 10 juli 2006 14:07, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: >>>> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>>>> Is the gnu.io namespace still necessary? I couldn't find the problem. >>>> >>>> Hi Pascal >>>> >>>> CommAPI is a little different in that it was grandfathered into the >>>> javax namespace with its own license at the time. >>>> >>>> It is my understanding that if CommAPI went through the JSR process, >>>> anyone would _clearly_ be able to implement a javax.comm package and >>>> RXTX would then be one of the first to do so. I believe Doug has >>>> expressed some interest in RXTX trying to work with the JSR process. >>>> >>>> Besides the license questions, there is the fact that RXTX has >>>> extensions to CommAPI which could cause confusion in the namespace. Not >>>> being a lawyer and *really* not liking to talk to lawyers in my free >>>> time, it is better to be safe than sorry. The lawyers tend to come in >>>> wolf packs when they do come. >>>> >>>> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay >>>> there as long as we are just geeks trying to figure out if a license >>>> does or does not allow us to implement in the javax.comm namespace. >>> >>> Nicely said. :) >>> >>> The whole point of namespaces is to create a universal registry of, in >>> this case, classes. This gnu.io namespace is very inconvenient. >>> >>> We feel the same way about lawyers. However I'd like to go into the >>> details of the license (see attachment) if you don't mind? >>> >>> The first license does not apply since RXTX does not use the software. >>> The second one at point 3 specifies our options. >>> >>>> 3. You may not modify the Java Platform Interface ("JPI", identified as >>>> classes contained within the "java" package or any subpackages of the >>>> "java" package), by creating additional classes within the JPI or >>>> otherwise causing the addition to or modification of the classes in the >>>> JPI. >>> >>> RXTX is a extension. >>> >>>> In the event that you create an additional class and associated API(s) >>>> which (i) extends the functionality of the Java platform, and (ii) is >>>> exposed to third party software developers for the purpose of developing >>>> additional software which invokes such additional API, you must promptly >>>> publish broadly an accurate specification for such API for free use by >>>> all developers. >>> >>> That's the way we operate. :) >>> >>>> You may not create, or authorize your licensees to create additional >>>> classes, interfaces, or subpackages that are in any way identified as >>>> "java", "javax", "sun" or similar convention as specified by Sun in any >>>> naming convention designation. >>> >>> They don't want additional components in the Communication API since they >>> don't want a mess in theire namespace. >>> >>> So we *can* use javax.comm for the core: >>> javax.comm.CommDriver >>> javax.comm.CommPort >>> javax.comm.CommPortIdentifier >>> javax.comm.CommPortOwnershipListener >>> javax.comm.NoSuchPortException >>> javax.comm.PortInUseException >>> javax.comm.UnsupportedCommOperationException >>> >>> ...and for the default hardware support: >>> javax.comm.SerialPort >>> javax.comm.SerialPortEvent >>> javax.comm.SerialPortEventListener >>> javax.comm.ParralelPort >>> javax.comm.ParralelPortEvent >>> javax.comm.ParralelPortEventListener >>> >>> ...but RXTX aditional hardware support has to go somewhere else like: >>> org.rxtx.RS485Port >>> org.rxtx.RS485PortEvent >>> org.rxtx.RS485PortEventListener >>> org.rxtx.I2CPort >>> org.rxtx.I2CPortEvent >>> org.rxtx.I2CPortEventListener >>> >>> Right? >> >> The one thing this discussion does not cover is in SerialPort.java. See >> the extensions to commapi listed after the following line: >> >> /* ---------------------- end of commapi ------------------------ */ >> >> The intent is not to break commapi but it could be perceived as so. The >> extensions added have been placed there as requested by users of RXTX. It >> would be nice to discuss these modifications with Sun and perhaps have >> some added to the final version of CommAPI. >> >> Some of them may not make sense while others do. Some can not be >> implemented in a platform neutral fashion. It would not make sense >> for RXTX to just bring these into Sun's namespace without due process. >> >> This is why I am fundamentally apposed to people "poisoning" Sun's >> namespace with RXTX 2.1 although I understand that is not their intent. >> >> These modifications are not advertised and their use is discouraged. But >> they are there. > > Hi Trent, > > So you are saying that gnu.io.SerialPort has some aditional methods over > javax.comm.SerialPort? > That does not change the API at all but it would be a problem if people would > start using those methods in the javax.comm namespace in the same way like > some people use the com.sun namespace. > Could wrapper classes at javax.comm do the job? In that way RXTX stays in its > namespace, javadoc can notice the aditional methods and the Communication API > will be available as expected. Hi Pascal Yes. There are additional methods in gnu.io.SerialPort. We clearly mark those as extensions to CommAPI and discourage their use. There just isn't a way to get the intended functionality out of CommAPI without them. I think the right thing to do here may be to remove these methods to avoid unintentional polution of the javax namespace if people are going to be putting these classes in that namespace. The way people are using RXTX 2.1 is not the same as it was originally pictured. Thats fine but we need to be responsible. We need to prevent what could be a problem. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Mon Jul 10 08:57:10 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 10 Jul 2006 16:57:10 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101447.25071.pascal@quies.net> Message-ID: <200607101657.11223.pascal@quies.net> > Yes. There are additional methods in gnu.io.SerialPort. We clearly mark > those as extensions to CommAPI and discourage their use. There just isn't > a way to get the intended functionality out of CommAPI without them. If you don't want the users to use the methods then make them class protected (remove the word "public" before the method) and if you can't do that we might do the following: ---- SerialPort.java package javax.comm class SerialPort extends gnu.io.SerialPort { public void rxtxOnlyMethod() { throw new Error("Don't use this method here!\nUse gnu.io.SerialPort instead"); } ---- end From neville_seed at yahoo.com Mon Jul 10 10:20:12 2006 From: neville_seed at yahoo.com (neville seed) Date: Mon, 10 Jul 2006 09:20:12 -0700 (PDT) Subject: [Rxtx] writing first application and compiling In-Reply-To: Message-ID: <20060710162012.9888.qmail@web51015.mail.yahoo.com> Can anyone recommend a starting place for writing, compiling and uploading the first app, ie a simple hello world. It seems that the PALM SDK does not have a build environment. I am happy to develop under linux of windows. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From bob_tai2001 at yahoo.com Mon Jul 10 14:48:30 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 10 Jul 2006 13:48:30 -0700 (PDT) Subject: [Rxtx] Java installer Message-ID: <20060710204830.53745.qmail@web32810.mail.mud.yahoo.com> Hi Manuel, I found your post from the newsletter, hope I am not off topic. You mention there is a IZpack installer for Rxtx? I been waiting for this type of deplyment idea from Rxtx! is this documented in the web site? I am in windows environment but didn't want to create classpath for each workstation. I rather install :) I apologize for cutting into this topic. Bob > >Trent, >What I want to send you is not a modification to rxtx, it just a >developers helper if you want to put a name to it. I have make an IzPack installer, which installs RXTX binaries depending on underlaying OS. And make an JSmooth warper that launches my app with out the need to have rxtx installed on the host JVM folder, it only need the RXTX to be in the bin\ of my app. I think this is more useful for Wiki than to the main project. Another thing I have experience in PalmOS programming, when ever I have time, I will investigate about the JNI of J2ME and try to port RXTX to Palm, I do not know when I will start, because I have a lot of work now. Regards, Manuel __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From naranjo.manuel at gmail.com Mon Jul 10 15:10:21 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Mon, 10 Jul 2006 18:10:21 -0300 Subject: [Rxtx] Java installer In-Reply-To: <20060710204830.53745.qmail@web32810.mail.mud.yahoo.com> References: <20060710204830.53745.qmail@web32810.mail.mud.yahoo.com> Message-ID: <44B2C23D.8050901@gmail.com> Bob, Hi, not this is not a RXTX installer, I have develop an installer with IzPack which actually installs RXTX and my hole app, and I think this can be useful for RXTX users, Regards, Manuel > Hi Manuel, > > I found your post from the newsletter, hope I am not > off topic. You mention there is a IZpack installer > for Rxtx? I been waiting for this type of deplyment > idea from Rxtx! is this documented in the web site? > I am in windows environment but didn't want to create > classpath for each workstation. I rather install :) > > I apologize for cutting into this topic. > > Bob > >> Trent, >> What I want to send you is not a modification to > rxtx, it just a >> developers > helper if you want to put a name to it. I have make an > IzPack > installer, > which installs RXTX binaries depending on underlaying > OS. And make an > JSmooth warper that launches my app with out the need > to have rxtx > installed > on the host JVM folder, it only need the RXTX to be in > the bin\ of my > app. > I think this is more useful for Wiki than to the main > project. > Another thing I have experience in PalmOS programming, > when ever I have > time, > I will investigate about the JNI of J2ME and try to > port RXTX to Palm, > I do not know when I will start, because I have a lot > of work now. > Regards, > Manuel > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From brian at mbari.org Tue Jul 11 11:59:24 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 11 Jul 2006 10:59:24 -0700 Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: References: <44AC7902.8070407@adventnet.com> Message-ID: <485C28F0-CA08-4393-9E34-4C8E7F22C125@mbari.org> Hi Trent, On Jul 7, 2006, at 6:15 PM, Trent Jarvi wrote: > On Fri, 7 Jul 2006, Brian Schlining wrote: >> Also, for some command/response applications that I've tried with >> RXTX, I >> find that if I write to the serialport and then immediately try to >> read from >> it I get byte arrays filled with zeros, no matter what I set the >> recieveTimeout to (this has occurred on both Mac OS X and >> Windows). The >> workaround that I found was to very briefly put the I/O thread to >> sleep, like >> so: >> >> // DO set up and get I/O streams >> //in = serialPort.getInputStream(); >> //out = serialPort.getOutputStream(); >> >> out.write(someByteArray); >> try { >> Thread.sleep(10); >> catch (InterruptedException e) { >> // handle exception >> } >> in.read(anotherByteArray); >> >> Note: I've never had to put the thread to sleep using Java comm, >> only with >> RXTX. Anyone know why this might be? > > Hi Brian > > Interesting. Is this something that can be reproduced with a loopback > connection or something commonly available? I was unaware of this > behavior. Is it restricted to something that quickly opens, > writes, reads > and closes the port by chance? I've encountered this while using RXTX to talk to VCR's that support RS422; I've never tried it with a loopback connection. Note that connection setup is: PC[RS232] <---> RS232/422 Converter <---> VCR[RS422] The application I'm using it for opens a connection and keeps it open for the life of the application. It makes a lot of read and writes when running...probably about as fast as the VCR hardware supports; with Javacomm, I think it was on the order of an IO transaction every 40ms. However even if I perform an IO read/write every 2 seconds with RXTX I still encounter the same problem, so it's not a matter of the frequency of the IO transactions. If you want to look at the code a test example can be found at https://svn.sourceforge.net/svnroot/vars/trunk/vars/src/test/java/ test/org/mbari/vcr/SimpleReadRxtx.java. The actual production code is at https://svn.sourceforge.net/svnroot/vars/trunk/vars/src/main/java/ org/mbari/vcr/rs422/VCR.java. The methods that you might be interested in to see how the code is used are initComm(), sendCommand (), getResponse() in VCR.java. You'll notice Thread.sleep(IO_DELAY) sprinkled in the sendCommand() methods and getResponse(). Without that I get arrays of zeros returned. If the IO_DELAY is less than 15ms then sending commands works fine but reading the responses is not reliable; I mostly get problems when trying to read the last few bytes or a response. Again, everything works fine with Sun's Javacomm w/o the Thread.sleep() on windows. Also, FYI, I tried to run this on a Mac using RXTX 2.0, but I ran into thread synchronization issues. These issues went away when I switched to RXTX 2.1. Cheers B ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining MBARI Software Engineer brian at mbari.org (831)775-1855 http://www.mbari.org/staff/brian I went to the woods because I wished to live deliberately, to front only the essential facts of life, and see if I could not learn what it had to teach, and not, when I came to die, discover that I had not lived. ~ Henry Thoreau -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060711/59b607f3/attachment-0351.html From ajmas at sympatico.ca Wed Jul 12 13:46:51 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 12 Jul 2006 15:46:51 -0400 Subject: [Rxtx] writing first application and compiling Message-ID: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Take a look in the Wiki. I have added a couple of examples in there: http://rxtx.qbang.org/wiki/index.php/Examples Andre > > From: neville seed > Date: 2006/07/10 Mon PM 12:20:12 EDT > To: RXTX Developers and Users > Subject: [Rxtx] writing first application and compiling > > > Can anyone recommend a starting place for writing, > compiling and uploading the first app, ie a simple > hello world. > > It seems that the PALM SDK does not have a build > environment. I am happy to develop under linux of windows. > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Jul 12 19:22:25 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 12 Jul 2006 19:22:25 -0600 (MDT) Subject: [Rxtx] writing first application and compiling In-Reply-To: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Thank you for doing this Andre. I'm sure it will get well used by people learning. I think the old commapi examples are no longer easily available so these are really needed. On Wed, 12 Jul 2006, Andre-John Mas wrote: > Hi, > > Take a look in the Wiki. I have added a couple of examples in there: > > http://rxtx.qbang.org/wiki/index.php/Examples > > Andre > >> >> From: neville seed >> Date: 2006/07/10 Mon PM 12:20:12 EDT >> To: RXTX Developers and Users >> Subject: [Rxtx] writing first application and compiling >> >> >> Can anyone recommend a starting place for writing, >> compiling and uploading the first app, ie a simple >> hello world. >> >> It seems that the PALM SDK does not have a build >> environment. I am happy to develop under linux of windows. >> >> __________________________________________________ >> Do You Yahoo!? >> Tired of spam? Yahoo! Mail has the best spam protection around >> http://mail.yahoo.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Thu Jul 13 17:21:26 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Thu, 13 Jul 2006 19:21:26 -0400 Subject: [Rxtx] writing first application and compiling In-Reply-To: References: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <54D55D35-A143-43AA-AF03-B89ADE9B9246@sympatico.ca> No problems. I would also like to encourage anyone else to contribute other useful stuff they might have. On 12-Jul-06, at 21:22 , Trent Jarvi wrote: > > Thank you for doing this Andre. > > I'm sure it will get well used by people learning. I think the old > commapi examples are no longer easily available so these are really > needed. > > On Wed, 12 Jul 2006, Andre-John Mas wrote: > >> Hi, >> >> Take a look in the Wiki. I have added a couple of examples in there: >> >> http://rxtx.qbang.org/wiki/index.php/Examples >> >> Andre >> >>> >>> From: neville seed >>> Date: 2006/07/10 Mon PM 12:20:12 EDT >>> To: RXTX Developers and Users >>> Subject: [Rxtx] writing first application and compiling >>> >>> >>> Can anyone recommend a starting place for writing, >>> compiling and uploading the first app, ie a simple >>> hello world. >>> >>> It seems that the PALM SDK does not have a build >>> environment. I am happy to develop under linux of windows. >>> >>> __________________________________________________ >>> Do You Yahoo!? >>> Tired of spam? Yahoo! Mail has the best spam protection around >>> http://mail.yahoo.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Sat Jul 8 15:05:46 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sat, 08 Jul 2006 17:05:46 -0400 Subject: [Rxtx] License question. In-Reply-To: <200607082219.59514.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> Message-ID: <44B01E2A.9010207@suespammers.org> Pascal S. de Kloe wrote: > I thought of the same thing. The modified BSD license would certainly make it > more eazy and acceptable for Sun to include RXTX in theire products. > > Unfortunately in general people who chose GPL don't like other licenses. ;) i have a general preference for BSD, but i'll defend RXTX here. RXTX is LGPL, not GPL. they're different, look it up. richard From pascal at quies.net Sun Jul 16 17:40:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 17 Jul 2006 01:40:13 +0200 Subject: [Rxtx] Java installer In-Reply-To: <200607101657.11223.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> Message-ID: <200607170140.14116.pascal@quies.net> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: > > Yes. There are additional methods in gnu.io.SerialPort. We clearly mark > > those as extensions to CommAPI and discourage their use. There just > > isn't a way to get the intended functionality out of CommAPI without > > them. > > If you don't want the users to use the methods then make them class > protected (remove the word "public" before the method) and if you can't do > that we might do the following: > > ---- SerialPort.java > package javax.comm > > class SerialPort extends gnu.io.SerialPort { > > public void > rxtxOnlyMethod() { > throw new Error("Don't use this method here!\nUse gnu.io.SerialPort > instead"); > } > ---- end So how about it, Trent? Can we ship those classes with the next release? From pascal at quies.net Sun Jul 16 17:45:42 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 17 Jul 2006 01:45:42 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> References: <200607081944.41123.pascal@quies.net> <200607091701.24661.pascal@quies.net> <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> Message-ID: <200607170145.43156.pascal@quies.net> Op maandag 10 juli 2006 10:53, schreef Joachim Buechse: > Alternatively you could also include the native lib in your > application jar, extract it at runtime to a temp file, load it with > System.load(). That works indeed. :) I'll finish my "detection class" with such a loader and the RXTX package tomorrow. Then one can simply include the JAR in the classpath and run org.rxtx.CommunicationAPI.initialize() to make sure the API is available. From tjarvi at qbang.org Sun Jul 16 18:59:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 16 Jul 2006 18:59:06 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607170140.14116.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> <200607170140.14116.pascal@quies.net> Message-ID: On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>> Yes. There are additional methods in gnu.io.SerialPort. We clearly mark >>> those as extensions to CommAPI and discourage their use. There just >>> isn't a way to get the intended functionality out of CommAPI without >>> them. >> >> If you don't want the users to use the methods then make them class >> protected (remove the word "public" before the method) and if you can't do >> that we might do the following: >> >> ---- SerialPort.java >> package javax.comm >> >> class SerialPort extends gnu.io.SerialPort { >> >> public void >> rxtxOnlyMethod() { >> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >> instead"); >> } >> ---- end > > So how about it, Trent? > > Can we ship those classes with the next release? Hi Pascal I'm not going to say what people can or can not ship. I'm going to propose removing all of the above extensions from SerialPort.java. I think it is the best thing to do after cooling off a bit. But thats all I've considered at this point. I'm in favor of removing the extensions and staying in gnu.io which more importantly means staying at arms length from javax. I can remove the extensions, put a windows fix in, bump the versions and tag the releases without changing packages if everyone agrees to that. If people want to know why CommAPI has not gone through a JSR which makes it clear rxtx can be in javax.comm and explains how conformancy is determined, I do not think this is the right forum though you can freely do so. -- Trent Jarvi tjarvi at qbang.org From phillip at uow.edu.au Sun Jul 16 22:08:30 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Mon, 17 Jul 2006 14:08:30 +1000 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application" in Mac OSX Message-ID: Hi I downloaded RXTX 2.1-7r2 http://rxtx.org/ (latest download), found the MacOSX folder, manually installed RXTXcomm.jar and librxtxSerial.jnilib in / Library/Java/Extensions and manually setup /var/spool/ucp and became a member of it. I have tried two programs (both built in XCode - TwoWaySerialComm and SerialDemo). Both can find the serial ports but throw a 'port in use exception' with the error "Unknown Application" when I try to open the port. The following is part of the code of TwoWaySerialComm void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { System.out.println("Current owner is " + portIdentifier.getCurrentOwner()); System.out.println("Name is " + this.getClass().getName()); CommPort commPort = portIdentifier.open(this.getClass ().getName(),2000); //throws exception if ( commPort instanceof SerialPort ) The method connect is called from main: public static void main ( String[] args ) { try { listPorts(); (new TwoWaySerialComm()).connect("/dev/tty.KeySerial1"); The following is the console run log of a program TwoWaySerialComm [Session started at 2006-07-14 14:50:29 +1000.] Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.modem - Serial /dev/cu.modem - Serial /dev/tty.KeySerial1 - Serial /dev/cu.KeySerial1 - Serial /dev/tty.USA28X2b2P2.2 - Serial /dev/cu.USA28X2b2P2.2 - Serial 6 ports found Current owner is null Name is TwoWaySerialComm gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:48) at TwoWaySerialComm.main(TwoWaySerialComm.java:163) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at apple.launcher.LaunchRunner.run(LaunchRunner.java:88) at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:50) at apple.launcher.JavaApplicationLauncher.launch (JavaApplicationLauncher.java:52) TwoWaySerialComm has exited with status 0. I am stuck, Can you help me please. thanks Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From pascal at quies.net Mon Jul 17 06:12:09 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 17 Jul 2006 14:12:09 +0200 Subject: [Rxtx] JSR In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607170140.14116.pascal@quies.net> Message-ID: <200607171412.09571.pascal@quies.net> Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: > On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > > Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: > >>> Yes. There are additional methods in gnu.io.SerialPort. We clearly > >>> mark those as extensions to CommAPI and discourage their use. There > >>> just isn't a way to get the intended functionality out of CommAPI > >>> without them. > >> > >> If you don't want the users to use the methods then make them class > >> protected (remove the word "public" before the method) and if you can't > >> do that we might do the following: > >> > >> ---- SerialPort.java > >> package javax.comm > >> > >> class SerialPort extends gnu.io.SerialPort { > >> > >> public void > >> rxtxOnlyMethod() { > >> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort > >> instead"); > >> } > >> ---- end > > > > So how about it, Trent? > > > > Can we ship those classes with the next release? > > Hi Pascal > > I'm not going to say what people can or can not ship. I'm going to > propose removing all of the above extensions from SerialPort.java. I > think it is the best thing to do after cooling off a bit. > > But thats all I've considered at this point. I'm in favor of removing the > extensions and staying in gnu.io which more importantly means staying at > arms length from javax. > > I can remove the extensions, put a windows fix in, bump the versions and > tag the releases without changing packages if everyone agrees to that. > If people want to know why CommAPI has not gone through a JSR which makes > it clear rxtx can be in javax.comm and explains how conformancy is > determined, I do not think this is the right forum though you can freely > do so. Hi Trent, If I understand it correctly you don't want to put those javax.comm classes in the distribution until a JSR completes. :( Sun wants a JSR too to change the API: > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. How about it? I can spend 5 hours a week. From tjarvi at qbang.org Mon Jul 17 07:32:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 07:32:06 -0600 (MDT) Subject: [Rxtx] JSR In-Reply-To: <200607171412.09571.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607170140.14116.pascal@quies.net> <200607171412.09571.pascal@quies.net> Message-ID: On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: >> On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: >>> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>>> Yes. There are additional methods in gnu.io.SerialPort. We clearly >>>>> mark those as extensions to CommAPI and discourage their use. There >>>>> just isn't a way to get the intended functionality out of CommAPI >>>>> without them. >>>> >>>> If you don't want the users to use the methods then make them class >>>> protected (remove the word "public" before the method) and if you can't >>>> do that we might do the following: >>>> >>>> ---- SerialPort.java >>>> package javax.comm >>>> >>>> class SerialPort extends gnu.io.SerialPort { >>>> >>>> public void >>>> rxtxOnlyMethod() { >>>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>>> instead"); >>>> } >>>> ---- end >>> >>> So how about it, Trent? >>> >>> Can we ship those classes with the next release? >> >> Hi Pascal >> >> I'm not going to say what people can or can not ship. I'm going to >> propose removing all of the above extensions from SerialPort.java. I >> think it is the best thing to do after cooling off a bit. >> >> But thats all I've considered at this point. I'm in favor of removing the >> extensions and staying in gnu.io which more importantly means staying at >> arms length from javax. >> >> I can remove the extensions, put a windows fix in, bump the versions and >> tag the releases without changing packages if everyone agrees to that. >> If people want to know why CommAPI has not gone through a JSR which makes >> it clear rxtx can be in javax.comm and explains how conformancy is >> determined, I do not think this is the right forum though you can freely >> do so. > > Hi Trent, > > If I understand it correctly you don't want to put those javax.comm classes in > the distribution until a JSR completes. :( > > Sun wants a JSR too to change the API: >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. > > How about it? I can spend 5 hours a week. Yes. I'm all in favor of this. Dr. Doug Lyon is our fearless leader in these matters and has final say. He has asked everyone if they have an issue with going through the JSR. I have seen no responses though some may have responeded to him in private. I am now working for The MathWorks in a related field. To best represent the RXTX community, we have asked Doug to be the neutral maintainer. This does not mean he is taking on all the work like making releases. He has the ability to and the power. But thats not really spending his time efficiently. It does mean when there are decisions to be made that may have conflicts, he has final say. The easy solution :) is to bug Trent or Doug and see if they will just go into javax.comm namespace. The right solution is to work with Doug and try to get the JSR process completed. I'm willing to help too as time permits. I'm willing to work with Doug. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Jul 17 09:11:20 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 17 Jul 2006 11:11:20 -0400 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Message-ID: <20060717151120.RSBG13653.tomts36-srv.bellnexxia.net@smtp1.sympatico.ca> I am told that this is an issue that will be resolved in 2.1-8. The changes are already in version control, so you can use that. I have and it resolved the problem for me. Phillip McKerrow wrote: > > Hi > > I downloaded RXTX 2.1-7r2 http://rxtx.org/ (latest download), > found the MacOSX folder, > manually installed RXTXcomm.jar and librxtxSerial.jnilib in / > Library/Java/Extensions and > manually setup /var/spool/ucp and became a member of it. > > I have tried two programs (both built in XCode - TwoWaySerialComm and > SerialDemo). Both can find the serial ports but throw a 'port in use > exception' with the error "Unknown Application" when I try to open > the port. > > The following is part of the code of TwoWaySerialComm > void connect ( String portName ) throws Exception > { > CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > if ( portIdentifier.isCurrentlyOwned() ) > { > System.out.println("Error: Port is currently in use"); > } > else > { > System.out.println("Current owner is " + > portIdentifier.getCurrentOwner()); > System.out.println("Name is " + this.getClass().getName()); > CommPort commPort = portIdentifier.open(this.getClass > ().getName(),2000); //throws exception > > if ( commPort instanceof SerialPort ) > > > The method connect is called from main: > public static void main ( String[] args ) > { > try > { > listPorts(); > (new TwoWaySerialComm()).connect("/dev/tty.KeySerial1"); > > > The following is the console run log of a program TwoWaySerialComm > [Session started at 2006-07-14 14:50:29 +1000.] > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > /dev/tty.modem - Serial > /dev/cu.modem - Serial > /dev/tty.KeySerial1 - Serial > /dev/cu.KeySerial1 - Serial > /dev/tty.USA28X2b2P2.2 - Serial > /dev/cu.USA28X2b2P2.2 - Serial > 6 ports found > Current owner is null > Name is TwoWaySerialComm > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at TwoWaySerialComm.connect(TwoWaySerialComm.java:48) > at TwoWaySerialComm.main(TwoWaySerialComm.java:163) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at apple.launcher.LaunchRunner.run(LaunchRunner.java:88) > at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:50) > at apple.launcher.JavaApplicationLauncher.launch > (JavaApplicationLauncher.java:52) > > TwoWaySerialComm has exited with status 0. > > I am stuck, Can you help me please. > > thanks > Phillip > > > ---------------------------------------------------------------------- > Phillip McKerrow http:// > www.uow.edu.au/~phillip/ > School of Information Technology and Computer Science > University of Wollongong * > Northfields Avenue, * * > Wollongong, NSW, 2522. + > AUSTRALIA * the land of the > southern cross > tel : +61 2 4221 3771 fax : +61 2 4221 4170 > > God so loved the world that he gave his one and only Son (Jesus), > that whoever believes in him shall not perish but have eternal life. > John 3:16 > ---------------------------------------------------------------------- > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Mon Jul 17 10:34:14 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 17 Jul 2006 12:34:14 -0400 Subject: [Rxtx] summary of issues In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607170140.14116.pascal@quies.net> <200607171412.09571.pascal@quies.net> Message-ID: Hi All, As I see it, at this stage of the discussion, I think it would be helpful to summarize the concerns. Let me see if I can get this straight, and please correct me, if I am wrong: 1. Sun is making no progress on improving the CommAPI spec. 2. We are seeking to reinvigorate a JSR for the CommAPI in order to keep sun involved. 3. Meanwhile we are extending the RXTX API, with non- commAPI improvements. 4. People are worried that the improvements will be non-portable, when the commAPI re-activates. 5. I have asked for feedback on the JSR approach and obtained zero response. 6. My limited imagination does not see any drawback to taking the JSR approach (except, possibly, from the overhead of a committee, or some license issue that I do not understand). 7. http://www.jcp.org/en/jsr/detail?id=922 shows the status of the JSR now. Status: Withdrawn The sun contact is: vincent.zhang at sun.com I have written to Vincent at Sun to ask him what would be involved with reactivation of JSR 922. If I hear back I will let you know. If there are any objections or suggestions, please let me know. Thanks! - Doug >On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > >> Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: >>> On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: >>>> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>>>> Yes. There are additional methods in gnu.io.SerialPort. We clearly >>>>>> mark those as extensions to CommAPI and discourage their use. There >>>>>> just isn't a way to get the intended functionality out of CommAPI >>>>>> without them. >>>>> >>>>> If you don't want the users to use the methods then make them class >>>>> protected (remove the word "public" before the method) and if you can't >>>>> do that we might do the following: >>>>> >>>>> ---- SerialPort.java >>>>> package javax.comm >>>>> >>>>> class SerialPort extends gnu.io.SerialPort { >>>>> >>>>> public void >>>>> rxtxOnlyMethod() { >>>>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>>>> instead"); >>>>> } >>>>> ---- end >>>> >>>> So how about it, Trent? >>>> >>>> Can we ship those classes with the next release? >>> >>> Hi Pascal >>> >>> I'm not going to say what people can or can not ship. I'm going to >>> propose removing all of the above extensions from SerialPort.java. I >>> think it is the best thing to do after cooling off a bit. >>> >>> But thats all I've considered at this point. I'm in favor of removing the >>> extensions and staying in gnu.io which more importantly means staying at >>> arms length from javax. >>> >>> I can remove the extensions, put a windows fix in, bump the versions and >>> tag the releases without changing packages if everyone agrees to that. >>> If people want to know why CommAPI has not gone through a JSR which makes >>> it clear rxtx can be in javax.comm and explains how conformancy is >>> determined, I do not think this is the right forum though you can freely >>> do so. >> >> Hi Trent, >> >> If I understand it correctly you don't want to put those >>javax.comm classes in >> the distribution until a JSR completes. :( >> >> Sun wants a JSR too to change the API: >>> Ultimately the COMMAPI would be better served if a Java >>> Community Process JSR (http://www.jcp.org) was opened and >>> the COMMAPI was rearchitected to provide a more pluggable >>> framework to improve cross-platform support. Such an >>> architecture would embody a better defined and better >>> documented SPI interface, including a way for comm. ports >>> to be revealed to the client application through the API >>> via platform-aware plugins. Similarly, native code used >>> to access comm port in general could be handled more >>> flexibly using a plugin model, whereby on any platform, >>> multiple native modules could be in use simultaneously. >> >> How about it? I can spend 5 hours a week. > >Yes. I'm all in favor of this. Dr. Doug Lyon is our fearless leader in >these matters and has final say. He has asked everyone if they have an >issue with going through the JSR. I have seen no responses though some >may have responeded to him in private. > >I am now working for The MathWorks in a related field. To best represent >the RXTX community, we have asked Doug to be the neutral maintainer. >This does not mean he is taking on all the work like making releases. He >has the ability to and the power. But thats not really spending his time >efficiently. It does mean when there are decisions to be made that may >have conflicts, he has final say. > >The easy solution :) is to bug Trent or Doug and see if they will just go >into javax.comm namespace. The right solution is to work with Doug and >try to get the JSR process completed. I'm willing to help too as time >permits. > >I'm willing to work with Doug. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jul 17 11:31:58 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 17 Jul 2006 13:31:58 -0400 Subject: [Rxtx] JSR Message-ID: <20060717173158.USWI24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> In the meantime could these methods not be added to a child class. This way the extra functionality can be provided, but you would have to explictly check to see of the class is an RXTX specifc interface. For example: class RxTxCommPort extends CommPort { //RxTx specific methods } CommPort port = commPortIdentifierInstance.open(...); if ( port instanceof RxTxCommPort ) { // do RxTx specifc stuff } // continue doing usual stuff Andre > > From: "Pascal S. de Kloe" > Date: 2006/07/17 Mon AM 08:12:09 EDT > To: RXTX Developers and Users > Subject: [Rxtx] JSR > > Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: > > On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > > > Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: > > >>> Yes. There are additional methods in gnu.io.SerialPort. We clearly > > >>> mark those as extensions to CommAPI and discourage their use. There > > >>> just isn't a way to get the intended functionality out of CommAPI > > >>> without them. > > >> > > >> If you don't want the users to use the methods then make them class > > >> protected (remove the word "public" before the method) and if you can't > > >> do that we might do the following: > > >> > > >> ---- SerialPort.java > > >> package javax.comm > > >> > > >> class SerialPort extends gnu.io.SerialPort { > > >> > > >> public void > > >> rxtxOnlyMethod() { > > >> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort > > >> instead"); > > >> } > > >> ---- end > > > > > > So how about it, Trent? > > > > > > Can we ship those classes with the next release? > > > > Hi Pascal > > > > I'm not going to say what people can or can not ship. I'm going to > > propose removing all of the above extensions from SerialPort.java. I > > think it is the best thing to do after cooling off a bit. > > > > But thats all I've considered at this point. I'm in favor of removing the > > extensions and staying in gnu.io which more importantly means staying at > > arms length from javax. > > > > I can remove the extensions, put a windows fix in, bump the versions and > > tag the releases without changing packages if everyone agrees to that. > > If people want to know why CommAPI has not gone through a JSR which makes > > it clear rxtx can be in javax.comm and explains how conformancy is > > determined, I do not think this is the right forum though you can freely > > do so. > > Hi Trent, > > If I understand it correctly you don't want to put those javax.comm classes in > the distribution until a JSR completes. :( > > Sun wants a JSR too to change the API: > > Ultimately the COMMAPI would be better served if a Java > > Community Process JSR (http://www.jcp.org) was opened and > > the COMMAPI was rearchitected to provide a more pluggable > > framework to improve cross-platform support. Such an > > architecture would embody a better defined and better > > documented SPI interface, including a way for comm. ports > > to be revealed to the client application through the API > > via platform-aware plugins. Similarly, native code used > > to access comm port in general could be handled more > > flexibly using a plugin model, whereby on any platform, > > multiple native modules could be in use simultaneously. > > How about it? I can spend 5 hours a week. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From joachim at buechse.de Mon Jul 17 11:59:19 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 17 Jul 2006 19:59:19 +0200 Subject: [Rxtx] Bumping versions In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> <200607170140.14116.pascal@quies.net> Message-ID: <6ABAF770-41AE-4BA0-800D-2DCC8025FCA8@buechse.de> Hello Trent, I would appreciate if we could get to a version 2.1.8. In fact as several recent posting have shown, almost anyone working on OSX would appreciate getting there. Should anything be removed before that? I dont know. There is nothing wrong with having 2.1.9 following shortly after 2.1.8. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 17.07.2006, at 02:59, Trent Jarvi wrote: > On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > >> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>> Yes. There are additional methods in gnu.io.SerialPort. We >>>> clearly mark >>>> those as extensions to CommAPI and discourage their use. There >>>> just >>>> isn't a way to get the intended functionality out of CommAPI >>>> without >>>> them. >>> >>> If you don't want the users to use the methods then make them class >>> protected (remove the word "public" before the method) and if you >>> can't do >>> that we might do the following: >>> >>> ---- SerialPort.java >>> package javax.comm >>> >>> class SerialPort extends gnu.io.SerialPort { >>> >>> public void >>> rxtxOnlyMethod() { >>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>> instead"); >>> } >>> ---- end >> >> So how about it, Trent? >> >> Can we ship those classes with the next release? > > Hi Pascal > > I'm not going to say what people can or can not ship. I'm going to > propose removing all of the above extensions from SerialPort.java. I > think it is the best thing to do after cooling off a bit. > > But thats all I've considered at this point. I'm in favor of > removing the > extensions and staying in gnu.io which more importantly means > staying at > arms length from javax. > > I can remove the extensions, put a windows fix in, bump the > versions and > tag the releases without changing packages if everyone agrees to that. > If people want to know why CommAPI has not gone through a JSR which > makes > it clear rxtx can be in javax.comm and explains how conformancy is > determined, I do not think this is the right forum though you can > freely > do so. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jul 17 12:40:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 12:40:32 -0600 (MDT) Subject: [Rxtx] Bumping versions In-Reply-To: <6ABAF770-41AE-4BA0-800D-2DCC8025FCA8@buechse.de> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> <200607170140.14116.pascal@quies.net> <6ABAF770-41AE-4BA0-800D-2DCC8025FCA8@buechse.de> Message-ID: Hi Joachim I will work with you towards that. I'm going to the Linux Symposium this week which should mean I have time to tinker. I'll work on rxtx while riding in a carpool to Ottawa. On Mon, 17 Jul 2006, Joachim Buechse wrote: > Hello Trent, > > I would appreciate if we could get to a version 2.1.8. In fact as > several recent posting have shown, almost anyone working on OSX would > appreciate getting there. Should anything be removed before that? I > dont know. There is nothing wrong with having 2.1.9 following shortly > after 2.1.8. > > Regards, > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 17.07.2006, at 02:59, Trent Jarvi wrote: > >> On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: >> >>> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>>> Yes. There are additional methods in gnu.io.SerialPort. We >>>>> clearly mark >>>>> those as extensions to CommAPI and discourage their use. There >>>>> just >>>>> isn't a way to get the intended functionality out of CommAPI >>>>> without >>>>> them. >>>> >>>> If you don't want the users to use the methods then make them class >>>> protected (remove the word "public" before the method) and if you >>>> can't do >>>> that we might do the following: >>>> >>>> ---- SerialPort.java >>>> package javax.comm >>>> >>>> class SerialPort extends gnu.io.SerialPort { >>>> >>>> public void >>>> rxtxOnlyMethod() { >>>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>>> instead"); >>>> } >>>> ---- end >>> >>> So how about it, Trent? >>> >>> Can we ship those classes with the next release? >> >> Hi Pascal >> >> I'm not going to say what people can or can not ship. I'm going to >> propose removing all of the above extensions from SerialPort.java. I >> think it is the best thing to do after cooling off a bit. >> >> But thats all I've considered at this point. I'm in favor of >> removing the >> extensions and staying in gnu.io which more importantly means >> staying at >> arms length from javax. >> >> I can remove the extensions, put a windows fix in, bump the >> versions and >> tag the releases without changing packages if everyone agrees to that. >> If people want to know why CommAPI has not gone through a JSR which >> makes >> it clear rxtx can be in javax.comm and explains how conformancy is >> determined, I do not think this is the right forum though you can >> freely >> do so. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pascal at quies.net Mon Jul 17 17:54:56 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Tue, 18 Jul 2006 01:54:56 +0200 Subject: [Rxtx] summary of issues In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> Message-ID: <200607180154.56359.pascal@quies.net> Op maandag 17 juli 2006 18:34, schreef Dr. Douglas Lyon: > Hi All, > As I see it, at this stage of the discussion, I think it would be helpful > to summarize the concerns. Let me see if I can get this > straight, and please correct me, if I am wrong: Thank you. :) > 1. Sun is making no progress on improving the CommAPI spec. > 2. We are seeking to reinvigorate a JSR for the CommAPI in order > to keep sun involved. Sun wants a JSR becouse they have other concerns than a almost obsolete piece of hardware. > 3. Meanwhile we are extending the RXTX API, with non- > commAPI improvements. > 4. People are worried that the improvements will be non-portable, > when the commAPI re-activates. > 5. I have asked for feedback on the JSR approach and obtained > zero response. > 6. My limited imagination does not see any drawback to taking > the JSR approach (except, possibly, from the overhead of a committee, or > some license issue that I do not understand). > 7. http://www.jcp.org/en/jsr/detail?id=922 shows the status of the JSR now. > Status: Withdrawn > The sun contact is: vincent.zhang at sun.com > I have written to Vincent at Sun to ask him what would be involved with > reactivation of JSR 922. We don't need to communicate with the employees but we need a plan. We need a working implementation with a free license. They have offered us some ideas like in the 2.0.3 README (see attachment). Is there a plan based on the differences of the various platforms? Is there a API purposal? Is there a plan of the JNI? If not I am willing to help. I can write/represent the POSIX part with special interrest of the free UNIX systems. -------------- next part -------------- DISTRIBUTION NOTES: This distribution contains the comm.jar file original part of the COMMAPI 2.0.3 release. The 2.0.3 release itself is no longer distributed. comm.jar, which contains the comm API java class files (eg. Sun's binary implementation of the interface classes), is being made available, unsupported, with no obligation to fix bugs, at the request of the RXTX project. The RxTx project (http://www.rxtx.org), uses the comm.jar class files, but provides their own native library components to provide support for other platforms. The 2.0.3 comm.jar is being provided in this way because as of COMMAPI 3.x, the java binary implementation forked and became incompatible with the RxTx project's native code. Due to the lack of a clear business case, and to resource constraints, no additional resources are being provided to provide an alternative engineering solution at the time of writing. RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: Ultimately the COMMAPI would be better served if a Java Community Process JSR (http://www.jcp.org) was opened and the COMMAPI was rearchitected to provide a more pluggable framework to improve cross-platform support. Such an architecture would embody a better defined and better documented SPI interface, including a way for comm. ports to be revealed to the client application through the API via platform-aware plugins. Similarly, native code used to access comm port in general could be handled more flexibly using a plugin model, whereby on any platform, multiple native modules could be in use simultaneously. Since there are now various ways serial ports can be implemented and accessed, modular comm. port JNI native libraries would be of benefit insofar as removing the burden of over-generalization from any single native component, or inversely, by relieving the implicit constraint that comm. drivers be accessed only via a monolithic mechanism, such as the UNIX vnode interface. paul.klissner at sun.com 6/10/06 From tjarvi at qbang.org Mon Jul 17 18:24:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 18:24:47 -0600 (MDT) Subject: [Rxtx] summary of issues In-Reply-To: <200607180154.56359.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607180154.56359.pascal@quies.net> Message-ID: On Tue, 18 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 17 juli 2006 18:34, schreef Dr. Douglas Lyon: >> Hi All, >> As I see it, at this stage of the discussion, I think it would be helpful >> to summarize the concerns. Let me see if I can get this >> straight, and please correct me, if I am wrong: > > Thank you. :) > >> 1. Sun is making no progress on improving the CommAPI spec. >> 2. We are seeking to reinvigorate a JSR for the CommAPI in order >> to keep sun involved. > > Sun wants a JSR becouse they have other concerns than a almost obsolete piece > of hardware. > >> 3. Meanwhile we are extending the RXTX API, with non- >> commAPI improvements. >> 4. People are worried that the improvements will be non-portable, >> when the commAPI re-activates. >> 5. I have asked for feedback on the JSR approach and obtained >> zero response. >> 6. My limited imagination does not see any drawback to taking >> the JSR approach (except, possibly, from the overhead of a committee, or >> some license issue that I do not understand). >> 7. http://www.jcp.org/en/jsr/detail?id=922 shows the status of the JSR now. >> Status: Withdrawn >> The sun contact is: vincent.zhang at sun.com >> I have written to Vincent at Sun to ask him what would be involved with >> reactivation of JSR 922. > > We don't need to communicate with the employees but we need a plan. We need a > working implementation with a free license. They have offered us some ideas > like in the 2.0.3 README (see attachment). > > Is there a plan based on the differences of the various platforms? Is there a > API purposal? Is there a plan of the JNI? > > If not I am willing to help. I can write/represent the POSIX part with special > interrest of the free UNIX systems. > Not to put words in your mouth but it sounds like you would rather not be in javax.comm namespace at all and do something like a VFS for serial ports as suggested in the readme? Maybe call it a VCS for character streams. That sounds like a major version change rather than an incremental change. So a vote for cutting the ropes and floating in the current? rxtx 3.0 or whatever abandoning current application requirements and perhaps largely rewriting rxtx.. Thats possible and could happen at the same time. An email to Vincent sounds polite enough at this stage. -- Trent Jarvi tjarvi at qbang.org From phillip at uow.edu.au Mon Jul 17 19:33:19 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Tue, 18 Jul 2006 11:33:19 +1000 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application in Mac OSX" Message-ID: <7DBE5FEB-EA06-45BC-ABBE-A9990281E32D@uow.edu.au> Hi We found a workaround - Problem fixed by creating /var/lock directory - seems that they changed the directory from /var/spool/uucp for the lock file but didn't update the documentation. audfg5:~ phillip$ sudo mkdir /var/lock Password: audfg5:~ phillip$ ls -ld /var/lock drwxr-xr-x 2 root wheel 68 Jul 18 09:51 /var/lock audfg5:~ phillip$ sudo chmod 775 /var/lock audfg5:~ phillip$ ls -ld /var/lock drwxrwxr-x 2 root wheel 68 Jul 18 09:51 /var/lock audfg5:~ phillip$ sudo chgrp uucp /var/lock audfg5:~ phillip$ ls -ld /var/lock drwxrwxr-x 2 root uucp 68 Jul 18 09:51 /var/lock audfg5:~ phillip$ ls -l /var/lock total 8 -r--r--r-- 1 phillip uucp 11 Jul 18 09:58 LK.003.009.002 Now both programs work and we get a warning on the console: RXTX Warning: Removing stale lock file. /var/lock/LK.003.009.002 Do we still need the /var/spool/uucp directory?? thanks Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From tjarvi at qbang.org Mon Jul 17 19:40:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 19:40:26 -0600 (MDT) Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application in Mac OSX" In-Reply-To: <7DBE5FEB-EA06-45BC-ABBE-A9990281E32D@uow.edu.au> References: <7DBE5FEB-EA06-45BC-ABBE-A9990281E32D@uow.edu.au> Message-ID: On Tue, 18 Jul 2006, Phillip McKerrow wrote: > Hi > We found a workaround - Problem fixed by creating /var/lock directory > - seems that they changed the directory from /var/spool/uucp for the > lock file but didn't update the documentation. > > audfg5:~ phillip$ sudo mkdir /var/lock > Password: > audfg5:~ phillip$ ls -ld /var/lock > drwxr-xr-x 2 root wheel 68 Jul 18 09:51 /var/lock > audfg5:~ phillip$ sudo chmod 775 /var/lock > audfg5:~ phillip$ ls -ld /var/lock > drwxrwxr-x 2 root wheel 68 Jul 18 09:51 /var/lock > audfg5:~ phillip$ sudo chgrp uucp /var/lock > audfg5:~ phillip$ ls -ld /var/lock > drwxrwxr-x 2 root uucp 68 Jul 18 09:51 /var/lock > audfg5:~ phillip$ ls -l /var/lock > total 8 > -r--r--r-- 1 phillip uucp 11 Jul 18 09:58 LK.003.009.002 > > Now both programs work and we get a warning on the console: > RXTX Warning: Removing stale lock file. /var/lock/LK.003.009.002 > > Do we still need the /var/spool/uucp directory?? > [The new code in CVS will not use Lockfiles on Mac OS X.] The above can happen if you did not close the port before exiting the program. The warning is harmless. RXTX notes that the old program is not running and removes the stale lockfile. -- Trent Jarvi tjarvi at qbang.org From phillip at uow.edu.au Tue Jul 18 01:07:40 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Tue, 18 Jul 2006 17:07:40 +1000 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX Message-ID: Hi I am trying to run a precompiled Java program (JavaKit for setting up the TINI processor over a serial link from http://www.maxim-ic.com/ products/tini/software/downloads.cfm). It uses javax.comm for serial communication. 1. I downloaded the Sparc Solaris version of comm.jar and placed it in /Library/Java/Extensions with RXTXcomm.jar and librxtxSerial.jnilib. 2. I added a javax.com.properties file to /System/Library/Frameworks/ JavaVM.framework/Versions/CurrentJDK/Home/lib It is a text file with one line Driver=gnu.io.RXTXCommDriver 3. When I execute JavaKit it crashes with the following console output audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver (CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:109) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Exception in thread "main" java.lang.UnsatisfiedLinkError: isSessionActive at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts (Portmapping.java:155) at com.sun.comm.Portmapping.refreshPortDatabase (Portmapping.java:100) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:138) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ Home/lib/ext instead of /Library/Java/Extensions it makes no difference: If I use the generic version of comm,jar file from Sun, JavaKit brings up a gui but can't find the serial ports: The console output is: audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while loading driver gnu.io.RXTXCommDriver Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no SolarisSerialParallel in java.library.path Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while loading driver com.sun.comm.SolarisDriver Am I doing something wrong in my efforts to get this going? Should I have another file loaded somewhere or have I run into a bug in RXTX?? thanks again for your help. Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From joachim at buechse.de Tue Jul 18 02:53:38 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 18 Jul 2006 10:53:38 +0200 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: References: Message-ID: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> 2.1.7 is the gnu.io.* version. You need 2.0.7 ie the javax.comm.* version. --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 18.07.2006, at 09:07, Phillip McKerrow wrote: > Hi > > I am trying to run a precompiled Java program (JavaKit for setting up > the TINI processor over a serial link from http://www.maxim-ic.com/ > products/tini/software/downloads.cfm). It uses javax.comm for serial > communication. > > 1. I downloaded the Sparc Solaris version of comm.jar and placed it > in /Library/Java/Extensions with RXTXcomm.jar and > librxtxSerial.jnilib. > > 2. I added a javax.com.properties file to /System/Library/Frameworks/ > JavaVM.framework/Versions/CurrentJDK/Home/lib > It is a text file with one line > Driver=gnu.io.RXTXCommDriver > > 3. When I execute JavaKit it crashes with the following console output > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver > (CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:109) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > Exception in thread "main" java.lang.UnsatisfiedLinkError: > isSessionActive > at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > at com.sun.comm.Portmapping.registerCommPorts > (Portmapping.java:155) > at com.sun.comm.Portmapping.refreshPortDatabase > (Portmapping.java:100) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:138) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > > If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ > Home/lib/ext > instead of /Library/Java/Extensions it makes no difference: > > If I use the generic version of comm,jar file from Sun, JavaKit > brings up a gui but can't find the serial ports: The console > output is: > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while > loading driver gnu.io.RXTXCommDriver > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no > SolarisSerialParallel in java.library.path > Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while > loading driver com.sun.comm.SolarisDriver > > > Am I doing something wrong in my efforts to get this going? Should I > have another file loaded somewhere or have I run into a bug in RXTX?? > > thanks again for your help. > > Phillip > > > ---------------------------------------------------------------------- > Phillip McKerrow http:// > www.uow.edu.au/~phillip/ > School of Information Technology and Computer Science > University of Wollongong * > Northfields Avenue, * * > Wollongong, NSW, 2522. + > AUSTRALIA * the land of the > southern cross > tel : +61 2 4221 3771 fax : +61 2 4221 > 4170 > > God so loved the world that he gave his one and only Son (Jesus), > that whoever believes in him shall not perish but have eternal life. > John 3:16 > ---------------------------------------------------------------------- > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alex at det.ua.pt Tue Jul 18 03:29:15 2006 From: alex at det.ua.pt (Alexandre Mota) Date: Tue, 18 Jul 2006 10:29:15 +0100 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: Message-ID: Hello Edit the JavaKit.java in order to use the gnu.io and compile everything. If you have the RXTX already installed and working it will work. I am using it on linux and windows with jdk 1.5. Best Regards Alexandre -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Phillip McKerrow Sent: ter?a-feira, 18 de Julho de 2006 8:08 To: rxtx at qbang.org Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX Hi I am trying to run a precompiled Java program (JavaKit for setting up the TINI processor over a serial link from http://www.maxim-ic.com/ products/tini/software/downloads.cfm). It uses javax.comm for serial communication. 1. I downloaded the Sparc Solaris version of comm.jar and placed it in /Library/Java/Extensions with RXTXcomm.jar and librxtxSerial.jnilib. 2. I added a javax.com.properties file to /System/Library/Frameworks/ JavaVM.framework/Versions/CurrentJDK/Home/lib It is a text file with one line Driver=gnu.io.RXTXCommDriver 3. When I execute JavaKit it crashes with the following console output audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver (CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:109) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Exception in thread "main" java.lang.UnsatisfiedLinkError: isSessionActive at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts (Portmapping.java:155) at com.sun.comm.Portmapping.refreshPortDatabase (Portmapping.java:100) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:138) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ Home/lib/ext instead of /Library/Java/Extensions it makes no difference: If I use the generic version of comm,jar file from Sun, JavaKit brings up a gui but can't find the serial ports: The console output is: audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while loading driver gnu.io.RXTXCommDriver Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no SolarisSerialParallel in java.library.path Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while loading driver com.sun.comm.SolarisDriver Am I doing something wrong in my efforts to get this going? Should I have another file loaded somewhere or have I run into a bug in RXTX?? thanks again for your help. Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jul 18 04:52:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 18 Jul 2006 04:52:02 -0600 (MDT) Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: References: Message-ID: On Tue, 18 Jul 2006, Phillip McKerrow wrote: > Hi > > I am trying to run a precompiled Java program (JavaKit for setting up > the TINI processor over a serial link from http://www.maxim-ic.com/ > products/tini/software/downloads.cfm). It uses javax.comm for serial > communication. > > 1. I downloaded the Sparc Solaris version of comm.jar and placed it > in /Library/Java/Extensions with RXTXcomm.jar and > librxtxSerial.jnilib. > > 2. I added a javax.com.properties file to /System/Library/Frameworks/ > JavaVM.framework/Versions/CurrentJDK/Home/lib > It is a text file with one line > Driver=gnu.io.RXTXCommDriver > > 3. When I execute JavaKit it crashes with the following console output > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver > (CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:109) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > Exception in thread "main" java.lang.UnsatisfiedLinkError: > isSessionActive > at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > at com.sun.comm.Portmapping.registerCommPorts > (Portmapping.java:155) > at com.sun.comm.Portmapping.refreshPortDatabase > (Portmapping.java:100) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:138) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > > If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ > Home/lib/ext > instead of /Library/Java/Extensions it makes no difference: > > If I use the generic version of comm,jar file from Sun, JavaKit > brings up a gui but can't find the serial ports: The console output is: > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while > loading driver gnu.io.RXTXCommDriver > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no > SolarisSerialParallel in java.library.path > Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while > loading driver com.sun.comm.SolarisDriver > > > Am I doing something wrong in my efforts to get this going? Should I > have another file loaded somewhere or have I run into a bug in RXTX?? > > thanks again for your help. > RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for that. Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Tue Jul 18 16:14:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 18 Jul 2006 18:14:38 -0400 Subject: [Rxtx] jcp and jsr In-Reply-To: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> References: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> Message-ID: Hi All, I have been in touch with: Paul Klissner Please read what Paul writes below. I am not sure, but this might be a good chance for the RXTX group to take action. As to what we should write for the JSR, I am thinking about something in the javax.comm namespace. What is the collective feeling about that? Thanks! - Doug Paul writes: "I think a JSR should be opened, but I don't see any point in proceeding with 922, which never formed and expert group, or provided a specification or reference implementation. It was a placeholder, and the title wasn't even relevant. I think we should discuss our ideas about what we'd like to accomplish and javax.comm and see if we can reach an agreement. You would submit a JSR through the Java Community Process, and if you do, I'd like to represent Sun on the expert group, and contribute to the effort. We may want to start with a fresh specification, borrowing what we want from the current javax.com, adding what we need, and creating a reference implementation. Paul" From pascal at quies.net Tue Jul 18 18:12:26 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 02:12:26 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> Message-ID: <200607190212.27131.pascal@quies.net> Hi Dr., The namespace is the last thing we need to worry about. Let's start with the common goals. For instance the current API is not very object oriented. It might be a good idea to have a static set of objects available representing every supported port available on the system in realtime. Each object should clearly know its own state and its capabilities. To get a port there could be a method like synchronized void connect(PortUser) where PortUser is a interface which handles the interaction with a input and a output stream and listers like PortStillAvailableListener, PortBufferListener and a DataAvailableListener. What is the collective feeling about that? Op woensdag 19 juli 2006 00:14, schreef Dr. Douglas Lyon: > Hi All, > I have been in touch with: > Paul Klissner > Please read what Paul writes below. > I am not sure, but this might be a good chance for > the RXTX group to take action. > As to what we should write for the JSR, I am thinking > about something in the javax.comm namespace. > What is the collective feeling about that? > Thanks! > - Doug > > Paul writes: > "I think a JSR should be opened, but I don't see any point > in proceeding with 922, which never formed and expert group, > or provided a specification or reference implementation. > It was a placeholder, and the title wasn't even relevant. > > I think we should discuss our ideas about what we'd like > to accomplish and javax.comm and see if we can reach an > agreement. > > You would submit a JSR through the Java Community Process, > and if you do, I'd like to represent Sun on the expert group, > and contribute to the effort. We may want to start with > a fresh specification, borrowing what we want from the > current javax.com, adding what we need, and creating > a reference implementation. From phillip at uow.edu.au Tue Jul 18 23:44:25 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Wed, 19 Jul 2006 15:44:25 +1000 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application in Mac OSX" Message-ID: <7EEF3F56-A406-4532-BB3D-AA642A4818CA@uow.edu.au> > > Do we still need the /var/spool/uucp directory?? > > >> Trent Jarvi wrote >>[The new code in CVS will not use Lockfiles on Mac OS X.] Great, that should make installation easier. When will the next version be released? Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From phillip at uow.edu.au Wed Jul 19 00:14:26 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Wed, 19 Jul 2006 16:14:26 +1000 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: References: Message-ID: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> > > Edit the JavaKit.java in order to use the gnu.io and compile > everything. > > Alexandre > Unfotunately all I have is a .jar that contains it. I haven't found the source on their web site. > From: Joachim Buechse > 2.1.7 is the gnu.io.* version. You need 2.0.7 ie the javax.comm.* > version. > > RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for > that. > > Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. > > Trent Jarv I found the rxtx download page and downloaded rxtx-2.0-7pre1 (source/ Mac) The Install folder in ForPackageMaker has librxtxSerial.jnilib and java.com.properties but instead of RXTXComm.jar it has jcl.jar (I have no idea what is is for - it doesn't seem to be a replacement for RXTXCom.jar) I tried to run the XCode project to build it but there is a syntax error - nativeSetSerialPortParams returns a void not a jboolean. Also, there is no target to make RXTXComm.jar JNIEXPORT void JNICALL Java_gnu_io_RXTXPort_nativeSetSerialPortParams (JNIEnv *, jobject, jint, jint, jint, jint); Can you tell me where to find either a working copy of 2.0 for Mac OSX, or RXTXComm.jar or a working XCode project for Version 2. This is getting very frustrating. thanks Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From joachim at buechse.de Wed Jul 19 01:17:03 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 19 Jul 2006 09:17:03 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607190212.27131.pascal@quies.net> References: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> <200607190212.27131.pascal@quies.net> Message-ID: <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> The static objects will work for Windows and Linux, however for OSX they will create problems: - ports can appear and disappear at any time with VCP drivers for USB - the port names are not known until the usb-port is "plugged in" Please do not forget that tty ports can be opened by several applications concurrently. All of those will "loose" the port if anyone opens the corresponding cu port. As this naming based mechanism does not exist on Windows (maybe it does via an API) it should probably be reflected in the API. In other words there are "two levels of open": - Open for reading status lines (1) - Open for reading/writing data (2) I am not sure if state (1) should also allow the modification of certain status lines (ie to set a modem ready). I am also not sure if the api should unify corresponding cu. and tty. ports into one single port. Regards, Joachim On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: > For instance the current API is not very object oriented. > It might be a good idea to have a static set of objects available > representing > every supported port available on the system in realtime. Each > object should > clearly know its own state and its capabilities. To get a port > there could be > a method like synchronized void connect(PortUser) where PortUser is a > interface which handles the interaction with a input and a output > stream and > listers like PortStillAvailableListener, PortBufferListener and a > DataAvailableListener. > > What is the collective feeling about that? From joachim at buechse.de Wed Jul 19 01:29:53 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 19 Jul 2006 09:29:53 +0200 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> References: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> Message-ID: <2D32167B-3830-41D6-9FDD-462301F0453F@buechse.de> As you have already downloaded the source, just cd into the main folder and do a "cvs up -d" this will remove some outdated files and create a new XCode project which should compile without problems. You may also want to search the mail archive or checkout README.OSX for my suggestion on how to avoid the javax.comm.properties file by creating a class com.sun.comm.SolarisDriver. Regards, Joachim PS: I can feel your pain... it was the same for me. In fact I never understood why there are different native or java implementations for 2.0 and 2.1. The two versions could easily be unified by using the simplest of OO programing (intermediate abstract classes). But I guess at the time of branching the direction was not clear. Also the licences are not the same... On 19.07.2006, at 08:14, Phillip McKerrow wrote: >> RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for >> that. >> >> Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. >> >> Trent Jarv > > I found the rxtx download page and downloaded rxtx-2.0-7pre1 (source/ > Mac) > > The Install folder in ForPackageMaker has librxtxSerial.jnilib and > java.com.properties but instead of RXTXComm.jar it has jcl.jar (I > have no idea what is is for - it doesn't seem to be a replacement for > RXTXCom.jar) > > I tried to run the XCode project to build it but there is a syntax > error - nativeSetSerialPortParams returns a void not a jboolean. > Also, there is no target to make RXTXComm.jar > > JNIEXPORT void JNICALL Java_gnu_io_RXTXPort_nativeSetSerialPortParams > (JNIEnv *, jobject, jint, jint, jint, jint); > > Can you tell me where to find either a working copy of 2.0 for Mac > OSX, or RXTXComm.jar or a working XCode project for Version 2. This > is getting very frustrating. > > thanks > > Phillip > > ---------------------------------------------------------------------- > Phillip McKerrow http:// > www.uow.edu.au/~phillip/ > School of Information Technology and Computer Science > University of Wollongong * > Northfields Avenue, * * > Wollongong, NSW, 2522. + > AUSTRALIA * the land of the > southern cross > tel : +61 2 4221 3771 fax : +61 2 4221 > 4170 > > God so loved the world that he gave his one and only Son (Jesus), > that whoever believes in him shall not perish but have eternal life. > John 3:16 > ---------------------------------------------------------------------- > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alex at det.ua.pt Wed Jul 19 03:02:40 2006 From: alex at det.ua.pt (Alexandre Mota) Date: Wed, 19 Jul 2006 10:02:40 +0100 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> References: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> Message-ID: <44BDF530.5080502@det.ua.pt> Phillip McKerrow wrote: >>Edit the JavaKit.java in order to use the gnu.io and compile >>everything. >> >>Alexandre >> >> >> >Unfotunately all I have is a .jar that contains it. I haven't found >the source on their web site. > > > > Download http://files.dalsemi.com/pub/tini/tini1_17.tgz Decompress it and you will find the JavaKiTSrc.jar in the src dir. Decompress it with jar -xf JavaKitSrc.jar and you will get all the source files you need. Alexandre PS: Remenber that puting JavaKit into work is allways a pain... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060719/f5172a01/attachment-0344.html From lyon at docjava.com Wed Jul 19 05:27:47 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 19 Jul 2006 07:27:47 -0400 Subject: [Rxtx] RXTX binary for mac In-Reply-To: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> References: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> Message-ID: Hi All, I have some older RXTX binaries that are deployed in a webstart application. You can try it with: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp The libs are signed and packed for webstart disto by me. http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/ Shows them. - DL > > >> Edit the JavaKit.java in order to use the gnu.io and compile? >> everything. >> >> Alexandre >> >Unfotunately all I have is a .jar that contains it. I haven't found? >the source on their web site. > > >> From: Joachim Buechse >> 2.1.7 is the gnu.io.* version. You need 2.0.7 ie the javax.comm.* >> version. >> > >> RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for? >> that. >> >> Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. >> >> Trent Jarv > >I found the rxtx download page and downloaded rxtx-2.0-7pre1 (source/ >Mac) > >The Install folder in ForPackageMaker has librxtxSerial.jnilib and? >java.com.properties but instead of RXTXComm.jar it has jcl.jar (I? >have no idea what is is for - it doesn't seem to be a replacement for? >RXTXCom.jar) > >I tried to run the XCode project to build it but there is a syntax? >error - nativeSetSerialPortParams returns a void not a jboolean.?? >Also, there is no target to make RXTXComm.jar > >JNIEXPORT void JNICALL Java_gnu_io_RXTXPort_nativeSetSerialPortParams > (JNIEnv *, jobject, jint, jint, jint, jint); > >Can you tell me where to find either a working copy of 2.0 for Mac? >OSX, or RXTXComm.jar or a working XCode project for Version 2. This? >is getting very frustrating. > >thanks > >Phillip > >---------------------------------------------------------------------- >Phillip McKerrow http:// >www.uow.edu.au/~phillip/ >School of Information Technology and Computer Science >University of Wollongong * >Northfields Avenue, * * >Wollongong, NSW, 2522. + >AUSTRALIA * the land of the? >southern cross >tel : +61 2 4221 3771 fax : +61 2 4221 4170 > >God so loved the world that he gave his one and only Son (Jesus), >that whoever believes in him shall not perish but have eternal life. >John 3:16 >---------------------------------------------------------------------- > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Wed Jul 19 06:11:27 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 14:11:27 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> Message-ID: <200607191411.27566.pascal@quies.net> Hi Joachim, Thanks for the constructive critisism. :) Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: > The static objects will work for Windows and Linux, however for OSX > they will create problems: > - ports can appear and disappear at any time with VCP drivers for USB > - the port names are not known until the usb-port is "plugged in" Ports can appear and disappear on *any* OS with USB support. Some Linux distributions even create and remove devicefiles on the fly. With the current API you fetch a list of all available ports and then you try to cast one. What happens if the port is no longer available at that time? What happens if a port vanishes during the data transfer? Of course you can catch exceptions but that makes the code quite messy. The idea was to get a PortStillAvailableListener interface. In that way the implementation is free to handle a cleanup or wait for return routine in a OO way. The I/O streams should just lock. The word static was not ment as persistent but as Java static available. Considder the following: java.lang.hw.HardwareConfiguration { public enum PortType { RS232, I2C, etc. }; /** Gets the currently available ports of type {@code PortType}. */ public static java.lang.hw.Port[] getPorts(PortType); } com.example.Driver implements PortUser, implements PortStillAvailableListener { public portNoLongerAvailable(PortEvent event) { // cleanup & dismiss. } } com.example.Application { public static void main(String[] args) { Driver someDriver = new Driver(); Port radomPort = HardwareConfiguration.getPorts( HardwareConfiguration.PortType.RS232)[1]; myDevice.addStillAvailableListener(someDriver); myDevice.connect(someDriver); } } > Please do not forget that tty ports can be opened by several > applications concurrently. All of those will "loose" the port if > anyone opens the corresponding cu port. Indeed we need a good overview of the differences between the various platforms. Should we create a document or a Wiki for this purpose? FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: http://www.openbsd.org/cgi-bin/man.cgi?query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html Linux uses /var/lock: http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES Is there absolutely no way to get a lock under Windows? > As this naming based > mechanism does not exist on Windows (maybe it does via an API) it > should probably be reflected in the API. In other words there are > "two levels of open": > > - Open for reading status lines (1) > - Open for reading/writing data (2) > > I am not sure if state (1) should also allow the modification of > certain status lines (ie to set a modem ready). I'm not sure I understand. Do you mean canonical and noncanonical mode? How far is Windows with the canonical mode. Is it comparable to POSIX? > I am also not sure if > the api should unify corresponding cu. and tty. ports into one single > port. I think the API should hide low-level details like devicefiles. Who is participating anyway? Is it just the four of us? Cheers, Pascal > On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: > > For instance the current API is not very object oriented. > > It might be a good idea to have a static set of objects available > > representing > > every supported port available on the system in realtime. Each > > object should > > clearly know its own state and its capabilities. To get a port > > there could be > > a method like synchronized void connect(PortUser) where PortUser is a > > interface which handles the interaction with a input and a output > > stream and > > listers like PortStillAvailableListener, PortBufferListener and a > > DataAvailableListener. > > > > What is the collective feeling about that? From joachim at buechse.de Wed Jul 19 07:09:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 19 Jul 2006 15:09:27 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191411.27566.pascal@quies.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> Message-ID: <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> Pascal, I think that the PortNoLongerAvailableListener creates more problems than it solves. I think that exceptions are much better suited for this case. There might be an additional method "Port.isOpen" or "Port.isAvailable" which interested applications may call at times best suited. Most implementations will only find out, that a port disappeared when trying to read or write. Anything else would require polling with a high frequency or kernel hooks that do not exist (in POSIX). Any kind of call back like portNoLongerAvailable() creates the risk of deadlocks and races which require an involved implementation as the library does not know what it is calling (ie a user might try to call close from the callback which can block a very long time). Callbacks introduce concurrency which unneccessarily increases the complexity. Regards, Joachim On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: > Hi Joachim, > > Thanks for the constructive critisism. :) > > Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >> The static objects will work for Windows and Linux, however for OSX >> they will create problems: >> - ports can appear and disappear at any time with VCP drivers for USB >> - the port names are not known until the usb-port is "plugged in" > > Ports can appear and disappear on *any* OS with USB support. Some > Linux > distributions even create and remove devicefiles on the fly. > > With the current API you fetch a list of all available ports and > then you try > to cast one. What happens if the port is no longer available at > that time? > What happens if a port vanishes during the data transfer? Of course > you can > catch exceptions but that makes the code quite messy. > > The idea was to get a PortStillAvailableListener interface. In that > way the > implementation is free to handle a cleanup or wait for return > routine in a OO > way. The I/O streams should just lock. > > The word static was not ment as persistent but as Java static > available. > Considder the following: > > java.lang.hw.HardwareConfiguration { > public enum PortType { RS232, I2C, etc. }; > > /** Gets the currently available ports of type {@code PortType}. */ > public static java.lang.hw.Port[] getPorts(PortType); > } > > com.example.Driver implements PortUser, implements > PortStillAvailableListener > { > public portNoLongerAvailable(PortEvent event) { > // cleanup & dismiss. > } > } > > com.example.Application { > public static void main(String[] args) { > Driver someDriver = new Driver(); > Port radomPort = HardwareConfiguration.getPorts( > HardwareConfiguration.PortType.RS232)[1]; > myDevice.addStillAvailableListener(someDriver); > myDevice.connect(someDriver); > } > } > >> Please do not forget that tty ports can be opened by several >> applications concurrently. All of those will "loose" the port if >> anyone opens the corresponding cu port. > > Indeed we need a good overview of the differences between the various > platforms. Should we create a document or a Wiki for this purpose? > > FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: > http://www.openbsd.org/cgi-bin/man.cgi? > query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD > +Current&arch=i386&format=html > > Linux uses /var/lock: > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > Is there absolutely no way to get a lock under Windows? > >> As this naming based >> mechanism does not exist on Windows (maybe it does via an API) it >> should probably be reflected in the API. In other words there are >> "two levels of open": >> >> - Open for reading status lines (1) >> - Open for reading/writing data (2) >> >> I am not sure if state (1) should also allow the modification of >> certain status lines (ie to set a modem ready). > > I'm not sure I understand. Do you mean canonical and noncanonical > mode? > > How far is Windows with the canonical mode. Is it comparable to POSIX? > >> I am also not sure if >> the api should unify corresponding cu. and tty. ports into one single >> port. > > I think the API should hide low-level details like devicefiles. > > > Who is participating anyway? Is it just the four of us? > > Cheers, > > Pascal > > >> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>> For instance the current API is not very object oriented. >>> It might be a good idea to have a static set of objects available >>> representing >>> every supported port available on the system in realtime. Each >>> object should >>> clearly know its own state and its capabilities. To get a port >>> there could be >>> a method like synchronized void connect(PortUser) where PortUser >>> is a >>> interface which handles the interaction with a input and a output >>> stream and >>> listers like PortStillAvailableListener, PortBufferListener and a >>> DataAvailableListener. >>> >>> What is the collective feeling about that? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Wed Jul 19 08:33:08 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Wed, 19 Jul 2006 11:33:08 -0300 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191411.27566.pascal@quies.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> Message-ID: <44BE42A4.3030203@gmail.com> > Linux uses /var/lock: > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > Is there absolutely no way to get a lock under Windows? Indeed Windows block ports when someone open ones. Java Comm could manage this feature. > Who is participating anyway? Is it just the four of us? I can help too. Regards, Manuel From pascal at quies.net Wed Jul 19 09:01:17 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 17:01:17 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> References: <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> Message-ID: <200607191701.17607.pascal@quies.net> In the POSIX world things are simple. If any transaction fails with ENOTTY we lock the I/O streams and create a PortNoLongerAvailableEvent. We *might* even go so far as to start a thread which polls the tty say once a second afther a PortNoLongerAvailableEvent and kill it if there is succes with a PortAvailableAgainEvent but there won't be anything like deadlocks and races. I promise. ;) Methods like isOpen and isAvailable require polling which is exactly what we both don't want and they can't be reliable since it is a moment. A clean sepparation of the functional code and Listeners for events makes the code better readable and more flexible. PS If OS X has a notification system for changes in the available ports this OS specific functionality is more simple to implement too. Op woensdag 19 juli 2006 15:09, schreef Joachim Buechse: > Pascal, > > I think that the PortNoLongerAvailableListener creates more problems > than it solves. > > I think that exceptions are much better suited for this case. There > might be an additional method "Port.isOpen" or "Port.isAvailable" > which interested applications may call at times best suited. > > Most implementations will only find out, that a port disappeared when > trying to read or write. Anything else would require polling with a > high frequency or kernel hooks that do not exist (in POSIX). Any kind > of call back like portNoLongerAvailable() creates the risk of > deadlocks and races which require an involved implementation as the > library does not know what it is calling (ie a user might try to call > close from the callback which can block a very long time). Callbacks > introduce concurrency which unneccessarily increases the complexity. > > Regards, > Joachim From jredman at ergotech.com Wed Jul 19 09:20:39 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 09:20:39 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191411.27566.pascal@quies.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> Message-ID: <44BE4DC7.7@ergotech.com> Pascal S. de Kloe wrote: >> I am also not sure if >> the api should unify corresponding cu. and tty. ports into one single >> port. > > I think the API should hide low-level details like devicefiles. Not all ports have device files. It's long been my goal to add support for virtual serial ports, that is, serial ports on Ethernet terminal servers, for example integrating RFC2217. This means that the port name is some combination of an IP address and TCP port number. Nothing in /dev. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From brian at mbari.org Wed Jul 19 10:04:51 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 19 Jul 2006 09:04:51 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BE42A4.3030203@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <44BE42A4.3030203@gmail.com> Message-ID: <5FDA8DB5-FD08-4EAA-81A7-C46A7CF6FA18@mbari.org> >> Who is participating anyway? Is it just the four of us? > I'm not much of a POSIX or C guy. But I do a lot of OO design. I'm happy to throw my 2 cents in too. Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060719/404de230/attachment-0343.html From pascal at quies.net Wed Jul 19 10:16:16 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 18:16:16 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BE4DC7.7@ergotech.com> References: <200607191411.27566.pascal@quies.net> <44BE4DC7.7@ergotech.com> Message-ID: <200607191816.17099.pascal@quies.net> Op woensdag 19 juli 2006 17:20, schreef Jim Redman: > Pascal S. de Kloe wrote: > >> I am also not sure if > >> the api should unify corresponding cu. and tty. ports into one single > >> port. > > > > I think the API should hide low-level details like devicefiles. > > Not all ports have device files. It's long been my goal to add support > for virtual serial ports, that is, serial ports on Ethernet terminal > servers, for example integrating RFC2217. This means that the port name > is some combination of an IP address and TCP port number. Nothing in /dev. > > Jim This idea doesn't need any native calls at all, right? How would you like to realize that? Jini? I'm sure you knew that the server is already there: http://www.viara.cn/en/jts.htm From pascal at quies.net Wed Jul 19 10:17:12 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 18:17:12 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <5FDA8DB5-FD08-4EAA-81A7-C46A7CF6FA18@mbari.org> References: <44BE42A4.3030203@gmail.com> <5FDA8DB5-FD08-4EAA-81A7-C46A7CF6FA18@mbari.org> Message-ID: <200607191817.12769.pascal@quies.net> Op woensdag 19 juli 2006 18:04, schreef Brian Schlining: > >> Who is participating anyway? Is it just the four of us? > > I'm not much of a POSIX or C guy. But I do a lot of OO design. I'm > happy to throw my 2 cents in too. > > Brian Schlining > Software Engineer > http://www.mbari.org Excellent! :) We need a lot of opinions from all kinds of users. From jredman at ergotech.com Wed Jul 19 10:54:18 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 10:54:18 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191816.17099.pascal@quies.net> References: <200607191411.27566.pascal@quies.net> <44BE4DC7.7@ergotech.com> <200607191816.17099.pascal@quies.net> Message-ID: <44BE63BA.9090905@ergotech.com> Pascal, Pascal S. de Kloe wrote: > Op woensdag 19 juli 2006 17:20, schreef Jim Redman: >> Pascal S. de Kloe wrote: >>>> I am also not sure if >>>> the api should unify corresponding cu. and tty. ports into one single >>>> port. >>> I think the API should hide low-level details like devicefiles. >> Not all ports have device files. It's long been my goal to add support >> for virtual serial ports, that is, serial ports on Ethernet terminal >> servers, for example integrating RFC2217. This means that the port name >> is some combination of an IP address and TCP port number. Nothing in /dev. >> >> Jim > > This idea doesn't need any native calls at all, right? No native calls, it's just a Socket link. > > How would you like to realize that? I keep wondering that myself. I had in mind port names that are, for example, "192.168.0.99:3000". These would need to be added to the properties file (or the -D option). I'm open for suggestion. It's conceptually, it's the same as USB. Instead of USB->Serial it's Ethernet->Serial. The difference is that the USB devices create virtual serial ports within the OS. Some Ethernet devices also do this, but since, unlike USB communications, TCP/IP is supported natively within Java such a driver is unnecessary. > Jini? Is that still alive and kicking? > > I'm sure you knew that the server is already there: > > http://www.viara.cn/en/jts.htm Yes, that library is part of the plan. These devices are real serial ports. Somewhere, out in the Ether there's a DB9/DB25 cable with RS232/485 bits flowing over it. Since these are real ports, I'd like the ports to look like real serial ports (SerialPort) and not have to handle them as special cases. We have a bunch of code that deals with serial devices (PLCs, Barcode, Temperature Controllers, RFID, SECS, etc. etc.) and to rewrite each one of those to handle this case doesn't make much sense when the correct place to encapsulate a serial port is in the SerialPort layer. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From pascal at quies.net Wed Jul 19 12:44:01 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 20:44:01 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BE63BA.9090905@ergotech.com> References: <200607191816.17099.pascal@quies.net> <44BE63BA.9090905@ergotech.com> Message-ID: <200607192044.01966.pascal@quies.net> Op woensdag 19 juli 2006 18:54, schreef Jim Redman: > I keep wondering that myself. I had in mind port names that are, for > example, "192.168.0.99:3000". These would need to be added to the > properties file (or the -D option). > > I'm open for suggestion. Jini works very well especialy for ethernets like the one you describe. It's a shame that it never got the attention it deserves. > > Jini? > > Is that still alive and kicking? Not that it does matter becouse Java software doesn't need much maintenance. ;) Have a look at http://www.jini.org/. From Paul.Klissner at Sun.COM Wed Jul 19 15:45:38 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 14:45:38 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> Message-ID: <44BEA802.7060508@sun.com> Joachim Buechse wrote: > Pascal, > > I think that the PortNoLongerAvailableListener creates more problems > than it solves. > > I think that exceptions are much better suited for this case. There > might be an additional method "Port.isOpen" or "Port.isAvailable" > which interested applications may call at times best suited. > > Most implementations will only find out, that a port disappeared when > trying to read or write. Anything else would require polling with a > high frequency or kernel hooks that do not exist (in POSIX). Any kind > of call back like portNoLongerAvailable() creates the risk of > deadlocks and races which require an involved implementation as the > library does not know what it is calling (ie a user might try to call > close from the callback which can block a very long time). Callbacks > introduce concurrency which unneccessarily increases the complexity. I think we should find out what are the minimum requirements to get a JSR open, form an expert group, and get that group discussing these things in the JSR. I'm not pushing for Sun to sponsor it, as I think there is a community interest already and that it deserves an independent life and commitment. ACCESS EXCEPTIONS: ----------------- I agree, exceptions of this sort are the way to go. Exceptions are already simpler than having to err check at each function call, so a big improvement. No need to architect a more trouble prone complexity into the API. PROJECT SCOPE: ------------- Also, we should think carefully about what the scope of this project would be. Should it be javax."comm" which handles both serial and parallel (is parallel going by the wayside). Should it be split into two project: javax.EIA232 (or javax.RS232), and javax.IEEE1284? Should we differentiate between single-ended serial protocols, like EIA232, I2C, 2-WIRE, SPI, vs. quasi-multidrop and full multidrop busses such as EIA422, EIA432 and EIA485? If we really were to add I2C support to the API, we'd have to delve into the semantics more, because there could be some implicit decoding of the bus the API users would want to see. At this point, I'm thinking they're all different, and should be their own projects.. perhaps there could be an umbrella layer that abstracted out some of the generic issues like device ownership and access, perhaps not. javax.eia232 javax.eia485 or (javax.EIX4xx?) javax.i2c, javax.spi (or javax.chipbus?) DRIVER PLUGINS: -------------- Taking javax.eia232 for example, I think we need an architecture that allows for multiple plugins to provide multiple simultaneous drivers/adapters to allow for heterogeneous providers on a single system. For example, not only can there be USB based serial devices but networked serial devices, for example accessing devices on thin clients. PORTMAPPING: ----------- For Sun's javax.comm 3.0, we introduced a portmapping abstraction layer, that creates a mechansim to help administer the view (filtering)of available ports given to the application, and the name of such ports. I hope we can consider the right platform neutral way to accomplish that. In javax.comm as it is now, the API has to know where to go and look to find ports. In 3.x I added the ability to specify where to look for standard ports as properties to make it more flexible, but for our thin client platform, which can represent a very dynamic buffet of ports splayed in the leaf nodes of a tree that isn't good enough. That complicates things for the users (having to specify and manage unique and long path names to ports which can come and go), so there is an option whereby the user can configure something like "com1" such that on a thin client it represents the first port of the first USB/serial dongle connected. Javax.comm knows how to find that in the context of the current thin client, but the administrator doesn't have to worry about it. How to architect the API flexibly enough to allow for this kind of thing needs to be considered. Paul > > Regards, > Joachim > > On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: > >> Hi Joachim, >> >> Thanks for the constructive critisism. :) >> >> Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >>> The static objects will work for Windows and Linux, however for OSX >>> they will create problems: >>> - ports can appear and disappear at any time with VCP drivers for USB >>> - the port names are not known until the usb-port is "plugged in" >> Ports can appear and disappear on *any* OS with USB support. Some >> Linux >> distributions even create and remove devicefiles on the fly. >> >> With the current API you fetch a list of all available ports and >> then you try >> to cast one. What happens if the port is no longer available at >> that time? >> What happens if a port vanishes during the data transfer? Of course >> you can >> catch exceptions but that makes the code quite messy. >> >> The idea was to get a PortStillAvailableListener interface. In that >> way the >> implementation is free to handle a cleanup or wait for return >> routine in a OO >> way. The I/O streams should just lock. >> >> The word static was not ment as persistent but as Java static >> available. >> Considder the following: >> >> java.lang.hw.HardwareConfiguration { >> public enum PortType { RS232, I2C, etc. }; >> >> /** Gets the currently available ports of type {@code PortType}. */ >> public static java.lang.hw.Port[] getPorts(PortType); >> } >> >> com.example.Driver implements PortUser, implements >> PortStillAvailableListener >> { >> public portNoLongerAvailable(PortEvent event) { >> // cleanup & dismiss. >> } >> } >> >> com.example.Application { >> public static void main(String[] args) { >> Driver someDriver = new Driver(); >> Port radomPort = HardwareConfiguration.getPorts( >> HardwareConfiguration.PortType.RS232)[1]; >> myDevice.addStillAvailableListener(someDriver); >> myDevice.connect(someDriver); >> } >> } >> >>> Please do not forget that tty ports can be opened by several >>> applications concurrently. All of those will "loose" the port if >>> anyone opens the corresponding cu port. >> Indeed we need a good overview of the differences between the various >> platforms. Should we create a document or a Wiki for this purpose? >> >> FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: >> http://www.openbsd.org/cgi-bin/man.cgi? >> query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD >> +Current&arch=i386&format=html >> >> Linux uses /var/lock: >> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES >> >> Is there absolutely no way to get a lock under Windows? >> >>> As this naming based >>> mechanism does not exist on Windows (maybe it does via an API) it >>> should probably be reflected in the API. In other words there are >>> "two levels of open": >>> >>> - Open for reading status lines (1) >>> - Open for reading/writing data (2) >>> >>> I am not sure if state (1) should also allow the modification of >>> certain status lines (ie to set a modem ready). >> I'm not sure I understand. Do you mean canonical and noncanonical >> mode? >> >> How far is Windows with the canonical mode. Is it comparable to POSIX? >> >>> I am also not sure if >>> the api should unify corresponding cu. and tty. ports into one single >>> port. >> I think the API should hide low-level details like devicefiles. >> >> >> Who is participating anyway? Is it just the four of us? >> >> Cheers, >> >> Pascal >> >> >>> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>>> For instance the current API is not very object oriented. >>>> It might be a good idea to have a static set of objects available >>>> representing >>>> every supported port available on the system in realtime. Each >>>> object should >>>> clearly know its own state and its capabilities. To get a port >>>> there could be >>>> a method like synchronized void connect(PortUser) where PortUser >>>> is a >>>> interface which handles the interaction with a input and a output >>>> stream and >>>> listers like PortStillAvailableListener, PortBufferListener and a >>>> DataAvailableListener. >>>> >>>> What is the collective feeling about that? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Wed Jul 19 16:32:37 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 16:32:37 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEA802.7060508@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <44BEB305.3030208@ergotech.com> For one, I'd object to the splitting of 232 and 485 and question why it's necessary. Often the only difference between 232 access and 485 access is whether there's a converter attached to the serial port. Put another way, while 485 is multidrop, I think that's an application level issue rather than a driver level issue. If the issue is electrical, I don't think that it's possible to reliably support receiver switching of a 2-wire 485 network within Java, the timing is just too tight, so your stuck with requiring a 485 converter that automatically switches (not an onerous burden for us) or some OS level intervention. Anyway, if we're going to start differentiating at the electrical level we still support some current loop systems (Siemens S5 PLC if you care). Jim Paul Klissner wrote: > Joachim Buechse wrote: >> Pascal, >> >> I think that the PortNoLongerAvailableListener creates more problems >> than it solves. >> >> I think that exceptions are much better suited for this case. There >> might be an additional method "Port.isOpen" or "Port.isAvailable" >> which interested applications may call at times best suited. >> >> Most implementations will only find out, that a port disappeared when >> trying to read or write. Anything else would require polling with a >> high frequency or kernel hooks that do not exist (in POSIX). Any kind >> of call back like portNoLongerAvailable() creates the risk of >> deadlocks and races which require an involved implementation as the >> library does not know what it is calling (ie a user might try to call >> close from the callback which can block a very long time). Callbacks >> introduce concurrency which unneccessarily increases the complexity. > > I think we should find out what are the minimum requirements > to get a JSR open, form an expert group, and get that group > discussing these things in the JSR. I'm not pushing for > Sun to sponsor it, as I think there is a community interest > already and that it deserves an independent life and > commitment. > > ACCESS EXCEPTIONS: > ----------------- > I agree, exceptions of this sort are the way to go. > Exceptions are already simpler than having to err > check at each function call, so a big improvement. > No need to architect a more trouble prone complexity > into the API. > > PROJECT SCOPE: > ------------- > > Also, we should think carefully about what the scope of > this project would be. Should it be javax."comm" which > handles both serial and parallel (is parallel going by the > wayside). Should it be split into two project: > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > > Should we differentiate between single-ended serial > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > quasi-multidrop and full multidrop busses such as > EIA422, EIA432 and EIA485? If we really were to > add I2C support to the API, we'd have to delve into > the semantics more, because there could be some > implicit decoding of the bus the API users would > want to see. > > At this point, I'm thinking they're all different, > and should be their own projects.. perhaps there > could be an umbrella layer that abstracted out > some of the generic issues like device ownership > and access, perhaps not. > > javax.eia232 > javax.eia485 or (javax.EIX4xx?) > javax.i2c, javax.spi (or javax.chipbus?) > > DRIVER PLUGINS: > -------------- > Taking javax.eia232 for example, I think we need an > architecture that allows for multiple plugins to > provide multiple simultaneous drivers/adapters to > allow for heterogeneous providers on a single system. > For example, not only can there be USB based serial > devices but networked serial devices, for example > accessing devices on thin clients. > > PORTMAPPING: > ----------- > For Sun's javax.comm 3.0, we introduced a portmapping > abstraction layer, that creates a mechansim to help > administer the view (filtering)of available ports given > to the application, and the name of such ports. I hope we > can consider the right platform neutral way to > accomplish that. > > In javax.comm as it is now, the API has to know > where to go and look to find ports. In 3.x I added > the ability to specify where to look for standard > ports as properties to make it more flexible, but > for our thin client platform, which can represent > a very dynamic buffet of ports splayed in the > leaf nodes of a tree that isn't good enough. > That complicates things for the users (having > to specify and manage unique and long path names > to ports which can come and go), so there is > an option whereby the user can configure > something like "com1" such that on a thin client > it represents the first port of the first USB/serial > dongle connected. Javax.comm knows how to find > that in the context of the current thin client, > but the administrator doesn't have to worry about it. > > How to architect the API flexibly enough to allow > for this kind of thing needs to be considered. > > Paul > > > >> Regards, >> Joachim >> >> On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: >> >>> Hi Joachim, >>> >>> Thanks for the constructive critisism. :) >>> >>> Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >>>> The static objects will work for Windows and Linux, however for OSX >>>> they will create problems: >>>> - ports can appear and disappear at any time with VCP drivers for USB >>>> - the port names are not known until the usb-port is "plugged in" >>> Ports can appear and disappear on *any* OS with USB support. Some >>> Linux >>> distributions even create and remove devicefiles on the fly. >>> >>> With the current API you fetch a list of all available ports and >>> then you try >>> to cast one. What happens if the port is no longer available at >>> that time? >>> What happens if a port vanishes during the data transfer? Of course >>> you can >>> catch exceptions but that makes the code quite messy. >>> >>> The idea was to get a PortStillAvailableListener interface. In that >>> way the >>> implementation is free to handle a cleanup or wait for return >>> routine in a OO >>> way. The I/O streams should just lock. >>> >>> The word static was not ment as persistent but as Java static >>> available. >>> Considder the following: >>> >>> java.lang.hw.HardwareConfiguration { >>> public enum PortType { RS232, I2C, etc. }; >>> >>> /** Gets the currently available ports of type {@code PortType}. */ >>> public static java.lang.hw.Port[] getPorts(PortType); >>> } >>> >>> com.example.Driver implements PortUser, implements >>> PortStillAvailableListener >>> { >>> public portNoLongerAvailable(PortEvent event) { >>> // cleanup & dismiss. >>> } >>> } >>> >>> com.example.Application { >>> public static void main(String[] args) { >>> Driver someDriver = new Driver(); >>> Port radomPort = HardwareConfiguration.getPorts( >>> HardwareConfiguration.PortType.RS232)[1]; >>> myDevice.addStillAvailableListener(someDriver); >>> myDevice.connect(someDriver); >>> } >>> } >>> >>>> Please do not forget that tty ports can be opened by several >>>> applications concurrently. All of those will "loose" the port if >>>> anyone opens the corresponding cu port. >>> Indeed we need a good overview of the differences between the various >>> platforms. Should we create a document or a Wiki for this purpose? >>> >>> FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: >>> http://www.openbsd.org/cgi-bin/man.cgi? >>> query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD >>> +Current&arch=i386&format=html >>> >>> Linux uses /var/lock: >>> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES >>> >>> Is there absolutely no way to get a lock under Windows? >>> >>>> As this naming based >>>> mechanism does not exist on Windows (maybe it does via an API) it >>>> should probably be reflected in the API. In other words there are >>>> "two levels of open": >>>> >>>> - Open for reading status lines (1) >>>> - Open for reading/writing data (2) >>>> >>>> I am not sure if state (1) should also allow the modification of >>>> certain status lines (ie to set a modem ready). >>> I'm not sure I understand. Do you mean canonical and noncanonical >>> mode? >>> >>> How far is Windows with the canonical mode. Is it comparable to POSIX? >>> >>>> I am also not sure if >>>> the api should unify corresponding cu. and tty. ports into one single >>>> port. >>> I think the API should hide low-level details like devicefiles. >>> >>> >>> Who is participating anyway? Is it just the four of us? >>> >>> Cheers, >>> >>> Pascal >>> >>> >>>> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>>>> For instance the current API is not very object oriented. >>>>> It might be a good idea to have a static set of objects available >>>>> representing >>>>> every supported port available on the system in realtime. Each >>>>> object should >>>>> clearly know its own state and its capabilities. To get a port >>>>> there could be >>>>> a method like synchronized void connect(PortUser) where PortUser >>>>> is a >>>>> interface which handles the interaction with a input and a output >>>>> stream and >>>>> listers like PortStillAvailableListener, PortBufferListener and a >>>>> DataAvailableListener. >>>>> >>>>> What is the collective feeling about that? >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Paul.Klissner at Sun.COM Wed Jul 19 17:31:36 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 16:31:36 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEB305.3030208@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> Message-ID: <44BEC0D8.4050806@sun.com> Jim Redman wrote: > For one, I'd object to the splitting of 232 and 485 and question why > it's necessary. Often the only difference between 232 access and 485 > access is whether there's a converter attached to the serial port. > > Put another way, while 485 is multidrop, I think that's an application > level issue rather than a driver level issue. > > If the issue is electrical, I don't think that it's possible to reliably > support receiver switching of a 2-wire 485 network within Java, the > timing is just too tight, so your stuck with requiring a 485 converter > that automatically switches (not an onerous burden for us) or some OS > level intervention. > > Anyway, if we're going to start differentiating at the electrical level > we still support some current loop systems (Siemens S5 PLC if you care). > > Jim To be honest, I've not done anything with 422, 423 or 485, so I have no objection to keeping them together if there isn't enough of a protocol distinction to make it worth seperating them out. I'd just like to find another suitable name than javax.comm, unless the JSR wants to start with javax.comm 4.0, since all the previous 'major revisions' are accounted for. javax.serialport? Paul > > Paul Klissner wrote: >> Joachim Buechse wrote: >>> Pascal, >>> >>> I think that the PortNoLongerAvailableListener creates more problems >>> than it solves. >>> >>> I think that exceptions are much better suited for this case. There >>> might be an additional method "Port.isOpen" or "Port.isAvailable" >>> which interested applications may call at times best suited. >>> >>> Most implementations will only find out, that a port disappeared when >>> trying to read or write. Anything else would require polling with a >>> high frequency or kernel hooks that do not exist (in POSIX). Any kind >>> of call back like portNoLongerAvailable() creates the risk of >>> deadlocks and races which require an involved implementation as the >>> library does not know what it is calling (ie a user might try to call >>> close from the callback which can block a very long time). Callbacks >>> introduce concurrency which unneccessarily increases the complexity. >> I think we should find out what are the minimum requirements >> to get a JSR open, form an expert group, and get that group >> discussing these things in the JSR. I'm not pushing for >> Sun to sponsor it, as I think there is a community interest >> already and that it deserves an independent life and >> commitment. >> >> ACCESS EXCEPTIONS: >> ----------------- >> I agree, exceptions of this sort are the way to go. >> Exceptions are already simpler than having to err >> check at each function call, so a big improvement. >> No need to architect a more trouble prone complexity >> into the API. >> >> PROJECT SCOPE: >> ------------- >> >> Also, we should think carefully about what the scope of >> this project would be. Should it be javax."comm" which >> handles both serial and parallel (is parallel going by the >> wayside). Should it be split into two project: >> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >> >> Should we differentiate between single-ended serial >> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >> quasi-multidrop and full multidrop busses such as >> EIA422, EIA432 and EIA485? If we really were to >> add I2C support to the API, we'd have to delve into >> the semantics more, because there could be some >> implicit decoding of the bus the API users would >> want to see. >> >> At this point, I'm thinking they're all different, >> and should be their own projects.. perhaps there >> could be an umbrella layer that abstracted out >> some of the generic issues like device ownership >> and access, perhaps not. >> >> javax.eia232 >> javax.eia485 or (javax.EIX4xx?) >> javax.i2c, javax.spi (or javax.chipbus?) >> >> DRIVER PLUGINS: >> -------------- >> Taking javax.eia232 for example, I think we need an >> architecture that allows for multiple plugins to >> provide multiple simultaneous drivers/adapters to >> allow for heterogeneous providers on a single system. >> For example, not only can there be USB based serial >> devices but networked serial devices, for example >> accessing devices on thin clients. >> >> PORTMAPPING: >> ----------- >> For Sun's javax.comm 3.0, we introduced a portmapping >> abstraction layer, that creates a mechansim to help >> administer the view (filtering)of available ports given >> to the application, and the name of such ports. I hope we >> can consider the right platform neutral way to >> accomplish that. >> >> In javax.comm as it is now, the API has to know >> where to go and look to find ports. In 3.x I added >> the ability to specify where to look for standard >> ports as properties to make it more flexible, but >> for our thin client platform, which can represent >> a very dynamic buffet of ports splayed in the >> leaf nodes of a tree that isn't good enough. >> That complicates things for the users (having >> to specify and manage unique and long path names >> to ports which can come and go), so there is >> an option whereby the user can configure >> something like "com1" such that on a thin client >> it represents the first port of the first USB/serial >> dongle connected. Javax.comm knows how to find >> that in the context of the current thin client, >> but the administrator doesn't have to worry about it. >> >> How to architect the API flexibly enough to allow >> for this kind of thing needs to be considered. >> >> Paul >> >> >> >>> Regards, >>> Joachim >>> >>> On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: >>> >>>> Hi Joachim, >>>> >>>> Thanks for the constructive critisism. :) >>>> >>>> Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >>>>> The static objects will work for Windows and Linux, however for OSX >>>>> they will create problems: >>>>> - ports can appear and disappear at any time with VCP drivers for USB >>>>> - the port names are not known until the usb-port is "plugged in" >>>> Ports can appear and disappear on *any* OS with USB support. Some >>>> Linux >>>> distributions even create and remove devicefiles on the fly. >>>> >>>> With the current API you fetch a list of all available ports and >>>> then you try >>>> to cast one. What happens if the port is no longer available at >>>> that time? >>>> What happens if a port vanishes during the data transfer? Of course >>>> you can >>>> catch exceptions but that makes the code quite messy. >>>> >>>> The idea was to get a PortStillAvailableListener interface. In that >>>> way the >>>> implementation is free to handle a cleanup or wait for return >>>> routine in a OO >>>> way. The I/O streams should just lock. >>>> >>>> The word static was not ment as persistent but as Java static >>>> available. >>>> Considder the following: >>>> >>>> java.lang.hw.HardwareConfiguration { >>>> public enum PortType { RS232, I2C, etc. }; >>>> >>>> /** Gets the currently available ports of type {@code PortType}. */ >>>> public static java.lang.hw.Port[] getPorts(PortType); >>>> } >>>> >>>> com.example.Driver implements PortUser, implements >>>> PortStillAvailableListener >>>> { >>>> public portNoLongerAvailable(PortEvent event) { >>>> // cleanup & dismiss. >>>> } >>>> } >>>> >>>> com.example.Application { >>>> public static void main(String[] args) { >>>> Driver someDriver = new Driver(); >>>> Port radomPort = HardwareConfiguration.getPorts( >>>> HardwareConfiguration.PortType.RS232)[1]; >>>> myDevice.addStillAvailableListener(someDriver); >>>> myDevice.connect(someDriver); >>>> } >>>> } >>>> >>>>> Please do not forget that tty ports can be opened by several >>>>> applications concurrently. All of those will "loose" the port if >>>>> anyone opens the corresponding cu port. >>>> Indeed we need a good overview of the differences between the various >>>> platforms. Should we create a document or a Wiki for this purpose? >>>> >>>> FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: >>>> http://www.openbsd.org/cgi-bin/man.cgi? >>>> query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD >>>> +Current&arch=i386&format=html >>>> >>>> Linux uses /var/lock: >>>> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES >>>> >>>> Is there absolutely no way to get a lock under Windows? >>>> >>>>> As this naming based >>>>> mechanism does not exist on Windows (maybe it does via an API) it >>>>> should probably be reflected in the API. In other words there are >>>>> "two levels of open": >>>>> >>>>> - Open for reading status lines (1) >>>>> - Open for reading/writing data (2) >>>>> >>>>> I am not sure if state (1) should also allow the modification of >>>>> certain status lines (ie to set a modem ready). >>>> I'm not sure I understand. Do you mean canonical and noncanonical >>>> mode? >>>> >>>> How far is Windows with the canonical mode. Is it comparable to POSIX? >>>> >>>>> I am also not sure if >>>>> the api should unify corresponding cu. and tty. ports into one single >>>>> port. >>>> I think the API should hide low-level details like devicefiles. >>>> >>>> >>>> Who is participating anyway? Is it just the four of us? >>>> >>>> Cheers, >>>> >>>> Pascal >>>> >>>> >>>>> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>>>>> For instance the current API is not very object oriented. >>>>>> It might be a good idea to have a static set of objects available >>>>>> representing >>>>>> every supported port available on the system in realtime. Each >>>>>> object should >>>>>> clearly know its own state and its capabilities. To get a port >>>>>> there could be >>>>>> a method like synchronized void connect(PortUser) where PortUser >>>>>> is a >>>>>> interface which handles the interaction with a input and a output >>>>>> stream and >>>>>> listers like PortStillAvailableListener, PortBufferListener and a >>>>>> DataAvailableListener. >>>>>> >>>>>> What is the collective feeling about that? >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Wed Jul 19 18:03:40 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 18:03:40 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEC0D8.4050806@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> Message-ID: <44BEC85C.2030809@ergotech.com> Paul Klissner wrote: > I'd just like to find another suitable name than javax.comm, unless > the JSR wants to start with javax.comm 4.0, since all the previous > 'major revisions' are accounted for. javax.serialport? Which perhaps brings us back to what are we trying to fix and how badly. There are a number of 3rd party implementation of Java Comm, at least one from IBM - part of what was J9, now Websphere, or something (presumbly soon to get a name that has eclipse in it sometime soon). Esmertec has one, and there are few others rolling around. If RXTX is the only implementation of the JSR with no backward compatibility, we've just forked Java Serial support and we (for a least one) will be worse off. We won't be able to use the new support because of a lack of support on J2ME platforms that we have no control over and RXTX/current JavaComm will be in maintenance mode or unsupported on all other platforms. So, is there any chance of building a compatibility requirement into this. To pick are really bad example JDBC has support for a DataSource or a Driver. Could we have an ExcellentSerialPort with a fallback to a SerialPort on a class not found exception? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From pascal at quies.net Wed Jul 19 18:22:45 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Thu, 20 Jul 2006 02:22:45 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEC85C.2030809@ergotech.com> References: <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> Message-ID: <200607200222.46023.pascal@quies.net> Op donderdag 20 juli 2006 02:03, schreef Jim Redman: > Which perhaps brings us back to what are we trying to fix and how badly. The initail problem was the license. :) RXTX is sitting in this gnu.comm namespace and is afraid to go to javax.comm. Getting a JSR would solve this problem. And while we're at it we might as well improve the situation with the various platforms. I made some sugestions that where denied as too complex. Cheers, Pascal From Paul.Klissner at Sun.COM Wed Jul 19 19:09:35 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 18:09:35 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607200222.46023.pascal@quies.net> References: <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <200607200222.46023.pascal@quies.net> Message-ID: <44BED7CF.5080405@sun.com> Pascal S. de Kloe wrote: > Op donderdag 20 juli 2006 02:03, schreef Jim Redman: >> Which perhaps brings us back to what are we trying to fix and how badly. > > The initail problem was the license. :) > > RXTX is sitting in this gnu.comm namespace and is afraid to go to javax.comm. > Getting a JSR would solve this problem. > > And while we're at it we might as well improve the situation with the various > platforms. I made some sugestions that where denied as too complex. "Denied" is a bit harsh :) I'll re-examine your e-mails to see if my preferences change. It's not like your proposition has been put up to a formal vote, just discussion. Paul From Paul.Klissner at Sun.COM Wed Jul 19 19:28:47 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 18:28:47 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEC85C.2030809@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> Message-ID: <44BEDC4F.9030403@sun.com> Jim Redman wrote: > Paul Klissner wrote: >> I'd just like to find another suitable name than javax.comm, unless >> the JSR wants to start with javax.comm 4.0, since all the previous >> 'major revisions' are accounted for. javax.serialport? > > Which perhaps brings us back to what are we trying to fix and how badly. The goals I'm most interested in at the moment are: 1. A pluggable platform portmapping scheme wherein each platform can determine which ports to present to the application, and preferably as some configurable logical name. For example on the Sun Ray thin client platform, if an application aquiring a view of serial ports available on the system, it will be informed of Sun Ray serial ports if the application is running in a session currently directed to that particular Sun Ray unit, even though the serial port's device node happens to be server-side deeply nested in a leaf node. If the application is not running on a Sun Ray the port doesn't show up. The Sun Ray plugin would make the decision about when and which ports to present to the application. 2. Pluggable driver-side interface where multiple platform-specific drivers can be utilized simultaneously to introduce more flexibility with the back end. > There are a number of 3rd party implementation of Java Comm, at least > one from IBM - part of what was J9, now Websphere, or something > (presumbly soon to get a name that has eclipse in it sometime soon). > Esmertec has one, and there are few others rolling around. I have not been advocating gutting the API, since much of it is perfectly adequate. I'm not totally opposed to making substantial changes or improvements depending on other people's needs. There's no reason previous versions of javax.comm need to suddenly disappear if products need legacy support. > > If RXTX is the only implementation of the JSR with no backward > compatibility, we've just forked Java Serial support and we (for a least > one) will be worse off. We won't be able to use the new support because > of a lack of support on J2ME platforms that we have no control over and > RXTX/current JavaComm will be in maintenance mode or unsupported on all > other platforms. There can't be *that* many platforms this is ported to. And it will be no javax.usb. Seems like most of the standard platforms will be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, JDBC... > > So, is there any chance of building a compatibility requirement into > this. To pick are really bad example JDBC has support for a DataSource > or a Driver. Could we have an ExcellentSerialPort with a fallback to a > SerialPort on a class not found exception? Maybe, or maybe we just let people know what we are doing and try to figure out how to get their applications ported. Might not be that difficult. From my standpoint anyway, earthshaking changes aren't really necessary. Others might disagree. Paul From rwelty at averillpark.net Wed Jul 19 19:35:54 2006 From: rwelty at averillpark.net (Richard P. Welty) Date: Wed, 19 Jul 2006 21:35:54 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter Message-ID: <44BEDDFA.7020108@averillpark.net> I'm returning to the use of rxtx after 2 years off doing things that don't need serial ports. I'm trying to get my laptop (fedora core 1) talking to a set of portable auto scales through a Keyspan USB adapter (in my past use of rxtx, I had actual serial ports, but those days are long gone.) I have the keyspan kernel module loaded, and lsusb shows the device as correctly identified. I'm missing the bit of magic needed to get rxtx to provide the port in response to CommPortIdentifier.getPortIdentifiers() thanks in advance for any help, richard From jredman at ergotech.com Wed Jul 19 19:43:25 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 19:43:25 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BED7CF.5080405@sun.com> References: <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <200607200222.46023.pascal@quies.net> <44BED7CF.5080405@sun.com> Message-ID: <44BEDFBD.4020404@ergotech.com> Paul Klissner wrote: > Pascal S. de Kloe wrote: >> Op donderdag 20 juli 2006 02:03, schreef Jim Redman: >>> Which perhaps brings us back to what are we trying to fix and how badly. >> The initail problem was the license. :) >> >> RXTX is sitting in this gnu.comm namespace and is afraid to go to javax.comm. >> Getting a JSR would solve this problem. >> >> And while we're at it we might as well improve the situation with the various >> platforms. I made some sugestions that where denied as too complex. > > "Denied" is a bit harsh :) I'll re-examine your e-mails > to see if my preferences change. It's not like your > proposition has been put up to a formal vote, just discussion. OK, I'll officially float backwards compatibility in the form of "It should be possible to use anything that comes out of the JSR in place of an existing java comm implementation". I wonder if "Denied" is too harsh for that one :) Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From ajmas at sympatico.ca Wed Jul 19 19:47:06 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Wed, 19 Jul 2006 21:47:06 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEDDFA.7020108@averillpark.net> References: <44BEDDFA.7020108@averillpark.net> Message-ID: <35101C10-59A5-4F02-AEEE-DB69112F8130@sympatico.ca> Do you see an associated device in /dev ? On 19-Jul-06, at 21:35 , Richard P. Welty wrote: > I'm returning to the use of rxtx after 2 years off doing > things that don't need serial ports. > > I'm trying to get my laptop (fedora core 1) talking to a > set of portable auto scales through a Keyspan USB adapter > (in my past use of rxtx, I had actual serial ports, but those > days are long gone.) I have the keyspan kernel module loaded, > and lsusb shows the device as correctly identified. I'm missing > the bit of magic needed to get rxtx to provide the port > in response to CommPortIdentifier.getPortIdentifiers() > > thanks in advance for any help, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Wed Jul 19 19:54:03 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 19:54:03 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEDC4F.9030403@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> Message-ID: <44BEE23B.30908@ergotech.com> Paul, For the record we're STILL supporting some PersonalJava platforms. We're _almost_ at the point where we can assume that the platforms will have a Collections framework, but routinely compile with a 1.1 check so that we don't make that assumption unnecessarily. Of 50+ non-graphical Factory Automation JavaBeans we have 2 that require Java2 (Reporting and JavaScripting), and we have people asking for a back-port. Embedded platforms don't change in a hurry. Unlike desktop platforms, embedded systems are expected to last 5-10+ years. There are factory automation vendors in the pharmaceutical industry who are buying systems on eBay because that's the FDA validate platform. It must be that make/model, spec'd sometime in the mid-90's. So... If you make an incompatible change TODAY figure we can start using that code _at the earliest_ somewhere around 2012 or the low teens. Are we _really_ the only people on the list supporting embedded/factory automation platforms? Jim Paul Klissner wrote: > Jim Redman wrote: >> Paul Klissner wrote: >>> I'd just like to find another suitable name than javax.comm, unless >>> the JSR wants to start with javax.comm 4.0, since all the previous >>> 'major revisions' are accounted for. javax.serialport? >> Which perhaps brings us back to what are we trying to fix and how badly. > The goals I'm most interested in at the moment are: > > 1. A pluggable platform portmapping scheme wherein each platform > can determine which ports to present to the application, and > preferably as some configurable logical name. > > For example on the Sun Ray thin client platform, if an application > aquiring a view of serial ports available on the system, it will > be informed of Sun Ray serial ports if the application is running > in a session currently directed to that particular Sun Ray unit, > even though the serial port's device node happens to be server-side > deeply nested in a leaf node. If the application is not running on > a Sun Ray the port doesn't show up. The Sun Ray plugin would make > the decision about when and which ports to present to the application. > > 2. Pluggable driver-side interface where multiple platform-specific > drivers can be utilized simultaneously to introduce more flexibility > with the back end. > >> There are a number of 3rd party implementation of Java Comm, at least >> one from IBM - part of what was J9, now Websphere, or something >> (presumbly soon to get a name that has eclipse in it sometime soon). >> Esmertec has one, and there are few others rolling around. > > I have not been advocating gutting the API, since much of it is > perfectly adequate. I'm not totally opposed to making substantial > changes or improvements depending on other people's needs. There's > no reason previous versions of javax.comm need to suddenly disappear > if products need legacy support. > > >> If RXTX is the only implementation of the JSR with no backward >> compatibility, we've just forked Java Serial support and we (for a least >> one) will be worse off. We won't be able to use the new support because >> of a lack of support on J2ME platforms that we have no control over and >> RXTX/current JavaComm will be in maintenance mode or unsupported on all >> other platforms. > > There can't be *that* many platforms this is ported to. And it will > be no javax.usb. Seems like most of the standard platforms will > be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, > JDBC... > >> So, is there any chance of building a compatibility requirement into >> this. To pick are really bad example JDBC has support for a DataSource >> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >> SerialPort on a class not found exception? > > Maybe, or maybe we just let people know what we are doing and > try to figure out how to get their applications ported. Might not > be that difficult. From my standpoint anyway, earthshaking > changes aren't really necessary. Others might disagree. > > Paul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tod at todbot.com Wed Jul 19 19:59:52 2006 From: tod at todbot.com (Tod E. Kurt) Date: Wed, 19 Jul 2006 18:59:52 -0700 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEDDFA.7020108@averillpark.net> References: <44BEDDFA.7020108@averillpark.net> Message-ID: Hi, "lsusb" doesn't show if you have the proper drivers loaded for the specific USB device, just that a USB device is plugged in. The text identifiers sent by the USB device aren't used by the OS except for things like lsusb. Look at the output of "dmesg" or /var/log/messages and see if you have a lines that looks like: keyspan 1-1:1.0: Keyspan 1 port adapter converter detected usb 1-1: Keyspan 1 port adapter converter now attached to ttyUSB0 If you do, then you've got a serial port at "/dev/ttyUSB0", and you can use minicom or whatever (even RXTX!) to play with it. If you get a message like: usb.c: USB device 4 (vend/prod 0x06cd/0x0121) is not claimed by any active driver. Then the USB driver can't find the 'keyspan' driver. If you're sure you have this driver, then hotplug isn't working for some reason. You could try running the command: % sudo modprobe keyspan And see if anything useful happens. You should see the 'keyspan' driver when you type "lsmod" to list the currently loaded kernel modules. -=tod On Jul 19, 2006, at 6:35 PM, Richard P. Welty wrote: > I'm returning to the use of rxtx after 2 years off doing > things that don't need serial ports. > > I'm trying to get my laptop (fedora core 1) talking to a > set of portable auto scales through a Keyspan USB adapter > (in my past use of rxtx, I had actual serial ports, but those > days are long gone.) I have the keyspan kernel module loaded, > and lsusb shows the device as correctly identified. I'm missing > the bit of magic needed to get rxtx to provide the port > in response to CommPortIdentifier.getPortIdentifiers() > > thanks in advance for any help, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From rwelty at suespammers.org Wed Jul 19 20:05:18 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Wed, 19 Jul 2006 22:05:18 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <35101C10-59A5-4F02-AEEE-DB69112F8130@sympatico.ca> References: <44BEDDFA.7020108@averillpark.net> <35101C10-59A5-4F02-AEEE-DB69112F8130@sympatico.ca> Message-ID: <44BEE4DE.9080707@suespammers.org> Andr?-John Mas wrote: > Do you see an associated device in /dev ? Well, there are lots of /dev/ttyUSB devices, there, but nothing jumps out as having been assigned to the keyspan. But then, I'm not that knowledgable about the USB mapping here; this is the first time I've tried to use one this way and I'm on the steep part of the learning curve. richard From rwelty at suespammers.org Wed Jul 19 20:08:20 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Wed, 19 Jul 2006 22:08:20 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: References: <44BEDDFA.7020108@averillpark.net> Message-ID: <44BEE594.50402@suespammers.org> Tod E. Kurt wrote: > Then the USB driver can't find the 'keyspan' driver. If you're sure > you have this driver, then hotplug isn't working for some reason. > You could try running the command: Ok, it looks like the keyspan driver may be the problem; it's having some sort of problem loading it. I'll have to look into this further tomorrow night. thanks, richard From pascal at quies.net Wed Jul 19 20:11:21 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Thu, 20 Jul 2006 04:11:21 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEDFBD.4020404@ergotech.com> References: <44BED7CF.5080405@sun.com> <44BEDFBD.4020404@ergotech.com> Message-ID: <200607200411.22012.pascal@quies.net> Op donderdag 20 juli 2006 03:43, schreef Jim Redman: > Paul Klissner wrote: > > Pascal S. de Kloe wrote: > >> Op donderdag 20 juli 2006 02:03, schreef Jim Redman: > >>> Which perhaps brings us back to what are we trying to fix and how > >>> badly. > >> > >> The initail problem was the license. :) > >> > >> RXTX is sitting in this gnu.comm namespace and is afraid to go to > >> javax.comm. Getting a JSR would solve this problem. > >> > >> And while we're at it we might as well improve the situation with the > >> various platforms. I made some sugestions that where denied as too > >> complex. > > > > "Denied" is a bit harsh :) I'll re-examine your e-mails > > to see if my preferences change. It's not like your > > proposition has been put up to a formal vote, just discussion. > > OK, I'll officially float backwards compatibility in the form of "It > should be possible to use anything that comes out of the JSR in place of > an existing java comm implementation". > > I wonder if "Denied" is too harsh for that one :) > > Jim Hehehe. I don't have any troubles with people voting against my ideas at all so don't worry Paul. :) However, it is exactly the compatibilty thing where Jim is talking about what makes me want to make a *huge* change if any. From jredman at ergotech.com Wed Jul 19 20:25:50 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 20:25:50 -0600 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEE594.50402@suespammers.org> References: <44BEDDFA.7020108@averillpark.net> <44BEE594.50402@suespammers.org> Message-ID: <44BEE9AE.3030200@ergotech.com> Some who remembers this better than me please help. You also need something like: -Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3 When you start the application. This can be put in a properties files (where?). Jim Richard P. Welty wrote: > Tod E. Kurt wrote: > >> Then the USB driver can't find the 'keyspan' driver. If you're sure >> you have this driver, then hotplug isn't working for some reason. >> You could try running the command: > > Ok, it looks like the keyspan driver may be the problem; it's having > some sort of problem loading it. I'll have to look into this further > tomorrow night. > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From ajmas at sympatico.ca Wed Jul 19 20:32:52 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Wed, 19 Jul 2006 22:32:52 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEE9AE.3030200@ergotech.com> References: <44BEDDFA.7020108@averillpark.net> <44BEE594.50402@suespammers.org> <44BEE9AE.3030200@ergotech.com> Message-ID: Are you sure about this? I know on MacOS X no such configuration was needed. If this is indeed true, this is poor design, in this day and age of dynamic devices. On 19-Jul-06, at 22:25 , Jim Redman wrote: > Some who remembers this better than me please help. > > You also need something like: > > -Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyUSB0:/dev/ttyUSB1:/ > dev/ttyUSB2:/dev/ttyUSB3 > > When you start the application. This can be put in a properties files > (where?). > > Jim > > Richard P. Welty wrote: >> Tod E. Kurt wrote: >> >>> Then the USB driver can't find the 'keyspan' driver. If you're sure >>> you have this driver, then hotplug isn't working for some reason. >>> You could try running the command: >> >> Ok, it looks like the keyspan driver may be the problem; it's having >> some sort of problem loading it. I'll have to look into this further >> tomorrow night. >> >> thanks, >> richard >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Wed Jul 19 20:41:01 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Wed, 19 Jul 2006 22:41:01 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEE9AE.3030200@ergotech.com> References: <44BEDDFA.7020108@averillpark.net> <44BEE594.50402@suespammers.org> <44BEE9AE.3030200@ergotech.com> Message-ID: <44BEED3D.5020304@suespammers.org> Jim Redman wrote: > Some who remembers this better than me please help. > > You also need something like: > > -Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3 > > When you start the application. This can be put in a properties files > (where?). Thanks for all the help, guys. Thinking back on how this laptop came to be in its current state, I'm of the opinion a format and complete rebuild with a newer version of Fedora is in order before I waste any more time in diagnosis. The problems I'm seeing clearly have nothing to do with RXTX and everything to do with how many upgrades have been chained together getting this laptop from whereever I started (RH 7.0 or 7.1) to FC1. It could probably be fixed in place, but I shudder to think about the amount of time needed to figure out the proper fix. But the software I'm putting together will need to run on Y2K/XP and Mac OS X, so I'll be following portability and installer discussions on this list rather intently (http://scale-app.sourceforge.net for anyone who cares.) richard From Paul.Klissner at Sun.COM Wed Jul 19 22:53:53 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 21:53:53 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEE23B.30908@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> Message-ID: <44BF0C61.4020900@sun.com> Jim Redman wrote: > Paul, > > For the record we're STILL supporting some PersonalJava platforms. > We're _almost_ at the point where we can assume that the platforms will > have a Collections framework, but routinely compile with a 1.1 check so > that we don't make that assumption unnecessarily. Of 50+ non-graphical > Factory Automation JavaBeans we have 2 that require Java2 (Reporting and > JavaScripting), and we have people asking for a back-port. > > Embedded platforms don't change in a hurry. Unlike desktop platforms, > embedded systems are expected to last 5-10+ years. > > There are factory automation vendors in the pharmaceutical industry who > are buying systems on eBay because that's the FDA validate platform. It > must be that make/model, spec'd sometime in the mid-90's. > > So... If you make an incompatible change TODAY figure we can start using > that code _at the earliest_ somewhere around 2012 or the low teens. > > Are we _really_ the only people on the list supporting embedded/factory > automation platforms? > > Jim Do you provide your own implementation classes? Why can't you just continue to use 2.1 for the embedded platform until 2012 if you're locked down? Are you worried bugs won't get fixed? Sun might consider open sourcing the 2.1 Java source. I can't promise that, but it's been discussed and hasn't met resistance, except from me, because I wasn't super impressed with the code. I can probably be persuaded to champion open sourcing that and going through the process/legal machinations within Sun if it frees us to pursue a JSR for a new generation of javax.comm where we can have a chunk of common code in Open Source and each platform is simply responsible for it's platform specific plugins. I don't have many opinions about this set in stone because there are a lot of technical and pragmatic considerations such as yours the community has that I am probably not aware of or sufficiently sensitive to yet. I don't feel I really have the bird's eye view of all of this yet. The other thing is, I can only offer 10% of my time right now, according to my management, which is why I'm not pushing to be the spec lead for the JSR, and want only to be a participant to represent Sun's interests on the E.G. There is nothing sacred about Sun employees in the JCP as far as a JSR initiated by another entity is concerned. I am not the person everything needs to be cleared through. Ideas I have will pass or fail based on their merit and the community perception just like anyone else's. Paul > > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul Klissner wrote: >>>> I'd just like to find another suitable name than javax.comm, unless >>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>> 'major revisions' are accounted for. javax.serialport? >>> Which perhaps brings us back to what are we trying to fix and how badly. >> The goals I'm most interested in at the moment are: >> >> 1. A pluggable platform portmapping scheme wherein each platform >> can determine which ports to present to the application, and >> preferably as some configurable logical name. >> >> For example on the Sun Ray thin client platform, if an application >> aquiring a view of serial ports available on the system, it will >> be informed of Sun Ray serial ports if the application is running >> in a session currently directed to that particular Sun Ray unit, >> even though the serial port's device node happens to be server-side >> deeply nested in a leaf node. If the application is not running on >> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >> the decision about when and which ports to present to the application. >> >> 2. Pluggable driver-side interface where multiple platform-specific >> drivers can be utilized simultaneously to introduce more flexibility >> with the back end. >> >>> There are a number of 3rd party implementation of Java Comm, at least >>> one from IBM - part of what was J9, now Websphere, or something >>> (presumbly soon to get a name that has eclipse in it sometime soon). >>> Esmertec has one, and there are few others rolling around. >> I have not been advocating gutting the API, since much of it is >> perfectly adequate. I'm not totally opposed to making substantial >> changes or improvements depending on other people's needs. There's >> no reason previous versions of javax.comm need to suddenly disappear >> if products need legacy support. >> >> >>> If RXTX is the only implementation of the JSR with no backward >>> compatibility, we've just forked Java Serial support and we (for a least >>> one) will be worse off. We won't be able to use the new support because >>> of a lack of support on J2ME platforms that we have no control over and >>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>> other platforms. >> There can't be *that* many platforms this is ported to. And it will >> be no javax.usb. Seems like most of the standard platforms will >> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >> JDBC... >> >>> So, is there any chance of building a compatibility requirement into >>> this. To pick are really bad example JDBC has support for a DataSource >>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>> SerialPort on a class not found exception? >> Maybe, or maybe we just let people know what we are doing and >> try to figure out how to get their applications ported. Might not >> be that difficult. From my standpoint anyway, earthshaking >> changes aren't really necessary. Others might disagree. >> >> Paul >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From Paul.Klissner at Sun.COM Thu Jul 20 00:27:41 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 23:27:41 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BF0C61.4020900@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> Message-ID: <44BF225D.80104@sun.com> Paul Klissner wrote: > Jim Redman wrote: >> Paul, >> >> For the record we're STILL supporting some PersonalJava platforms. >> We're _almost_ at the point where we can assume that the platforms will >> have a Collections framework, but routinely compile with a 1.1 check so >> that we don't make that assumption unnecessarily. Of 50+ non-graphical >> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >> JavaScripting), and we have people asking for a back-port. >> >> Embedded platforms don't change in a hurry. Unlike desktop platforms, >> embedded systems are expected to last 5-10+ years. >> >> There are factory automation vendors in the pharmaceutical industry who >> are buying systems on eBay because that's the FDA validate platform. It >> must be that make/model, spec'd sometime in the mid-90's. >> >> So... If you make an incompatible change TODAY figure we can start using >> that code _at the earliest_ somewhere around 2012 or the low teens. >> >> Are we _really_ the only people on the list supporting embedded/factory >> automation platforms? >> >> Jim > > Do you provide your own implementation classes? > > Why can't you just continue to use 2.1 for the embedded platform until > 2012 if you're locked down? Are you worried bugs won't get fixed? > Sun might consider open sourcing the 2.1 Java source. Excuse me, I meant 2.0.3 > I can't promise > that, but it's been discussed and hasn't met resistance, except > from me, because I wasn't super impressed with the code. I can probably > be persuaded to champion open sourcing that and going through the > process/legal machinations within Sun if it frees us to pursue > a JSR for a new generation of javax.comm where we can have a chunk of > common code in Open Source and each platform is simply responsible > for it's platform specific plugins. > > I don't have many opinions about this set in stone because there > are a lot of technical and pragmatic considerations such as yours > the community has that I am probably not aware of or sufficiently > sensitive to yet. I don't feel I really have the bird's eye view > of all of this yet. > > The other thing is, I can only offer 10% of my time right now, > according to my management, which is why I'm not pushing to > be the spec lead for the JSR, and want only to be a participant > to represent Sun's interests on the E.G. There is nothing sacred > about Sun employees in the JCP as far as a JSR initiated by another > entity is concerned. I am not the person everything needs to be > cleared through. Ideas I have will pass or fail based on their > merit and the community perception just like anyone else's. > > Paul > >> Paul Klissner wrote: >>> Jim Redman wrote: >>>> Paul Klissner wrote: >>>>> I'd just like to find another suitable name than javax.comm, unless >>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>> 'major revisions' are accounted for. javax.serialport? >>>> Which perhaps brings us back to what are we trying to fix and how badly. >>> The goals I'm most interested in at the moment are: >>> >>> 1. A pluggable platform portmapping scheme wherein each platform >>> can determine which ports to present to the application, and >>> preferably as some configurable logical name. >>> >>> For example on the Sun Ray thin client platform, if an application >>> aquiring a view of serial ports available on the system, it will >>> be informed of Sun Ray serial ports if the application is running >>> in a session currently directed to that particular Sun Ray unit, >>> even though the serial port's device node happens to be server-side >>> deeply nested in a leaf node. If the application is not running on >>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>> the decision about when and which ports to present to the application. >>> >>> 2. Pluggable driver-side interface where multiple platform-specific >>> drivers can be utilized simultaneously to introduce more flexibility >>> with the back end. >>> >>>> There are a number of 3rd party implementation of Java Comm, at least >>>> one from IBM - part of what was J9, now Websphere, or something >>>> (presumbly soon to get a name that has eclipse in it sometime soon). >>>> Esmertec has one, and there are few others rolling around. >>> I have not been advocating gutting the API, since much of it is >>> perfectly adequate. I'm not totally opposed to making substantial >>> changes or improvements depending on other people's needs. There's >>> no reason previous versions of javax.comm need to suddenly disappear >>> if products need legacy support. >>> >>> >>>> If RXTX is the only implementation of the JSR with no backward >>>> compatibility, we've just forked Java Serial support and we (for a least >>>> one) will be worse off. We won't be able to use the new support because >>>> of a lack of support on J2ME platforms that we have no control over and >>>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>>> other platforms. >>> There can't be *that* many platforms this is ported to. And it will >>> be no javax.usb. Seems like most of the standard platforms will >>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>> JDBC... >>> >>>> So, is there any chance of building a compatibility requirement into >>>> this. To pick are really bad example JDBC has support for a DataSource >>>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>>> SerialPort on a class not found exception? >>> Maybe, or maybe we just let people know what we are doing and >>> try to figure out how to get their applications ported. Might not >>> be that difficult. From my standpoint anyway, earthshaking >>> changes aren't really necessary. Others might disagree. >>> >>> Paul >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Thu Jul 20 00:50:21 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 20 Jul 2006 08:50:21 +0200 Subject: [Rxtx] jcp and jsr Message-ID: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> Hi all, I work with SNIJDER Micro Systems. We're doing embedded Java and just heard about this discussion by way of Ted Kosan from the embedded Java community. We think Jim is right about the compatibility issues for embedded Java platforms. Our own embedded Java platform (see http://www.embedded-web.com ) uses a 3rd party implementation of javax.comm written by the JVM vendor. As Jim says, changes take much longer to propagate in the embedded space. If the 'new' javax.comm is not backwards compatible, embedded JVM vendors (esmertec, IBM, Tao Group, etc.) will probably evaluate whether it makes sense for them to support the new API. Some will eventually adopt it, but that will take time. Some will just stay with the current API, thus increasing the gap between embedded Java developers and desktop Java developers (different APIs to do the same thing) This is a very real problem in our opinion. Also taking into account that many desktop computers nowadays don't even have standard serial ports, I believe that the embedded Java community already gathers a significant share of the potential javax.comm users. I think backwards compatibility should be seriously considered. Best regards, Guillermo Jim Redman wrote: >Paul Klissner wrote: > > I'd just like to find another suitable name than javax.comm, unless > > the JSR wants to start with javax.comm 4.0, since all the previous > > 'major revisions' are accounted for. javax.serialport? > >Which perhaps brings us back to what are we trying to fix and how badly. > >There are a number of 3rd party implementation of Java Comm, at least >one from IBM - part of what was J9, now Websphere, or something >(presumbly soon to get a name that has eclipse in it sometime soon). >Esmertec has one, and there are few others rolling around. > >If RXTX is the only implementation of the JSR with no backward >compatibility, we've just forked Java Serial support and we (for a least >one) will be worse off. We won't be able to use the new support because >of a lack of support on J2ME platforms that we have no control over and >RXTX/current JavaComm will be in maintenance mode or unsupported on all >other platforms. > >So, is there any chance of building a compatibility requirement into >this. To pick are really bad example JDBC has support for a DataSource >or a Driver. Could we have an ExcellentSerialPort with a fallback to a >SerialPort on a class not found exception? > >Jim -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Thu Jul 20 00:57:04 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 20 Jul 2006 08:57:04 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> References: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> Message-ID: <7.0.1.0.0.20060720085221.036d88e8@sms.nl> Paul Klissner wrote: >Jim Redman wrote: > > Paul, > > > > For the record we're STILL supporting some PersonalJava platforms. > > We're _almost_ at the point where we can assume that the platforms will > > have a Collections framework, but routinely compile with a 1.1 check so > > that we don't make that assumption unnecessarily. Of 50+ non-graphical > > Factory Automation JavaBeans we have 2 that require Java2 (Reporting and > > JavaScripting), and we have people asking for a back-port. > > > > Embedded platforms don't change in a hurry. Unlike desktop platforms, > > embedded systems are expected to last 5-10+ years. > > > > There are factory automation vendors in the pharmaceutical industry who > > are buying systems on eBay because that's the FDA validate platform. It > > must be that make/model, spec'd sometime in the mid-90's. > > > > So... If you make an incompatible change TODAY figure we can start using > > that code _at the earliest_ somewhere around 2012 or the low teens. > > > > Are we _really_ the only people on the list supporting embedded/factory > > automation platforms? > > > > Jim > >Do you provide your own implementation classes? > >Why can't you just continue to use 2.1 for the embedded platform until >2012 if you're locked down? Are you worried bugs won't get fixed? If embedded platforms keep using the "old" (current) javax.comm API but the desktop Java world starts to use a new, backwards-incompatible API, then this will result in more trouble for embedded Java application developers as they will no longer be able to use the same API on desktop systems and embedded platforms. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Thu Jul 20 00:59:16 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 20 Jul 2006 08:59:16 +0200 Subject: [Rxtx] jcp and jsr Message-ID: <7.0.1.0.0.20060720085812.036d9c28@sms.nl> Pascal S. de Kloe wrote: >Who is participating anyway? Is it just the four of us? > >Cheers, > >Pascal We would be more than happy to participate if we can be of any help. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From Paul.Klissner at Sun.COM Thu Jul 20 02:23:42 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Thu, 20 Jul 2006 01:23:42 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <7.0.1.0.0.20060720085221.036d88e8@sms.nl> References: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> <7.0.1.0.0.20060720085221.036d88e8@sms.nl> Message-ID: <44BF3D8E.4030705@sun.com> Guillermo Rodriguez Garcia wrote: > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul, >>> >>> For the record we're STILL supporting some PersonalJava platforms. >>> We're _almost_ at the point where we can assume that the platforms will >>> have a Collections framework, but routinely compile with a 1.1 check so >>> that we don't make that assumption unnecessarily. Of 50+ non-graphical >>> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >>> JavaScripting), and we have people asking for a back-port. >>> >>> Embedded platforms don't change in a hurry. Unlike desktop platforms, >>> embedded systems are expected to last 5-10+ years. >>> >>> There are factory automation vendors in the pharmaceutical industry who >>> are buying systems on eBay because that's the FDA validate platform. It >>> must be that make/model, spec'd sometime in the mid-90's. >>> >>> So... If you make an incompatible change TODAY figure we can start using >>> that code _at the earliest_ somewhere around 2012 or the low teens. >>> >>> Are we _really_ the only people on the list supporting embedded/factory >>> automation platforms? >>> >>> Jim >> Do you provide your own implementation classes? >> >> Why can't you just continue to use 2.1 for the embedded platform until >> 2012 if you're locked down? Are you worried bugs won't get fixed? > > If embedded platforms keep using the "old" (current) javax.comm API but > the desktop Java world starts to use a new, backwards-incompatible API, > then this will result in more trouble for embedded Java application > developers as they will no longer be able to use the same API on desktop > systems and embedded platforms. OK, I understand the situation more clearly now. The kinds of changes I'm opting don't seem difficult to design in a backward compatible way. I haven't scrutinized the other requests on the list. I guess it will be interesting to hear what the proponents for other changes have to say. Paul > > Guillermo > > -- > Guillermo Rodriguez Garcia > > Snijder Micro Systems phone +31-493-351020 > G. Rodriguez Garcia fax +31-493-351530 > Visser 25 email guille at sms.nl > NL5751 BL Deurne > The Netherlands http://www.snijder.com > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jul 20 02:46:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 20 Jul 2006 10:46:09 +0200 Subject: [Rxtx] quo vadis API/namespace (Re: jcp and jsr) In-Reply-To: <44BEDC4F.9030403@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> Message-ID: Paul, for the first time in many months, I have the impression, that we have the same agenda;-) If the "driver-level"-api changes however "nobody" will be disappointed. However, regarding the user-level-api I disagree. As fundamental changes to the API have been suggested several times I must be ignoring something. I would be delighted to learn were the current API fails - i.e. what can not be done or is overly complex based on the current API. Of course it is better fun to start something from scratch, but unless there are really substantial gains from completely redesigning an API I don't see the point. The promise of Java is to write once (which I interpret as write against the same API for all platforms). Getting VM providers like esmertec to support a new/replacement API is not a simple task, it requires a business case which for the biggest part simply does not exist. If we keep the javax.comm namespace and keep the "user-level"-api a superset of the current PortIdentifier/Port-api, the same application can work against javax.comm 2.0/3.0/future.x. Of course a factory/wrapping approach can always unify different APIs but this adds more implementation/ testing complexity to every application. So in short: Unless we find a strong argument why javax.comm can't be used I prefer that we keep it. Unless we find a strong feature / use- case that can not be handled with (an extension of) the current CommPort/CommPortIndentifier I'd prefer to keep that as well. Regards, Joachim On 20.07.2006, at 03:28, Paul Klissner wrote: > The goals I'm most interested in at the moment are: > > 1. A pluggable platform portmapping scheme wherein each platform > can determine which ports to present to the application, and > preferably as some configurable logical name. > > For example on the Sun Ray thin client platform, if an application > aquiring a view of serial ports available on the system, it will > be informed of Sun Ray serial ports if the application is running > in a session currently directed to that particular Sun Ray unit, > even though the serial port's device node happens to be server-side > deeply nested in a leaf node. If the application is not running on > a Sun Ray the port doesn't show up. The Sun Ray plugin would make > the decision about when and which ports to present to the application. > > 2. Pluggable driver-side interface where multiple platform-specific > drivers can be utilized simultaneously to introduce more flexibility > with the back end. > >> There are a number of 3rd party implementation of Java Comm, at least >> one from IBM - part of what was J9, now Websphere, or something >> (presumbly soon to get a name that has eclipse in it sometime soon). >> Esmertec has one, and there are few others rolling around. > > I have not been advocating gutting the API, since much of it is > perfectly adequate. I'm not totally opposed to making substantial > changes or improvements depending on other people's needs. There's > no reason previous versions of javax.comm need to suddenly disappear > if products need legacy support. > > >> >> If RXTX is the only implementation of the JSR with no backward >> compatibility, we've just forked Java Serial support and we (for a >> least >> one) will be worse off. We won't be able to use the new support >> because >> of a lack of support on J2ME platforms that we have no control >> over and >> RXTX/current JavaComm will be in maintenance mode or unsupported >> on all >> other platforms. > > There can't be *that* many platforms this is ported to. And it will > be no javax.usb. Seems like most of the standard platforms will > be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, > JDBC... > >> >> So, is there any chance of building a compatibility requirement into >> this. To pick are really bad example JDBC has support for a >> DataSource >> or a Driver. Could we have an ExcellentSerialPort with a fallback >> to a >> SerialPort on a class not found exception? > > Maybe, or maybe we just let people know what we are doing and > try to figure out how to get their applications ported. Might not > be that difficult. From my standpoint anyway, earthshaking > changes aren't really necessary. Others might disagree. > > Paul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Luis.Moreira at jet.uk Thu Jul 20 03:56:38 2006 From: Luis.Moreira at jet.uk (Luis Moreira) Date: Thu, 20 Jul 2006 10:56:38 +0100 Subject: [Rxtx] problems with setting up Rxtx Message-ID: Hi Guys, I have just joined the list and I am very new to JAVA. I am investigating serial communications and I just realised that the JAVAX.COMM package does not support windows anymore. I then looked at alternatives and the RXTX package came up. The problem I have at the moment is not using the classes but, rather how to install RXTX package so that I can use the classes, what do I need to install to support it and how if I write a program using it, do I make it portable. Best regards Luis From lyon at docjava.com Thu Jul 20 07:16:55 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 20 Jul 2006 09:16:55 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> Message-ID: Hi All, There has been some discussion about plugins for serial communications. As I see it, what Java really needs is a NativeLibraryManager. This is a rather much larger charge than "just" RXTX. The RXTX basic mode of operation is that we associate static blocks of code with a "System.load". Failure occurs when the class containing such a block of code is loaded AND the native library is not found. What are some of the options? 1. Do nothing, let the program fail with an exception. 2. try to catch an UnsatisfiedLinkError as a part of making the driver. 3. Search the java.library.path to see if the driver is present (i.e., guard the input). 4. Other?? In the case of either step 2 or 3, we need to fix the lack of a library. What are the options for fixing a library? 1. Do nothing, but give the user an interesting error with instructions on what to do. 2. Attempt to find the library on the file system (perhaps with user help). 3. Attempt to download the library and install it (perhaps with user permission). 4. Attempt to internalize the library as a UUEncoded serialized object and install it (better ask the user, again!). 5. Other?? My attempts at making RXTX more robust on install have led to mixed results. Altering the java.library.path has led to a bit of byte-code engineering (as this is loaded at JVM start time). Internalizing of libraries is attractive, until you realize how many libraries are involved. Dyanmically changing libraries during development is very attractive, for developers, who are changing libraries often. It is also very interesting for those who want to control the version of the libraries in the run-time. For example, something like the following will guard the input to the system load: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getInstance() { if (driver != null) return driver; if (!NativeLibDetect.isLibInPath("rxtxSerial")) fixDriver(); if (NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } At the other extreme, something like: try { System.load("rxtxSerial"); } catch (UnsatisfiedLinkError e) { System.out.println("could not load lib"); } Will at least attempt to handle the missing lib, in a simple way. Perhaps some error handling is better than none. To fix the driver, I can beam it down from a web page, using: private static void fixDriver() { File tmpDir = new File( SystemUtils.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); try { UrlUtils.getUrl(getResourceUrl(), tmpDir); String nativeLib = getNativeLibName(); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(nativeLib); if (b == null) { System.out.println("could not get:" + nativeLib); return; } File f = getRxtxHome(); Futil.writeBytes(getRxtxLibFile(), b); SystemUtils.appendJavaLibraryPath(f); } catch (IOException e) { e.printStackTrace(); } } Where the libraries are stored in the hacky dispatch: private static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isMacOs()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); System.out.println("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } Appending to the library path is tricky, at run-time: public static void appendJavaLibraryPath(File p) { if (p.isFile()) System.out.println("warning: appendJavaLibraryPath:" + "only directories are findable:"+p); System.out.println("appending:"+p+" to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:"+System.getProperty(javaLibraryPa th)); } The key is altering the core visibility of the sys_paths in the class loader: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } No, it isn't simple (nor even easy) but once the API is set we have a kind of NativeLibraryManager that helps us to make libraries, like RXTX more robust. As far as I know, there is nothing quite like it (unless you all know differently). Is there any interest in this? Forgive me if this is too far off the beaten path, but the inability to load a native library remains a source of fragility in the RXTX system, IMHO. Thanks for your thoughts! - Doug From jredman at ergotech.com Thu Jul 20 08:06:41 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 20 Jul 2006 08:06:41 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BF0C61.4020900@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> Message-ID: <44BF8DF1.4040101@ergotech.com> Paul, The issue with a new, incompatible implementation is, as you've identified below, is support for the old API. Open sourcing would be helpful, but then someone (us?) would have to maintain the source through changing versions of Window, and RXTX on Linux platforms. Or we'd have to have to versions of our codebase, which doesn't appeal too much. The maintenance issue is not impossible, but I think that in essence I'm agreeing with a comment you made earlier. IF a huge change is required, then lets get on with it. However, if the changes that are required are just extensions and enhancements, with some low-level re-engineering, then can we keep a compatible high-level API so that people needing the new features can use an extended API and those who need cross-platform compatibility can continue to use the existing features. Jim Paul Klissner wrote: > Jim Redman wrote: >> Paul, >> >> For the record we're STILL supporting some PersonalJava platforms. >> We're _almost_ at the point where we can assume that the platforms will >> have a Collections framework, but routinely compile with a 1.1 check so >> that we don't make that assumption unnecessarily. Of 50+ non-graphical >> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >> JavaScripting), and we have people asking for a back-port. >> >> Embedded platforms don't change in a hurry. Unlike desktop platforms, >> embedded systems are expected to last 5-10+ years. >> >> There are factory automation vendors in the pharmaceutical industry who >> are buying systems on eBay because that's the FDA validate platform. It >> must be that make/model, spec'd sometime in the mid-90's. >> >> So... If you make an incompatible change TODAY figure we can start using >> that code _at the earliest_ somewhere around 2012 or the low teens. >> >> Are we _really_ the only people on the list supporting embedded/factory >> automation platforms? >> >> Jim > > Do you provide your own implementation classes? > > Why can't you just continue to use 2.1 for the embedded platform until > 2012 if you're locked down? Are you worried bugs won't get fixed? > Sun might consider open sourcing the 2.1 Java source. I can't promise > that, but it's been discussed and hasn't met resistance, except > from me, because I wasn't super impressed with the code. I can probably > be persuaded to champion open sourcing that and going through the > process/legal machinations within Sun if it frees us to pursue > a JSR for a new generation of javax.comm where we can have a chunk of > common code in Open Source and each platform is simply responsible > for it's platform specific plugins. > > I don't have many opinions about this set in stone because there > are a lot of technical and pragmatic considerations such as yours > the community has that I am probably not aware of or sufficiently > sensitive to yet. I don't feel I really have the bird's eye view > of all of this yet. > > The other thing is, I can only offer 10% of my time right now, > according to my management, which is why I'm not pushing to > be the spec lead for the JSR, and want only to be a participant > to represent Sun's interests on the E.G. There is nothing sacred > about Sun employees in the JCP as far as a JSR initiated by another > entity is concerned. I am not the person everything needs to be > cleared through. Ideas I have will pass or fail based on their > merit and the community perception just like anyone else's. > > Paul > >> Paul Klissner wrote: >>> Jim Redman wrote: >>>> Paul Klissner wrote: >>>>> I'd just like to find another suitable name than javax.comm, unless >>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>> 'major revisions' are accounted for. javax.serialport? >>>> Which perhaps brings us back to what are we trying to fix and how badly. >>> The goals I'm most interested in at the moment are: >>> >>> 1. A pluggable platform portmapping scheme wherein each platform >>> can determine which ports to present to the application, and >>> preferably as some configurable logical name. >>> >>> For example on the Sun Ray thin client platform, if an application >>> aquiring a view of serial ports available on the system, it will >>> be informed of Sun Ray serial ports if the application is running >>> in a session currently directed to that particular Sun Ray unit, >>> even though the serial port's device node happens to be server-side >>> deeply nested in a leaf node. If the application is not running on >>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>> the decision about when and which ports to present to the application. >>> >>> 2. Pluggable driver-side interface where multiple platform-specific >>> drivers can be utilized simultaneously to introduce more flexibility >>> with the back end. >>> >>>> There are a number of 3rd party implementation of Java Comm, at least >>>> one from IBM - part of what was J9, now Websphere, or something >>>> (presumbly soon to get a name that has eclipse in it sometime soon). >>>> Esmertec has one, and there are few others rolling around. >>> I have not been advocating gutting the API, since much of it is >>> perfectly adequate. I'm not totally opposed to making substantial >>> changes or improvements depending on other people's needs. There's >>> no reason previous versions of javax.comm need to suddenly disappear >>> if products need legacy support. >>> >>> >>>> If RXTX is the only implementation of the JSR with no backward >>>> compatibility, we've just forked Java Serial support and we (for a least >>>> one) will be worse off. We won't be able to use the new support because >>>> of a lack of support on J2ME platforms that we have no control over and >>>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>>> other platforms. >>> There can't be *that* many platforms this is ported to. And it will >>> be no javax.usb. Seems like most of the standard platforms will >>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>> JDBC... >>> >>>> So, is there any chance of building a compatibility requirement into >>>> this. To pick are really bad example JDBC has support for a DataSource >>>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>>> SerialPort on a class not found exception? >>> Maybe, or maybe we just let people know what we are doing and >>> try to figure out how to get their applications ported. Might not >>> be that difficult. From my standpoint anyway, earthshaking >>> changes aren't really necessary. Others might disagree. >>> >>> Paul >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Paul.Klissner at Sun.COM Thu Jul 20 09:31:38 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Thu, 20 Jul 2006 08:31:38 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BF8DF1.4040101@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> <44BF8DF1.4040101@ergotech.com> Message-ID: <44BFA1DA.10301@sun.com> Jim Redman wrote: > Paul, > > The issue with a new, incompatible implementation is, as you've > identified below, is support for the old API. Open sourcing would be > helpful, but then someone (us?) would have to maintain the source > through changing versions of Window, and RXTX on Linux platforms. Or > we'd have to have to versions of our codebase, which doesn't appeal too > much. > > The maintenance issue is not impossible, but I think that in essence I'm > agreeing with a comment you made earlier. > > IF a huge change is required, then lets get on with it. However, if the > changes that are required are just extensions and enhancements, with > some low-level re-engineering, then can we keep a compatible high-level > API so that people needing the new features can use an extended API and > those who need cross-platform compatibility can continue to use the > existing features. > > Jim Guillermo made a crystal clear case and I understand the problem that that will be caused by forking the API in any sense of the word. I only want to uphold Sun's interests and resolve the problems we ran into with the RXTX community when Sun added portmapping to 3.0, which was not easily undone and was implemented as kind of a hack because it wasn't directly supported by the javax.comm architection. As I mentioned previously the changes I want to make have primarily to do with adding platform-specific portmapping via plugins, and supporting multiple javax.comm backend drivers on the same host (some ports would use one driver, others ports might use another). Also I'd like to address some bugfixes that were done in Sun's version 3.0 (including better error reporting, and more robust code for locating configuration files). Besides that, I'm not aware of any deficiences, but I've glanced other e-mails where people have suggested some. It would be good to get a summary of everyone's wishes. I've stated mine. I given much thought to what it would take to properly address EIA-422, EIA-423 and EIA-485 (if any); but those would probably be extensions. Sounds like the differences might be transparent to the API. I'll look into that more. Paul > > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul, >>> >>> For the record we're STILL supporting some PersonalJava platforms. >>> We're _almost_ at the point where we can assume that the platforms will >>> have a Collections framework, but routinely compile with a 1.1 check so >>> that we don't make that assumption unnecessarily. Of 50+ non-graphical >>> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >>> JavaScripting), and we have people asking for a back-port. >>> >>> Embedded platforms don't change in a hurry. Unlike desktop platforms, >>> embedded systems are expected to last 5-10+ years. >>> >>> There are factory automation vendors in the pharmaceutical industry who >>> are buying systems on eBay because that's the FDA validate platform. It >>> must be that make/model, spec'd sometime in the mid-90's. >>> >>> So... If you make an incompatible change TODAY figure we can start using >>> that code _at the earliest_ somewhere around 2012 or the low teens. >>> >>> Are we _really_ the only people on the list supporting embedded/factory >>> automation platforms? >>> >>> Jim >> Do you provide your own implementation classes? >> >> Why can't you just continue to use 2.1 for the embedded platform until >> 2012 if you're locked down? Are you worried bugs won't get fixed? >> Sun might consider open sourcing the 2.1 Java source. I can't promise >> that, but it's been discussed and hasn't met resistance, except >> from me, because I wasn't super impressed with the code. I can probably >> be persuaded to champion open sourcing that and going through the >> process/legal machinations within Sun if it frees us to pursue >> a JSR for a new generation of javax.comm where we can have a chunk of >> common code in Open Source and each platform is simply responsible >> for it's platform specific plugins. >> >> I don't have many opinions about this set in stone because there >> are a lot of technical and pragmatic considerations such as yours >> the community has that I am probably not aware of or sufficiently >> sensitive to yet. I don't feel I really have the bird's eye view >> of all of this yet. >> >> The other thing is, I can only offer 10% of my time right now, >> according to my management, which is why I'm not pushing to >> be the spec lead for the JSR, and want only to be a participant >> to represent Sun's interests on the E.G. There is nothing sacred >> about Sun employees in the JCP as far as a JSR initiated by another >> entity is concerned. I am not the person everything needs to be >> cleared through. Ideas I have will pass or fail based on their >> merit and the community perception just like anyone else's. >> >> Paul >> >>> Paul Klissner wrote: >>>> Jim Redman wrote: >>>>> Paul Klissner wrote: >>>>>> I'd just like to find another suitable name than javax.comm, unless >>>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>>> 'major revisions' are accounted for. javax.serialport? >>>>> Which perhaps brings us back to what are we trying to fix and how badly. >>>> The goals I'm most interested in at the moment are: >>>> >>>> 1. A pluggable platform portmapping scheme wherein each platform >>>> can determine which ports to present to the application, and >>>> preferably as some configurable logical name. >>>> >>>> For example on the Sun Ray thin client platform, if an application >>>> aquiring a view of serial ports available on the system, it will >>>> be informed of Sun Ray serial ports if the application is running >>>> in a session currently directed to that particular Sun Ray unit, >>>> even though the serial port's device node happens to be server-side >>>> deeply nested in a leaf node. If the application is not running on >>>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>>> the decision about when and which ports to present to the application. >>>> >>>> 2. Pluggable driver-side interface where multiple platform-specific >>>> drivers can be utilized simultaneously to introduce more flexibility >>>> with the back end. >>>> >>>>> There are a number of 3rd party implementation of Java Comm, at least >>>>> one from IBM - part of what was J9, now Websphere, or something >>>>> (presumbly soon to get a name that has eclipse in it sometime soon). >>>>> Esmertec has one, and there are few others rolling around. >>>> I have not been advocating gutting the API, since much of it is >>>> perfectly adequate. I'm not totally opposed to making substantial >>>> changes or improvements depending on other people's needs. There's >>>> no reason previous versions of javax.comm need to suddenly disappear >>>> if products need legacy support. >>>> >>>> >>>>> If RXTX is the only implementation of the JSR with no backward >>>>> compatibility, we've just forked Java Serial support and we (for a least >>>>> one) will be worse off. We won't be able to use the new support because >>>>> of a lack of support on J2ME platforms that we have no control over and >>>>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>>>> other platforms. >>>> There can't be *that* many platforms this is ported to. And it will >>>> be no javax.usb. Seems like most of the standard platforms will >>>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>>> JDBC... >>>> >>>>> So, is there any chance of building a compatibility requirement into >>>>> this. To pick are really bad example JDBC has support for a DataSource >>>>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>>>> SerialPort on a class not found exception? >>>> Maybe, or maybe we just let people know what we are doing and >>>> try to figure out how to get their applications ported. Might not >>>> be that difficult. From my standpoint anyway, earthshaking >>>> changes aren't really necessary. Others might disagree. >>>> >>>> Paul >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From Paul.Klissner at Sun.COM Thu Jul 20 09:45:11 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Thu, 20 Jul 2006 08:45:11 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BFA1DA.10301@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> <44BF8DF1.4040101@ergotech.com> <44BFA1DA.10301@sun.com> Message-ID: <44BFA507.3020001@sun.com> Paul Klissner wrote: > Jim Redman wrote: >> Paul, >> >> The issue with a new, incompatible implementation is, as you've >> identified below, is support for the old API. Open sourcing would be >> helpful, but then someone (us?) would have to maintain the source >> through changing versions of Window, and RXTX on Linux platforms. Or >> we'd have to have to versions of our codebase, which doesn't appeal >> too much. >> >> The maintenance issue is not impossible, but I think that in essence >> I'm agreeing with a comment you made earlier. >> >> IF a huge change is required, then lets get on with it. However, if >> the changes that are required are just extensions and enhancements, >> with some low-level re-engineering, then can we keep a compatible >> high-level API so that people needing the new features can use an >> extended API and those who need cross-platform compatibility can >> continue to use the existing features. >> >> Jim > > Guillermo made a crystal clear case and I understand the problem > that that will be caused by forking the API in any sense of the > word. I only want to uphold Sun's interests and resolve the problems > we ran into with the RXTX community when Sun added portmapping > to 3.0, which was not easily undone and was implemented as kind > of a hack because it wasn't directly supported by the javax.comm > architection. ^^^"architecture" > > As I mentioned previously the changes I want to make have primarily > to do with adding platform-specific portmapping via plugins, > and supporting multiple javax.comm backend drivers on the same > host (some ports would use one driver, others ports might use another). > > Also I'd like to address some bugfixes that were done in Sun's > version 3.0 (including better error reporting, and more robust > code for locating configuration files). Besides that, I'm not > aware of any deficiences, but I've glanced other e-mails where > people have suggested some. It would be good to get a summary > of everyone's wishes. I've stated mine. > > I given much thought to what it would take to properly address ^^^haven't > EIA-422, EIA-423 and EIA-485 (if any); but those would > probably be extensions. Sounds like the differences might > be transparent to the API. I'll look into that more. > > Paul > > >> >> Paul Klissner wrote: >>> Jim Redman wrote: >>>> Paul, >>>> >>>> For the record we're STILL supporting some PersonalJava platforms. >>>> We're _almost_ at the point where we can assume that the platforms >>>> will have a Collections framework, but routinely compile with a 1.1 >>>> check so that we don't make that assumption unnecessarily. Of 50+ >>>> non-graphical Factory Automation JavaBeans we have 2 that require >>>> Java2 (Reporting and JavaScripting), and we have people asking for a >>>> back-port. >>>> >>>> Embedded platforms don't change in a hurry. Unlike desktop >>>> platforms, embedded systems are expected to last 5-10+ years. >>>> >>>> There are factory automation vendors in the pharmaceutical industry >>>> who are buying systems on eBay because that's the FDA validate >>>> platform. It must be that make/model, spec'd sometime in the mid-90's. >>>> >>>> So... If you make an incompatible change TODAY figure we can start >>>> using that code _at the earliest_ somewhere around 2012 or the low >>>> teens. >>>> >>>> Are we _really_ the only people on the list supporting >>>> embedded/factory automation platforms? >>>> >>>> Jim >>> Do you provide your own implementation classes? >>> >>> Why can't you just continue to use 2.1 for the embedded platform until >>> 2012 if you're locked down? Are you worried bugs won't get fixed? >>> Sun might consider open sourcing the 2.1 Java source. I can't promise >>> that, but it's been discussed and hasn't met resistance, except >>> from me, because I wasn't super impressed with the code. I can probably >>> be persuaded to champion open sourcing that and going through the >>> process/legal machinations within Sun if it frees us to pursue >>> a JSR for a new generation of javax.comm where we can have a chunk of >>> common code in Open Source and each platform is simply responsible >>> for it's platform specific plugins. >>> >>> I don't have many opinions about this set in stone because there >>> are a lot of technical and pragmatic considerations such as yours >>> the community has that I am probably not aware of or sufficiently >>> sensitive to yet. I don't feel I really have the bird's eye view >>> of all of this yet. >>> >>> The other thing is, I can only offer 10% of my time right now, >>> according to my management, which is why I'm not pushing to >>> be the spec lead for the JSR, and want only to be a participant >>> to represent Sun's interests on the E.G. There is nothing sacred >>> about Sun employees in the JCP as far as a JSR initiated by another >>> entity is concerned. I am not the person everything needs to be >>> cleared through. Ideas I have will pass or fail based on their >>> merit and the community perception just like anyone else's. >>> >>> Paul >>> >>>> Paul Klissner wrote: >>>>> Jim Redman wrote: >>>>>> Paul Klissner wrote: >>>>>>> I'd just like to find another suitable name than javax.comm, unless >>>>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>>>> 'major revisions' are accounted for. javax.serialport? >>>>>> Which perhaps brings us back to what are we trying to fix and how >>>>>> badly. >>>>> The goals I'm most interested in at the moment are: >>>>> >>>>> 1. A pluggable platform portmapping scheme wherein each platform >>>>> can determine which ports to present to the application, and >>>>> preferably as some configurable logical name. >>>>> >>>>> For example on the Sun Ray thin client platform, if an application >>>>> aquiring a view of serial ports available on the system, it will >>>>> be informed of Sun Ray serial ports if the application is running >>>>> in a session currently directed to that particular Sun Ray unit, >>>>> even though the serial port's device node happens to be server-side >>>>> deeply nested in a leaf node. If the application is not running on >>>>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>>>> the decision about when and which ports to present to the application. >>>>> >>>>> 2. Pluggable driver-side interface where multiple platform-specific >>>>> drivers can be utilized simultaneously to introduce more flexibility >>>>> with the back end. >>>>> >>>>>> There are a number of 3rd party implementation of Java Comm, at >>>>>> least one from IBM - part of what was J9, now Websphere, or >>>>>> something (presumbly soon to get a name that has eclipse in it >>>>>> sometime soon). Esmertec has one, and there are few others rolling >>>>>> around. >>>>> I have not been advocating gutting the API, since much of it is >>>>> perfectly adequate. I'm not totally opposed to making substantial >>>>> changes or improvements depending on other people's needs. There's >>>>> no reason previous versions of javax.comm need to suddenly disappear >>>>> if products need legacy support. >>>>> >>>>> >>>>>> If RXTX is the only implementation of the JSR with no backward >>>>>> compatibility, we've just forked Java Serial support and we (for a >>>>>> least one) will be worse off. We won't be able to use the new >>>>>> support because of a lack of support on J2ME platforms that we >>>>>> have no control over and RXTX/current JavaComm will be in >>>>>> maintenance mode or unsupported on all other platforms. >>>>> There can't be *that* many platforms this is ported to. And it will >>>>> be no javax.usb. Seems like most of the standard platforms will >>>>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>>>> JDBC... >>>>> >>>>>> So, is there any chance of building a compatibility requirement >>>>>> into this. To pick are really bad example JDBC has support for a >>>>>> DataSource or a Driver. Could we have an ExcellentSerialPort with >>>>>> a fallback to a SerialPort on a class not found exception? >>>>> Maybe, or maybe we just let people know what we are doing and >>>>> try to figure out how to get their applications ported. Might not >>>>> be that difficult. From my standpoint anyway, earthshaking >>>>> changes aren't really necessary. Others might disagree. >>>>> >>>>> Paul >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From jredman at ergotech.com Thu Jul 20 10:30:01 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 20 Jul 2006 10:30:01 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BFA507.3020001@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> <44BF8DF1.4040101@ergotech.com> <44BFA1DA.10301@sun.com> <44BFA507.3020001@sun.com> Message-ID: <44BFAF89.5010003@ergotech.com> Thast what hapens if you post late at nihgt nad erly in the moning as wel. :) Paul Klissner wrote: > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul, >>> >>> The issue with a new, incompatible implementation is, as you've >>> identified below, is support for the old API. Open sourcing would be >>> helpful, but then someone (us?) would have to maintain the source >>> through changing versions of Window, and RXTX on Linux platforms. Or >>> we'd have to have to versions of our codebase, which doesn't appeal >>> too much. >>> >>> The maintenance issue is not impossible, but I think that in essence >>> I'm agreeing with a comment you made earlier. >>> >>> IF a huge change is required, then lets get on with it. However, if >>> the changes that are required are just extensions and enhancements, >>> with some low-level re-engineering, then can we keep a compatible >>> high-level API so that people needing the new features can use an >>> extended API and those who need cross-platform compatibility can >>> continue to use the existing features. >>> >>> Jim >> Guillermo made a crystal clear case and I understand the problem >> that that will be caused by forking the API in any sense of the >> word. I only want to uphold Sun's interests and resolve the problems >> we ran into with the RXTX community when Sun added portmapping >> to 3.0, which was not easily undone and was implemented as kind >> of a hack because it wasn't directly supported by the javax.comm >> architection. > ^^^"architecture" >> As I mentioned previously the changes I want to make have primarily >> to do with adding platform-specific portmapping via plugins, >> and supporting multiple javax.comm backend drivers on the same >> host (some ports would use one driver, others ports might use another). >> >> Also I'd like to address some bugfixes that were done in Sun's >> version 3.0 (including better error reporting, and more robust >> code for locating configuration files). Besides that, I'm not >> aware of any deficiences, but I've glanced other e-mails where >> people have suggested some. It would be good to get a summary >> of everyone's wishes. I've stated mine. >> >> I given much thought to what it would take to properly address > ^^^haven't >> EIA-422, EIA-423 and EIA-485 (if any); but those would >> probably be extensions. Sounds like the differences might >> be transparent to the API. I'll look into that more. >> >> Paul >> >> >>> Paul Klissner wrote: >>>> Jim Redman wrote: >>>>> Paul, >>>>> >>>>> For the record we're STILL supporting some PersonalJava platforms. >>>>> We're _almost_ at the point where we can assume that the platforms >>>>> will have a Collections framework, but routinely compile with a 1.1 >>>>> check so that we don't make that assumption unnecessarily. Of 50+ >>>>> non-graphical Factory Automation JavaBeans we have 2 that require >>>>> Java2 (Reporting and JavaScripting), and we have people asking for a >>>>> back-port. >>>>> >>>>> Embedded platforms don't change in a hurry. Unlike desktop >>>>> platforms, embedded systems are expected to last 5-10+ years. >>>>> >>>>> There are factory automation vendors in the pharmaceutical industry >>>>> who are buying systems on eBay because that's the FDA validate >>>>> platform. It must be that make/model, spec'd sometime in the mid-90's. >>>>> >>>>> So... If you make an incompatible change TODAY figure we can start >>>>> using that code _at the earliest_ somewhere around 2012 or the low >>>>> teens. >>>>> >>>>> Are we _really_ the only people on the list supporting >>>>> embedded/factory automation platforms? >>>>> >>>>> Jim >>>> Do you provide your own implementation classes? >>>> >>>> Why can't you just continue to use 2.1 for the embedded platform until >>>> 2012 if you're locked down? Are you worried bugs won't get fixed? >>>> Sun might consider open sourcing the 2.1 Java source. I can't promise >>>> that, but it's been discussed and hasn't met resistance, except >>>> from me, because I wasn't super impressed with the code. I can probably >>>> be persuaded to champion open sourcing that and going through the >>>> process/legal machinations within Sun if it frees us to pursue >>>> a JSR for a new generation of javax.comm where we can have a chunk of >>>> common code in Open Source and each platform is simply responsible >>>> for it's platform specific plugins. >>>> >>>> I don't have many opinions about this set in stone because there >>>> are a lot of technical and pragmatic considerations such as yours >>>> the community has that I am probably not aware of or sufficiently >>>> sensitive to yet. I don't feel I really have the bird's eye view >>>> of all of this yet. >>>> >>>> The other thing is, I can only offer 10% of my time right now, >>>> according to my management, which is why I'm not pushing to >>>> be the spec lead for the JSR, and want only to be a participant >>>> to represent Sun's interests on the E.G. There is nothing sacred >>>> about Sun employees in the JCP as far as a JSR initiated by another >>>> entity is concerned. I am not the person everything needs to be >>>> cleared through. Ideas I have will pass or fail based on their >>>> merit and the community perception just like anyone else's. >>>> >>>> Paul >>>> >>>>> Paul Klissner wrote: >>>>>> Jim Redman wrote: >>>>>>> Paul Klissner wrote: >>>>>>>> I'd just like to find another suitable name than javax.comm, unless >>>>>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>>>>> 'major revisions' are accounted for. javax.serialport? >>>>>>> Which perhaps brings us back to what are we trying to fix and how >>>>>>> badly. >>>>>> The goals I'm most interested in at the moment are: >>>>>> >>>>>> 1. A pluggable platform portmapping scheme wherein each platform >>>>>> can determine which ports to present to the application, and >>>>>> preferably as some configurable logical name. >>>>>> >>>>>> For example on the Sun Ray thin client platform, if an application >>>>>> aquiring a view of serial ports available on the system, it will >>>>>> be informed of Sun Ray serial ports if the application is running >>>>>> in a session currently directed to that particular Sun Ray unit, >>>>>> even though the serial port's device node happens to be server-side >>>>>> deeply nested in a leaf node. If the application is not running on >>>>>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>>>>> the decision about when and which ports to present to the application. >>>>>> >>>>>> 2. Pluggable driver-side interface where multiple platform-specific >>>>>> drivers can be utilized simultaneously to introduce more flexibility >>>>>> with the back end. >>>>>> >>>>>>> There are a number of 3rd party implementation of Java Comm, at >>>>>>> least one from IBM - part of what was J9, now Websphere, or >>>>>>> something (presumbly soon to get a name that has eclipse in it >>>>>>> sometime soon). Esmertec has one, and there are few others rolling >>>>>>> around. >>>>>> I have not been advocating gutting the API, since much of it is >>>>>> perfectly adequate. I'm not totally opposed to making substantial >>>>>> changes or improvements depending on other people's needs. There's >>>>>> no reason previous versions of javax.comm need to suddenly disappear >>>>>> if products need legacy support. >>>>>> >>>>>> >>>>>>> If RXTX is the only implementation of the JSR with no backward >>>>>>> compatibility, we've just forked Java Serial support and we (for a >>>>>>> least one) will be worse off. We won't be able to use the new >>>>>>> support because of a lack of support on J2ME platforms that we >>>>>>> have no control over and RXTX/current JavaComm will be in >>>>>>> maintenance mode or unsupported on all other platforms. >>>>>> There can't be *that* many platforms this is ported to. And it will >>>>>> be no javax.usb. Seems like most of the standard platforms will >>>>>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>>>>> JDBC... >>>>>> >>>>>>> So, is there any chance of building a compatibility requirement >>>>>>> into this. To pick are really bad example JDBC has support for a >>>>>>> DataSource or a Driver. Could we have an ExcellentSerialPort with >>>>>>> a fallback to a SerialPort on a class not found exception? >>>>>> Maybe, or maybe we just let people know what we are doing and >>>>>> try to figure out how to get their applications ported. Might not >>>>>> be that difficult. From my standpoint anyway, earthshaking >>>>>> changes aren't really necessary. Others might disagree. >>>>>> >>>>>> Paul >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Thu Jul 20 10:31:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 20 Jul 2006 10:31:57 -0600 (MDT) Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEA802.7060508@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: > PROJECT SCOPE: > ------------- > > Also, we should think carefully about what the scope of > this project would be. Should it be javax."comm" which > handles both serial and parallel (is parallel going by the > wayside). Should it be split into two project: > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > > Should we differentiate between single-ended serial > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > quasi-multidrop and full multidrop busses such as > EIA422, EIA432 and EIA485? If we really were to > add I2C support to the API, we'd have to delve into > the semantics more, because there could be some > implicit decoding of the bus the API users would > want to see. > Hi Paul The way RXTX works, which is a fair representation of the people using the API, is complete support for RIA232, minimal support for IEEE1284. From what I understand, Sun was going along the same lines. If we combined both projects, we would have half a parallel port implementation. I see maybe 4 requests for features not in the parallel support a year. The other protocols should not be limited by a JSR which is going to be focused upon serial port interests. The IEA485 hacks in RXTX along with I2C and Raw should _not_ be considered a strong basis for extending the API to cover these protocols. If people want to do real implementations, they should not face a 'standard' which wasnt really focused upon their interests. I think we understand the parallel port issues fairly well but have not implemented many features and I don't know if we would. So a versatile API is favorable but I do not think we have the proper community to represent much more than Serial. We could provide a framework or maybe just a model for further work with other standards. -- Trent Jarvi tjarvi at qbang.org From naranjo.manuel at gmail.com Thu Jul 20 10:49:33 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Thu, 20 Jul 2006 13:49:33 -0300 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <44BFB41D.4010604@gmail.com> Trent Jarvi wrote: >> PROJECT SCOPE: >> ------------- >> >> Also, we should think carefully about what the scope of >> this project would be. Should it be javax."comm" which >> handles both serial and parallel (is parallel going by the >> wayside). Should it be split into two project: >> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >> >> Should we differentiate between single-ended serial >> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >> quasi-multidrop and full multidrop busses such as >> EIA422, EIA432 and EIA485? If we really were to >> add I2C support to the API, we'd have to delve into >> the semantics more, because there could be some >> implicit decoding of the bus the API users would >> want to see. >> > > Hi Paul > > The way RXTX works, which is a fair representation of the people using the > API, is complete support for RIA232, minimal support for IEEE1284. From > what I understand, Sun was going along the same lines. If we combined > both projects, we would have half a parallel port implementation. I see > maybe 4 requests for features not in the parallel support a year. > > The other protocols should not be limited by a JSR which is going to be > focused upon serial port interests. The IEA485 hacks in RXTX along with > I2C and Raw should _not_ be considered a strong basis for extending the > API to cover these protocols. If people want to do real implementations, > they should not face a 'standard' which wasnt really focused upon their > interests. I think we understand the parallel port issues fairly well but > have not implemented many features and I don't know if we would. > > So a versatile API is favorable but I do not think we have the proper > community to represent much more than Serial. We could provide a > framework or maybe just a model for further work with other standards. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Hi, I agree with Trent, as far as I have seen most projects that were using RXTX and Java Comm where designed to work only with Serial Ports. What is fact is that a Parallel port can not be modeled at all like a Serial Port, except that they both expose and Input Stream and an Output Stream. As I have read there is a huge market of embedded applications using port accessing. We could take two different aproaches with the JSR, one could be define a way to access every kind of port independent of the implementation of the port himself. We could access Serial, Parallel, I2C, USB, etc. But we will have huge problems with it, because we will have to face a lot of low level programming which of course will be platform dependent, and that is were the write one use everywhere of Java could dye. The other approach is to define an Api that only supports Serial Ports, compatible with the one that is defined in javax.comm 2.0, and make some classes that extend that packages, maybe even in another package, like AWT and JSWING do. We then could eventually extend to other kinds of ports but that will require a lot of work more. I'm not a person specialized on Informatical Engineering, so I do not think I can give a hand on Low Level programming, I do can help with the Java part, debugging and testing. Regards, Manuel From brian at mbari.org Thu Jul 20 11:19:33 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 20 Jul 2006 10:19:33 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <8BFCAB48-6302-44CD-ABF0-560BC04AD26E@mbari.org> > The way RXTX works, which is a fair representation of the people > using the > API, is complete support for RIA232, minimal support for IEEE1284. > From > what I understand, Sun was going along the same lines. If we combined > both projects, we would have half a parallel port implementation. > I see > maybe 4 requests for features not in the parallel support a year. > > The other protocols should not be limited by a JSR which is going > to be > focused upon serial port interests. The IEA485 hacks in RXTX along > with > I2C and Raw should _not_ be considered a strong basis for extending > the > API to cover these protocols. If people want to do real > implementations, > they should not face a 'standard' which wasnt really focused upon > their > interests. I think we understand the parallel port issues fairly > well but > have not implemented many features and I don't know if we would. > > So a versatile API is favorable but I do not think we have the proper > community to represent much more than Serial. We could provide a > framework or maybe just a model for further work with other standards. I agree completely. Folks use RXTX for serial ports. In my field (Oceanography), we uses RS232 to talk to nearly all our instruments. So we really need a great implementation of serial port communications in Java that runs on a variety of architectures. I'd prefer if the JSR focused on that. >> I given much thought to what it would take to properly address >> > ^^^haven't > >> EIA-422, EIA-423 and EIA-485 (if any); but those would >> probably be extensions. Sounds like the differences might >> be transparent to the API. I'll look into that more. I've had good luck using the current implementation of RXTX with RS422, although you'll need to use a pin converter. my 2 cents. Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060720/fb956c68/attachment-0342.html From pascal at quies.net Fri Jul 21 15:43:40 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Fri, 21 Jul 2006 23:43:40 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: Message-ID: <200607212343.40882.pascal@quies.net> Op donderdag 20 juli 2006 15:16, schreef Dr. Douglas Lyon: > Hi All, > There has been some discussion about plugins for serial communications. > > As I see it, what Java really needs is a NativeLibraryManager. This is > a rather much larger charge than "just" RXTX. > > The RXTX basic mode of operation is that we associate static > blocks of code with a "System.load". > > Failure occurs when the class containing such a block of code is > loaded AND the native library is not found. > > What are some of the options? > > 1. Do nothing, let the program fail with an exception. > 2. try to catch an UnsatisfiedLinkError as a part of making > the driver. > 3. Search the java.library.path to see if the driver is present > (i.e., guard the input). > 4. Other?? > > In the case of either step 2 or 3, we need to fix the lack of a library. > > What are the options for fixing a library? > 1. Do nothing, but give the user an interesting error with instructions on > what to do. > 2. Attempt to find the library on the file system (perhaps with user help). > 3. Attempt to download the library and install it (perhaps with user > permission). > 4. Attempt to internalize the library as a UUEncoded serialized object and > install it (better ask the user, again!). > 5. Other?? 5. Put the binaries together with the attached classes in a jar. Joachim told me that and it works! I forgot to publish the results. :$ ---- begin example import org.rxtx.CommunicationAPI; ... CommunicationAPI commExtension = new CommunicationAPI(); try { commExtenios.loadNativeLibraries(); } catch (Exception e) { // We *need* javax.comm } // Now we have the extension available. ... ---- end example Do you like it? Commens anyone? The path to the libraries is in the form of /native/rxtx/-/{libserial,libparallel} so /native/rxtx/windows-i386/libserial would do. I asked for binaries but only Joachim offered me help with OS X on the next release. Does anyone have javax.comm warper classes? -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 6781 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060721/b39a5592/CommunicationAPI-0341.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: PlatformNotSupportedException.java Type: text/x-java Size: 1621 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060721/b39a5592/PlatformNotSupportedException-0341.bin From pascal at quies.net Fri Jul 21 15:45:30 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Fri, 21 Jul 2006 23:45:30 +0200 Subject: [Rxtx] quo vadis API/namespace (Re: jcp and jsr) In-Reply-To: References: <44BEDC4F.9030403@sun.com> Message-ID: <200607212345.30495.pascal@quies.net> Op donderdag 20 juli 2006 10:46, schreef Joachim Buechse: > So in short: Unless we find a strong argument why javax.comm can't be > used I prefer that we keep it. Unless we find a strong feature / use- > case that can not be handled with (an extension of) the current > CommPort/CommPortIndentifier I'd prefer to keep that as well. I seem to be the only one who sees failures in the API so lets keep it that way. Now how do we get a JSR/lisence if we don't want any changes? :P From lyon at docjava.com Sat Jul 22 06:07:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 22 Jul 2006 08:07:03 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607212343.40882.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> Message-ID: Hi All, I like the idea of the native lib in a jar with other classes. An alternative I did not know would work. Now, if you place the rxtx classes and native library in the same jar, do they both have to be in any specific place in order to be found? In my approach, you can locate the native library at run-time, and you need not alter any environmental variables nor mangle the JDK home. Thus, each user can have a different native library, one for development and one for release, for example. Regards, - Doug >Op donderdag 20 juli 2006 15:16, schreef Dr. Douglas Lyon: >> Hi All, >> There has been some discussion about plugins for serial communications. >> >> As I see it, what Java really needs is a NativeLibraryManager. This is >> a rather much larger charge than "just" RXTX. >> >> The RXTX basic mode of operation is that we associate static >> blocks of code with a "System.load". >> >> Failure occurs when the class containing such a block of code is >> loaded AND the native library is not found. >> >> What are some of the options? >> >> 1. Do nothing, let the program fail with an exception. >> 2. try to catch an UnsatisfiedLinkError as a part of making >> the driver. >> 3. Search the java.library.path to see if the driver is present >> (i.e., guard the input). >> 4. Other?? >> >> In the case of either step 2 or 3, we need to fix the lack of a library. >> >> What are the options for fixing a library? >> 1. Do nothing, but give the user an interesting error with instructions on >> what to do. >> 2. Attempt to find the library on the file system (perhaps with user help). >> 3. Attempt to download the library and install it (perhaps with user >> permission). >> 4. Attempt to internalize the library as a UUEncoded serialized object and >> install it (better ask the user, again!). >> 5. Other?? > >5. Put the binaries together with the attached classes in a jar. > >Joachim told me that and it works! I forgot to publish the results. :$ > > >---- begin example >import org.rxtx.CommunicationAPI; > >... >CommunicationAPI commExtension = new CommunicationAPI(); >try { > commExtenios.loadNativeLibraries(); >} catch (Exception e) { > // We *need* javax.comm >} > >// Now we have the extension available. >... >---- end example > > >Do you like it? Commens anyone? > > >The path to the libraries is in the form >of /native/rxtx/-/{libserial,libparallel} >so /native/rxtx/windows-i386/libserial would do. > >I asked for binaries but only Joachim offered me help with OS X on the next >release. > >Does anyone have javax.comm warper classes? > >Attachment converted: PowerBookHd:CommunicationAPI.java (TEXT/ttxt) (001C1686) >Attachment converted: PowerBookHd:PlatformNotSupporte#1C1687.java >(TEXT/ttxt) (001C1687) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 22 07:06:06 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 15:06:06 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607212343.40882.pascal@quies.net> Message-ID: <200607221506.07140.pascal@quies.net> > Now, if you place the rxtx classes and native library in the same > jar, do they both have to be in any specific place in order to be found? Answer: > >The path to the libraries is in the form > >of /native/rxtx/-/{libserial,libparallel} > >so /native/rxtx/windows-i386/libserial would do. I'me looking for the various os.name and os.arch values right now. From lyon at docjava.com Sat Jul 22 08:06:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 22 Jul 2006 10:06:26 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607221506.07140.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> <200607221506.07140.pascal@quies.net> Message-ID: Hi All, Here is how I have arranged my signed versions of the native binaries: http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/windows/native.jar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/native.jar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/linux/native.jar Then I do: public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isMacOs()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); System.out.println("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } My new-age NativeLibraryManger concept-thang allows you to write stuff like: /** * This method fixes the driver by beaming over * to the tmp directory a native.jar file. * The native.jar file is signed and its * native libs are beamed over to the user home directory * ~/.rxtx/
* Finally, the java.library.path is altered to include
* ~/.rxtx/ */ private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), NativeLibraryManager.mapLibraryName("rxtxSerial")); } catch (IOException e) { e.printStackTrace(); } } I do a lazy singleton design pattern: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getInstance() { if (driver != null) return driver; if (!NativeLibraryManager.isLibInPath("rxtxSerial")) fixDriver(); if (NativeLibraryManager.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } I am at a cross-roads here, since a file-based distro might be preferable to a URL based distro. To make this really general, and to "remember" where the last version of a native library came from, I serialize a bean into user preferences The user can then store native libraries anywhere, remembering the location in the preferences. What is the general feeling about this? Thanks! - Doug > > Now, if you place the rxtx classes and native library in the same >> jar, do they both have to be in any specific place in order to be found? > >Answer: > >> >The path to the libraries is in the form >> >of /native/rxtx/-/{libserial,libparallel} >> >so /native/rxtx/windows-i386/libserial would do. > >I'me looking for the various os.name and os.arch values right now. >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Sat Jul 22 10:30:55 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 22 Jul 2006 11:30:55 -0500 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607212343.40882.pascal@quies.net> Message-ID: <44C252BF.6040404@cox.net> Dr. Douglas Lyon wrote: > Hi All, > I like the idea of the native lib in a jar with other classes. > An alternative I did not know would work. I have several applications that run with a security policy. In these applications, native library loading will require an appropriate FilePermission that should be known about ahead of time. The current native library implementation will require the native library to be extracted from the jar and written to disk, requiring a FilePermission("...","write") for that file, and then will also require read access to load the library. I personally don't want to give write access to a JVM for a shared library which can provide a point of abuse by errant code. Gregg Wonderly From gergg at cox.net Sat Jul 22 10:33:52 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 22 Jul 2006 11:33:52 -0500 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607212343.40882.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> Message-ID: <44C25370.9070506@cox.net> >Pascal S. de Kloe wrote: >>> I am also not sure if >>> the api should unify corresponding cu. and tty. ports into one single >>> port. >> >> I think the API should hide low-level details like devicefiles. > >Not all ports have device files. It's long been my goal to add support >for virtual serial ports, that is, serial ports on Ethernet terminal >servers, for example integrating RFC2217. This means that the port name >is some combination of an IP address and TCP port number. Nothing in /dev. What I think would make the most sense is a simple "device" enumeration Server Provider Interface that would bring port objects into the JVM based on the platform JVM providers knowledge of how to enumerate those ports. Application writers would provide a plugin using the SPI that would codify those devices into named entities that they are interested in. public interface HardwarePort { public String getName(); public String getHardwareID(); public String getManufacturer(); public List getCapabilities(); public Object getImplementation(); } public interface PortCapability { public String getDescription(); public CapabilityId getIdentifier(); } public enum CapabilityId { INPUT, // Can receive input OUTPUT, // Can send output ASYNCHRONOUS, // Can send and receive at the same time SYNCHRONOUS, // No synchronous I/O ADDRESSABLE // Port has an address associated } Then, you might imagine that the enumerated capabilities had a standardized/specified interface that you'd find implemented on ports that had such capabilities. The getImplementation() method would return the implementation class provided by the JVM provider that had all of the interfaces tied to it. These are just some quick thoughts, pick away at them. I am very interested in getting a new comm api in place which can provide the ability for all USB connected devices to have drivers provided as 100% java for all non-timing critical types of device interfaces. The JVM provider should have an SPI to write to which will enable them to abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into something that we can talk 100% java to. That's my big desire. Starting with something simple which gives a good start in that direction would be great! Gregg Wonderly From pascal at quies.net Sat Jul 22 10:43:27 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 18:43:27 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <44C252BF.6040404@cox.net> References: <44C252BF.6040404@cox.net> Message-ID: <200607221843.27765.pascal@quies.net> Op zaterdag 22 juli 2006 18:30, schreef Gregg Wonderly: > Dr. Douglas Lyon wrote: > > Hi All, > > I like the idea of the native lib in a jar with other classes. > > An alternative I did not know would work. > > I have several applications that run with a security policy. In these > applications, native library loading will require an appropriate > FilePermission that should be known about ahead of time. The current > native library implementation will require the native library to be > extracted from the jar and written to disk, requiring a > FilePermission("...","write") for that file, and then will also require > read access to load the library. I personally don't want to give write > access to a JVM for a shared library which can provide a point of abuse by > errant code. > > Gregg Wonderly That's indeed a pitty limitation. It creates a lot of possible exceptions too. On the other hand, any native lib passes the securiy model. Applications who can access hardware ports can be expected to create files, right? From pascal at quies.net Sat Jul 22 10:54:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 18:54:13 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607221506.07140.pascal@quies.net> Message-ID: <200607221854.13467.pascal@quies.net> Hi Dr., We're both trying to do the same thing. The CommunicationAPI does not only look at the OS but it also indexes the available hardware architectures and does not need OsUtils. Any Java 2 runtime will do. The plan was to make a single JAR with the binaries for all supported platforms, the RXTX gnu.io package and the javax.comm wrapers. A signed version would be nice. A few questions remain tough. Does anybody know how Sun uses the SunOS and Solaris identifiers for the Java property os.name? Op zaterdag 22 juli 2006 16:06, schreef Dr. Douglas Lyon: > Hi All, > Here is how I have arranged my signed versions of the native > binaries: > http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/windows/native.j >ar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/native.jar > http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/linux/native.jar > > Then I do: > public static URL getResourceUrl() throws MalformedURLException { > String rxtxUrl = "http://show.docjava.com:8086/" + > "book/cgij/code/jnlp/libs/rxtx/"; > if (OsUtils.isLinux()) > return new URL(rxtxUrl + "linux/native.jar"); > if (OsUtils.isMacOs()) > return new URL(rxtxUrl + "mac/native.jar"); > if (OsUtils.isWindows()) > return new URL(rxtxUrl + "windows/native.jar"); > System.out.println("no automatic install supported for this > platform. " + > "Please e-mail lyon at docjava.com with a bug report"); > return null; > } > > My new-age NativeLibraryManger concept-thang allows you to > write stuff like: > > /** > * This method fixes the driver by beaming over > * to the tmp directory a native.jar file. > * The native.jar file is signed and its > * native libs are beamed over to the user home directory > * ~/.rxtx/
> * Finally, the java.library.path is altered to include
> * ~/.rxtx/ > */ > private static void fixDriver() { > > try { > NativeLibraryManager.fixDriver(getResourceUrl(), > NativeLibraryManager.mapLibraryName("rxtxSerial")); > } catch (IOException e) { > e.printStackTrace(); > } > } > > I do a lazy singleton design pattern: > > public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public synchronized static RXTXCommDriver getInstance() { > if (driver != null) return driver; > if (!NativeLibraryManager.isLibInPath("rxtxSerial")) > fixDriver(); > if (NativeLibraryManager.isLibInPath("rxtxSerial")) { > driver = new RXTXCommDriver(); > driver.initialize(); > } > return driver; > } > > I am at a cross-roads here, since a file-based distro might be preferable > to a URL based distro. To make this really general, and to "remember" where > the last version of a native library came from, I serialize a bean into > user preferences > The user can then store native libraries anywhere, remembering the location > in the preferences. > > What is the general feeling about this? > > Thanks! > - Doug > > > > Now, if you place the rxtx classes and native library in the same > >> > >> jar, do they both have to be in any specific place in order to be > >> found? > > > >Answer: > >> >The path to the libraries is in the form > >> >of /native/rxtx/-/{libserial,libparallel} > >> >so /native/rxtx/windows-i386/libserial would do. > > > >I'me looking for the various os.name and os.arch values right now. > >_______________________________________________ > >Rxtx mailing list > >Rxtx at qbang.org > >http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Sat Jul 22 11:17:51 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 22 Jul 2006 19:17:51 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <44C252BF.6040404@cox.net> References: <200607212343.40882.pascal@quies.net> <44C252BF.6040404@cox.net> Message-ID: <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> We could easily have a stub method / flag that allows you to explicitly load the native library (via System.loadLibrary ie from the java.library.path). In this case the "auto-extraction" would not take place. On 22.07.2006, at 18:30, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> Hi All, >> I like the idea of the native lib in a jar with other classes. >> An alternative I did not know would work. > > I have several applications that run with a security policy. In these > applications, native library loading will require an appropriate > FilePermission > that should be known about ahead of time. The current native library > implementation will require the native library to be extracted from > the jar and > written to disk, requiring a FilePermission("...","write") for that > file, and > then will also require read access to load the library. I > personally don't want > to give write access to a JVM for a shared library which can > provide a point of > abuse by errant code. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 22 11:20:19 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 19:20:19 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607221506.07140.pascal@quies.net> Message-ID: <200607221920.20096.pascal@quies.net> The attachment setup.zip contains a very small update of CommunicationAPI and a good start with the various platforms. All we need to do is fill those directories with binaries. Various binaries are missing the pararlel library. Why is that? -------------- next part -------------- A non-text attachment was scrubbed... Name: setup.zip Type: application/x-zip Size: 8459 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060722/12770623/setup-0340.bin From gregg at cytetech.com Thu Jul 20 21:32:55 2006 From: gregg at cytetech.com (Gregg Wonderly) Date: Thu, 20 Jul 2006 22:32:55 -0500 Subject: [Rxtx] jcp and jsr Message-ID: <44C04AE7.9050800@cytetech.com> >Pascal S. de Kloe wrote: >>> I am also not sure if >>> the api should unify corresponding cu. and tty. ports into one single >>> port. >> >> I think the API should hide low-level details like devicefiles. > >Not all ports have device files. It's long been my goal to add support >for virtual serial ports, that is, serial ports on Ethernet terminal >servers, for example integrating RFC2217. This means that the port name >is some combination of an IP address and TCP port number. Nothing in /dev. What I think would make the most sense is a simple "device" enumeration Server Provider Interface that would bring port objects into the JVM based on the platform JVM providers knowledge of how to enumerate those ports. Application writers would provide a plugin using the SPI that would codify those devices into named entities that they are interested in. public interface HardwarePort { public String getName(); public String getHardwareID(); public String getManufacturer(); public List getCapabilities(); public Object getImplementation(); } public interface PortCapability { public String getDescription(); public CapabilityId getIdentifier(); } public enum CapabilityId { INPUT, // Can receive input OUTPUT, // Can send output ASYNCHRONOUS, // Can send and receive at the same time SYNCHRONOUS, // No synchronous I/O ADDRESSABLE // Port has an address associated } Then, you might imagine that the enumerated capabilities had a standardized/specified interface that you'd find implemented on ports that had such capabilities. The getImplementation() method would return the implementation class provided by the JVM provider that had all of the interfaces tied to it. These are just some quick thoughts, pick away at them. I am very interested in getting a new comm api in place which can provide the ability for all USB connected devices to have drivers provided as 100% java for all non-timing critical types of device interfaces. The JVM provider should have an SPI to write to which will enable them to abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into something that we can talk 100% java to. That's my big desire. Starting with something simple which gives a good start in that direction would be great! Gregg Wonderly From pascal at quies.net Sat Jul 22 11:32:03 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 19:32:03 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44C25370.9070506@cox.net> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> Message-ID: <200607221932.04194.pascal@quies.net> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: > >Pascal S. de Kloe wrote: > >>> I am also not sure if > >>> the api should unify corresponding cu. and tty. ports into one single > >>> port. > >> > >> I think the API should hide low-level details like devicefiles. > > > >Not all ports have device files. It's long been my goal to add support > >for virtual serial ports, that is, serial ports on Ethernet terminal > >servers, for example integrating RFC2217. This means that the port name > >is some combination of an IP address and TCP port number. Nothing in > > /dev. > > What I think would make the most sense is a simple "device" enumeration > Server Provider Interface that would bring port objects into the JVM based > on the platform JVM providers knowledge of how to enumerate those ports. > Application writers would provide a plugin using the SPI that would codify > those devices into named entities that they are interested in. > > public interface HardwarePort { > public String getName(); > public String getHardwareID(); > public String getManufacturer(); > public List getCapabilities(); > public Object getImplementation(); > } > > public interface PortCapability { > public String getDescription(); > public CapabilityId getIdentifier(); > } > > public enum CapabilityId { > INPUT, // Can receive input > OUTPUT, // Can send output > ASYNCHRONOUS, // Can send and receive at the same time > SYNCHRONOUS, // No synchronous I/O > ADDRESSABLE // Port has an address associated > } > > Then, you might imagine that the enumerated capabilities had a > standardized/specified interface that you'd find implemented on ports that > had such capabilities. > > The getImplementation() method would return the implementation class > provided by the JVM provider that had all of the interfaces tied to it. > > These are just some quick thoughts, pick away at them. > > I am very interested in getting a new comm api in place which can provide > the ability for all USB connected devices to have drivers provided as 100% > java for all non-timing critical types of device interfaces. > > The JVM provider should have an SPI to write to which will enable them to > abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into something > that we can talk 100% java to. > > That's my big desire. Starting with something simple which gives a good > start in that direction would be great! That was exactly my wish too. The point people brought up was: 1) It's too complex. 2) What does it solve? In both facts they are right. It'll take a *long* time to plan such a thing right but if it works you have a product. Anyway, I'd like to join. ;) From joachim at buechse.de Sat Jul 22 11:37:11 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 22 Jul 2006 19:37:11 +0200 Subject: [Rxtx] Strange error (show stopper) Message-ID: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> I just discovered a strange error in RXTX on OSX. SerialDemo.java manages to corrupt the event_info_structure by a simple OpenPort,ClosePort - this could be in relation to the deadlock problem that was reported recently. Could anyone try to reproduce this on Solaris or some other system which is neither WIN32 nor Linux (ie which uses a drain thread). In SerialImp.c : RXTXPort(interruptEventLoop) Apparently the event_info_structure gets corrupted shortly after pthread_kill(index->drain_tid, SIGABRT); In particular, the index->closing flag gets overwritten by a pointer value. **** Adding the following debugging code: pthread_kill(index->drain_tid, SIGABRT); sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i \n", index->fd, index, index->closing ); report( message ); /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ usleep(50 * 1000); sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i \n", index->fd, index, index->closing ); report( message ); **** gives me: 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 drain_loop: received EINTR------------------ drain_loop exiting --------------------- entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 eventLoop: got interrupt 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 **** Modifying SerialImp.h : event_info_struct by moving the prev*, next* pointers jmethodID checkMonitorThread; struct event_info_struct *dummy, *dummy2; fd_set rfds; struct timeval tv_sleep; int closing; struct event_info_struct *next, *prev; *** (ie replacing their original position with dummys and moving them *** behind the closing flag) results in this: 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 drain_loop: received EINTR------------------ drain_loop exiting --------------------- entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 eventLoop: got interrupt 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 *** I was not able to track down the problem. If anyone could check wether this happens on other platforms as well, we may get closer to a fix. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich From joachim at buechse.de Sat Jul 22 11:46:35 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 22 Jul 2006 19:46:35 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607221932.04194.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> Message-ID: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> It seems that Gregg's suggestion could be implemented without changing the existing "user-level" API of javax.comm. Most of the information suggested for HardwarePort is not accessible from within the POSSIX-API but this is a different story. It is clear that javax.comm can never provide a way to talk to all USB devices, simply because some USB devices have several endpoints. But it could provide a means of talking to devices that function as a bidirectional-pipe (ie any USB to serial bridge). Regards, Joachim On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>> Pascal S. de Kloe wrote: >>>>> I am also not sure if >>>>> the api should unify corresponding cu. and tty. ports into one >>>>> single >>>>> port. >>>> >>>> I think the API should hide low-level details like devicefiles. >>> >>> Not all ports have device files. It's long been my goal to add >>> support >>> for virtual serial ports, that is, serial ports on Ethernet terminal >>> servers, for example integrating RFC2217. This means that the >>> port name >>> is some combination of an IP address and TCP port number. >>> Nothing in >>> /dev. >> >> What I think would make the most sense is a simple "device" >> enumeration >> Server Provider Interface that would bring port objects into the >> JVM based >> on the platform JVM providers knowledge of how to enumerate those >> ports. >> Application writers would provide a plugin using the SPI that >> would codify >> those devices into named entities that they are interested in. >> >> public interface HardwarePort { >> public String getName(); >> public String getHardwareID(); >> public String getManufacturer(); >> public List getCapabilities(); >> public Object getImplementation(); >> } >> >> public interface PortCapability { >> public String getDescription(); >> public CapabilityId getIdentifier(); >> } >> >> public enum CapabilityId { >> INPUT, // Can receive input >> OUTPUT, // Can send output >> ASYNCHRONOUS, // Can send and receive at the same time >> SYNCHRONOUS, // No synchronous I/O >> ADDRESSABLE // Port has an address associated >> } >> >> Then, you might imagine that the enumerated capabilities had a >> standardized/specified interface that you'd find implemented on >> ports that >> had such capabilities. >> >> The getImplementation() method would return the implementation class >> provided by the JVM provider that had all of the interfaces tied >> to it. >> >> These are just some quick thoughts, pick away at them. >> >> I am very interested in getting a new comm api in place which can >> provide >> the ability for all USB connected devices to have drivers provided >> as 100% >> java for all non-timing critical types of device interfaces. >> >> The JVM provider should have an SPI to write to which will enable >> them to >> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >> something >> that we can talk 100% java to. >> >> That's my big desire. Starting with something simple which gives >> a good >> start in that direction would be great! > > That was exactly my wish too. > > The point people brought up was: > 1) It's too complex. > 2) What does it solve? > > In both facts they are right. It'll take a *long* time to plan such > a thing > right but if it works you have a product. Anyway, I'd like to join. ;) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Jul 22 11:55:23 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 22 Jul 2006 14:55:23 -0300 Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: <44C2668B.5080703@gmail.com> Joachim Buechse escribi?: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. > > It is clear that javax.comm can never provide a way to talk to all > USB devices, simply because some USB devices have several endpoints. > But it could provide a means of talking to devices that function as a > bidirectional-pipe (ie any USB to serial bridge). > > Regards, > Joachim Hi, About USB, why do not we contact the guys that make a library to support USB under Java from Linux? I think there is all ready an JSR for USB access, what we could do to this JSR is help to implement Usb access from other OSes. Regards, Manuel > > On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > >> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>> Pascal S. de Kloe wrote: >>>>>> I am also not sure if >>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>> single >>>>>> port. >>>>> I think the API should hide low-level details like devicefiles. >>>> Not all ports have device files. It's long been my goal to add >>>> support >>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>> servers, for example integrating RFC2217. This means that the >>>> port name >>>> is some combination of an IP address and TCP port number. >>>> Nothing in >>>> /dev. >>> What I think would make the most sense is a simple "device" >>> enumeration >>> Server Provider Interface that would bring port objects into the >>> JVM based >>> on the platform JVM providers knowledge of how to enumerate those >>> ports. >>> Application writers would provide a plugin using the SPI that >>> would codify >>> those devices into named entities that they are interested in. >>> >>> public interface HardwarePort { >>> public String getName(); >>> public String getHardwareID(); >>> public String getManufacturer(); >>> public List getCapabilities(); >>> public Object getImplementation(); >>> } >>> >>> public interface PortCapability { >>> public String getDescription(); >>> public CapabilityId getIdentifier(); >>> } >>> >>> public enum CapabilityId { >>> INPUT, // Can receive input >>> OUTPUT, // Can send output >>> ASYNCHRONOUS, // Can send and receive at the same time >>> SYNCHRONOUS, // No synchronous I/O >>> ADDRESSABLE // Port has an address associated >>> } >>> >>> Then, you might imagine that the enumerated capabilities had a >>> standardized/specified interface that you'd find implemented on >>> ports that >>> had such capabilities. >>> >>> The getImplementation() method would return the implementation class >>> provided by the JVM provider that had all of the interfaces tied >>> to it. >>> >>> These are just some quick thoughts, pick away at them. >>> >>> I am very interested in getting a new comm api in place which can >>> provide >>> the ability for all USB connected devices to have drivers provided >>> as 100% >>> java for all non-timing critical types of device interfaces. >>> >>> The JVM provider should have an SPI to write to which will enable >>> them to >>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>> something >>> that we can talk 100% java to. >>> >>> That's my big desire. Starting with something simple which gives >>> a good >>> start in that direction would be great! >> That was exactly my wish too. >> >> The point people brought up was: >> 1) It's too complex. >> 2) What does it solve? >> >> In both facts they are right. It'll take a *long* time to plan such >> a thing >> right but if it works you have a product. Anyway, I'd like to join. ;) >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Sat Jul 22 11:58:00 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Sat, 22 Jul 2006 13:58:00 -0400 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> Message-ID: <41E45C85-4A22-4C5B-915F-62ED36BACCF2@sympatico.ca> A couple of questions: - what version are you using? - does this happen with the version in cvs? Andre On 22-Jul-06, at 13:37 , Joachim Buechse wrote: > I just discovered a strange error in RXTX on OSX. SerialDemo.java > manages to corrupt the event_info_structure by a simple > OpenPort,ClosePort - this could be in relation to the deadlock > problem that was reported recently. > > Could anyone try to reproduce this on Solaris or some other system > which is neither WIN32 nor Linux (ie which uses a drain thread). > > In SerialImp.c : RXTXPort(interruptEventLoop) > > Apparently the event_info_structure gets corrupted shortly after > > pthread_kill(index->drain_tid, SIGABRT); > > In particular, the index->closing flag gets overwritten by a pointer > value. > > > **** Adding the following debugging code: > > pthread_kill(index->drain_tid, SIGABRT); > sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ > usleep(50 * 1000); > sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > > **** gives me: > > 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 > > **** Modifying SerialImp.h : event_info_struct by moving the > prev*, next* pointers > > jmethodID checkMonitorThread; > struct event_info_struct *dummy, *dummy2; > fd_set rfds; > struct timeval tv_sleep; > int closing; > struct event_info_struct *next, *prev; > > *** (ie replacing their original position with dummys and moving them > *** behind the closing flag) results in this: > > 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 > > > *** I was not able to track down the problem. If anyone could check > wether this happens on other platforms as well, we may get closer to > a fix. > > Regards, > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Paul.Klissner at Sun.COM Sat Jul 22 12:19:41 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Sat, 22 Jul 2006 11:19:41 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: <44C26C3D.8020501@sun.com> Joachim Buechse wrote: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. > > It is clear that javax.comm can never provide a way to talk to all > USB devices, simply because some USB devices have several endpoints. > But it could provide a means of talking to devices that function as a > bidirectional-pipe (ie any USB to serial bridge). If the 'back end' driver could be java as well an .so then driver's could be written using javax.usb, which is available currently for Linux. Paul > > Regards, > Joachim > > On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > >> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>> Pascal S. de Kloe wrote: >>>>>> I am also not sure if >>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>> single >>>>>> port. >>>>> I think the API should hide low-level details like devicefiles. >>>> Not all ports have device files. It's long been my goal to add >>>> support >>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>> servers, for example integrating RFC2217. This means that the >>>> port name >>>> is some combination of an IP address and TCP port number. >>>> Nothing in >>>> /dev. >>> What I think would make the most sense is a simple "device" >>> enumeration >>> Server Provider Interface that would bring port objects into the >>> JVM based >>> on the platform JVM providers knowledge of how to enumerate those >>> ports. >>> Application writers would provide a plugin using the SPI that >>> would codify >>> those devices into named entities that they are interested in. >>> >>> public interface HardwarePort { >>> public String getName(); >>> public String getHardwareID(); >>> public String getManufacturer(); >>> public List getCapabilities(); >>> public Object getImplementation(); >>> } >>> >>> public interface PortCapability { >>> public String getDescription(); >>> public CapabilityId getIdentifier(); >>> } >>> >>> public enum CapabilityId { >>> INPUT, // Can receive input >>> OUTPUT, // Can send output >>> ASYNCHRONOUS, // Can send and receive at the same time >>> SYNCHRONOUS, // No synchronous I/O >>> ADDRESSABLE // Port has an address associated >>> } >>> >>> Then, you might imagine that the enumerated capabilities had a >>> standardized/specified interface that you'd find implemented on >>> ports that >>> had such capabilities. >>> >>> The getImplementation() method would return the implementation class >>> provided by the JVM provider that had all of the interfaces tied >>> to it. >>> >>> These are just some quick thoughts, pick away at them. >>> >>> I am very interested in getting a new comm api in place which can >>> provide >>> the ability for all USB connected devices to have drivers provided >>> as 100% >>> java for all non-timing critical types of device interfaces. >>> >>> The JVM provider should have an SPI to write to which will enable >>> them to >>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>> something >>> that we can talk 100% java to. >>> >>> That's my big desire. Starting with something simple which gives >>> a good >>> start in that direction would be great! >> That was exactly my wish too. >> >> The point people brought up was: >> 1) It's too complex. >> 2) What does it solve? >> >> In both facts they are right. It'll take a *long* time to plan such >> a thing >> right but if it works you have a product. Anyway, I'd like to join. ;) >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 22 12:48:15 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 20:48:15 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607221920.20096.pascal@quies.net> References: <200607221920.20096.pascal@quies.net> Message-ID: <200607222048.16215.pascal@quies.net> http://quies.net/communicationapi.jar Fixed a few typo's and it works on Linux i386. It should also work on Windows i386. The rest is missing libParallel or more... -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 6664 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060722/5fd7c1ce/CommunicationAPI-0340.bin From Paul.Klissner at Sun.COM Sat Jul 22 12:53:12 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Sat, 22 Jul 2006 11:53:12 -0700 Subject: [Rxtx] jcp and jsr (libusb, javax.usb) In-Reply-To: <44C2668B.5080703@gmail.com> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> <44C2668B.5080703@gmail.com> Message-ID: <44C27418.1090309@sun.com> Manuel Naranjo wrote: > Joachim Buechse escribi?: >> It seems that Gregg's suggestion could be implemented without >> changing the existing "user-level" API of javax.comm. Most of the >> information suggested for HardwarePort is not accessible from within >> the POSSIX-API but this is a different story. >> >> It is clear that javax.comm can never provide a way to talk to all >> USB devices, simply because some USB devices have several endpoints. >> But it could provide a means of talking to devices that function as a >> bidirectional-pipe (ie any USB to serial bridge). >> >> Regards, >> Joachim > > Hi, > About USB, why do not we contact the guys that make a library to support > USB under Java from Linux? > I think there is all ready an JSR for USB access, what we could do to this > JSR is help to implement Usb access from other OSes. JAVAX.USB --------- javax.usb already a SourceForge project. I was Sun's rep on the expert group for JSR-80, javax.usb. I lived and breathed it for a 1.5 yrs working with spec lead from IBM on it. It's for real and the linux implementation works (not sure about the Win32 port on sourceforge). IBM even created a porting layer to simplify porting it to other platforms by implementing in Java all of the numerous 'clerical' functions of the API in Java so that the porting layer is absolutely minimal. The hardest part is managing the hotpluggable device tree topology as objects, and depending on one's platform or coding skills probably wouldn't take more than a week or two to get right. LIBUSB 1.0 (*NOT* libusb 0.1.8) ---------- There is also the native C library libusb. libusb 0.1.8 is weak, but libusb 1.0 under development holds the promise of being an extrordinarily robust C API to access USB devices through, and could definitely use some help getting people to port it to other platforms. I've attached the proposed libusb 1.0 API header which Sun worked with Johannes on for months before he went off into oblivion. The API has stalled and a fire might need to be lit under Johannes or it might need to be forked to get it moving again, but the spec for 1.0 is awesome, and this puppy is ready to turn into something sweet with some fresh blood on it. And it is a really good technology to become aquainted with... hint hint. Both of those APIs are really excellent and hold great promise for the community and use of USB technology in general. One of my goals, now which competes for my time with other higher priority projects was to layer an implementation of javax.usb over libusb 1.0, so that javax.usb would follow libusb to any platform and only one port would be required. But since libusb 1.0 is moving slowly, largely because the current sourceforge gatekeeper for the project, Johannes Erdfelt's lack of energy and sparse communication, it might be faster to simply port javax.usb to Mac OS, Win, Solaris and BSD if some people could get behind those, unless someone want's to get behind making libusb happen. >>>> >>>> public enum CapabilityId { >>>> INPUT, // Can receive input >>>> OUTPUT, // Can send output >>>> ASYNCHRONOUS, // Can send and receive at the same time >>>> SYNCHRONOUS, // No synchronous I/O >>>> ADDRESSABLE // Port has an address associated >>>> } My understanding is that synchronous/asynchronous refers to the way the data is clocked. I think FULLDUPLEX/HALFDUPLEX is what the author meant, or needs to be added. Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: libusb.h Type: text/x-sun-h-file Size: 26696 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060722/4a43e034/libusb-0340.bin From pascal at quies.net Sat Jul 22 17:53:31 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 01:53:31 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> References: <44C252BF.6040404@cox.net> <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> Message-ID: <200607230153.32328.pascal@quies.net> Hi Joachim, I'm not getting it. How do you easily get a "stub method / flag"? Op zaterdag 22 juli 2006 19:17, schreef Joachim Buechse: > We could easily have a stub method / flag that allows you to > explicitly load the native library (via System.loadLibrary ie from > the java.library.path). In this case the "auto-extraction" would not > take place. > > On 22.07.2006, at 18:30, Gregg Wonderly wrote: > > Dr. Douglas Lyon wrote: > >> Hi All, > >> I like the idea of the native lib in a jar with other classes. > >> An alternative I did not know would work. > > > > I have several applications that run with a security policy. In these > > applications, native library loading will require an appropriate > > FilePermission > > that should be known about ahead of time. The current native library > > implementation will require the native library to be extracted from > > the jar and > > written to disk, requiring a FilePermission("...","write") for that > > file, and > > then will also require read access to load the library. I > > personally don't want > > to give write access to a JVM for a shared library which can > > provide a point of > > abuse by errant code. > > > > Gregg Wonderly > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat Jul 22 18:46:33 2006 From: jredman at ergotech.com (Jim Redman) Date: Sat, 22 Jul 2006 18:46:33 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44C26C3D.8020501@sun.com> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> <44C26C3D.8020501@sun.com> Message-ID: <44C2C6E9.8020408@ergotech.com> Paul, I think that you've already proposed a "pluggable" underlying architecture and I think that this might be better implemented there. If you need some more examples, I'd like to have a Bluetooth interface (with dynamic discovery). Jim Paul Klissner wrote: > Joachim Buechse wrote: >> It seems that Gregg's suggestion could be implemented without >> changing the existing "user-level" API of javax.comm. Most of the >> information suggested for HardwarePort is not accessible from within >> the POSSIX-API but this is a different story. >> >> It is clear that javax.comm can never provide a way to talk to all >> USB devices, simply because some USB devices have several endpoints. >> But it could provide a means of talking to devices that function as a >> bidirectional-pipe (ie any USB to serial bridge). > > If the 'back end' driver could be java as well an .so > then driver's could be written using javax.usb, which > is available currently for Linux. > > Paul > > > >> Regards, >> Joachim >> >> On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: >> >>> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>>> Pascal S. de Kloe wrote: >>>>>>> I am also not sure if >>>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>>> single >>>>>>> port. >>>>>> I think the API should hide low-level details like devicefiles. >>>>> Not all ports have device files. It's long been my goal to add >>>>> support >>>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>>> servers, for example integrating RFC2217. This means that the >>>>> port name >>>>> is some combination of an IP address and TCP port number. >>>>> Nothing in >>>>> /dev. >>>> What I think would make the most sense is a simple "device" >>>> enumeration >>>> Server Provider Interface that would bring port objects into the >>>> JVM based >>>> on the platform JVM providers knowledge of how to enumerate those >>>> ports. >>>> Application writers would provide a plugin using the SPI that >>>> would codify >>>> those devices into named entities that they are interested in. >>>> >>>> public interface HardwarePort { >>>> public String getName(); >>>> public String getHardwareID(); >>>> public String getManufacturer(); >>>> public List getCapabilities(); >>>> public Object getImplementation(); >>>> } >>>> >>>> public interface PortCapability { >>>> public String getDescription(); >>>> public CapabilityId getIdentifier(); >>>> } >>>> >>>> public enum CapabilityId { >>>> INPUT, // Can receive input >>>> OUTPUT, // Can send output >>>> ASYNCHRONOUS, // Can send and receive at the same time >>>> SYNCHRONOUS, // No synchronous I/O >>>> ADDRESSABLE // Port has an address associated >>>> } >>>> >>>> Then, you might imagine that the enumerated capabilities had a >>>> standardized/specified interface that you'd find implemented on >>>> ports that >>>> had such capabilities. >>>> >>>> The getImplementation() method would return the implementation class >>>> provided by the JVM provider that had all of the interfaces tied >>>> to it. >>>> >>>> These are just some quick thoughts, pick away at them. >>>> >>>> I am very interested in getting a new comm api in place which can >>>> provide >>>> the ability for all USB connected devices to have drivers provided >>>> as 100% >>>> java for all non-timing critical types of device interfaces. >>>> >>>> The JVM provider should have an SPI to write to which will enable >>>> them to >>>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>>> something >>>> that we can talk 100% java to. >>>> >>>> That's my big desire. Starting with something simple which gives >>>> a good >>>> start in that direction would be great! >>> That was exactly my wish too. >>> >>> The point people brought up was: >>> 1) It's too complex. >>> 2) What does it solve? >>> >>> In both facts they are right. It'll take a *long* time to plan such >>> a thing >>> right but if it works you have a product. Anyway, I'd like to join. ;) >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From lyon at docjava.com Sun Jul 23 04:27:22 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 06:27:22 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607222048.16215.pascal@quies.net> References: <200607221920.20096.pascal@quies.net> <200607222048.16215.pascal@quies.net> Message-ID: The Class.forName is a static method. Therefore myClass.forName Should be Class.forName and myClass becomes an unused parameter. - DL >http://quies.net/communicationapi.jar > >Fixed a few typo's and it works on Linux i386. It should also work on Windows >i386. The rest is missing libParallel or more... > > >Attachment converted: PowerBookHd:CommunicationAPI 1.java >(TEXT/ttxt) (001C1A15) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Jul 23 04:32:45 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 06:32:45 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607222048.16215.pascal@quies.net> References: <200607221920.20096.pascal@quies.net> <200607222048.16215.pascal@quies.net> Message-ID: Also, the is Java2 check does not check if you are running under jdk1.5 - DL >http://quies.net/communicationapi.jar > >Fixed a few typo's and it works on Linux i386. It should also work on Windows >i386. The rest is missing libParallel or more... > > >Attachment converted: PowerBookHd:CommunicationAPI 1.java >(TEXT/ttxt) (001C1A15) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Jul 23 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 06:54:12 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607221843.27765.pascal@quies.net> References: <44C252BF.6040404@cox.net> <200607221843.27765.pascal@quies.net> Message-ID: Hi All, Perhaps Java web start can address Gregg's concerns. The native libs are placed into a signed jar for distribution. As to the assertion that serial-port based programs need file io abilities, that seems true, to me. Particularly for /dev/ttyN type native libs or libs that use lock files. The question of how to obtain a signed application that is given file-io authority may be settled by using a signing technology. Even applets can be signed, to enable improved access to the file system. What else can we try? Any ideas? Thanks! - Doug >Op zaterdag 22 juli 2006 18:30, schreef Gregg Wonderly: >> Dr. Douglas Lyon wrote: >> > Hi All, >> > I like the idea of the native lib in a jar with other classes. >> > An alternative I did not know would work. >> >> I have several applications that run with a security policy. In these >> applications, native library loading will require an appropriate >> FilePermission that should be known about ahead of time. The current >> native library implementation will require the native library to be >> extracted from the jar and written to disk, requiring a >> FilePermission("...","write") for that file, and then will also require >> read access to load the library. I personally don't want to give write >> access to a JVM for a shared library which can provide a point of abuse by >> errant code. >> >> Gregg Wonderly > >That's indeed a pitty limitation. It creates a lot of possible exceptions too. > >On the other hand, any native lib passes the securiy model. Applications who >can access hardware ports can be expected to create files, right? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 04:57:33 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 12:57:33 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607222048.16215.pascal@quies.net> Message-ID: <200607231257.34284.pascal@quies.net> Op zondag 23 juli 2006 12:27, schreef Dr. Douglas Lyon: > The Class.forName is a static method. Therefore > myClass.forName Should be Class.forName and > myClass becomes an unused parameter. > - DL Thank you. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 6625 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060723/00f3b627/CommunicationAPI-0340.bin From pascal at quies.net Sun Jul 23 05:02:59 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 13:02:59 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607222048.16215.pascal@quies.net> Message-ID: <200607231302.59252.pascal@quies.net> Op zondag 23 juli 2006 12:32, schreef Dr. Douglas Lyon: > Also, the is Java2 check does not check if you are running under > jdk1.5 > - DL Could you please explain? The JDK 1.5 will pass the check just fine. From lyon at docjava.com Sun Jul 23 05:34:10 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 07:34:10 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607221854.13467.pascal@quies.net> References: <200607221506.07140.pascal@quies.net> <200607221854.13467.pascal@quies.net> Message-ID: Hi All, Please call me Doug (the Dr. is for the classroom). Thanks! - Doug >Hi Dr., > >We're both trying to do the same thing. > >The CommunicationAPI does not only look at the OS but it also indexes the >available hardware architectures and does not need OsUtils. Any Java 2 >runtime will do. > >The plan was to make a single JAR with the binaries for all supported >platforms, the RXTX gnu.io package and the javax.comm wrapers. > >A signed version would be nice. > >A few questions remain tough. Does anybody know how Sun uses the SunOS and >Solaris identifiers for the Java property os.name? > > > >Op zaterdag 22 juli 2006 16:06, schreef Dr. Douglas Lyon: >> Hi All, >> Here is how I have arranged my signed versions of the native >> binaries: >> http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/windows/native.j >>ar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/native.jar >> http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/linux/native.jar >> >> Then I do: >> public static URL getResourceUrl() throws MalformedURLException { >> String rxtxUrl = "http://show.docjava.com:8086/" + >> "book/cgij/code/jnlp/libs/rxtx/"; >> if (OsUtils.isLinux()) >> return new URL(rxtxUrl + "linux/native.jar"); >> if (OsUtils.isMacOs()) >> return new URL(rxtxUrl + "mac/native.jar"); >> if (OsUtils.isWindows()) >> return new URL(rxtxUrl + "windows/native.jar"); >> System.out.println("no automatic install supported for this >> platform. " + >> "Please e-mail lyon at docjava.com with a bug report"); >> return null; >> } >> >> My new-age NativeLibraryManger concept-thang allows you to >> write stuff like: >> >> /** >> * This method fixes the driver by beaming over >> * to the tmp directory a native.jar file. >> * The native.jar file is signed and its >> * native libs are beamed over to the user home directory >> * ~/.rxtx/
>> * Finally, the java.library.path is altered to include
>> * ~/.rxtx/ >> */ >> private static void fixDriver() { >> >> try { >> NativeLibraryManager.fixDriver(getResourceUrl(), >> NativeLibraryManager.mapLibraryName("rxtxSerial")); >> } catch (IOException e) { >> e.printStackTrace(); >> } >> } >> >> I do a lazy singleton design pattern: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public synchronized static RXTXCommDriver getInstance() { >> if (driver != null) return driver; >> if (!NativeLibraryManager.isLibInPath("rxtxSerial")) >> fixDriver(); >> if (NativeLibraryManager.isLibInPath("rxtxSerial")) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> } >> return driver; >> } >> >> I am at a cross-roads here, since a file-based distro might be preferable >> to a URL based distro. To make this really general, and to "remember" where >> the last version of a native library came from, I serialize a bean into >> user preferences >> The user can then store native libraries anywhere, remembering the location >> in the preferences. >> >> What is the general feeling about this? >> >> Thanks! >> - Doug >> >> > > Now, if you place the rxtx classes and native library in the same >> >> >> >> jar, do they both have to be in any specific place in order to be >> >> found? >> > >> >Answer: >> >> >The path to the libraries is in the form >> >> >of /native/rxtx/-/{libserial,libparallel} >> >> >so /native/rxtx/windows-i386/libserial would do. >> > >> >I'me looking for the various os.name and os.arch values right now. >> >_______________________________________________ >> >Rxtx mailing list >> >Rxtx at qbang.org >> >http://mailman.qbang.org/mailman/listinfo/rxtx > > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 06:12:33 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 14:12:33 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607221843.27765.pascal@quies.net> Message-ID: <200607231412.34078.pascal@quies.net> Op zondag 23 juli 2006 12:54, schreef Dr. Douglas Lyon: > Hi All, > Perhaps Java web start can address Gregg's concerns. > The native libs are placed into a signed jar for distribution. > As to the assertion that serial-port based programs need file io > abilities, that seems true, to me. Particularly for /dev/ttyN type > native libs or libs that use lock files. > The question of how to obtain a signed application that is given > file-io authority may be settled by using a signing technology. > > Even applets can be signed, to enable improved access to the file > system. > > What else can we try? Any ideas? It might be a good idea to use a more optimized version for youre networked applications. These native libraries are huge for some reason. Can you build a "downloader"? From lyon at docjava.com Sun Jul 23 06:46:43 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 08:46:43 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607231302.59252.pascal@quies.net> References: <200607222048.16215.pascal@quies.net> <200607231302.59252.pascal@quies.net> Message-ID: public static void main(String[] args) { System.out.println("isJava2="+System.getProperty("java.version")); } Prints out 1.5_06 on my system, but you seem to need the "1.2" to be present on the system...right? RXTX does work under 1.5, at least on my system. - DL >Op zondag 23 juli 2006 12:32, schreef Dr. Douglas Lyon: >> Also, the is Java2 check does not check if you are running under >> jdk1.5 >> - DL > >Could you please explain? >The JDK 1.5 will pass the check just fine. >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Jul 23 06:58:02 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 08:58:02 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607231412.34078.pascal@quies.net> References: <200607221843.27765.pascal@quies.net> <200607231412.34078.pascal@quies.net> Message-ID: Hi All, Yes, I do have a download, as to the question of "huge": ls -al native.jar -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar 28kbytes is not really huge, right? In fact, if you uncompress the jar, you get: -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so Which is almost 80kbytes, so the jar is 40% of the native libs size, and it is signed. At least on the Linux version, it is smaller. I did not check the other versions. And with java web start, the JNLP only downloads the native jar if it is new or changed. And it only downloads the native jar used for the target platform. Here is how the jnlp looks, FYI... addbk.JAddressBook.Main DocJava, Inc. I have been playing around with "eager" and "lazy" directives, but I can't really tell the difference. Cheers! - Doug >Op zondag 23 juli 2006 12:54, schreef Dr. Douglas Lyon: >> Hi All, >> Perhaps Java web start can address Gregg's concerns. >> The native libs are placed into a signed jar for distribution. >> As to the assertion that serial-port based programs need file io >> abilities, that seems true, to me. Particularly for /dev/ttyN type >> native libs or libs that use lock files. >> The question of how to obtain a signed application that is given >> file-io authority may be settled by using a signing technology. >> >> Even applets can be signed, to enable improved access to the file >> system. >> >> What else can we try? Any ideas? > >It might be a good idea to use a more optimized version for youre networked >applications. These native libraries are huge for some reason. >Can you build a "downloader"? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 07:53:54 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 15:53:54 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607231302.59252.pascal@quies.net> Message-ID: <200607231553.55088.pascal@quies.net> Op zondag 23 juli 2006 14:46, schreef Dr. Douglas Lyon: > public static void main(String[] args) { > System.out.println("isJava2="+System.getProperty("java.version")); > > } > Prints out 1.5_06 on my system, but you seem to need the "1.2" to be > present on the system...right? if (System.getProperty("java.version").compareTo("1.2") < 0) throw new Error("RXTX requires a Java 2 platform."); The line requires a version string of "1.2" or higher. Sun decided to name all versions since 1.2 as Java 2. (That is why there is this 2 in J2SE.) The error should never happen anyway if you compile the code with the -target 1.2 flag. From pascal at quies.net Sun Jul 23 07:55:52 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 15:55:52 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607231412.34078.pascal@quies.net> Message-ID: <200607231555.52419.pascal@quies.net> Op zondag 23 juli 2006 14:58, schreef Dr. Douglas Lyon: > Hi All, > Yes, I do have a download, as to the question of "huge": > ls -al native.jar > -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar > 28kbytes is not really huge, right? > In fact, if you uncompress the jar, you get: > -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so > -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so > Which is almost 80kbytes, so the jar is 40% of the native libs size, and > it is signed. > At least on the Linux version, it is smaller. I did not check the > other versions. > > And with java web start, the JNLP only downloads the native jar if it is > new or changed. > And it only downloads the native jar used for the target platform. > > Here is how the jnlp looks, FYI... > codebase="http://show.docjava.com:8086/book/cgij/code/jnlp/"> > > addbk.JAddressBook.Main > DocJava, Inc. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have been playing around with "eager" and "lazy" directives, > but I can't really tell the difference. > > Cheers! > - Doug That is a nice sollution. Is there a tag for the architecture too becouse now you assume i386 and that is of course not necesairy true. From joachim at buechse.de Sun Jul 23 11:17:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 23 Jul 2006 19:17:29 +0200 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <41E45C85-4A22-4C5B-915F-62ED36BACCF2@sympatico.ca> References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> <41E45C85-4A22-4C5B-915F-62ED36BACCF2@sympatico.ca> Message-ID: <0B7FC525-4C71-49E8-B652-CCF6C67B4A58@buechse.de> This happens with the versions in CVS (2.07+ and 2.17+). On 22.07.2006, at 19:58, Andr?-John Mas wrote: > A couple of questions: > - what version are you using? > - does this happen with the version in cvs? > > Andre > > On 22-Jul-06, at 13:37 , Joachim Buechse wrote: > >> I just discovered a strange error in RXTX on OSX. SerialDemo.java >> manages to corrupt the event_info_structure by a simple >> OpenPort,ClosePort - this could be in relation to the deadlock >> problem that was reported recently. >> >> Could anyone try to reproduce this on Solaris or some other system >> which is neither WIN32 nor Linux (ie which uses a drain thread). >> >> In SerialImp.c : RXTXPort(interruptEventLoop) >> >> Apparently the event_info_structure gets corrupted shortly after >> >> pthread_kill(index->drain_tid, SIGABRT); >> >> In particular, the index->closing flag gets overwritten by a pointer >> value. >> >> >> **** Adding the following debugging code: >> >> pthread_kill(index->drain_tid, SIGABRT); >> sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i >> \n", index->fd, index, index->closing ); >> report( message ); >> /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ >> usleep(50 * 1000); >> sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i >> \n", index->fd, index, index->closing ); >> report( message ); >> >> **** gives me: >> >> 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 >> drain_loop: received EINTR------------------ drain_loop exiting >> --------------------- >> entering check_tiocmget_changes >> leaving check_tiocmget_changes >> port_has_changed_fionread: change is 0 >> eventLoop: got interrupt >> 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 >> >> **** Modifying SerialImp.h : event_info_struct by moving the >> prev*, next* pointers >> >> jmethodID checkMonitorThread; >> struct event_info_struct *dummy, *dummy2; >> fd_set rfds; >> struct timeval tv_sleep; >> int closing; >> struct event_info_struct *next, *prev; >> >> *** (ie replacing their original position with dummys and moving them >> *** behind the closing flag) results in this: >> >> 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 >> drain_loop: received EINTR------------------ drain_loop exiting >> --------------------- >> entering check_tiocmget_changes >> leaving check_tiocmget_changes >> port_has_changed_fionread: change is 0 >> eventLoop: got interrupt >> 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 >> >> >> *** I was not able to track down the problem. If anyone could check >> wether this happens on other platforms as well, we may get closer to >> a fix. >> >> Regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Sun Jul 23 11:44:48 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 23 Jul 2006 19:44:48 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607230153.32328.pascal@quies.net> References: <44C252BF.6040404@cox.net> <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> <200607230153.32328.pascal@quies.net> Message-ID: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> Gregg's concern was, that extracting the library from the jar and loading it via System.load needs file access privileges. To solve this concern, all that's required is a static method/flag that triggers loading via System.loadLibrary instead (of course, then he needs to make sure, that the library is on the java.library.path). This could also be handled via a system property of course. Regards, Joachim On 23.07.2006, at 01:53, Pascal S. de Kloe wrote: > Hi Joachim, > > I'm not getting it. > How do you easily get a "stub method / flag"? > > > Op zaterdag 22 juli 2006 19:17, schreef Joachim Buechse: >> We could easily have a stub method / flag that allows you to >> explicitly load the native library (via System.loadLibrary ie from >> the java.library.path). In this case the "auto-extraction" would not >> take place. >> >> On 22.07.2006, at 18:30, Gregg Wonderly wrote: >>> Dr. Douglas Lyon wrote: >>>> Hi All, >>>> I like the idea of the native lib in a jar with other classes. >>>> An alternative I did not know would work. >>> >>> I have several applications that run with a security policy. In >>> these >>> applications, native library loading will require an appropriate >>> FilePermission >>> that should be known about ahead of time. The current native >>> library >>> implementation will require the native library to be extracted from >>> the jar and >>> written to disk, requiring a FilePermission("...","write") for that >>> file, and >>> then will also require read access to load the library. I >>> personally don't want >>> to give write access to a JVM for a shared library which can >>> provide a point of >>> abuse by errant code. >>> >>> Gregg Wonderly >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 13:34:17 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 21:34:17 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> References: <200607230153.32328.pascal@quies.net> <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> Message-ID: <200607232134.17451.pascal@quies.net> Aaah, the penny drops. I was reading it as the stub method _root_ flag like using the root of a jar as a context for java.library.path. Thanks for explaining. :) I'll build it right away. Op zondag 23 juli 2006 19:44, schreef Joachim Buechse: > Gregg's concern was, that extracting the library from the jar and > loading it via System.load needs file access privileges. To solve > this concern, all that's required is a static method/flag that > triggers loading via System.loadLibrary instead (of course, then he > needs to make sure, that the library is on the java.library.path). > This could also be handled via a system property of course. > > Regards, > Joachim > > On 23.07.2006, at 01:53, Pascal S. de Kloe wrote: > > Hi Joachim, > > > > I'm not getting it. > > How do you easily get a "stub method / flag"? > > > > Op zaterdag 22 juli 2006 19:17, schreef Joachim Buechse: > >> We could easily have a stub method / flag that allows you to > >> explicitly load the native library (via System.loadLibrary ie from > >> the java.library.path). In this case the "auto-extraction" would not > >> take place. > >> > >> On 22.07.2006, at 18:30, Gregg Wonderly wrote: > >>> Dr. Douglas Lyon wrote: > >>>> Hi All, > >>>> I like the idea of the native lib in a jar with other classes. > >>>> An alternative I did not know would work. > >>> > >>> I have several applications that run with a security policy. In > >>> these > >>> applications, native library loading will require an appropriate > >>> FilePermission > >>> that should be known about ahead of time. The current native > >>> library > >>> implementation will require the native library to be extracted from > >>> the jar and > >>> written to disk, requiring a FilePermission("...","write") for that > >>> file, and > >>> then will also require read access to load the library. I > >>> personally don't want > >>> to give write access to a JVM for a shared library which can > >>> provide a point of > >>> abuse by errant code. > >>> > >>> Gregg Wonderly > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 18:10:45 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 02:10:45 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607232134.17451.pascal@quies.net> References: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> <200607232134.17451.pascal@quies.net> Message-ID: <200607240210.45992.pascal@quies.net> Hello gentleman, The CommunicationAPI class / utility is almost ready. Could you please have a final look and give your opinion? Does anybody know how the SunOS and the Solaris os.name is used? Sun uses just sparc as the description for os.arch. Is it safe to use the 32-bit binaries? @Gregg You can extract the necessary libraries during the installation with the extractNativeLibraries method to the application directory so they get loaded automatically. Is that good enough? @Trent Would you include this class afther any possible comments in the distribution? -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 10884 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060723/d2e99122/CommunicationAPI-0339.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: PlatformNotSupportedException.java Type: text/x-java Size: 1621 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060723/d2e99122/PlatformNotSupportedException-0339.bin From lyon at docjava.com Sun Jul 23 18:14:08 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 20:14:08 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607231555.52419.pascal@quies.net> References: <200607231412.34078.pascal@quies.net> <200607231555.52419.pascal@quies.net> Message-ID: Hi All, The present JNLP distro that I use: > > >> >> > Works for Macs using G3 and G4's. I have not tested this with an i386 mac, as I do not have one. And it only works with i386 based linux... As far as architecture goes: Allows for a chip arch, and this might address your question. The real bottleneck is that you need one of everything to test a deployment, or you have to know a bunch of people (like on this list!) to do a proper test. Cheers! - Doug >Op zondag 23 juli 2006 14:58, schreef Dr. Douglas Lyon: >> Hi All, >> Yes, I do have a download, as to the question of "huge": >> ls -al native.jar >> -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar >> 28kbytes is not really huge, right? >> In fact, if you uncompress the jar, you get: >> -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so >> -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so >> Which is almost 80kbytes, so the jar is 40% of the native libs size, and >> it is signed. >> At least on the Linux version, it is smaller. I did not check the >> other versions. >> >> And with java web start, the JNLP only downloads the native jar if it is >> new or changed. >> And it only downloads the native jar used for the target platform. >> >> Here is how the jnlp looks, FYI... >> > codebase="http://show.docjava.com:8086/book/cgij/code/jnlp/"> >> >> addbk.JAddressBook.Main >> DocJava, Inc. >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > >> >> > > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> I have been playing around with "eager" and "lazy" directives, >> but I can't really tell the difference. >> >> Cheers! >> - Doug > >That is a nice sollution. > >Is there a tag for the architecture too becouse now you assume i386 and that >is of course not necesairy true. >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Sun Jul 23 10:38:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 23 Jul 2006 11:38:50 -0500 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607221843.27765.pascal@quies.net> References: <44C252BF.6040404@cox.net> <200607221843.27765.pascal@quies.net> Message-ID: <44C3A61A.3060706@cox.net> Pascal S. de Kloe wrote: > Op zaterdag 22 juli 2006 18:30, schreef Gregg Wonderly: >>I have several applications that run with a security policy. In these >>applications, native library loading will require an appropriate >>FilePermission that should be known about ahead of time. The current >>native library implementation will require the native library to be >>extracted from the jar and written to disk, requiring a >>FilePermission("...","write") for that file, and then will also require >>read access to load the library. I personally don't want to give write >>access to a JVM for a shared library which can provide a point of abuse by >>errant code. > That's indeed a pitty limitation. It creates a lot of possible exceptions too. > > On the other hand, any native lib passes the securiy model. Applications who > can access hardware ports can be expected to create files, right? The use of an appropriate security policy is a deployment time configuration. There needs to be appropriate limits that confine the software to its intended tasks. Gregg Wonderly From gergg at cox.net Sun Jul 23 10:56:39 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 23 Jul 2006 11:56:39 -0500 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607221920.20096.pascal@quies.net> <200607222048.16215.pascal@quies.net> Message-ID: <44C3AA47.4060003@cox.net> Dr. Douglas Lyon wrote: > The Class.forName is a static method. Therefore > myClass.forName Should be Class.forName and > myClass becomes an unused parameter. Or better yet, make that parameter a context classloader and call Class.forName( classname, classloader); so that the location of the codebase for loading classes can be separate from the applications classpath. Gregg Wonderly From tjarvi at qbang.org Sun Jul 23 20:26:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 20:26:04 -0600 (MDT) Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: I do not see a point of having CommAPI do much more than basic termios interfaces and possibly parallel ports. The kernels can deliver that interface just fine for USB and other types. One problem with the current implementation for USB and IrDA is hotplug. There is a HAL daemon that can send connect and disconnect events which should probably be added to a new API. Sun is also working on a HAL port for Solaris. It is hackish but I saw at the Linux symposium that it will be getting attention and improving. The point being that these events could be included not that HAL is the end of all problems. It would appear to me that anything further in USB space should be done with the/a USB API to avoid duplication of efforts. USB is only one of many low level options for termios interfaces. On Sat, 22 Jul 2006, Joachim Buechse wrote: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. > > It is clear that javax.comm can never provide a way to talk to all > USB devices, simply because some USB devices have several endpoints. > But it could provide a means of talking to devices that function as a > bidirectional-pipe (ie any USB to serial bridge). > > Regards, > Joachim > > On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > >> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>> Pascal S. de Kloe wrote: >>>>>> I am also not sure if >>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>> single >>>>>> port. >>>>> >>>>> I think the API should hide low-level details like devicefiles. >>>> >>>> Not all ports have device files. It's long been my goal to add >>>> support >>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>> servers, for example integrating RFC2217. This means that the >>>> port name >>>> is some combination of an IP address and TCP port number. >>>> Nothing in >>>> /dev. >>> >>> What I think would make the most sense is a simple "device" >>> enumeration >>> Server Provider Interface that would bring port objects into the >>> JVM based >>> on the platform JVM providers knowledge of how to enumerate those >>> ports. >>> Application writers would provide a plugin using the SPI that >>> would codify >>> those devices into named entities that they are interested in. >>> >>> public interface HardwarePort { >>> public String getName(); >>> public String getHardwareID(); >>> public String getManufacturer(); >>> public List getCapabilities(); >>> public Object getImplementation(); >>> } >>> >>> public interface PortCapability { >>> public String getDescription(); >>> public CapabilityId getIdentifier(); >>> } >>> >>> public enum CapabilityId { >>> INPUT, // Can receive input >>> OUTPUT, // Can send output >>> ASYNCHRONOUS, // Can send and receive at the same time >>> SYNCHRONOUS, // No synchronous I/O >>> ADDRESSABLE // Port has an address associated >>> } >>> >>> Then, you might imagine that the enumerated capabilities had a >>> standardized/specified interface that you'd find implemented on >>> ports that >>> had such capabilities. >>> >>> The getImplementation() method would return the implementation class >>> provided by the JVM provider that had all of the interfaces tied >>> to it. >>> >>> These are just some quick thoughts, pick away at them. >>> >>> I am very interested in getting a new comm api in place which can >>> provide >>> the ability for all USB connected devices to have drivers provided >>> as 100% >>> java for all non-timing critical types of device interfaces. >>> >>> The JVM provider should have an SPI to write to which will enable >>> them to >>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>> something >>> that we can talk 100% java to. >>> >>> That's my big desire. Starting with something simple which gives >>> a good >>> start in that direction would be great! >> >> That was exactly my wish too. >> >> The point people brought up was: >> 1) It's too complex. >> 2) What does it solve? >> >> In both facts they are right. It'll take a *long* time to plan such >> a thing >> right but if it works you have a product. Anyway, I'd like to join. ;) >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jul 23 20:31:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 20:31:45 -0600 (MDT) Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607231412.34078.pascal@quies.net> References: <200607221843.27765.pascal@quies.net> <200607231412.34078.pascal@quies.net> Message-ID: On Sun, 23 Jul 2006, Pascal S. de Kloe wrote: > Op zondag 23 juli 2006 12:54, schreef Dr. Douglas Lyon: >> Hi All, >> Perhaps Java web start can address Gregg's concerns. >> The native libs are placed into a signed jar for distribution. >> As to the assertion that serial-port based programs need file io >> abilities, that seems true, to me. Particularly for /dev/ttyN type >> native libs or libs that use lock files. >> The question of how to obtain a signed application that is given >> file-io authority may be settled by using a signing technology. >> >> Even applets can be signed, to enable improved access to the file >> system. >> >> What else can we try? Any ideas? > > It might be a good idea to use a more optimized version for youre networked > applications. These native libraries are huge for some reason. > Can you build a "downloader"? It may be that the binaries are not stripped. "strip librtxserial.so" for instance. That will remove the symbols which are not usually needed in production. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jul 23 20:49:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 20:49:16 -0600 (MDT) Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607240210.45992.pascal@quies.net> References: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> <200607232134.17451.pascal@quies.net> <200607240210.45992.pascal@quies.net> Message-ID: On Mon, 24 Jul 2006, Pascal S. de Kloe wrote: > Hello gentleman, > > The CommunicationAPI class / utility is almost ready. > Could you please have a final look and give your opinion? > > > Does anybody know how the SunOS and the Solaris os.name is used? > > Sun uses just sparc as the description for os.arch. Is it safe to use the > 32-bit binaries? > > > > @Gregg > You can extract the necessary libraries during the installation with the > extractNativeLibraries method to the application directory so they get loaded > automatically. Is that good enough? > > @Trent > Would you include this class afther any possible comments in the distribution? > Hi Pascal, It would appear to me that this is a tool for using the API, not an API. So perhaps the classname is not the best choice. The class also has a main which would not make a great deal of sense to include in the library to me. It would make a nice example for the contrib directory or a new utility directory though. Documentation of its availability in the main document could make it stand out from the other contrib files. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jul 23 21:27:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 21:27:48 -0600 (MDT) Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> Message-ID: On Sat, 22 Jul 2006, Joachim Buechse wrote: > I just discovered a strange error in RXTX on OSX. SerialDemo.java > manages to corrupt the event_info_structure by a simple > OpenPort,ClosePort - this could be in relation to the deadlock > problem that was reported recently. > > Could anyone try to reproduce this on Solaris or some other system > which is neither WIN32 nor Linux (ie which uses a drain thread). > > In SerialImp.c : RXTXPort(interruptEventLoop) > > Apparently the event_info_structure gets corrupted shortly after > > pthread_kill(index->drain_tid, SIGABRT); > > In particular, the index->closing flag gets overwritten by a pointer > value. > > > **** Adding the following debugging code: > > pthread_kill(index->drain_tid, SIGABRT); > sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ > usleep(50 * 1000); > sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > > **** gives me: > > 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 > > **** Modifying SerialImp.h : event_info_struct by moving the > prev*, next* pointers > > jmethodID checkMonitorThread; > struct event_info_struct *dummy, *dummy2; > fd_set rfds; > struct timeval tv_sleep; > int closing; > struct event_info_struct *next, *prev; > > *** (ie replacing their original position with dummys and moving them > *** behind the closing flag) results in this: > > 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 > > > *** I was not able to track down the problem. If anyone could check > wether this happens on other platforms as well, we may get closer to > a fix. > Hi Joachim Interesting. I did run many tests with that code on may OSs. To be fair, the tests are just starting to get into good shape again. I'm still tagging releases with a bit of feel and not enough process. I'll look at this some more tomorrow night. The SIGABRT was added recently as part of the close speedups. Thats from memory. I can provide the exact patch that introduced that tomorrow. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jul 23 22:22:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 22:22:26 -0600 (MDT) Subject: [Rxtx] clarification Message-ID: It should be clear that doug is the maintainer of rxtx.org now. I'll be running around very fast trying to make that easier for him but if you want something in rxtx, it is doug that does that. There are some things doug isnt very good at. He needs some help there. If he asks others for their opinion, thats his call. If he asks others for help, thats his call. This was setup to help the community. I hope everyone makes good use of it as they are now. I'm very happy with what I see but I want to make it clear that nobody should be asking me to be in rxtx. I have interests but they may not always be yours. -- Trent Jarvi tjarvi at qbang.org From guille at sms.nl Mon Jul 24 00:32:26 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Mon, 24 Jul 2006 08:32:26 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <7.0.1.0.0.20060724082455.038aa518@sms.nl> At 18:31 20/07/2006, Trent Jarvi wrote: > > PROJECT SCOPE: > > ------------- > > > > Also, we should think carefully about what the scope of > > this project would be. Should it be javax."comm" which > > handles both serial and parallel (is parallel going by the > > wayside). Should it be split into two project: > > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > > > > Should we differentiate between single-ended serial > > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > > quasi-multidrop and full multidrop busses such as > > EIA422, EIA432 and EIA485? If we really were to > > add I2C support to the API, we'd have to delve into > > the semantics more, because there could be some > > implicit decoding of the bus the API users would > > want to see. > > > >Hi Paul > >The way RXTX works, which is a fair representation of the people using the >API, is complete support for RIA232, minimal support for IEEE1284. From >what I understand, Sun was going along the same lines. If we combined >both projects, we would have half a parallel port implementation. I see >maybe 4 requests for features not in the parallel support a year. > >The other protocols should not be limited by a JSR which is going to be >focused upon serial port interests. The IEA485 hacks in RXTX along with >I2C and Raw should _not_ be considered a strong basis for extending the >API to cover these protocols. If people want to do real implementations, >they should not face a 'standard' which wasnt really focused upon their >interests. I think we understand the parallel port issues fairly well but >have not implemented many features and I don't know if we would. I agree with all of this. API requirements for I2C, SPI, etc. are very different from those for RS232/485/422. Our embedded Java platform has APIs for all of these and more and they don't share a lot apart from the fact that they all use Input/OutputStreams (and in the case of SPI you still need to cater with the fact that every time you want to read you must also write to the device.) If I was to design javax.comm from scratch, I think I would focus on serial ports exclusively (== whatever the underlying OS represents as serial ports). Even parallel is a bit out of place IMHO, although I understand it needs to stay for backwards compatibility. >So a versatile API is favorable but I do not think we have the proper >community to represent much more than Serial. Yes, I think the same. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From joachim at buechse.de Mon Jul 24 01:33:14 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 24 Jul 2006 09:33:14 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607231412.34078.pascal@quies.net> <200607231555.52419.pascal@quies.net> Message-ID: <106C7BEC-EC26-4A05-8E94-61E2C9F2A54E@buechse.de> Or you put your project on Sourceforge and use this: http://sourceforge.net/docs/compile_farm#hosts On 24.07.2006, at 02:14, Dr. Douglas Lyon wrote: > Hi All, > The present JNLP distro that I use: >>> >>> >> download="eager" /> >>> >> > > Works for Macs using G3 and G4's. I have not tested > this with an i386 mac, as I do not have one. And it only works > with i386 based linux... > > As far as architecture goes: > > > > Allows for a chip arch, and this might address your question. > > The real bottleneck is that you need one of everything to test a > deployment, > or you have to know a bunch of people (like on this list!) to do a > proper test. > > Cheers! > - Doug > > >> Op zondag 23 juli 2006 14:58, schreef Dr. Douglas Lyon: >>> Hi All, >>> Yes, I do have a download, as to the question of "huge": >>> ls -al native.jar >>> -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar >>> 28kbytes is not really huge, right? >>> In fact, if you uncompress the jar, you get: >>> -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so >>> -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so >>> Which is almost 80kbytes, so the jar is 40% of the native libs >>> size, and >>> it is signed. >>> At least on the Linux version, it is smaller. I did not check the >>> other versions. >>> >>> And with java web start, the JNLP only downloads the native jar >>> if it is >>> new or changed. >>> And it only downloads the native jar used for the target platform. >>> >>> Here is how the jnlp looks, FYI... >>> >> codebase="http://show.docjava.com:8086/book/cgij/code/ >>> jnlp/"> >>> >>> addbk.JAddressBook.Main >>> DocJava, Inc. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> download="eager" /> >>> >>> >>> >>> >>> >> download="lazy" /> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I have been playing around with "eager" and "lazy" directives, >>> but I can't really tell the difference. >>> >>> Cheers! >>> - Doug >> >> That is a nice sollution. >> >> Is there a tag for the architecture too becouse now you assume >> i386 and that >> is of course not necesairy true. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jul 24 02:13:15 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 24 Jul 2006 10:13:15 +0200 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> Message-ID: <939306BB-2AEE-4D20-906E-9A9B40C76125@buechse.de> The pthread_kill is followed by a sleep. When the sleep returns the structure is damaged. I did not find the source that overwrites the closing field - it is correctly set by the exiting drain thread. But something overwrites it afterwards. I currently believe that this existed for some time but was never seen because the previous versions did not rely on the structure to be in good shape when tearing down connections. However I may be completely wrong and it is an OSX problem. To help me find the source, it would be nice to get some indications what the 2 debug lines I suggested return on other platforms. Joachim On 24.07.2006, at 05:27, Trent Jarvi wrote: > On Sat, 22 Jul 2006, Joachim Buechse wrote: > >> I just discovered a strange error in RXTX on OSX. SerialDemo.java >> manages to corrupt the event_info_structure by a simple >> OpenPort,ClosePort - this could be in relation to the deadlock >> problem that was reported recently. >> >> Could anyone try to reproduce this on Solaris or some other system >> which is neither WIN32 nor Linux (ie which uses a drain thread). >> >> In SerialImp.c : RXTXPort(interruptEventLoop) >> >> Apparently the event_info_structure gets corrupted shortly after >> >> pthread_kill(index->drain_tid, SIGABRT); >> >> In particular, the index->closing flag gets overwritten by a pointer >> value. > > Hi Joachim > > Interesting. I did run many tests with that code on may OSs. To > be fair, > the tests are just starting to get into good shape again. I'm still > tagging releases with a bit of feel and not enough process. I'll > look at > this some more tomorrow night. > > The SIGABRT was added recently as part of the close speedups. > Thats from > memory. I can provide the exact patch that introduced that tomorrow. > > -- > Trent Jarvi > tjarvi at qbang.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Mon Jul 24 05:58:21 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 13:58:21 +0200 Subject: [Rxtx] =?iso-8859-1?q?NativeLibraryManager_-_A_general_solution_a?= =?iso-8859-1?q?n_to_old=09problem=2E?= In-Reply-To: <44C3AA47.4060003@cox.net> References: <44C3AA47.4060003@cox.net> Message-ID: <200607241358.21366.pascal@quies.net> Op zondag 23 juli 2006 18:56, schreef Gregg Wonderly: > Dr. Douglas Lyon wrote: > > The Class.forName is a static method. Therefore > > myClass.forName Should be Class.forName and > > myClass becomes an unused parameter. > > Or better yet, make that parameter a context classloader and call > > Class.forName( classname, classloader); > > so that the location of the codebase for loading classes can be separate > from the applications classpath. I agree. -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 10719 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060724/693f269d/CommunicationAPI-0339.bin From pascal at quies.net Mon Jul 24 06:05:53 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 14:05:53 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607240210.45992.pascal@quies.net> Message-ID: <200607241405.53456.pascal@quies.net> Op maandag 24 juli 2006 04:49, schreef Trent Jarvi: > > @Trent > > Would you include this class afther any possible comments in the > > distribution? > > Hi Pascal, > > It would appear to me that this is a tool for using the API, not an API. > So perhaps the classname is not the best choice. > > The class also has a main which would not make a great deal of sense to > include in the library to me. It would make a nice example for the > contrib directory or a new utility directory though. Documentation of its > availability in the main document could make it stand out from the other > contrib files. The name-change and the removal of main() would ofcourse be no problem. You really don't want to distribute binaries, huh? How can the developers of RXTX know whether it works on a machine they don't have? Anyway, I don't see anotherway to get a version of the extension "that just works" than to build my own distribution. :@ I also can't believe that nobody on this list has binaries for official supported platforms like Windows IA64 and Windows x86_64 unless the build fails on these platforms (which would be nice to know). http://java.sun.com/j2se/1.4.2/system-configurations.html http://java.sun.com/j2se/1.5.0/system-configurations.html From pascal at quies.net Mon Jul 24 06:08:45 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 14:08:45 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <106C7BEC-EC26-4A05-8E94-61E2C9F2A54E@buechse.de> References: <106C7BEC-EC26-4A05-8E94-61E2C9F2A54E@buechse.de> Message-ID: <200607241408.45956.pascal@quies.net> Op maandag 24 juli 2006 09:33, schreef Joachim Buechse: > Or you put your project on Sourceforge and use this: > > http://sourceforge.net/docs/compile_farm#hosts That's nice. :) I'll host a distribution on Sourceforge real soon. HP also has a such a facility for PA-RISC and IA64 architectures at http://www.testdrive.hp.com/ The other day I was thinking about building a big bittorrent with Qemu images for developers. The number of platforms seems impressive: http://qemu.org/status.html With each image compressed with bzip2 a clean installation of OpenBSD and FreeBSD and a Debian Woody + gmake + gcc for each Qemu platform will take about 1.5GB. From lyon at docjava.com Mon Jul 24 07:07:02 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 24 Jul 2006 09:07:02 -0400 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060724082455.038aa518@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: Hi All, There has been a lot of discussion regarding RS485. Let me see if I can summarize this, please correct me if I am wrong; I am deliberately ignoring connector and electrical issues, focusing, instead, on protocol and software issues. Also, I have never used RS485, and I don't know much about it. 1. Serial ports that claim RS232 are typically used in the data link layer of the OSI model of networking. Basically, this means that they work with a point-to-point protocol and are meant to connect two devices. 2. Within the RS232 standard there are framing bits (start and stop bits) and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. Thats' it. 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) you do it in software, not in the RS232 standard. 4. RS485 is different from RS232 in that it is in the Network Layer of the OSI model of networking. 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in a factory). RS-485 is similar to RS-422, but RS-422 allows just one driver with multiple receivers whereas RS-485 supports multiple drivers and receivers. 6. RS-485 is a serial bus with multiple nodes and thus must handle network link layer protocols. By using high-impedance receivers, you can have as many as 256 nodes. 7. The RS-485 can be implemented with RXTX in the core and a layer of software on top to handle media access control (MAC sublayer). There are also hardware converters. http://www.rs485.com/pconverters.html for example. However, some of these require software control. There is some support in the form of the Rs485.java class, in RXTX. 8. The RS-485 specification will add to the size of the JSR 9. Javax.comm specification, version 2.0 (the Real OLD version) says: This version of the Java communications API contains support for RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not mentioned. 10. DO people want to add RS485 to a new JSR? Would it make sense for the RS-485 people to speak up now? Please let me know if you think my summary is wrong. Thanks! - Doug >At 18:31 20/07/2006, Trent Jarvi wrote: >> > PROJECT SCOPE: >> > ------------- >> > >> > Also, we should think carefully about what the scope of >> > this project would be. Should it be javax."comm" which >> > handles both serial and parallel (is parallel going by the >> > wayside). Should it be split into two project: >> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >> > >> > Should we differentiate between single-ended serial >> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >> > quasi-multidrop and full multidrop busses such as >> > EIA422, EIA432 and EIA485? If we really were to >> > add I2C support to the API, we'd have to delve into >> > the semantics more, because there could be some >> > implicit decoding of the bus the API users would >> > want to see. >> > >> >>Hi Paul >> >>The way RXTX works, which is a fair representation of the people using the >>API, is complete support for RIA232, minimal support for IEEE1284. From >>what I understand, Sun was going along the same lines. If we combined >>both projects, we would have half a parallel port implementation. I see >>maybe 4 requests for features not in the parallel support a year. >> >>The other protocols should not be limited by a JSR which is going to be >>focused upon serial port interests. The IEA485 hacks in RXTX along with >>I2C and Raw should _not_ be considered a strong basis for extending the >>API to cover these protocols. If people want to do real implementations, >>they should not face a 'standard' which wasnt really focused upon their >>interests. I think we understand the parallel port issues fairly well but >>have not implemented many features and I don't know if we would. > >I agree with all of this. API requirements for I2C, SPI, etc. are very >different from those for RS232/485/422. Our embedded Java platform has >APIs for all of these and more and they don't share a lot apart from the >fact that they all use Input/OutputStreams (and in the case of SPI you >still need to cater with the fact that every time you want to read you >must also write to the device.) > >If I was to design javax.comm from scratch, I think I would focus on >serial ports exclusively (== whatever the underlying OS represents as >serial ports). Even parallel is a bit out of place IMHO, although I >understand it needs to stay for backwards compatibility. > > >>So a versatile API is favorable but I do not think we have the proper >>community to represent much more than Serial. > >Yes, I think the same. > >Guillermo >-- >Guillermo Rodriguez Garcia > >Snijder Micro Systems phone +31-493-351020 >G. Rodriguez Garcia fax +31-493-351530 >Visser 25 email guille at sms.nl >NL5751 BL Deurne >The Netherlands http://www.snijder.com > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Mon Jul 24 07:46:55 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Mon, 24 Jul 2006 10:46:55 -0300 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: <44C4CF4F.1080706@gmail.com> Doug: I do not think that RS485 is a must by now. I do think we must make a JSR to standarize a bit Serial Ports accessing. Maybe we can make a JSR just for serial ports, and then start trying with other kind of ports and make others JSR. Or try to expand our first JSR, but I trully do not know if that can be made. About other ports besides RS485, the others I2C, SPI, etc, run at a very low level, maybe too close to the processor for Java. I do not know if Java is fast enough to access this ports, even more as this ports depends directly from the architecture, the write once run every way of Java is somekind useless at this level, so I do not think this is suitable for us. Regards, Manuel > Hi All, > There has been a lot of discussion regarding RS485. > > Let me see if I can summarize this, please correct me if I am wrong; > I am deliberately ignoring connector and electrical issues, focusing, > instead, on protocol and software issues. Also, I have never used > RS485, and I don't know much about it. > > 1. Serial ports that claim RS232 are typically used in > the data link layer of the OSI model of networking. Basically, this means > that they work with a point-to-point protocol and are meant to connect two > devices. > > 2. Within the RS232 standard there are framing bits (start and stop bits) > and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. > Thats' it. > > 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) > you do it in software, not in the RS232 standard. > > 4. RS485 is different from RS232 in that it is in the Network Layer of > the OSI model of networking. > > 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > a factory). > RS-485 is similar to RS-422, but RS-422 allows just one driver with > multiple receivers whereas RS-485 supports multiple drivers and > receivers. > > 6. RS-485 is a serial bus with multiple nodes and thus must handle network > link layer protocols. By using high-impedance receivers, you can have > as many as 256 nodes. > > 7. The RS-485 can be implemented with RXTX in the core and a layer of software > on top to handle media access control (MAC sublayer). There are also > hardware converters. > http://www.rs485.com/pconverters.html for example. However, some of > these require software control. There is some support in the form of > the Rs485.java class, > in RXTX. > > 8. The RS-485 specification will add to the size of the JSR > > 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > This version of the Java communications API contains support for > RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > mentioned. > > 10. DO people want to add RS485 to a new JSR? > > Would it make sense for the RS-485 people to speak up now? > Please let me know if you think my summary is wrong. > > Thanks! > - Doug > > > > > > >> At 18:31 20/07/2006, Trent Jarvi wrote: >> >>> > PROJECT SCOPE: >>> > ------------- >>> > >>> > Also, we should think carefully about what the scope of >>> > this project would be. Should it be javax."comm" which >>> > handles both serial and parallel (is parallel going by the >>> > wayside). Should it be split into two project: >>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>> > >>> > Should we differentiate between single-ended serial >>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>> > quasi-multidrop and full multidrop busses such as >>> > EIA422, EIA432 and EIA485? If we really were to >>> > add I2C support to the API, we'd have to delve into >>> > the semantics more, because there could be some >>> > implicit decoding of the bus the API users would >>> > want to see. >>> > >>> >>> Hi Paul >>> >>> The way RXTX works, which is a fair representation of the people using the >>> API, is complete support for RIA232, minimal support for IEEE1284. From >>> what I understand, Sun was going along the same lines. If we combined >>> both projects, we would have half a parallel port implementation. I see >>> maybe 4 requests for features not in the parallel support a year. >>> >>> The other protocols should not be limited by a JSR which is going to be >>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>> I2C and Raw should _not_ be considered a strong basis for extending the >>> API to cover these protocols. If people want to do real implementations, >>> they should not face a 'standard' which wasnt really focused upon their >>> interests. I think we understand the parallel port issues fairly well but >>> have not implemented many features and I don't know if we would. >>> >> I agree with all of this. API requirements for I2C, SPI, etc. are very >> different from those for RS232/485/422. Our embedded Java platform has >> APIs for all of these and more and they don't share a lot apart from the >> fact that they all use Input/OutputStreams (and in the case of SPI you >> still need to cater with the fact that every time you want to read you >> must also write to the device.) >> >> If I was to design javax.comm from scratch, I think I would focus on >> serial ports exclusively (== whatever the underlying OS represents as >> serial ports). Even parallel is a bit out of place IMHO, although I >> understand it needs to stay for backwards compatibility. >> >> >> >>> So a versatile API is favorable but I do not think we have the proper >>> community to represent much more than Serial. >>> >> Yes, I think the same. >> >> Guillermo >> -- >> Guillermo Rodriguez Garcia >> >> Snijder Micro Systems phone +31-493-351020 >> G. Rodriguez Garcia fax +31-493-351530 >> Visser 25 email guille at sms.nl >> NL5751 BL Deurne >> The Netherlands http://www.snijder.com >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From gergg at cox.net Mon Jul 24 07:51:53 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 08:51:53 -0500 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607240210.45992.pascal@quies.net> References: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> <200607232134.17451.pascal@quies.net> <200607240210.45992.pascal@quies.net> Message-ID: <44C4D079.80609@cox.net> Pascal S. de Kloe wrote: > @Gregg > You can extract the necessary libraries during the installation with the > extractNativeLibraries method to the application directory so they get loaded > automatically. Is that good enough? If you start the JVM with -Djava.security.manager what permissions are required? Can you send me a policy that is applicable so that I can review what permissions are being required? Gregg Wonderly From gergg at cox.net Mon Jul 24 07:54:22 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 08:54:22 -0500 Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: <44C4D10E.50604@cox.net> Joachim Buechse wrote: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. Sorry for the late reply here. My intent was this. That there could be a low level port/device SPI that could be put in place once, and then overtime we could layer other APIs, including an updated javax.comm which would make use of this SPI. Gregg Wonderly From cmalan at lhar.co.za Mon Jul 24 08:04:01 2006 From: cmalan at lhar.co.za (Christo Malan) Date: Mon, 24 Jul 2006 16:04:01 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: <44C4D351.603@lhar.co.za> Hi I don't think RS-485 belong in rxtx, the scope of the spec is not wide enough as it only specify the electrical layer. Their is no data protocol recommended or defined. This mean that we have no idea when to sample for a bit, how long is a bit and how many bits before we can say new data is available. Christo Dr. Douglas Lyon wrote: > Hi All, > There has been a lot of discussion regarding RS485. > > Let me see if I can summarize this, please correct me if I am wrong; > I am deliberately ignoring connector and electrical issues, focusing, > instead, on protocol and software issues. Also, I have never used > RS485, and I don't know much about it. > > 1. Serial ports that claim RS232 are typically used in > the data link layer of the OSI model of networking. Basically, this means > that they work with a point-to-point protocol and are meant to connect two > devices. > > 2. Within the RS232 standard there are framing bits (start and stop bits) > and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. > Thats' it. > > 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) > you do it in software, not in the RS232 standard. > > 4. RS485 is different from RS232 in that it is in the Network Layer of > the OSI model of networking. > > 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > a factory). > RS-485 is similar to RS-422, but RS-422 allows just one driver with > multiple receivers whereas RS-485 supports multiple drivers and > receivers. > > 6. RS-485 is a serial bus with multiple nodes and thus must handle network > link layer protocols. By using high-impedance receivers, you can have > as many as 256 nodes. > > 7. The RS-485 can be implemented with RXTX in the core and a layer of software > on top to handle media access control (MAC sublayer). There are also > hardware converters. > http://www.rs485.com/pconverters.html for example. However, some of > these require software control. There is some support in the form of > the Rs485.java class, > in RXTX. > > 8. The RS-485 specification will add to the size of the JSR > > 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > This version of the Java communications API contains support for > RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > mentioned. > > 10. DO people want to add RS485 to a new JSR? > > Would it make sense for the RS-485 people to speak up now? > Please let me know if you think my summary is wrong. > > Thanks! > - Doug > > > > > > >> At 18:31 20/07/2006, Trent Jarvi wrote: >> >>> > PROJECT SCOPE: >>> > ------------- >>> > >>> > Also, we should think carefully about what the scope of >>> > this project would be. Should it be javax."comm" which >>> > handles both serial and parallel (is parallel going by the >>> > wayside). Should it be split into two project: >>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>> > >>> > Should we differentiate between single-ended serial >>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>> > quasi-multidrop and full multidrop busses such as >>> > EIA422, EIA432 and EIA485? If we really were to >>> > add I2C support to the API, we'd have to delve into >>> > the semantics more, because there could be some >>> > implicit decoding of the bus the API users would >>> > want to see. >>> > >>> >>> Hi Paul >>> >>> The way RXTX works, which is a fair representation of the people using the >>> API, is complete support for RIA232, minimal support for IEEE1284. From >>> what I understand, Sun was going along the same lines. If we combined >>> both projects, we would have half a parallel port implementation. I see >>> maybe 4 requests for features not in the parallel support a year. >>> >>> The other protocols should not be limited by a JSR which is going to be >>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>> I2C and Raw should _not_ be considered a strong basis for extending the >>> API to cover these protocols. If people want to do real implementations, >>> they should not face a 'standard' which wasnt really focused upon their >>> interests. I think we understand the parallel port issues fairly well but >>> have not implemented many features and I don't know if we would. >>> >> I agree with all of this. API requirements for I2C, SPI, etc. are very >> different from those for RS232/485/422. Our embedded Java platform has >> APIs for all of these and more and they don't share a lot apart from the >> fact that they all use Input/OutputStreams (and in the case of SPI you >> still need to cater with the fact that every time you want to read you >> must also write to the device.) >> >> If I was to design javax.comm from scratch, I think I would focus on >> serial ports exclusively (== whatever the underlying OS represents as >> serial ports). Even parallel is a bit out of place IMHO, although I >> understand it needs to stay for backwards compatibility. >> >> >> >>> So a versatile API is favorable but I do not think we have the proper >>> community to represent much more than Serial. >>> >> Yes, I think the same. >> >> Guillermo >> -- >> Guillermo Rodriguez Garcia >> >> Snijder Micro Systems phone +31-493-351020 >> G. Rodriguez Garcia fax +31-493-351530 >> Visser 25 email guille at sms.nl >> NL5751 BL Deurne >> The Netherlands http://www.snijder.com >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > From pascal at quies.net Mon Jul 24 08:19:03 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 16:19:03 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <44C4D079.80609@cox.net> References: <200607240210.45992.pascal@quies.net> <44C4D079.80609@cox.net> Message-ID: <200607241619.04053.pascal@quies.net> Op maandag 24 juli 2006 15:51, schreef Gregg Wonderly: > Pascal S. de Kloe wrote: > > @Gregg > > You can extract the necessary libraries during the installation with the > > extractNativeLibraries method to the application directory so they get > > loaded automatically. Is that good enough? > > If you start the JVM with -Djava.security.manager what permissions are > required? Can you send me a policy that is applicable so that I can review > what permissions are being required? Just look at the javadoc in CommunicationAPI.java for SecurityExceptions. ;) From gergg at cox.net Mon Jul 24 08:21:49 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 09:21:49 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4CF4F.1080706@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> Message-ID: <44C4D77D.5080200@cox.net> Manuel Francisco Naranjo wrote: > Doug: > I do not think that RS485 is a must by now. I do think we must make a > JSR to standarize a bit Serial Ports accessing. Maybe we can make a JSR > just for serial ports, and then start trying with other kind of ports > and make others JSR. Or try to expand our first JSR, but I trully do > not know if that can be made. I think that anyone aimed at the javax.comm space should be interested in creating a hardware access SPI first. This is the predominate stumbling block for java having access to various hardware devices. The more we can promote as a standard, the more we can expect consistency and availability! > About other ports besides RS485, the others I2C, SPI, etc, run at a very > low level, maybe too close to the processor for Java. SPI (not service provider interface) is a great protocol for disparet systems because the clocking is synchronous based on the fastest speed available at each end. This means that you can do SPI, today, in java by connecting serial port signal lines, or parallel port data lines to an SPI device, and bit banging the protocol. It won't be lightening fast, but it will be very much functional. What would make the most since is the ability for applications to designate various signalling line sources such as serial signaling lines and parallel port data lines as SPI data, slave select and clock signals, and plug those into an existing API. public class SPISlaveSelectLine { public SPISlaveSelectLine( int slave, SignalPort sp ) { ... } } public class SPIClockLine { public SPIClockLine( SignalPort sp ) { ... } } public class SPIDataLine { public SPIDataLine( SignalPort sp ) { ... } } I'd really like to see the embedded systems community take up this task and push these kinds of things forward. Having standard APIs would make it possible to run your software on aJile's AJ processors, the Muvium PIC environment, javacard, J2ME, etc. Imagine being able to plug a cellphone into the wall, attach a cable which has signalling lines and presto a remote terminal for monitoring and control. Data collection is a very needed capability as the next wave of technology evolution. The Java platform is not enabled with APIs to do this trivially yet. So, it doesn't look viable to many... Gregg Wonderly From guille at sms.nl Mon Jul 24 08:37:21 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 16:37:21 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: <1153751841.44c4db21de4bb@webmail.eatserver.nl> Hi Doug, Some comments below. Quoting "Dr. Douglas Lyon" : > Hi All, > There has been a lot of discussion regarding RS485. > > Let me see if I can summarize this, please correct me if I am wrong; > I am deliberately ignoring connector and electrical issues, focusing, > instead, on protocol and software issues. Also, I have never used > RS485, and I don't know much about it. > > 1. Serial ports that claim RS232 are typically used in > the data link layer of the OSI model of networking. Basically, this means > that they work with a point-to-point protocol and are meant to connect two > devices. It is actually physical + link (layers 1 and 2 of the OSI model), but yes, this is essentially right. > > 2. Within the RS232 standard there are framing bits (start and stop bits) > and error control bits (parity). The flow control is xon-xoff or DTR, CTS, > RTS. Thats' it. I'm not even sure that the RS232 standard talks about xon-xoff and such, I think it does not do much more than defining the electrical signals. Also note that RS232 was originally defined for the DTE-DCE interface (e.g. a device such as a modem connected to a computer). The current use of RS232 as a "general purpose" point to point link is a generalization of the RS232 standard. > > 3. If you want more than that from RS232 (forward error correction, ARQ, > etc.) > you do it in software, not in the RS232 standard. > > 4. RS485 is different from RS232 in that it is in the Network Layer of > the OSI model of networking. I would not put it that way. RS485 is very similar to RS232 with three main differences: - Only tx/rx, no extra signals such as DTR, RTS, CTS, etc (but then many "RS232" serial ports don't have them either) - Different electrical specs (which do not concern us here) - Multidrop and only one node talks at a given time (half duplex) But it does not define addresses (many RS485-based protocol use addresses for the nodes but that's not part of the RS485 standard), routing, etc. For software developers it still looks like a serial port (which it is!) except for the half-duplex part. More on this below. So RS485 is still about layers 1 and 2, same as RS232. I think all of this could be easier if we talk about UARTs instead of "RS232/RS485/RS422". All of these three are typically UARTs with some sort of buffer to get the electrical levels right: RS232 interface == UART + RS232 buffer/transceiver RS485 interface == UART + RS485 buffer/transceiver RS422 interface == UART + RS422 buffer/transceiver > > 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > a factory). > RS-485 is similar to RS-422, but RS-422 allows just one driver with > multiple receivers whereas RS-485 supports multiple drivers and > receivers. RS422 is exactly the same as RS485 except that it uses 4 wires instead of 2 wires so it can be full duplex again (but again this depends on the protocol you layer on top) > > 6. RS-485 is a serial bus with multiple nodes and thus must handle network > link layer protocols. By using high-impedance receivers, you can have > as many as 256 nodes. > > 7. The RS-485 can be implemented with RXTX in the core and a layer of > software > on top to handle media access control (MAC sublayer). There are also > hardware converters. > http://www.rs485.com/pconverters.html for example. However, some of > these require software control. There is some support in the form of > the Rs485.java class, > in RXTX. > > 8. The RS-485 specification will add to the size of the JSR > > 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > This version of the Java communications API contains support for > RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > mentioned. > > 10. DO people want to add RS485 to a new JSR? > > Would it make sense for the RS-485 people to speak up now? > Please let me know if you think my summary is wrong. Basically, for a software developer the only difference between RS485 and RS232 is the half-duplex nature of RS485, which means that you cannot receive and send at the same time. This has some implications depending on how RS485 is implemented in hardware, and on the (application) protocol defined on top of RS485. As I said, a RS485 interface is normally implemented using a standard UART plus a RS485 buffer/transceiver. RS485 buffers/transceivers can be in transmit mode or in receive mode. In a given RS485 bus, only one node should be in transmit mode at any given time, with the rest of the nodes 'listening' until it is their turn to transmit (and it is the application level protocol the one defines who should transmit next.) The RS485 chips used as buffers/transceivers normally have a control pin that is used to switch them into transmit or receive mode. There are typically three ways to handle this: 1. One of the control signals from the UART, such as RTS, DTR, etc. is connected to this control pin. The software must explicitly toggle this signal in order to switch the RS485 buffer/transceiver into transmit or receive mode. This puts a lot of burden on the software side and is sometimes unreliable because of complex timing issues as well as issues with buffering at the device driver level, but it is still a popular solution. 2. The UART itself knows about RS485 and can be configured to control the RS485 buffer/transceiver automatically, without any sort of software intervention. This is a very good solution since it is transparent to the software. However most UARTs don't know about RS485. 3. Standard UART + some custom hardware to control the direction pin. This is also transparent to the software. RS232/RS485 converters are an example of this approach. Implications for the software: For 3/ the software does not need to do anything special. For 2/ all you need is some sort of mechanism to tell the UART to enter RS485-mode (typically a ioctlex). For 1/ there is no simple solution. The timing issues make it difficult to implement this sort of mechanism in user space so it is often done at the device driver level. If this is the case, then all one needs is a mechanism to tell the driver to enter RS485-mode (again, a ioctlex). If this is NOT the case, then the application will need to take care. To do this more or less reliably, you would probably need a couple of things: - Some way to disable software buffering (and FIFOs if possible) - Some way to poll the UART's serial transmit register so that you can determine exactly when all data has been sent (many UARTs don't even support this) and switch to receive mode. - High resolution timers. - Real-time capabilities. Pretty strict requirements as you can see, which is why this approach never works very well except for very specific applications. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From naranjo.manuel at gmail.com Mon Jul 24 08:39:15 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Mon, 24 Jul 2006 11:39:15 -0300 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D77D.5080200@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> Message-ID: <44C4DB93.8080008@gmail.com> Gregg: Thanks for taking me out of the dark ;). Trully I did not know that SPI was an underlaying level of Serial ports, and Parallel ports. I give back what I said. I also would like to see my cell phone plug to every were, and be able to program it with java, is just that I do not know if we are going to get ourselves in a very almost unfinishable task. Regards, Manuel > Manuel Francisco Naranjo wrote: > >> Doug: >> I do not think that RS485 is a must by now. I do think we must make a >> JSR to standarize a bit Serial Ports accessing. Maybe we can make a JSR >> > > just for serial ports, and then start trying with other kind of ports > > and make others JSR. Or try to expand our first JSR, but I trully do > > not know if that can be made. > > I think that anyone aimed at the javax.comm space should be interested in > creating a hardware access SPI first. This is the predominate stumbling > block for java having access to various hardware devices. The more we can > promote as a standard, the more we can expect consistency and availability! > > >> About other ports besides RS485, the others I2C, SPI, etc, run at a very >> low level, maybe too close to the processor for Java. >> > > SPI (not service provider interface) is a great protocol for disparet systems > because the clocking is synchronous based on the fastest speed available at each > end. This means that you can do SPI, today, in java by connecting serial port > signal lines, or parallel port data lines to an SPI device, and bit banging the > protocol. It won't be lightening fast, but it will be very much functional. > What would make the most since is the ability for applications to designate > various signalling line sources such as serial signaling lines and parallel port > data lines as SPI data, slave select and clock signals, and plug those into an > existing API. > > public class SPISlaveSelectLine { > public SPISlaveSelectLine( int slave, SignalPort sp ) { > ... > } > } > > public class SPIClockLine { > public SPIClockLine( SignalPort sp ) { > ... > } > } > > public class SPIDataLine { > public SPIDataLine( SignalPort sp ) { > ... > } > } > > I'd really like to see the embedded systems community take up this task and push > these kinds of things forward. Having standard APIs would make it possible to > run your software on aJile's AJ processors, the Muvium PIC environment, > javacard, J2ME, etc. Imagine being able to plug a cellphone into the wall, > attach a cable which has signalling lines and presto a remote terminal for > monitoring and control. > > Data collection is a very needed capability as the next wave of technology > evolution. The Java platform is not enabled with APIs to do this trivially yet. > So, it doesn't look viable to many... > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From guille at sms.nl Mon Jul 24 08:41:21 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 16:41:21 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D351.603@lhar.co.za> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: <1153752081.44c4dc11eedf3@webmail.eatserver.nl> Quoting Christo Malan : > Hi > > I don't think RS-485 belong in rxtx, the scope of the spec is not wide > enough as it only specify the electrical layer. Their is no data > protocol recommended or defined. RS485 is exactly at the same level as RS232, no more and no less. > This mean that we have no idea when to > sample for a bit, how long is a bit and how many bits before we can say > new data is available. A "RS485 serial port" is just a UART whose output complies with the RS485 electrical spec, just as a "RS232 serial port" is just a UART whose output complies with the RS232 electrical spec. Bit times, sampling intervals, character structure etc. are the same for both protocols... Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From tjarvi at qbang.org Mon Jul 24 08:44:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 24 Jul 2006 08:44:53 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D351.603@lhar.co.za> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: A JSR/JCP would not just involve RXTX. In fact it would be very nice to have others with expertise in various areas like I2C, IrDA, RS485, RS422, ... involved. Within the RXTX community, I do not think we have enough depth to tackle RS485 alone. I'm aware of some of the low level issues but to be honest, I've never actually used it. The RS485 classes in RXTX are more like notes to myself about the issues involved without hardware solutions. In operating systems like Linux, this may be much less of an issue in the future. Linux is putting realtime patches now in the kernels which could make RS485 over EIA232 possible. This is probably the last chance RS485 has to get into a published spec for a long time though. Right now, I do not think its reasonable to include it in the process. Others could make that less of a problem. On Mon, 24 Jul 2006, Christo Malan wrote: > Hi > > I don't think RS-485 belong in rxtx, the scope of the spec is not wide > enough as it only specify the electrical layer. Their is no data > protocol recommended or defined. This mean that we have no idea when to > sample for a bit, how long is a bit and how many bits before we can say > new data is available. > > Christo > > Dr. Douglas Lyon wrote: >> Hi All, >> There has been a lot of discussion regarding RS485. >> >> Let me see if I can summarize this, please correct me if I am wrong; >> I am deliberately ignoring connector and electrical issues, focusing, >> instead, on protocol and software issues. Also, I have never used >> RS485, and I don't know much about it. >> >> 1. Serial ports that claim RS232 are typically used in >> the data link layer of the OSI model of networking. Basically, this means >> that they work with a point-to-point protocol and are meant to connect two >> devices. >> >> 2. Within the RS232 standard there are framing bits (start and stop bits) >> and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. >> Thats' it. >> >> 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) >> you do it in software, not in the RS232 standard. >> >> 4. RS485 is different from RS232 in that it is in the Network Layer of >> the OSI model of networking. >> >> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in >> a factory). >> RS-485 is similar to RS-422, but RS-422 allows just one driver with >> multiple receivers whereas RS-485 supports multiple drivers and >> receivers. >> >> 6. RS-485 is a serial bus with multiple nodes and thus must handle network >> link layer protocols. By using high-impedance receivers, you can have >> as many as 256 nodes. >> >> 7. The RS-485 can be implemented with RXTX in the core and a layer of software >> on top to handle media access control (MAC sublayer). There are also >> hardware converters. >> http://www.rs485.com/pconverters.html for example. However, some of >> these require software control. There is some support in the form of >> the Rs485.java class, >> in RXTX. >> >> 8. The RS-485 specification will add to the size of the JSR >> >> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: >> This version of the Java communications API contains support for >> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not >> mentioned. >> >> 10. DO people want to add RS485 to a new JSR? >> >> Would it make sense for the RS-485 people to speak up now? >> Please let me know if you think my summary is wrong. >> >> Thanks! >> - Doug >> >> >> >> >> >> >>> At 18:31 20/07/2006, Trent Jarvi wrote: >>> >>>> > PROJECT SCOPE: >>>> > ------------- >>>> > >>>> > Also, we should think carefully about what the scope of >>>> > this project would be. Should it be javax."comm" which >>>> > handles both serial and parallel (is parallel going by the >>>> > wayside). Should it be split into two project: >>>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>>> > >>>> > Should we differentiate between single-ended serial >>>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>>> > quasi-multidrop and full multidrop busses such as >>>> > EIA422, EIA432 and EIA485? If we really were to >>>> > add I2C support to the API, we'd have to delve into >>>> > the semantics more, because there could be some >>>> > implicit decoding of the bus the API users would >>>> > want to see. >>>> > >>>> >>>> Hi Paul >>>> >>>> The way RXTX works, which is a fair representation of the people using the >>>> API, is complete support for RIA232, minimal support for IEEE1284. From >>>> what I understand, Sun was going along the same lines. If we combined >>>> both projects, we would have half a parallel port implementation. I see >>>> maybe 4 requests for features not in the parallel support a year. >>>> >>>> The other protocols should not be limited by a JSR which is going to be >>>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>>> I2C and Raw should _not_ be considered a strong basis for extending the >>>> API to cover these protocols. If people want to do real implementations, >>>> they should not face a 'standard' which wasnt really focused upon their >>>> interests. I think we understand the parallel port issues fairly well but >>>> have not implemented many features and I don't know if we would. >>>> >>> I agree with all of this. API requirements for I2C, SPI, etc. are very >>> different from those for RS232/485/422. Our embedded Java platform has >>> APIs for all of these and more and they don't share a lot apart from the >>> fact that they all use Input/OutputStreams (and in the case of SPI you >>> still need to cater with the fact that every time you want to read you >>> must also write to the device.) >>> >>> If I was to design javax.comm from scratch, I think I would focus on >>> serial ports exclusively (== whatever the underlying OS represents as >>> serial ports). Even parallel is a bit out of place IMHO, although I >>> understand it needs to stay for backwards compatibility. >>> >>> >>> >>>> So a versatile API is favorable but I do not think we have the proper >>>> community to represent much more than Serial. >>>> >>> Yes, I think the same. >>> >>> Guillermo >>> -- >>> Guillermo Rodriguez Garcia >>> >>> Snijder Micro Systems phone +31-493-351020 >>> G. Rodriguez Garcia fax +31-493-351530 >>> Visser 25 email guille at sms.nl >>> NL5751 BL Deurne >>> The Netherlands http://www.snijder.com >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From guille at sms.nl Mon Jul 24 08:47:47 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 16:47:47 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D77D.5080200@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> Message-ID: <1153752467.44c4dd93c08f7@webmail.eatserver.nl> Hi Gregg, Quoting Gregg Wonderly : > SPI (not service provider interface) is a great protocol for disparet systems > > because the clocking is synchronous based on the fastest speed available at > each > end. This means that you can do SPI, today, in java by connecting serial > port > signal lines, or parallel port data lines to an SPI device, and bit banging > the > protocol. It won't be lightening fast, but it will be very much functional. [...] > I'd really like to see the embedded systems community take up this task and > push > these kinds of things forward. Having standard APIs would make it possible > to > run your software on aJile's AJ processors, the Muvium PIC environment, > javacard, J2ME, etc. Imagine being able to plug a cellphone into the wall, > attach a cable which has signalling lines and presto a remote terminal for > monitoring and control. As an embedded Java vendor, SNIJDER Micro Systems certainly sees the value of standardized APIs to talk to different types of communication buses including SPI, I2C, 1-Wire, etc., for embedded applications. However we think this has nothing to do with javax.comm. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From guille at sms.nl Mon Jul 24 09:05:22 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 17:05:22 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4DB93.8080008@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <44C4DB93.8080008@gmail.com> Message-ID: <1153753522.44c4e1b24f2e1@webmail.eatserver.nl> Quoting Manuel Francisco Naranjo : > Gregg: > Thanks for taking me out of the dark ;). Trully I did not know that SPI > was an underlaying level of Serial ports, and Parallel ports. In fact it isn't; it is just another serial protocol, just like I2C. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From jredman at ergotech.com Mon Jul 24 09:29:10 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 09:29:10 -0600 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: <44C4E746.8070808@ergotech.com> Folks, The RS232/485/422/etc. etc. is a complete red herring (http://en.wikipedia.org/wiki/Red_herring in case you don't know the expression). The differences between the two are at the electrical level, not at the RXTX level. I'll provide a concrete example and see if we can get away from this issue. There's an industrial serial communications standard - Modbus. Modbus capable devices are very common and can be purchased, generally, with an RS232 or a 485 or a 422 - you decide when you buy it. Some actually provide both 232 and 485 on the same connector. Now, within our environment you configure a Modbus JavaBean. One of the parameters is the "Station Number". The station number is required for both RS232 and RS485 devices - the protocol doesn't change based on the electrical requirements of the device. Now I can configure an application talking to, say, station 2 and station 7. I can add an RS485 converter to the computer serial port and put two physical devices there, configured as station 2 and station 7 and everything works fine. HOWEVER, over RS232 some devices will respond to both station 2 and station 7. So THE SAME APPLICATION will work with both 232 and 485. The only changes are hardware related. This same behavior is true of a number of 485 "networks" and many industrial devices that have 485 interfaces have 232 as an option using the same protocol. Jim Trent Jarvi wrote: > A JSR/JCP would not just involve RXTX. In fact it would be very nice to > have others with expertise in various areas like I2C, IrDA, RS485, RS422, > ... involved. > > Within the RXTX community, I do not think we have enough depth to tackle > RS485 alone. I'm aware of some of the low level issues but to be honest, > I've never actually used it. The RS485 classes in RXTX are more like > notes to myself about the issues involved without hardware solutions. In > operating systems like Linux, this may be much less of an issue in the > future. Linux is putting realtime patches now in the kernels which could > make RS485 over EIA232 possible. > > This is probably the last chance RS485 has to get into a published spec > for a long time though. Right now, I do not think its reasonable to > include it in the process. Others could make that less of a problem. > > On Mon, 24 Jul 2006, Christo Malan wrote: > >> Hi >> >> I don't think RS-485 belong in rxtx, the scope of the spec is not wide >> enough as it only specify the electrical layer. Their is no data >> protocol recommended or defined. This mean that we have no idea when to >> sample for a bit, how long is a bit and how many bits before we can say >> new data is available. >> >> Christo >> >> Dr. Douglas Lyon wrote: >>> Hi All, >>> There has been a lot of discussion regarding RS485. >>> >>> Let me see if I can summarize this, please correct me if I am wrong; >>> I am deliberately ignoring connector and electrical issues, focusing, >>> instead, on protocol and software issues. Also, I have never used >>> RS485, and I don't know much about it. >>> >>> 1. Serial ports that claim RS232 are typically used in >>> the data link layer of the OSI model of networking. Basically, this means >>> that they work with a point-to-point protocol and are meant to connect two >>> devices. >>> >>> 2. Within the RS232 standard there are framing bits (start and stop bits) >>> and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. >>> Thats' it. >>> >>> 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) >>> you do it in software, not in the RS232 standard. >>> >>> 4. RS485 is different from RS232 in that it is in the Network Layer of >>> the OSI model of networking. >>> >>> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in >>> a factory). >>> RS-485 is similar to RS-422, but RS-422 allows just one driver with >>> multiple receivers whereas RS-485 supports multiple drivers and >>> receivers. >>> >>> 6. RS-485 is a serial bus with multiple nodes and thus must handle network >>> link layer protocols. By using high-impedance receivers, you can have >>> as many as 256 nodes. >>> >>> 7. The RS-485 can be implemented with RXTX in the core and a layer of software >>> on top to handle media access control (MAC sublayer). There are also >>> hardware converters. >>> http://www.rs485.com/pconverters.html for example. However, some of >>> these require software control. There is some support in the form of >>> the Rs485.java class, >>> in RXTX. >>> >>> 8. The RS-485 specification will add to the size of the JSR >>> >>> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: >>> This version of the Java communications API contains support for >>> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not >>> mentioned. >>> >>> 10. DO people want to add RS485 to a new JSR? >>> >>> Would it make sense for the RS-485 people to speak up now? >>> Please let me know if you think my summary is wrong. >>> >>> Thanks! >>> - Doug >>> >>> >>> >>> >>> >>> >>>> At 18:31 20/07/2006, Trent Jarvi wrote: >>>> >>>>>> PROJECT SCOPE: >>>>>> ------------- >>>>>> >>>>>> Also, we should think carefully about what the scope of >>>>>> this project would be. Should it be javax."comm" which >>>>>> handles both serial and parallel (is parallel going by the >>>>>> wayside). Should it be split into two project: >>>>>> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>>>>> >>>>>> Should we differentiate between single-ended serial >>>>>> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>>>>> quasi-multidrop and full multidrop busses such as >>>>>> EIA422, EIA432 and EIA485? If we really were to >>>>>> add I2C support to the API, we'd have to delve into >>>>>> the semantics more, because there could be some >>>>>> implicit decoding of the bus the API users would >>>>>> want to see. >>>>>> >>>>> Hi Paul >>>>> >>>>> The way RXTX works, which is a fair representation of the people using the >>>>> API, is complete support for RIA232, minimal support for IEEE1284. From >>>>> what I understand, Sun was going along the same lines. If we combined >>>>> both projects, we would have half a parallel port implementation. I see >>>>> maybe 4 requests for features not in the parallel support a year. >>>>> >>>>> The other protocols should not be limited by a JSR which is going to be >>>>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>>>> I2C and Raw should _not_ be considered a strong basis for extending the >>>>> API to cover these protocols. If people want to do real implementations, >>>>> they should not face a 'standard' which wasnt really focused upon their >>>>> interests. I think we understand the parallel port issues fairly well but >>>>> have not implemented many features and I don't know if we would. >>>>> >>>> I agree with all of this. API requirements for I2C, SPI, etc. are very >>>> different from those for RS232/485/422. Our embedded Java platform has >>>> APIs for all of these and more and they don't share a lot apart from the >>>> fact that they all use Input/OutputStreams (and in the case of SPI you >>>> still need to cater with the fact that every time you want to read you >>>> must also write to the device.) >>>> >>>> If I was to design javax.comm from scratch, I think I would focus on >>>> serial ports exclusively (== whatever the underlying OS represents as >>>> serial ports). Even parallel is a bit out of place IMHO, although I >>>> understand it needs to stay for backwards compatibility. >>>> >>>> >>>> >>>>> So a versatile API is favorable but I do not think we have the proper >>>>> community to represent much more than Serial. >>>>> >>>> Yes, I think the same. >>>> >>>> Guillermo >>>> -- >>>> Guillermo Rodriguez Garcia >>>> >>>> Snijder Micro Systems phone +31-493-351020 >>>> G. Rodriguez Garcia fax +31-493-351530 >>>> Visser 25 email guille at sms.nl >>>> NL5751 BL Deurne >>>> The Netherlands http://www.snijder.com >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From jredman at ergotech.com Mon Jul 24 09:50:21 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 09:50:21 -0600 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D77D.5080200@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> Message-ID: <44C4EC3D.6010204@ergotech.com> Jim, How about we go back to basics and define a serial port. Under Java, I can open /dev/ttyS0, COM1:, etc and read/write a serial port. So what does RXTX bring to the table? If we can define what we need from the product at a high level (functional spec.) then we can look at what's wrong underneath (design requirements). I can do this fairly easily. Functionally, I want support for SerialPort - a superset of that would be fine. SerialPort provides an abstraction that provides everything I need for accessing serial devices. At the design level, I'd like a "pluggable" architecture. That is, I'd like to able to accommodate anything that it makes sense to implement in terms of the SerialPort interface. An obvious plugin is one that supports the current RXTX serial port access - through device files. But _I'd_ like a plugin for serial ports over Ethernet, serial ports over BlueTooth (including discovery), etc. I'm sure others could think of modules they'd like i2c, SPI, etc. etc. I'm not sure that ANY of these should be part of the spec. although perhaps the device file based version could be part of a reference implementation. I don't know that this is really much different from the existing architecture. I doubt that much code could be shared between, for example, a BlueTooth serial port and a /dev/ttyS0 serial port, but perhaps those more familiar with the code could comment. I suspect some cleanup of registration, etc. would be needed to formalize plugins, but I doubt it's too great. Some time ago I learnt the definition of a "Goal". It should be concrete, winnable and build unity. So, I have laid out a concrete goal, build to a superset of the SerialPort interface, it's winnable because it's not a complete rewrite of RXTX and it builds unity because anyone's pet electrical specification can be added. A simplistic view, tell me where I went wrong. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From lyon at docjava.com Mon Jul 24 10:06:40 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 24 Jul 2006 12:06:40 -0400 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4E746.8070808@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> Message-ID: >Hi All, Wow, what an informed and interesting debate from my most innocent and well-intentioned of e-mails. I must say that I am learning a great deal from this list! When I speak about RS232 I wanted to focus on the protocol, not the connector shape or pin-out or electrical issues. Issues like that are addressed by the rs232c standard. The RS232 is a really loaded term! The C revision of the standard was issued in 1969 in part to accommodate electrical characteristics. Revision D was issued in 1986. The current revision is TIA-232-F Interface Between Data Terminal Equipment and Data Circuit-Terminating Equipment Employing Serial Binary Data Interchange, issued in 1997. None of this is of any particular relevance to the basic underlying question: Should the next JSR attempt to address the multi-drop abilities of RS-485? Thanks! - Doug >Folks, > >The RS232/485/422/etc. etc. is a complete red herring >(http://en.wikipedia.org/wiki/Red_herring in case you don't know the >expression). The differences between the two are at the electrical >level, not at the RXTX level. I'll provide a concrete example and see >if we can get away from this issue. > >There's an industrial serial communications standard - Modbus. Modbus >capable devices are very common and can be purchased, generally, with an >RS232 or a 485 or a 422 - you decide when you buy it. Some actually >provide both 232 and 485 on the same connector. Now, within our >environment you configure a Modbus JavaBean. One of the parameters is >the "Station Number". The station number is required for both RS232 and >RS485 devices - the protocol doesn't change based on the electrical >requirements of the device. Now I can configure an application talking >to, say, station 2 and station 7. I can add an RS485 converter to the >computer serial port and put two physical devices there, configured as >station 2 and station 7 and everything works fine. HOWEVER, over RS232 >some devices will respond to both station 2 and station 7. So THE SAME >APPLICATION will work with both 232 and 485. The only changes are >hardware related. This same behavior is true of a number of 485 >"networks" and many industrial devices that have 485 interfaces have 232 >as an option using the same protocol. > >Jim > > >Trent Jarvi wrote: >> A JSR/JCP would not just involve RXTX. In fact it would be very nice to >> have others with expertise in various areas like I2C, IrDA, RS485, RS422, >> ... involved. >> >> Within the RXTX community, I do not think we have enough depth to tackle >> RS485 alone. I'm aware of some of the low level issues but to be honest, >> I've never actually used it. The RS485 classes in RXTX are more like >> notes to myself about the issues involved without hardware solutions. In >> operating systems like Linux, this may be much less of an issue in the >> future. Linux is putting realtime patches now in the kernels which could >> make RS485 over EIA232 possible. >> >> This is probably the last chance RS485 has to get into a published spec >> for a long time though. Right now, I do not think its reasonable to >> include it in the process. Others could make that less of a problem. >> >> On Mon, 24 Jul 2006, Christo Malan wrote: >> >>> Hi >>> >>> I don't think RS-485 belong in rxtx, the scope of the spec is not wide >>> enough as it only specify the electrical layer. Their is no data >>> protocol recommended or defined. This mean that we have no idea when to >>> sample for a bit, how long is a bit and how many bits before we can say >>> new data is available. >>> >>> Christo >>> >>> Dr. Douglas Lyon wrote: >>>> Hi All, >>>> There has been a lot of discussion regarding RS485. >>>> >>>> Let me see if I can summarize this, please correct me if I am wrong; >>>> I am deliberately ignoring connector and electrical issues, focusing, >>>> instead, on protocol and software issues. Also, I have never used >>>> RS485, and I don't know much about it. > >>> >>>> 1. Serial ports that claim RS232 are typically used in >>>> the data link layer of the OSI model of networking. Basically, this means >>>> that they work with a point-to-point protocol and are meant to connect two > >>> devices. >>>> >>>> 2. Within the RS232 standard there are framing bits (start and stop bits) >>>> and error control bits (parity). The flow control is xon-xoff or >>>>DTR, CTS, RTS. >>>> Thats' it. >>>> >>>> 3. If you want more than that from RS232 (forward error >>>>correction, ARQ, etc.) >>>> you do it in software, not in the RS232 standard. >>>> >>>> 4. RS485 is different from RS232 in that it is in the Network Layer of >>>> the OSI model of networking. >>>> >>>> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in >>>> a factory). >>>> RS-485 is similar to RS-422, but RS-422 allows just one driver with >>>> multiple receivers whereas RS-485 supports multiple drivers and >>>> receivers. >>>> >>>> 6. RS-485 is a serial bus with multiple nodes and thus must handle network >>>> link layer protocols. By using high-impedance receivers, you can have >>>> as many as 256 nodes. >>>> >>>> 7. The RS-485 can be implemented with RXTX in the core and a >>>>layer of software >>>> on top to handle media access control (MAC sublayer). There are also >>>> hardware converters. >>>> http://www.rs485.com/pconverters.html for example. However, some of >>>> these require software control. There is some support in the form of >>>> the Rs485.java class, >>>> in RXTX. >>>> >>>> 8. The RS-485 specification will add to the size of the JSR >>>> >>>> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: >>>> This version of the Java communications API contains support for >>>> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not >>>> mentioned. >>>> >>>> 10. DO people want to add RS485 to a new JSR? >>>> >>>> Would it make sense for the RS-485 people to speak up now? >>>> Please let me know if you think my summary is wrong. >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>> >>>> >>>> >>>> >>>>> At 18:31 20/07/2006, Trent Jarvi wrote: >>>>> >>>>>>> PROJECT SCOPE: >>>>>>> ------------- >>>>>>> >>>>>>> Also, we should think carefully about what the scope of >>>>>>> this project would be. Should it be javax."comm" which >>>>>>> handles both serial and parallel (is parallel going by the >>>>>>> wayside). Should it be split into two project: >>>>>>> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>>>>>> >>>>>>> Should we differentiate between single-ended serial >>>>>>> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>>>>>> quasi-multidrop and full multidrop busses such as >>>>>>> EIA422, EIA432 and EIA485? If we really were to >>>>>>> add I2C support to the API, we'd have to delve into >>>>>>> the semantics more, because there could be some >>>>>>> implicit decoding of the bus the API users would >>>>>>> want to see. >>>>>>> >>>>>> Hi Paul >>>>>> >>>>>> The way RXTX works, which is a fair representation of the >>>>>>people using the >>>>>> API, is complete support for RIA232, minimal support for IEEE1284. From >>>>>> what I understand, Sun was going along the same lines. If we combined >>>>>> both projects, we would have half a parallel port implementation. I see >>>>>> maybe 4 requests for features not in the parallel support a year. >>>>>> >>>>>> The other protocols should not be limited by a JSR which is going to be >>>>>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>>>>> I2C and Raw should _not_ be considered a strong basis for extending the >>>>>> API to cover these protocols. If people want to do real >>>>>>implementations, >>>>>> they should not face a 'standard' which wasnt really focused upon their >>>>>> interests. I think we understand the parallel port issues >>>>>>fairly well but >>>>>> have not implemented many features and I don't know if we would. >>>>>> >>>>> I agree with all of this. API requirements for I2C, SPI, etc. are very >>>>> different from those for RS232/485/422. Our embedded Java platform has >>>>> APIs for all of these and more and they don't share a lot apart from the >>>>> fact that they all use Input/OutputStreams (and in the case of SPI you > >>>> still need to cater with the fact that every time you want to read you >>>>> must also write to the device.) >>>>> >>>>> If I was to design javax.comm from scratch, I think I would focus on >>>>> serial ports exclusively (== whatever the underlying OS represents as > >>>> serial ports). Even parallel is a bit out of place IMHO, although I >>>>> understand it needs to stay for backwards compatibility. >>>>> >>>>> >>>>> >>>>>> So a versatile API is favorable but I do not think we have the proper >>>>>> community to represent much more than Serial. >>>>>> >>>>> Yes, I think the same. >>>>> >>>>> Guillermo >>>>> -- >>>>> Guillermo Rodriguez Garcia >>>>> >>>>> Snijder Micro Systems phone +31-493-351020 >>>>> G. Rodriguez Garcia fax +31-493-351530 >>>>> Visser 25 email guille at sms.nl >>>>> NL5751 BL Deurne >>>>> The Netherlands http://www.snijder.com >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >-- >Jim Redman >(505) 662 5156 x85 >http://www.ergotech.com >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Mon Jul 24 10:16:44 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 18:16:44 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> Message-ID: <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> Hi Doug, Quoting "Dr. Douglas Lyon" : > >Hi All, > > > Wow, what an informed and interesting debate from my most > innocent and well-intentioned of e-mails. > > I must say that I am learning a great deal from this list! > > When I speak about > RS232 I wanted to focus on the protocol, not the connector shape or > pin-out or electrical issues. Issues like that are addressed by the > rs232c standard. > The RS232 is a really loaded term! Right. Maybe we should be talking about "serial ports" instead. At the functional level it does not make any difference whether it is RS232, RS485, or RS422... except maybe for the direction control in the case of RS485 ports. [...] > > None of this is of any particular relevance to the basic underlying > question: > > Should the next JSR attempt to address the multi-drop abilities of RS-485? What I would suggest is to just add a new 'ioctlex'-like method to the SerialPort API: A method that you'd use to pass platform- or implementation-specific info to the underlying driver or OS to do things such as "enabling RS485 mode" or "disable FIFOs" or "poll the TSR register". No need to define any function codes. This is for stuff that is platform- or implementation-specific and as such cannot be easily abstracted anyway. The goal is to accomodate hat those systems that have serial ports with special, non-standard capabilities without forcing developers to leave javax.comm. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From Paul.Klissner at Sun.COM Mon Jul 24 10:45:33 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Mon, 24 Jul 2006 09:45:33 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> Message-ID: <44C4F92D.6090807@sun.com> >> None of this is of any particular relevance to the basic underlying >> question: >> >> Should the next JSR attempt to address the multi-drop abilities of RS-485? > > What I would suggest is to just add a new 'ioctlex'-like method > to the SerialPort API: A method that you'd use to pass platform- > or implementation-specific info to the underlying driver or OS > to do things such as "enabling RS485 mode" or "disable FIFOs" or > "poll the TSR register". > > No need to define any function codes. This is for stuff that is > platform- or implementation-specific and as such cannot be easily > abstracted anyway. Detrimental to platform independence. Paul From berkland at spamcop.net Mon Jul 24 11:07:58 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 24 Jul 2006 13:07:58 -0400 Subject: [Rxtx] jcp and jsr In-Reply-To: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> Message-ID: <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> Gregg Wonderly wrote: > That there could be a low level port/device SPI > that could be put in place once, and then overtime > we could layer other APIs, including an updated > javax.comm which would make use of this SPI. I think there is great merit in this suggestion. I would like to see the ability to register a new "port" along with a custom handler in the Java client code before attempting to access the port. e.g . CommManager.getInstance().registerPortImpl("USB1:", new HidPortAdapter(/*vendorId=*/ "1234", /*deviceId=*/ "4321"); CommManager.getInstance().registerPortImpl("Ether1:", new InetPortAdapter(/*ipAndPort=*/ "192.168.1.101:8088"); It would allow other protocols that this group doesn't have depth in to be developed by someone who does on an "as needed" basis. Additionally, the value of this would be with some devices that implement basically the same protocol that was initially used over RS232 for a USB (via an HID) or Ethernet interface. There are a number of these in POS hardware. The existing JavaPOS driver written against JavaCOMM 2.0 could be reused by plugging in an HID or IP adapter before attempting to access the device. It might also be valuable to use something like an extended version of the portmapping file found in JavaCOMM 3.0. A configuration file could allow this definition to take place outside of any Java client code. Such a mapping file wouldn't even need to be part of the JSR API or reference implementation. It could be handled in a specific implementation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060724/7f51342e/attachment-0338.html From guille at sms.nl Mon Jul 24 11:14:54 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 19:14:54 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4F92D.6090807@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> Message-ID: <1153761294.44c5000ec1360@webmail.eatserver.nl> Quoting Paul Klissner : > >> None of this is of any particular relevance to the basic underlying > >> question: > >> > >> Should the next JSR attempt to address the multi-drop abilities of > RS-485? > > > > What I would suggest is to just add a new 'ioctlex'-like method > > to the SerialPort API: A method that you'd use to pass platform- > > or implementation-specific info to the underlying driver or OS > > to do things such as "enabling RS485 mode" or "disable FIFOs" or > > "poll the TSR register". > > > > No need to define any function codes. This is for stuff that is > > platform- or implementation-specific and as such cannot be easily > > abstracted anyway. > > Detrimental to platform independence. Yes, it is. But as you go closer and closer to the hardware level some things are by nature platform-dependent, and sometimes just cannot be solved in a platform-independent way. In these cases, is it better to have no solution at all than having one that is less than perfect? Put it another way, would you prefer having people say "I just cannot do this in Java; I'll go somewhere else" rather than "I can do this in Java -- only not in a platform-independent way" ? Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From gergg at cox.net Mon Jul 24 11:34:00 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 12:34:00 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153752467.44c4dd93c08f7@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> Message-ID: <44C50488.1040508@cox.net> Guillermo Rodriguez wrote: > As an embedded Java vendor, SNIJDER Micro Systems certainly sees the > value of standardized APIs to talk to different types of communication > buses including SPI, I2C, 1-Wire, etc., for embedded applications. > However we think this has nothing to do with javax.comm. I don't think this is only about javax.comm. Certainly that's important. I'm just wading into this conversation mainstream and trying to say: If you are going to do anything about "fixing" javax.comm to work on all platforms, please, please, please start with a hardware port SPI definition that lets you get to serial ports, and then provide the existing javax.com API and whatever new API you think is necessary (I don't have any really issues with the existing API directly). Then, there will be a place for others interesting in SPI, i2C, USB and other things to get started with providing access to devices that are also interesting in Java applications, and directly, in embedded Java applications. Gregg Wonderly From Paul.Klissner at Sun.COM Mon Jul 24 11:41:51 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Mon, 24 Jul 2006 10:41:51 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153761294.44c5000ec1360@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> Message-ID: <44C5065F.3060802@sun.com> Guillermo Rodriguez wrote: > Quoting Paul Klissner : > >>>> None of this is of any particular relevance to the basic underlying >>>> question: >>>> >>>> Should the next JSR attempt to address the multi-drop abilities of >> RS-485? >>> What I would suggest is to just add a new 'ioctlex'-like method >>> to the SerialPort API: A method that you'd use to pass platform- >>> or implementation-specific info to the underlying driver or OS >>> to do things such as "enabling RS485 mode" or "disable FIFOs" or >>> "poll the TSR register". >>> >>> No need to define any function codes. This is for stuff that is >>> platform- or implementation-specific and as such cannot be easily >>> abstracted anyway. >> Detrimental to platform independence. > > Yes, it is. But as you go closer and closer to the hardware level some > things are by nature platform-dependent, and sometimes just cannot be > solved in a platform-independent way. In these cases, is it better to > have no solution at all than having one that is less than perfect? > > Put it another way, would you prefer having people say "I just cannot > do this in Java; I'll go somewhere else" rather than "I can do this > in Java -- only not in a platform-independent way" ? If there isn't a reasonable way to abstract it out, then why use Java? The whole idea is platform neutrality, otherwise, what is the huge advantage of adopting a standardized Java API? I think it is wrong to subvert the API. I think we have to arrive at some sort of consensus about the scope of the API and do our best to engineer a robust API in terms of that scope using abstraction. There may be outliers, but the outliers probably aren't portable, and probably would do just as well to not use java for that particular application. If this was a JSR, if we found some compelling problem that kept cropping up the API could be reved so as not to just orphan cases with legitimate requests. If someone really needs to do funky things with the hardware, why wouldn't that be put in the native back end? Couldn't some of this be addressed by the multiple SPI layer that I recommended as one of the two changes I'd like to see made to javax.comm (the other being a port mapping plugin layer)? Paul From jredman at ergotech.com Mon Jul 24 11:49:46 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 11:49:46 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> Message-ID: <44C5083A.6090902@ergotech.com> A thought for later since we haven't really reached this level of detail, but since this type of approach seems likely... If a configuration file is mandatory, can we specify what the file is called and what the format of the options are (mandatory?, and optional) without limiting extensions. This just adds consistency across platforms/implementations. Jim Doug Berkland wrote: > Gregg Wonderly wrote: > > That there could be a low level port/device SPI > > that could be put in place once, and then overtime > > we could layer other APIs, including an updated > > javax.comm which would make use of this SPI. > > I think there is great merit in this suggestion. I would like to see > the ability to register a new "port" along with a custom handler in the > Java client code before attempting to access the port. > e.g . > CommManager.getInstance().registerPortImpl("USB1:", new > HidPortAdapter(/*vendorId=*/ "1234", /*deviceId=*/ "4321"); > CommManager.getInstance().registerPortImpl("Ether1:", new > InetPortAdapter(/*ipAndPort=*/ " 192.168.1.101:8088 > "); > > It would allow other protocols that this group doesn't have depth in to > be developed by someone who does on an "as needed" basis. > > Additionally, the value of this would be with some devices that > implement basically the same protocol that was initially used over RS232 > for a USB (via an HID) or Ethernet interface. There are a number of > these in POS hardware. The existing JavaPOS driver written against > JavaCOMM 2.0 could be reused by plugging in an HID or IP adapter before > attempting to access the device. > > It might also be valuable to use something like an extended version of > the portmapping file found in JavaCOMM 3.0. A configuration file could > allow this definition to take place outside of any Java client code. > Such a mapping file wouldn't even need to be part of the JSR API or > reference implementation. It could be handled in a specific > implementation. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From mtnvega at yahoo.com.br Mon Jul 24 11:51:40 2006 From: mtnvega at yahoo.com.br (mtnvega) Date: Mon, 24 Jul 2006 14:51:40 -0300 Subject: [Rxtx] Serial Read/Write Details Message-ID: <44C508AC.7060103@yahoo.com.br> Hello, I'm have being flirting with RXTX for a while since I'm working on a college project where I will need to communicate with a microcontroller using USART. Now is the time to start using it! But I have some doubts and I hope you can help-me. I will need to both send and receive data from the serial port. First I will need to send some command bytes then wait for some data that will be returned from the microcontroller. And I would like to know which is the best way to do that. I'm mean, of course send and receive data is the purpose of the serial port and RXTX but I'm looking for some details since there will be no package control but just a fixed command format and confirmation messages from the microcontroller side. I would like to know if I should open and close the port or if I can just open it once. I read that upon writing to output the input buffer are filled with the same data, is it right? If yes, isn't it a problem since I'm waiting for data back in a very small time? Thank you, Luiz _______________________________________________________ Voc? quer respostas para suas perguntas? Ou voc? sabe muito e quer compartilhar seu conhecimento? Experimente o Yahoo! Respostas ! http://br.answers.yahoo.com/ From jredman at ergotech.com Mon Jul 24 12:45:50 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 12:45:50 -0600 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C50488.1040508@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> Message-ID: <44C5155E.7080105@ergotech.com> Gregg, Is SPI applicable to a SerialPort interface over Ethernet (or Bluetooth)? I've assumed that it's specific to directly-connected-UART-based serial ports - something similar to I2C. I'm starting to think that I'm opposed to having hardware definitions (transport layer?) in the JavaComm spec., but then what's left? Jim Gregg Wonderly wrote: > Guillermo Rodriguez wrote: >> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the >> value of standardized APIs to talk to different types of communication >> buses including SPI, I2C, 1-Wire, etc., for embedded applications. >> However we think this has nothing to do with javax.comm. > > I don't think this is only about javax.comm. Certainly that's important. I'm > just wading into this conversation mainstream and trying to say: > > If you are going to do anything about "fixing" javax.comm to work on all > platforms, please, please, please start with a hardware port SPI definition that > lets you get to serial ports, and then provide the existing javax.com API and > whatever new API you think is necessary (I don't have any really issues with the > existing API directly). > > Then, there will be a place for others interesting in SPI, i2C, USB and other > things to get started with providing access to devices that are also interesting > in Java applications, and directly, in embedded Java applications. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Mon Jul 24 13:15:19 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 14:15:19 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C5155E.7080105@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <44C5155E.7080105@ergotech.com> Message-ID: <44C51C47.90409@cox.net> Jim Redman wrote: > Is SPI applicable to a SerialPort interface over Ethernet (or > Bluetooth)? I've assumed that it's specific to > directly-connected-UART-based serial ports - something similar to I2C. SPI is a simple 2 line (clock and data) plus slave select bi-directional, full duplex data transfer mechanism. It has nothing to do, directly with serial ports, but could be implemented using serial port signalling lines. > I'm starting to think that I'm opposed to having hardware definitions > (transport layer?) in the JavaComm spec., but then what's left? Jim, there are multiple conversations going on, on the list. There is a group of people that just want a standard serial port mechanism in Java, apparently NOW! They are going back and forth about that. There is another conversation about doing a JSR to make the serial port interfaces a standard, since Sun's original implementation was never a Java standard. There is a small group saying if you're going to do a JSR for serial ports, why not provide a nice foundation for serial ports which might also support other kinds of "ports" and associated protocols. And there are a couple of other conversations about Pascal's stuff. It's this last group that I am the most interested in. I think that it is possible to create a simple Service Provider Interface for 'hardware interfacing' that covers serial ports and also includes expandability to cover other types of hardware. We want to find the level of abstraction that the most number of OSes provide in their user level APIs, and create a matching SPI at that level which will allow a JVM vendor to provide access to the types of hardware that is common on their OSes/hardware. Then, third parties might add some value by providing some good abstrations for particular types of protocols or particular vendors' hardware (ports which can be switched between RS232 and RS485 for example). Finally, we can create an implementation of the javax.comm API which uses this SPI to provide exactly the same API as today, but with an approved foundation for hardware access from java using 100% java code. Gregg Wonderly From mark at mdsh.com Mon Jul 24 16:03:38 2006 From: mark at mdsh.com (Mark Himsley) Date: Mon, 24 Jul 2006 23:03:38 +0100 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: I don't see how any Java app is going to know the difference between an RS232, RS422, or RS485 port. I regularly use RXTX controlling RS422 devices (controlling VTRs) and I can use an RS232 port with bodged wiring (for short distances) or RS232 port with a media converted - either of which may be built into the PC or may be a USB device - or an RS422 USB device. They are just 'serial port' devices. Please don't get hung up on higher layer stuff - that's for application developers to add on top of a rock-solid multi platform 'serial port' driver implementations. On 24 July 2006 08:44 -0600 Trent Jarvi wrote: > > A JSR/JCP would not just involve RXTX. In fact it would be very nice to > have others with expertise in various areas like I2C, IrDA, RS485, RS422, > ... involved. > > Within the RXTX community, I do not think we have enough depth to tackle > RS485 alone. I'm aware of some of the low level issues but to be honest, > I've never actually used it. The RS485 classes in RXTX are more like > notes to myself about the issues involved without hardware solutions. In > operating systems like Linux, this may be much less of an issue in the > future. Linux is putting realtime patches now in the kernels which could > make RS485 over EIA232 possible. > > This is probably the last chance RS485 has to get into a published spec > for a long time though. Right now, I do not think its reasonable to > include it in the process. Others could make that less of a problem. > > On Mon, 24 Jul 2006, Christo Malan wrote: > > > Hi > > > > I don't think RS-485 belong in rxtx, the scope of the spec is not wide > > enough as it only specify the electrical layer. Their is no data > > protocol recommended or defined. This mean that we have no idea when to > > sample for a bit, how long is a bit and how many bits before we can say > > new data is available. > > > > Christo > > > > Dr. Douglas Lyon wrote: > >> Hi All, > >> There has been a lot of discussion regarding RS485. > >> > >> Let me see if I can summarize this, please correct me if I am wrong; > >> I am deliberately ignoring connector and electrical issues, focusing, > >> instead, on protocol and software issues. Also, I have never used > >> RS485, and I don't know much about it. > >> > >> 1. Serial ports that claim RS232 are typically used in > >> the data link layer of the OSI model of networking. Basically, this > >> means that they work with a point-to-point protocol and are meant to > >> connect two devices. > >> > >> 2. Within the RS232 standard there are framing bits (start and stop > >> bits) and error control bits (parity). The flow control is xon-xoff or > >> DTR, CTS, RTS. Thats' it. > >> > >> 3. If you want more than that from RS232 (forward error correction, > >> ARQ, etc.) you do it in software, not in the RS232 standard. > >> > >> 4. RS485 is different from RS232 in that it is in the Network Layer of > >> the OSI model of networking. > >> > >> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > >> a factory). > >> RS-485 is similar to RS-422, but RS-422 allows just one driver with > >> multiple receivers whereas RS-485 supports multiple drivers and > >> receivers. > >> > >> 6. RS-485 is a serial bus with multiple nodes and thus must handle > >> network link layer protocols. By using high-impedance receivers, you > >> can have as many as 256 nodes. > >> > >> 7. The RS-485 can be implemented with RXTX in the core and a layer of > >> software on top to handle media access control (MAC sublayer). There > >> are also hardware converters. > >> http://www.rs485.com/pconverters.html for example. However, some of > >> these require software control. There is some support in the form of > >> the Rs485.java class, > >> in RXTX. > >> > >> 8. The RS-485 specification will add to the size of the JSR > >> > >> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > >> This version of the Java communications API contains support for > >> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > >> mentioned. > >> > >> 10. DO people want to add RS485 to a new JSR? > >> > >> Would it make sense for the RS-485 people to speak up now? > >> Please let me know if you think my summary is wrong. > >> > >> Thanks! > >> - Doug > >> > >> > >> > >> > >> > >> > >>> At 18:31 20/07/2006, Trent Jarvi wrote: > >>> > >>>> > PROJECT SCOPE: > >>>> > ------------- > >>>> > > >>>> > Also, we should think carefully about what the scope of > >>>> > this project would be. Should it be javax."comm" which > >>>> > handles both serial and parallel (is parallel going by the > >>>> > wayside). Should it be split into two project: > >>>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > >>>> > > >>>> > Should we differentiate between single-ended serial > >>>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > >>>> > quasi-multidrop and full multidrop busses such as > >>>> > EIA422, EIA432 and EIA485? If we really were to > >>>> > add I2C support to the API, we'd have to delve into > >>>> > the semantics more, because there could be some > >>>> > implicit decoding of the bus the API users would > >>>> > want to see. > >>>> > > >>>> > >>>> Hi Paul > >>>> > >>>> The way RXTX works, which is a fair representation of the people > >>>> using the API, is complete support for RIA232, minimal support for > >>>> IEEE1284. From what I understand, Sun was going along the same > >>>> lines. If we combined both projects, we would have half a parallel > >>>> port implementation. I see maybe 4 requests for features not in the > >>>> parallel support a year. > >>>> > >>>> The other protocols should not be limited by a JSR which is going to > >>>> be focused upon serial port interests. The IEA485 hacks in RXTX > >>>> along with I2C and Raw should _not_ be considered a strong basis for > >>>> extending the API to cover these protocols. If people want to do > >>>> real implementations, they should not face a 'standard' which wasnt > >>>> really focused upon their interests. I think we understand the > >>>> parallel port issues fairly well but have not implemented many > >>>> features and I don't know if we would. > >>>> > >>> I agree with all of this. API requirements for I2C, SPI, etc. are very > >>> different from those for RS232/485/422. Our embedded Java platform has > >>> APIs for all of these and more and they don't share a lot apart from > >>> the fact that they all use Input/OutputStreams (and in the case of > >>> SPI you still need to cater with the fact that every time you want to > >>> read you must also write to the device.) > >>> > >>> If I was to design javax.comm from scratch, I think I would focus on > >>> serial ports exclusively (== whatever the underlying OS represents as > >>> serial ports). Even parallel is a bit out of place IMHO, although I > >>> understand it needs to stay for backwards compatibility. > >>> > >>> > >>> > >>>> So a versatile API is favorable but I do not think we have the proper > >>>> community to represent much more than Serial. > >>>> > >>> Yes, I think the same. > >>> > >>> Guillermo > >>> -- > >>> Guillermo Rodriguez Garcia > >>> > >>> Snijder Micro Systems phone +31-493-351020 > >>> G. Rodriguez Garcia fax +31-493-351530 > >>> Visser 25 email guille at sms.nl > >>> NL5751 BL Deurne > >>> The Netherlands http://www.snijder.com > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> > >> > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Mark Himsley From berkland at spamcop.net Mon Jul 24 16:55:18 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 24 Jul 2006 18:55:18 -0400 Subject: [Rxtx] jcp and jsr In-Reply-To: <44C5083A.6090902@ergotech.com> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> <44C5083A.6090902@ergotech.com> Message-ID: <269e40090607241555g281c7f24s5577b86e35d27eab@mail.gmail.com> I'm sorry, I keep reading SPI as "Service Provider Interface" instead of "Serial Peripheral Interface". (See http://en.wikipedia.org/wiki/Serial_Peripheral_Interface.) What I thought was being suggested was a pluggable implementation like that found in javax.security. (The SPI there actually stands for "Security Provider Interface" not "Service Provider Interface" like I had thought.) I guess that might be a CPI (Comm Provider Interface) or PPI (Port Provider Interface.) At any rate what I would like to see is a JSR with (in order of priority) - compatible API for code written against current javax.comm 2.0 classes - ability to register or "force" a port by providing a name and implementation (not have to rely completely on the "auto-discovery") - nothing precluding the use of a portmapping in a given implementation - ability to register port implementations On 7/24/06, Jim Redman wrote: > > A thought for later since we haven't really reached this level of > detail, but since this type of approach seems likely... > > If a configuration file is mandatory, can we specify what the file is > called and what the format of the options are (mandatory?, and optional) > without limiting extensions. > > This just adds consistency across platforms/implementations. > > Jim > > Doug Berkland wrote: > > Gregg Wonderly wrote: > > > That there could be a low level port/device SPI > > > that could be put in place once, and then overtime > > > we could layer other APIs, including an updated > > > javax.comm which would make use of this SPI. > > > > I think there is great merit in this suggestion. I would like to see > > the ability to register a new "port" along with a custom handler in the > > Java client code before attempting to access the port. > > e.g . > > CommManager.getInstance().registerPortImpl("USB1:", new > > HidPortAdapter(/*vendorId=*/ "1234", /*deviceId=*/ "4321"); > > CommManager.getInstance().registerPortImpl("Ether1:", new > > InetPortAdapter(/*ipAndPort=*/ " 192.168.1.101:8088 > > "); > > > > It would allow other protocols that this group doesn't have depth in to > > be developed by someone who does on an "as needed" basis. > > > > Additionally, the value of this would be with some devices that > > implement basically the same protocol that was initially used over RS232 > > for a USB (via an HID) or Ethernet interface. There are a number of > > these in POS hardware. The existing JavaPOS driver written against > > JavaCOMM 2.0 could be reused by plugging in an HID or IP adapter before > > attempting to access the device. > > > > It might also be valuable to use something like an extended version of > > the portmapping file found in JavaCOMM 3.0. A configuration file could > > allow this definition to take place outside of any Java client code. > > Such a mapping file wouldn't even need to be part of the JSR API or > > reference implementation. It could be handled in a specific > > implementation. > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060724/02c50e6a/attachment-0338.html From tjarvi at qbang.org Mon Jul 24 18:44:54 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 24 Jul 2006 18:44:54 -0600 (MDT) Subject: [Rxtx] Serial Read/Write Details In-Reply-To: <44C508AC.7060103@yahoo.com.br> References: <44C508AC.7060103@yahoo.com.br> Message-ID: On Mon, 24 Jul 2006, mtnvega wrote: > Hello, > > I'm have being flirting with RXTX for a while since I'm working on a > college project where I will > need to communicate with a microcontroller using USART. > > Now is the time to start using it! But I have some doubts and I hope you > can help-me. > > I will need to both send and receive data from the serial port. First I > will need to send some command > bytes then wait for some data that will be returned from the > microcontroller. And I would like > to know which is the best way to do that. I'm mean, of course send and > receive data is the purpose > of the serial port and RXTX but I'm looking for some details since there > will be no package control > but just a fixed command format and confirmation messages from the > microcontroller side. > > I would like to know if I should open and close the port or if I can > just open it once. > I read that upon writing to output the input buffer are filled with the > same data, is it right? > If yes, isn't it a problem since I'm waiting for data back in a very > small time? > Hi Luiz Unless you want to use the port with a second application, just open the port once and close it when you exit the application. The input will not be filled with the data you write. The API has events to let you know when data is available and when your data has gone out the port. You can look in the contrib directory that comes with the source for crude examples of event notification. I think there is an example on the wiki too. I don't think you will have any problems. -- Trent Jarvi tjarvi at qbang.org From guille at sms.nl Tue Jul 25 00:26:12 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 08:26:12 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C50488.1040508@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> Message-ID: <7.0.1.0.0.20060725082124.036309e0@sms.nl> At 19:34 24/07/2006, Gregg Wonderly wrote: >Guillermo Rodriguez wrote: > > As an embedded Java vendor, SNIJDER Micro Systems certainly sees the > > value of standardized APIs to talk to different types of communication > > buses including SPI, I2C, 1-Wire, etc., for embedded applications. > > However we think this has nothing to do with javax.comm. > >I don't think this is only about javax.comm. Certainly that's >important. I'm >just wading into this conversation mainstream and trying to say: > >If you are going to do anything about "fixing" javax.comm to work on all >platforms, please, please, please start with a hardware port SPI >definition that >lets you get to serial ports, and then provide the existing javax.com API and >whatever new API you think is necessary (I don't have any really >issues with the >existing API directly). > >Then, there will be a place for others interesting in SPI, i2C, USB and other >things to get started with providing access to devices that are also >interesting >in Java applications, and directly, in embedded Java applications. I do agree that the best a hardware port SPI definition (where SPI = Service Provider Interface, not the SPI protocol) is a good thing to have to support serial ports layered over other transports. However these are still serial ports at the end. I still don't think the javax.comm API is well suited to "any" serial bus such as I2C, SPI, etc. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 00:41:46 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 08:41:46 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C5065F.3060802@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> Message-ID: <7.0.1.0.0.20060725082630.036d2d10@sms.nl> At 19:41 24/07/2006, Paul Klissner wrote: >Guillermo Rodriguez wrote: >>Quoting Paul Klissner : >> >>>>>None of this is of any particular relevance to the basic underlying >>>>>question: >>>>> >>>>>Should the next JSR attempt to address the multi-drop abilities of >>>RS-485? >>>>What I would suggest is to just add a new 'ioctlex'-like method >>>>to the SerialPort API: A method that you'd use to pass platform- >>>>or implementation-specific info to the underlying driver or OS >>>>to do things such as "enabling RS485 mode" or "disable FIFOs" or >>>>"poll the TSR register". >>>> >>>>No need to define any function codes. This is for stuff that is >>>>platform- or implementation-specific and as such cannot be easily >>>>abstracted anyway. >>>Detrimental to platform independence. >>Yes, it is. But as you go closer and closer to the hardware level some >>things are by nature platform-dependent, and sometimes just cannot be >>solved in a platform-independent way. In these cases, is it better to >>have no solution at all than having one that is less than perfect? >>Put it another way, would you prefer having people say "I just cannot >>do this in Java; I'll go somewhere else" rather than "I can do this >>in Java -- only not in a platform-independent way" ? > >If there isn't a reasonable way to abstract it out, then >why use Java? If an application can be 99% platform independent with small bits being not portable, why *not* use Java? I'd prefer to see people using Java to write non-portable applications than having them use C instead. I believe that Java should promote platform neutrality, but that does not necessarily mean precluding the use of anything that is NOT platform independent. And let's face it, if you are using javax.comm to talk to some serial device directly, then chances are you are already tied to some specific hardware anyway. Also, some people (myself included) think that Java can also be used as a systems programming language, not only for applications. For many embedded platforms this is certainly the case. In our platform we even write device drivers directly in Java. I would imagine the Sun SPOT team (www.sunspotworld.com) supports a similar view. If people needs to do non-portable stuff and wants to do it in Java I'd rather have them do it in Java than tell them to do it in C instead. >The whole idea is platform neutrality, otherwise, what is the >huge advantage of adopting a standardized Java API? I think >it is wrong to subvert the API. I think we have to arrive at >some sort of consensus about the scope of the API and do our >best to engineer a robust API in terms of that scope using >abstraction. > >There may be outliers, but the outliers probably aren't portable, >and probably would do just as well to not use java for that >particular application. The cases I have in mind is more like portable applications with very small bits of non portable code. I can imagine lots of portable applications that need access to RS485, specially in the industrial process control and factory automation fields. As I said in an earlier mail RS485 is half- duplex, but there is standard way to do RS485 direction control from software. Does it mean that the whole application should not be written in Java, only because some small bits of code related to RS485 direction control are not completely portable? > If this was a JSR, if we found some >compelling problem that kept cropping up the API could be >reved so as not to just orphan cases with legitimate requests. > >If someone really needs to do funky things with the hardware, >why wouldn't that be put in the native back end? But nobody said the functionality can't be implemented in the native back end. However you still need an application level API to enable/disable it. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 00:44:43 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 08:44:43 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <269e40090607241555g281c7f24s5577b86e35d27eab@mail.gmail.co m> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> <44C5083A.6090902@ergotech.com> <269e40090607241555g281c7f24s5577b86e35d27eab@mail.gmail.com> Message-ID: <7.0.1.0.0.20060725084431.036d0700@sms.nl> At 00:55 25/07/2006, Doug Berkland wrote: >I'm sorry, I keep reading SPI as "Service Provider Interface" >instead of "Serial Peripheral Interface". (See >http://en.wikipedia.org/wiki/Serial_Peripheral_Interface. >) > >What I thought was being suggested was a pluggable implementation >like that found in javax.security. (The SPI there actually stands >for "Security Provider Interface" not "Service Provider Interface" >like I had thought.) I guess that might be a CPI (Comm Provider >Interface) or PPI (Port Provider Interface.) > >At any rate what I would like to see is a JSR with (in order of priority) >- compatible API for code written against current javax.comm 2.0 classes >- ability to register or "force" a port by providing a name and >implementation (not have to rely completely on the "auto-discovery") >- nothing precluding the use of a portmapping in a given implementation >- ability to register port implementations That sounds very good to me. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From tjarvi at qbang.org Tue Jul 25 01:21:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 01:21:53 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725082124.036309e0@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> Message-ID: On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: > At 19:34 24/07/2006, Gregg Wonderly wrote: >> Guillermo Rodriguez wrote: >>> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the >>> value of standardized APIs to talk to different types of communication >>> buses including SPI, I2C, 1-Wire, etc., for embedded applications. >>> However we think this has nothing to do with javax.comm. >> >> I don't think this is only about javax.comm. Certainly that's >> important. I'm >> just wading into this conversation mainstream and trying to say: >> >> If you are going to do anything about "fixing" javax.comm to work on all >> platforms, please, please, please start with a hardware port SPI >> definition that >> lets you get to serial ports, and then provide the existing javax.com API and >> whatever new API you think is necessary (I don't have any really >> issues with the >> existing API directly). >> >> Then, there will be a place for others interesting in SPI, i2C, USB and other >> things to get started with providing access to devices that are also >> interesting >> in Java applications, and directly, in embedded Java applications. > > I do agree that the best a hardware port SPI definition (where SPI = Service > Provider Interface, not the SPI protocol) is a good thing to have to support > serial ports layered over other transports. However these are still serial > ports at the end. I still don't think the javax.comm API is well suited to > "any" serial bus such as I2C, SPI, etc. > Perhaps the javax.com namespace is just wrong. I think thats a larger issue we are not well prepared to answer. We do have a larger group participating so there is interest beyond our current solution. My concern is getting into blue sky efforts that never materialize. We have a very concrete solution that just needs a few modifications to make current java users happy. This solution is more or less supporting POSIX termios on all platforms including windows. This solution does not ask deep questions like is it USB or RS485 or IrDA. Smart kernel people worry about that. Thats what works. When the fun goes away and I'm fixing spam on slow mail-lists, thats what will continue to work. Thats what will be tested on hundreds of machines every six months. I don't want to remind people of JSR80 windows support but you should keep that in mind while getting too far from the crusty roman roads. I'd love to move off to the side in the namespace and leave javax.com for a great effort unifying the time space continuum to be announced at a later date. Beyond that, we would need serious commitment from people in the community to get more working. Both rxtx.org and Sun are about maxed out right now. -- Trent Jarvi tjarvi at qbang.org From martin at jopdesign.com Tue Jul 25 01:32:22 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 09:32:22 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> Message-ID: <005b01c6afbc$794fc060$0202a8c0@luna> >>> None of this is of any particular relevance to the basic underlying >>> question: >>> >>> Should the next JSR attempt to address the multi-drop abilities of RS-485? I would vote for a strong yes. >> >> What I would suggest is to just add a new 'ioctlex'-like method >> to the SerialPort API: A method that you'd use to pass platform- >> or implementation-specific info to the underlying driver or OS >> to do things such as "enabling RS485 mode" or "disable FIFOs" or >> "poll the TSR register". >> >> No need to define any function codes. This is for stuff that is >> platform- or implementation-specific and as such cannot be easily >> abstracted anyway. > > Detrimental to platform independence. We can model it platform independent with two methods: enterTransmit() and extiTransmit() to do whatever is necessary on the underlying platform to switch to RS485 transmit mode and back. Martin From guille at sms.nl Tue Jul 25 01:45:53 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 09:45:53 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <005b01c6afbc$794fc060$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> Message-ID: <7.0.1.0.0.20060725094317.0363b390@sms.nl> Hi Martin, At 09:32 25/07/2006, Martin Schoeberl wrote: > >>> None of this is of any particular relevance to the basic underlying > >>> question: > >>> > >>> Should the next JSR attempt to address the multi-drop abilities > of RS-485? > >I would vote for a strong yes. > > >> > >> What I would suggest is to just add a new 'ioctlex'-like method > >> to the SerialPort API: A method that you'd use to pass platform- > >> or implementation-specific info to the underlying driver or OS > >> to do things such as "enabling RS485 mode" or "disable FIFOs" or > >> "poll the TSR register". > >> > >> No need to define any function codes. This is for stuff that is > >> platform- or implementation-specific and as such cannot be easily > >> abstracted anyway. > > > > Detrimental to platform independence. > >We can model it platform independent with two methods: > >enterTransmit() and extiTransmit() to do whatever is necessary >on the underlying platform to switch to RS485 transmit mode and >back. Tempting as it is, I don't think this covers all cases. For example, in those cases where RS485 direction control must be done 100% in software, the software needs to have a way to flush (sync) software buffers, poll the hardware FIFOs and TSR (not THR), etc. Or, for example, for those UARTs that do automatic RS485 direction control with a configurable turnaround delay, how would you configure this turnaround delay from the application? Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 01:48:10 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 09:48:10 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> Message-ID: <7.0.1.0.0.20060725094602.036cec00@sms.nl> Hi Trent, At 09:21 25/07/2006, Trent Jarvi wrote: >On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: > > > At 19:34 24/07/2006, Gregg Wonderly wrote: > >> Guillermo Rodriguez wrote: > >>> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the > >>> value of standardized APIs to talk to different types of communication > >>> buses including SPI, I2C, 1-Wire, etc., for embedded applications. > >>> However we think this has nothing to do with javax.comm. > >> > >> I don't think this is only about javax.comm. Certainly that's > >> important. I'm > >> just wading into this conversation mainstream and trying to say: > >> > >> If you are going to do anything about "fixing" javax.comm to work on all > >> platforms, please, please, please start with a hardware port SPI > >> definition that > >> lets you get to serial ports, and then provide the existing > javax.com API and > >> whatever new API you think is necessary (I don't have any really > >> issues with the > >> existing API directly). > >> > >> Then, there will be a place for others interesting in SPI, i2C, > USB and other > >> things to get started with providing access to devices that are also > >> interesting > >> in Java applications, and directly, in embedded Java applications. > > > > I do agree that the best a hardware port SPI definition (where > SPI = Service > > Provider Interface, not the SPI protocol) is a good thing to have > to support > > serial ports layered over other transports. However these are still serial > > ports at the end. I still don't think the javax.comm API is well suited to > > "any" serial bus such as I2C, SPI, etc. > > > >Perhaps the javax.com namespace is just wrong. I think thats a larger >issue we are not well prepared to answer. We do have a larger group >participating so there is interest beyond our current solution. My concern was not about the name specifically, but about the idea that a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, IrDA, etc. Looking from a distance all of these may look similar but the fact is, they have little to do with each other (apart from being 'communication protocols' or 'buses') Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From Paul.Klissner at Sun.COM Tue Jul 25 01:51:26 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Tue, 25 Jul 2006 00:51:26 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725082630.036d2d10@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> Message-ID: <44C5CD7E.9030903@sun.com> Guillermo Rodriguez Garcia wrote: > At 19:41 24/07/2006, Paul Klissner wrote: >> Guillermo Rodriguez wrote: >>> Quoting Paul Klissner : >>> >>>>>> None of this is of any particular relevance to the basic underlying >>>>>> question: >>>>>> >>>>>> Should the next JSR attempt to address the multi-drop abilities of >>>> RS-485? >>>>> What I would suggest is to just add a new 'ioctlex'-like method >>>>> to the SerialPort API: A method that you'd use to pass platform- >>>>> or implementation-specific info to the underlying driver or OS >>>>> to do things such as "enabling RS485 mode" or "disable FIFOs" or >>>>> "poll the TSR register". >>>>> >>>>> No need to define any function codes. This is for stuff that is >>>>> platform- or implementation-specific and as such cannot be easily >>>>> abstracted anyway. >>>> Detrimental to platform independence. >>> Yes, it is. But as you go closer and closer to the hardware level some >>> things are by nature platform-dependent, and sometimes just cannot be >>> solved in a platform-independent way. In these cases, is it better to >>> have no solution at all than having one that is less than perfect? >>> Put it another way, would you prefer having people say "I just cannot >>> do this in Java; I'll go somewhere else" rather than "I can do this >>> in Java -- only not in a platform-independent way" ? >> If there isn't a reasonable way to abstract it out, then >> why use Java? > > If an application can be 99% platform independent with small bits > being not portable, why *not* use Java? I'd prefer to see people > using Java to write non-portable applications than having them > use C instead. > > I believe that Java should promote platform neutrality, but that > does not necessarily mean precluding the use of anything that is > NOT platform independent. And let's face it, if you are using > javax.comm to talk to some serial device directly, then chances > are you are already tied to some specific hardware anyway. > > Also, some people (myself included) think that Java can also be > used as a systems programming language, not only for applications. > For many embedded platforms this is certainly the case. In our > platform we even write device drivers directly in Java. I would > imagine the Sun SPOT team (www.sunspotworld.com) supports a > similar view. > > If people needs to do non-portable stuff and wants to do it in > Java I'd rather have them do it in Java than tell them to do it > in C instead. That sounds a bit evangelizing. I think C is perfectly viable for some jobs, and might even be preferable in some cases, for example in some cases where performance or space is a factor. I feel it isn't right to corrupt an API with hacks for the goal of enticing users to Java, even for all the 'right' reasons. >> If someone really needs to do funky things with the hardware, >> why wouldn't that be put in the native back end? > > But nobody said the functionality can't be implemented in the > native back end. However you still need an application level API > to enable/disable it. Sure, but the functions, if really along the lines of the defined standard, can be abstracted, rather than cheat with a general purpose hack-all ioctl-like interface that just begs to be abused, lending itself to a litany of non-portable applications. I maintain we should scope the project appropriately, then take our best shot at a reasonably complete set of abstract functions, and improve it if necessary over time (alpha and beta, release candidates? And then update the API in a backward-compatible way based on feedback after FCS if necessary), rather than add an everything-but-the-kitchen-sink escape clause method. A determined programmer facing a corner case can figure out a way to accomplish the goal in most cases. Even if the API doesn't provide an ioctl call, it is possible to create implementation classes that mak methods visible outsidethe scope of the API-defined methods. For example, if I am implementing class Foo in FooImpl.java, And Foo.java defines interface methods a(), b() and c(), FooImpl.java can also have public methods d(), e() and f(), which can be accessed from the application by casting a Foo object into a FooImpl object. This is one way to provide a back door without compromising the core API itself to do it. This puts the responsibility of breaking platform independence on the developers and not on the designers. Paul From tjarvi at qbang.org Tue Jul 25 02:57:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 02:57:28 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725094602.036cec00@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> Message-ID: On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: > Hi Trent, > > At 09:21 25/07/2006, Trent Jarvi wrote: >> On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: >> >>> At 19:34 24/07/2006, Gregg Wonderly wrote: >>>> Guillermo Rodriguez wrote: >>>>> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the >>>>> value of standardized APIs to talk to different types of communication >>>>> buses including SPI, I2C, 1-Wire, etc., for embedded applications. >>>>> However we think this has nothing to do with javax.comm. >>>> >>>> I don't think this is only about javax.comm. Certainly that's >>>> important. I'm >>>> just wading into this conversation mainstream and trying to say: >>>> >>>> If you are going to do anything about "fixing" javax.comm to work on all >>>> platforms, please, please, please start with a hardware port SPI >>>> definition that >>>> lets you get to serial ports, and then provide the existing >> javax.com API and >>>> whatever new API you think is necessary (I don't have any really >>>> issues with the >>>> existing API directly). >>>> >>>> Then, there will be a place for others interesting in SPI, i2C, >> USB and other >>>> things to get started with providing access to devices that are also >>>> interesting >>>> in Java applications, and directly, in embedded Java applications. >>> >>> I do agree that the best a hardware port SPI definition (where >> SPI = Service >>> Provider Interface, not the SPI protocol) is a good thing to have >> to support >>> serial ports layered over other transports. However these are still serial >>> ports at the end. I still don't think the javax.comm API is well suited to >>> "any" serial bus such as I2C, SPI, etc. >>> >> >> Perhaps the javax.com namespace is just wrong. I think thats a larger >> issue we are not well prepared to answer. We do have a larger group >> participating so there is interest beyond our current solution. > > My concern was not about the name specifically, but about the idea that > a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, > IrDA, etc. Looking from a distance all of these may look similar but > the fact is, they have little to do with each other (apart from being > 'communication protocols' or 'buses') > Hi Guillermo Interesting name. Fair enough. My thoughts are that if it can't be unified in the kernel we are out of our skulls trying to do it in user space. Hacks trying to do such will sure to be in open solaris or linux symposiums about why user space sucks. But there is a minimal bit that overlapps that is what most users want. If we limit the scope, it isnt that hard of a problem. By limiting the scope we also limit our deliverables. If you have an interest in a specific area it will probably not be enough. -- Trent Jarvi tjarvi at qbang.org From martin at jopdesign.com Tue Jul 25 03:25:38 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 11:25:38 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> Message-ID: <001901c6afcc$4bcf64f0$0c28a8c0@luna> >> >> >> >> What I would suggest is to just add a new 'ioctlex'-like method >> >> to the SerialPort API: A method that you'd use to pass platform- >> >> or implementation-specific info to the underlying driver or OS >> >> to do things such as "enabling RS485 mode" or "disable FIFOs" or >> >> "poll the TSR register". >> >> >> >> No need to define any function codes. This is for stuff that is >> >> platform- or implementation-specific and as such cannot be easily >> >> abstracted anyway. >> > >> > Detrimental to platform independence. >> >>We can model it platform independent with two methods: >> >>enterTransmit() and extiTransmit() to do whatever is necessary >>on the underlying platform to switch to RS485 transmit mode and >>back. > > Tempting as it is, I don't think this covers all cases. For example, > in those cases where RS485 direction control must be done 100% in > software, the software needs to have a way to flush (sync) software > buffers, poll the hardware FIFOs and TSR (not THR), etc. I just meant to hide those low-level issues you mention in the enter/exitTransmit modes. > > Or, for example, for those UARTs that do automatic RS485 direction > control with a configurable turnaround delay, how would you configure > this turnaround delay from the application? Mmh, perhaps in a similar way as you configure timeouts? Isn't this 'just' a timeout value? Martin From guille at sms.nl Tue Jul 25 04:05:29 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 12:05:29 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <001901c6afcc$4bcf64f0$0c28a8c0@luna> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> Message-ID: <7.0.1.0.0.20060725115736.03706a38@sms.nl> At 11:25 25/07/2006, Martin Schoeberl wrote: > >> >> > >> >> What I would suggest is to just add a new 'ioctlex'-like method > >> >> to the SerialPort API: A method that you'd use to pass platform- > >> >> or implementation-specific info to the underlying driver or OS > >> >> to do things such as "enabling RS485 mode" or "disable FIFOs" or > >> >> "poll the TSR register". > >> >> > >> >> No need to define any function codes. This is for stuff that is > >> >> platform- or implementation-specific and as such cannot be easily > >> >> abstracted anyway. > >> > > >> > Detrimental to platform independence. > >> > >>We can model it platform independent with two methods: > >> > >>enterTransmit() and extiTransmit() to do whatever is necessary > >>on the underlying platform to switch to RS485 transmit mode and > >>back. > > > > Tempting as it is, I don't think this covers all cases. For example, > > in those cases where RS485 direction control must be done 100% in > > software, the software needs to have a way to flush (sync) software > > buffers, poll the hardware FIFOs and TSR (not THR), etc. > >I just meant to hide those low-level issues you mention in the >enter/exitTransmit modes. If the system has dedicated RS485 hardware then the underlying kernel or device driver may know about it and all of the hassle can be conveniently encapsulated in some enter/exitTransmit methods -- but in this case you can also skip these and just have the driver enable transmit mode as long as it has data to transmit, and stay in receive mode otherwise. If the system has a UART that can be configured as RS232 or RS485 then you may need to tell the kernel or device driver to enter RS485 mode explicitly. Your approach may work there as well. If the system does not have dedicated RS485 hardware and you are using an external RS232-RS485 protocol converter (a very common case) then the driver and kernel probably don't know about that and you have to take care at the application level (javax.comm doesn't even need to know this converter exists), and in order to that you may need to do different things depending on the specific converter you're using. > > > > Or, for example, for those UARTs that do automatic RS485 direction > > control with a configurable turnaround delay, how would you configure > > this turnaround delay from the application? > >Mmh, perhaps in a similar way as you configure timeouts? >Isn't this 'just' a timeout value? Yes, but this is just a specific parameter that you can configure in a specific type of UART (an EXAR UART). Other UARTs might be different. The point I'm trying to make is that there are just too many parameters to have an API for each specific case. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 04:12:31 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 12:12:31 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C5CD7E.9030903@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> <44C5CD7E.9030903@sun.com> Message-ID: <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> At 09:51 25/07/2006, Paul Klissner wrote: >Guillermo Rodriguez Garcia wrote: > > At 19:41 24/07/2006, Paul Klissner wrote: > >> Guillermo Rodriguez wrote: > >>> Quoting Paul Klissner : > >>> > >>>>>> None of this is of any particular relevance to the basic underlying > >>>>>> question: > >>>>>> > >>>>>> Should the next JSR attempt to address the multi-drop abilities of > >>>> RS-485? > >>>>> What I would suggest is to just add a new 'ioctlex'-like method > >>>>> to the SerialPort API: A method that you'd use to pass platform- > >>>>> or implementation-specific info to the underlying driver or OS > >>>>> to do things such as "enabling RS485 mode" or "disable FIFOs" or > >>>>> "poll the TSR register". > >>>>> > >>>>> No need to define any function codes. This is for stuff that is > >>>>> platform- or implementation-specific and as such cannot be easily > >>>>> abstracted anyway. > >>>> Detrimental to platform independence. > >>> Yes, it is. But as you go closer and closer to the hardware level some > >>> things are by nature platform-dependent, and sometimes just cannot be > >>> solved in a platform-independent way. In these cases, is it better to > >>> have no solution at all than having one that is less than perfect? > >>> Put it another way, would you prefer having people say "I just cannot > >>> do this in Java; I'll go somewhere else" rather than "I can do this > >>> in Java -- only not in a platform-independent way" ? > >> If there isn't a reasonable way to abstract it out, then > >> why use Java? > > > > If an application can be 99% platform independent with small bits > > being not portable, why *not* use Java? I'd prefer to see people > > using Java to write non-portable applications than having them > > use C instead. > > > > I believe that Java should promote platform neutrality, but that > > does not necessarily mean precluding the use of anything that is > > NOT platform independent. And let's face it, if you are using > > javax.comm to talk to some serial device directly, then chances > > are you are already tied to some specific hardware anyway. > > > > Also, some people (myself included) think that Java can also be > > used as a systems programming language, not only for applications. > > For many embedded platforms this is certainly the case. In our > > platform we even write device drivers directly in Java. I would > > imagine the Sun SPOT team (www.sunspotworld.com) supports a > > similar view. > > > > If people needs to do non-portable stuff and wants to do it in > > Java I'd rather have them do it in Java than tell them to do it > > in C instead. > >That sounds a bit evangelizing. Could be, but then what's wrong with that? As I said there is people that thinks that Java can be perfectly adequate for system level programming -- especially for embedded platforms. I guess the whole issue is whether it is better to have no solution at all for a specific problem than a solution that is not perfect (in this context a "perfect" solution is one that is portable and platform-independent). I think a solution that is not perfect is better than no solution. If I understand correctly you say that you prefer to have no Java solution (and have people use C) rather than one that is not portable. >I think C is perfectly viable >for some jobs, and might even be preferable in some cases, for example >in some cases where performance or space is a factor. I feel it isn't >right to corrupt an API with hacks for the goal of enticing users >to Java, even for all the 'right' reasons. > > >> If someone really needs to do funky things with the hardware, > >> why wouldn't that be put in the native back end? > > > > But nobody said the functionality can't be implemented in the > > native back end. However you still need an application level API > > to enable/disable it. > >Sure, but the functions, if really along the lines of the defined >standard, can be abstracted, rather than cheat with a general >purpose hack-all ioctl-like interface that just begs to be abused, >lending itself to a litany of non-portable applications. Well, I didn't specifically say there's no way to abstract these functions. I only said that it is not easy, and that I don't know of any reasonable way to do it. But if others can find a way, that is fine of course. >I maintain we should scope the project appropriately, then take >our best shot at a reasonably complete set of abstract functions, >and improve it if necessary over time (alpha and beta, release >candidates? And then update the API in a backward-compatible way >based on feedback after FCS if necessary), rather than add an >everything-but-the-kitchen-sink escape clause method. > >A determined programmer facing a corner case can figure out a way >to accomplish the goal in most cases. Even if the API doesn't provide >an ioctl call, it is possible to create implementation classes that >mak methods visible outsidethe scope of the API-defined methods. > >For example, if I am implementing class Foo in FooImpl.java, >And Foo.java defines interface methods a(), b() and c(), >FooImpl.java can also have public methods d(), e() and f(), which can >be accessed from the application by casting a Foo object into >a FooImpl object. This is one way to provide a back door without >compromising the core API itself to do it. This puts the >responsibility of breaking platform independence on the developers >and not on the designers. Yes, that may be a good way to do it. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 04:21:31 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 12:21:31 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> Message-ID: <7.0.1.0.0.20060725121958.03714668@sms.nl> Hi Trent, At 10:57 25/07/2006, Trent Jarvi wrote: > >> Perhaps the javax.com namespace is just wrong. I think thats a larger > >> issue we are not well prepared to answer. We do have a larger group > >> participating so there is interest beyond our current solution. > > > > My concern was not about the name specifically, but about the idea that > > a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, > > IrDA, etc. Looking from a distance all of these may look similar but > > the fact is, they have little to do with each other (apart from being > > 'communication protocols' or 'buses') > > > >Hi Guillermo > >Interesting name. > >Fair enough. My thoughts are that if it can't be unified in the kernel we >are out of our skulls trying to do it in user space. Hacks trying to do >such will sure to be in open solaris or linux symposiums about why user >space sucks. > >But there is a minimal bit that overlapps that is what most users want. >If we limit the scope, it isnt that hard of a problem. By limiting the >scope we also limit our deliverables. If you have an interest in a >specific area it will probably not be enough. Yes, you are right. But isn't this 'minimal bit that overlaps' what we have already? (basically support for UART-based serial ports plus minimal support for parallel ports) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From lyon at docjava.com Tue Jul 25 05:44:43 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 25 Jul 2006 07:44:43 -0400 Subject: [Rxtx] 7 RS485 questions... In-Reply-To: <7.0.1.0.0.20060725115736.03706a38@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: Hi All, 1. Does anyone have a sense for how much larger the JSR would be if it embraced a multi-drop protocol, like RS485? 2. Do we address collision detection and addressing in RS485? 3. How would collision detection and addressing impact the size of the specification? 4. Would JSR80 (and, perhaps a RS485-USB converter) be the more appropriate place for RS485 support? 5. Is RS485 Transmission controlled by RTS, and the TxD line? 6. How tight is the windows timing on control of the RTS line? 7. Does an RTS controlled RS485 converter work well at high baud rates under windows? Thanks! - Doug From naranjo.manuel at gmail.com Tue Jul 25 06:29:45 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Tue, 25 Jul 2006 09:29:45 -0300 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725094602.036cec00@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> Message-ID: <44C60EB9.5000803@gmail.com> Guillermo Rodriguez Garcia escribi?: > My concern was not about the name specifically, but about the idea that > a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, > IrDA, etc. Looking from a distance all of these may look similar but > the fact is, they have little to do with each other (apart from being > 'communication protocols' or 'buses') > I think Guillermo is right, all ports has in common that they are buses. A stupid idea but why don't declarate the package javax.bus and make javax.comm a dedicated namespace to rs232 and parallell to mantain backward compatibility, obviously the classes at javax.comm should extend classes from javax.bus. Regards, Manuel From j.a.horsmeier at wanadoo.nl Tue Jul 25 07:00:17 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Tue, 25 Jul 2006 15:00:17 +0200 Subject: [Rxtx] 7 RS485 questions... In-Reply-To: Message-ID: <05a701c6afea$47002e00$0a01a8c0@CALVIN> Douglas Lyon wrote: > 1. Does anyone have a sense for how much larger the JSR would > be if it embraced a multi-drop protocol, like RS485? The RS485 multidrop capability all resides on top of the communication layer, i.e. all transmitters but one are disabled (all devices are just listening). When the message has been sent at most one device answers (see 2) > 2. Do we address collision detection and addressing in RS485? Addressing a device is also implemented on top of the communication layer. If/when two devices happen to have the same address it would be disastrous. An address is defined by the protocol, e.g. modbus allows for 250 or so different addresses but another protocol might allow for 2^32 different devices hooked up on one two wire cable. > 3. How would collision detection and addressing impact the size of > the specification? IMHO it's none of rxtx's business, it's a configuration error on the devices if that happens. > 4. Would JSR80 (and, perhaps a RS485-USB converter) be the > more appropriate place for RS485 support? Don't know. > 5. Is RS485 Transmission controlled by RTS, and the TxD line? Two wire RS485 doesn't have a RTS line. It's all in the timing. The half duplex protocol is extremely simple: one master sends, all devices listen, after that at most one device enables its transmitter and sends something back. > 6. How tight is the windows timing on control of the RTS line? Before a device enables its transmitter it should wait a bit because of cable lengths and the other device that must *disable* its transmitter. It's all up to the devices and rxtx can do nothing about it. > 7. Does an RTS controlled RS485 converter work well at high baud > rates under windows? Baud rates aren't the problem; cable lengths are the problem, sensitivity for distortion are the problem. The wait time between en/disabling transmitters can be configured in the devices and can be software controlled on the pc. kind regards, Jos From tjarvi at qbang.org Tue Jul 25 07:08:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 07:08:53 -0600 (MDT) Subject: [Rxtx] 7 RS485 questions... In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: > 5. Is RS485 Transmission controlled by RTS, and the TxD line? This is done when using EIA232 to drive RS485 with no adaptor. This is the RS485 hack that is in RXTX 2.1 that never went anyplace. I discovered no typical kernel will openly support this line of thought. It is not maintainable. There are hardware solutions. Off the top of my head it required < 10 ms responses and typical kernels + java do 10 ms responses. Realtime kernels or special kernel drivers are required. It is possible but not supportable. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Tue Jul 25 07:46:52 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 08:46:52 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <005b01c6afbc$794fc060$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> Message-ID: <44C620CC.6090901@cox.net> Martin Schoeberl wrote: > We can model it platform independent with two methods: > > enterTransmit() and extiTransmit() to do whatever is necessary > on the underlying platform to switch to RS485 transmit mode and > back. Or, do what is typically done, and use a single write operation as the indication of a 'packet' that will let the underlying RS-485/422 driver assert the appropriate signalling. Gregg Wonderly From guille at sms.nl Tue Jul 25 07:48:04 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 15:48:04 +0200 Subject: [Rxtx] 7 RS485 questions... In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: <7.0.1.0.0.20060725154329.036deb18@sms.nl> Hi Doug, Some answers below. At 13:44 25/07/2006, Dr. Douglas Lyon wrote: >Hi All, > >1. Does anyone have a sense for how much larger the JSR would be >if it embraced a multi-drop protocol, like RS485? As I've said in other mails RS485 is in essence just a UART-based serial port interface just like RS232. The only functional difference is that it is multi-drop and half-duplex so there must be a way for nodes to switch between transmit and receive modes but then the RS485 standard does not tell you when or how you should do that -- this depends on the upper layer protocols (for example Modbus) >2. Do we address collision detection and addressing in RS485? Collision detection and addressing are not defined by the RS485 standard. Upper layer protocols such as Modbus take care of that. >3. How would collision detection and addressing impact the size of >the specification? See above. >4. Would JSR80 (and, perhaps a RS485-USB converter) be the more appropriate >place for RS485 support? I don't think so. As I said RS485 is just a serial port like RS232 is. >5. Is RS485 Transmission controlled by RTS, and the TxD line? Some RS232-RS485 protocol converters use the RTS line as a control signal to switch between transmit and receive modes. Others use DTR. Others do not use any of them. >6. How tight is the windows timing on control of the RTS line? Depends on the upper layer protocols, e.g. Modbus. Not defined by RS485. >7. Does an RTS controlled RS485 converter work well at high baud >rates under windows? Depends on how tight the timing is. For some applications it may work well but for many probably won't. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 09:22:09 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Tue, 25 Jul 2006 17:22:09 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C620CC.6090901@cox.net> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> Message-ID: <1153840929.44c6372186f67@webmail.eatserver.nl> Hi Gregg, Quoting Gregg Wonderly : > Martin Schoeberl wrote: > > We can model it platform independent with two methods: > > > > enterTransmit() and extiTransmit() to do whatever is necessary > > on the underlying platform to switch to RS485 transmit mode and > > back. > > Or, do what is typically done, and use a single write operation as the > indication of a 'packet' that will let the underlying RS-485/422 driver > assert > the appropriate signalling. The problem with this is that there is no guarantee that a single call to the write method of the OutputStream associated with a javax.comm SerialPort will translate to a single write to the underlying device driver -- this depends on the javax.comm implementation. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From Paul.Klissner at Sun.COM Tue Jul 25 09:35:19 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Tue, 25 Jul 2006 08:35:19 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C60EB9.5000803@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> <44C60EB9.5000803@gmail.com> Message-ID: <44C63A37.8080406@sun.com> Manuel Francisco Naranjo wrote: > Guillermo Rodriguez Garcia escribi?: >> My concern was not about the name specifically, but about the idea that >> a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, >> IrDA, etc. Looking from a distance all of these may look similar but >> the fact is, they have little to do with each other (apart from being >> 'communication protocols' or 'buses') >> > I think Guillermo is right, all ports has in common that they are buses. > A stupid idea but why don't declarate the package javax.bus and make > javax.comm a dedicated namespace to rs232 and parallell to mantain > backward compatibility, obviously the classes at javax.comm should > extend classes from javax.bus. I like the initial sound of that idea too and was starting to think along those lines myself. But what would be the points of commonality to extend? Device mapping, ownership? Read, write, type, status? Too late for javax.usb (JSR80) very complex Bus and for the most part cast in stone. And 'bus' has such a wide scope. Also that would imply two downloads to install any given bus support, which might not be the end of the world. And maybe two JSRs? Paul From martin at jopdesign.com Tue Jul 25 09:37:12 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 17:37:12 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> Message-ID: <00c801c6b000$33a68f00$0c28a8c0@luna> >> Martin Schoeberl wrote: >> > We can model it platform independent with two methods: >> > >> > enterTransmit() and extiTransmit() to do whatever is necessary >> > on the underlying platform to switch to RS485 transmit mode and >> > back. >> >> Or, do what is typically done, and use a single write operation as the >> indication of a 'packet' that will let the underlying RS-485/422 driver >> assert >> the appropriate signalling. > > The problem with this is that there is no guarantee that a single call > to the write method of the OutputStream associated with a javax.comm > SerialPort will translate to a single write to the underlying device > driver -- this depends on the javax.comm implementation. > I completely agree - it's still a stream and not a packet. This is similar to a single write to a TCP/IP socket. There is no guarantee that you get this data as a single packet/single read on the other side. However, I've seen a lot of programs assuming that this happens ;-) Martin From gergg at cox.net Tue Jul 25 10:15:41 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 11:15:41 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725082124.036309e0@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> Message-ID: <44C643AD.6020604@cox.net> Guillermo Rodriguez Garcia wrote: > At 19:34 24/07/2006, Gregg Wonderly wrote: >>Then, there will be a place for others interesting in SPI, i2C, USB and other >>things to get started with providing access to devices that are also >>interesting >>in Java applications, and directly, in embedded Java applications. > > I do agree that the best a hardware port SPI definition (where SPI = Service > Provider Interface, not the SPI protocol) is a good thing to have to support > serial ports layered over other transports. However these are still serial > ports at the end. I still don't think the javax.comm API is well suited to > "any" serial bus such as I2C, SPI, etc. Yes, absolutely these other wire protocols are different. As I tried to say before, I think that the javax.comm API works fine for my needs. I think that we need to keep it around, no matter what else happens. So, for me, there are a few choices. 1. Create a new JSR to formalize the existing API and include some hardwired JNI code to provide port enumeration and access. 2. Create a new JSR to create a port abstraction SPI to allow JVM providers to enumerate all kinds of port/circuit based hardware to the JVM. Create an implementation of the existing javax.comm API that uses this SPI. 3. Just implement some JNI and Java libraries post them on sourceforge/java.net and let people have at them. For 1 and 2, you'll have to get the JCP to approve that the JSR is worth making a standard. Option 3 doesn't really solve a problem as much as it creates a new way to deal with an existing problem. I think 2 is the most desireable way to go. It really will open the door for more access to hardware from Java! Gregg Wonderly From joachim at buechse.de Tue Jul 25 10:17:07 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 25 Jul 2006 18:17:07 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <00c801c6b000$33a68f00$0c28a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: Just trigger writing on flush(). It is perfectly legal for an Outputstream implementation to do do nothing until flush is called and the documentation of OutputStream.flush reads: "Flushes this output stream and forces any buffered output bytes to be written out. The general contract of flush is that calling it is an indication that, if any bytes previously written have been buffered by the implementation of the output stream, such bytes should immediately be written to their intended destination." As RS485 is a "dont speak up unless requested" protocol, a mandatory flush after write seems like the way to go to me No client can prevent another client from writing, so there is no point in keeping the output-drivers enabled after all data currently buffered has been written. So flush() should trigger "enterTransmit, writePacket[s], exitTransmit". If the service provider (ie concrete implementation of the flush method) decides that the write is inapropriate at the moment (ie because of a higher level arbitration protocol that might be implemented by the service provider) it will simply block the flush or throw an IOException (preferably after some sort of timeout). Regards, Joachim PS: It is great to see all the motivation that is brought forward on this list regarding the future. It would be great if only 10% of that motivation could be transformed into a cleanup and extension of the existing code. The current code access model seems rather inappropriate for the prototyping of the ideas beeing presented. Trent can we get a "contributions" branch with "free" access. On 25.07.2006, at 17:37, Martin Schoeberl wrote: >>> Martin Schoeberl wrote: >>>> We can model it platform independent with two methods: >>>> >>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>> on the underlying platform to switch to RS485 transmit mode and >>>> back. >>> >>> Or, do what is typically done, and use a single write operation >>> as the >>> indication of a 'packet' that will let the underlying RS-485/422 >>> driver >>> assert >>> the appropriate signalling. >> >> The problem with this is that there is no guarantee that a single >> call >> to the write method of the OutputStream associated with a javax.comm >> SerialPort will translate to a single write to the underlying device >> driver -- this depends on the javax.comm implementation. >> > I completely agree - it's still a stream and not a packet. > > This is similar to a single write to a TCP/IP socket. There > is no guarantee that you get this data as a single packet/single > read on the other side. However, I've seen a lot of programs > assuming that this happens ;-) > > Martin > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Tue Jul 25 10:34:59 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Tue, 25 Jul 2006 18:34:59 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <1153845299.44c64833920bd@webmail.eatserver.nl> Hi Joachim, That is a very nice approach which I think would work well as far as the underlying device driver knows about RS485. However it still does not solve the problem with external protocol converters where the device driver only knows about regular UARTs and RTS or DTR must be used to toggle direction of the converter. Guillermo Quoting Joachim Buechse : > Just trigger writing on flush(). It is perfectly legal for an > Outputstream implementation to do do nothing until flush is called > and the documentation of OutputStream.flush reads: > > "Flushes this output stream and forces any buffered output bytes to > be written out. The general contract of flush is that calling it is > an indication that, if any bytes previously written have been > buffered by the implementation of the output stream, such bytes > should immediately be written to their intended destination." > > As RS485 is a "dont speak up unless requested" protocol, a mandatory > flush after write seems like the way to go to me > > No client can prevent another client from writing, so there is no > point in keeping the output-drivers enabled after all data currently > buffered has been written. So flush() should trigger "enterTransmit, > writePacket[s], exitTransmit". If the service provider (ie concrete > implementation of the flush method) decides that the write is > inapropriate at the moment (ie because of a higher level arbitration > protocol that might be implemented by the service provider) it will > simply block the flush or throw an IOException (preferably after some > sort of timeout). > > Regards, > Joachim > > PS: It is great to see all the motivation that is brought forward on > this list regarding the future. It would be great if only 10% of that > motivation could be transformed into a cleanup and extension of the > existing code. The current code access model seems rather > inappropriate for the prototyping of the ideas beeing presented. > Trent can we get a "contributions" branch with "free" access. > > > On 25.07.2006, at 17:37, Martin Schoeberl wrote: > > >>> Martin Schoeberl wrote: > >>>> We can model it platform independent with two methods: > >>>> > >>>> enterTransmit() and extiTransmit() to do whatever is necessary > >>>> on the underlying platform to switch to RS485 transmit mode and > >>>> back. > >>> > >>> Or, do what is typically done, and use a single write operation > >>> as the > >>> indication of a 'packet' that will let the underlying RS-485/422 > >>> driver > >>> assert > >>> the appropriate signalling. > >> > >> The problem with this is that there is no guarantee that a single > >> call > >> to the write method of the OutputStream associated with a javax.comm > >> SerialPort will translate to a single write to the underlying device > >> driver -- this depends on the javax.comm implementation. > >> > > I completely agree - it's still a stream and not a packet. > > > > This is similar to a single write to a TCP/IP socket. There > > is no guarantee that you get this data as a single packet/single > > read on the other side. However, I've seen a lot of programs > > assuming that this happens ;-) > > > > Martin > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- http://www.snijder.com/ SNIJDER Micro Systems From guille at sms.nl Tue Jul 25 10:44:56 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Tue, 25 Jul 2006 18:44:56 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C643AD.6020604@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <44C643AD.6020604@cox.net> Message-ID: <1153845896.44c64a8890968@webmail.eatserver.nl> Hi Gregg, Quoting Gregg Wonderly : > Guillermo Rodriguez Garcia wrote: > > At 19:34 24/07/2006, Gregg Wonderly wrote: > >>Then, there will be a place for others interesting in SPI, i2C, USB and > other > >>things to get started with providing access to devices that are also > >>interesting > >>in Java applications, and directly, in embedded Java applications. > > > > I do agree that the best a hardware port SPI definition (where SPI = > Service > > Provider Interface, not the SPI protocol) is a good thing to have to > support > > serial ports layered over other transports. However these are still serial > > ports at the end. I still don't think the javax.comm API is well suited to > > "any" serial bus such as I2C, SPI, etc. > > Yes, absolutely these other wire protocols are different. As I tried to say > > before, I think that the javax.comm API works fine for my needs. I think > that > we need to keep it around, no matter what else happens. So, for me, there > are a > few choices. > > 1. Create a new JSR to formalize the existing API and include some hardwired > JNI > code to provide port enumeration and access. > > 2. Create a new JSR to create a port abstraction SPI to allow JVM providers > to > enumerate all kinds of port/circuit based hardware to the JVM. Create an > implementation of the existing javax.comm API that uses this SPI. As an embedded Java vendor we work very close to the hardware level and have to deal daily with dozens of different types of ports and communication buses and protocols. Based on our experience I think that a SPI for "all kinds of port/circuit based hardware" is just too generic and not really practical. I think having a Service Provider Interface within javax.comm so that custom serial port implementations can be plugged in is a very good idea. However I don't think it is convenient to have it as a separate JSR and then with such a broad scope. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From joachim at buechse.de Tue Jul 25 10:56:12 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 25 Jul 2006 18:56:12 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <1153845299.44c64833920bd@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> <1153845299.44c64833920bd@webmail.eatserver.nl> Message-ID: In this case you need to configure your port with a different device driver. You may optionally take an existing port, wrap it up in a "wrapping device driver" implemented in Java and add it to the list of ports as a new port... In any case the core application should not care. On 25.07.2006, at 18:34, Guillermo Rodriguez wrote: > Hi Joachim, > > That is a very nice approach which I think would work well as far > as the underlying device driver knows about RS485. > > However it still does not solve the problem with external protocol > converters where the device driver only knows about regular UARTs > and RTS or DTR must be used to toggle direction of the converter. > > Guillermo > > Quoting Joachim Buechse : > >> Just trigger writing on flush(). It is perfectly legal for an >> Outputstream implementation to do do nothing until flush is called >> and the documentation of OutputStream.flush reads: >> >> "Flushes this output stream and forces any buffered output bytes to >> be written out. The general contract of flush is that calling it is >> an indication that, if any bytes previously written have been >> buffered by the implementation of the output stream, such bytes >> should immediately be written to their intended destination." >> >> As RS485 is a "dont speak up unless requested" protocol, a mandatory >> flush after write seems like the way to go to me >> >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). >> >> Regards, >> Joachim >> >> PS: It is great to see all the motivation that is brought forward on >> this list regarding the future. It would be great if only 10% of that >> motivation could be transformed into a cleanup and extension of the >> existing code. The current code access model seems rather >> inappropriate for the prototyping of the ideas beeing presented. >> Trent can we get a "contributions" branch with "free" access. >> >> >> On 25.07.2006, at 17:37, Martin Schoeberl wrote: >> >>>>> Martin Schoeberl wrote: >>>>>> We can model it platform independent with two methods: >>>>>> >>>>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>>>> on the underlying platform to switch to RS485 transmit mode and >>>>>> back. >>>>> >>>>> Or, do what is typically done, and use a single write operation >>>>> as the >>>>> indication of a 'packet' that will let the underlying RS-485/422 >>>>> driver >>>>> assert >>>>> the appropriate signalling. >>>> >>>> The problem with this is that there is no guarantee that a single >>>> call >>>> to the write method of the OutputStream associated with a >>>> javax.comm >>>> SerialPort will translate to a single write to the underlying >>>> device >>>> driver -- this depends on the javax.comm implementation. >>>> >>> I completely agree - it's still a stream and not a packet. >>> >>> This is similar to a single write to a TCP/IP socket. There >>> is no guarantee that you get this data as a single packet/single >>> read on the other side. However, I've seen a lot of programs >>> assuming that this happens ;-) >>> >>> Martin >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > > -- > http://www.snijder.com/ > SNIJDER Micro Systems > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From martin at jopdesign.com Tue Jul 25 11:13:10 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 19:13:10 +0200 Subject: [Rxtx] JSR Direction; packetizing writes References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com><005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net><1153840929.44c6372186f67@webmail.eatserver.nl><00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <000f01c6b00d$9bcc51c0$0202a8c0@luna> > No client can prevent another client from writing, so there is no > point in keeping the output-drivers enabled after all data currently > buffered has been written. So flush() should trigger "enterTransmit, > writePacket[s], exitTransmit". If the service provider (ie concrete > implementation of the flush method) decides that the write is > inapropriate at the moment (ie because of a higher level arbitration > protocol that might be implemented by the service provider) it will > simply block the flush or throw an IOException (preferably after some > sort of timeout). Not only flush() would mean enterTransmit(). With your idea each write should enable the driver, but only flush() can disable the driver after the last byte is written. RS485 is a beast. E.g. some driver chips need a few us (100us for a Maxim 1480B!) from output enable till output low/high. On a different application we had to wait a little bit before disabling the output driver to have a clear '1' on the bus as it took too long for the termination resistors to force the bus to 1. I can imagine that this is not really funny with general RS232/RS485 converters. Martin From joachim at buechse.de Tue Jul 25 11:42:18 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 25 Jul 2006 19:42:18 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <000f01c6b00d$9bcc51c0$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com><005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net><1153840929.44c6372186f67@webmail.eatserver.nl><00c801c6b000$33a68f00$0c28a8c0@luna> <000f01c6b00d$9bcc51c0$0202a8c0@luna> Message-ID: Simple answer: NO. You can not control the timing of the Java VM (especially not on ME) and hence you do not want to enable the outputs before you have all data collected. The timings you mention are all in the implementation space of the device driver. The core application should not care, neither should the javax.comm api in my opinion. Should I happen to be the pour soul that tries to implement an RS485 device driver reference implementation I will try to remember your email and add appropriate properties. Regards, Joachim On 25.07.2006, at 19:13, Martin Schoeberl wrote: >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). > > Not only flush() would mean enterTransmit(). With your idea each > write should enable the driver, but only flush() can disable > the driver after the last byte is written. > > RS485 is a beast. E.g. some driver chips need a few us (100us > for a Maxim 1480B!) from output enable till output low/high. > > On a different application we had to wait a little bit before > disabling the output driver to have a clear '1' on the bus as it took > too long for the termination resistors to force the bus to 1. > > I can imagine that this is not really funny with general > RS232/RS485 converters. > > Martin > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Tue Jul 25 12:50:20 2006 From: jredman at ergotech.com (Jim Redman) Date: Tue, 25 Jul 2006 12:50:20 -0600 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <44C667EC.2070602@ergotech.com> The horror! This would be terribly inefficient. Especially in serial protocols you need to start getting bits on the wire as soon as possible. It could also have some timeout implications. Jim Joachim Buechse wrote: > Just trigger writing on flush(). It is perfectly legal for an > Outputstream implementation to do do nothing until flush is called > and the documentation of OutputStream.flush reads: > > "Flushes this output stream and forces any buffered output bytes to > be written out. The general contract of flush is that calling it is > an indication that, if any bytes previously written have been > buffered by the implementation of the output stream, such bytes > should immediately be written to their intended destination." > > As RS485 is a "dont speak up unless requested" protocol, a mandatory > flush after write seems like the way to go to me > > No client can prevent another client from writing, so there is no > point in keeping the output-drivers enabled after all data currently > buffered has been written. So flush() should trigger "enterTransmit, > writePacket[s], exitTransmit". If the service provider (ie concrete > implementation of the flush method) decides that the write is > inapropriate at the moment (ie because of a higher level arbitration > protocol that might be implemented by the service provider) it will > simply block the flush or throw an IOException (preferably after some > sort of timeout). > > Regards, > Joachim > > PS: It is great to see all the motivation that is brought forward on > this list regarding the future. It would be great if only 10% of that > motivation could be transformed into a cleanup and extension of the > existing code. The current code access model seems rather > inappropriate for the prototyping of the ideas beeing presented. > Trent can we get a "contributions" branch with "free" access. > > > On 25.07.2006, at 17:37, Martin Schoeberl wrote: > >>>> Martin Schoeberl wrote: >>>>> We can model it platform independent with two methods: >>>>> >>>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>>> on the underlying platform to switch to RS485 transmit mode and >>>>> back. >>>> Or, do what is typically done, and use a single write operation >>>> as the >>>> indication of a 'packet' that will let the underlying RS-485/422 >>>> driver >>>> assert >>>> the appropriate signalling. >>> The problem with this is that there is no guarantee that a single >>> call >>> to the write method of the OutputStream associated with a javax.comm >>> SerialPort will translate to a single write to the underlying device >>> driver -- this depends on the javax.comm implementation. >>> >> I completely agree - it's still a stream and not a packet. >> >> This is similar to a single write to a TCP/IP socket. There >> is no guarantee that you get this data as a single packet/single >> read on the other side. However, I've seen a lot of programs >> assuming that this happens ;-) >> >> Martin >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From jredman at ergotech.com Tue Jul 25 12:53:02 2006 From: jredman at ergotech.com (Jim Redman) Date: Tue, 25 Jul 2006 12:53:02 -0600 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <000f01c6b00d$9bcc51c0$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com><005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net><1153840929.44c6372186f67@webmail.eatserver.nl><00c801c6b000$33a68f00$0c28a8c0@luna> <000f01c6b00d$9bcc51c0$0202a8c0@luna> Message-ID: <44C6688E.8040202@ergotech.com> Since we now seem to have entered a discussion of how to switch receive/transmit on 485 lines, I can tell you from experience that you cannot reliably do this from Java. Java just is not fast enough. I spend some time trying to get this to work with RXTX and it would work _most_ of the time, but you need to be able to guarantee ms level response which you can't do in any system that doesn't have real-time capabilities. Jim Martin Schoeberl wrote: >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). > > Not only flush() would mean enterTransmit(). With your idea each > write should enable the driver, but only flush() can disable > the driver after the last byte is written. > > RS485 is a beast. E.g. some driver chips need a few us (100us > for a Maxim 1480B!) from output enable till output low/high. > > On a different application we had to wait a little bit before > disabling the output driver to have a clear '1' on the bus as it took > too long for the termination resistors to force the bus to 1. > > I can imagine that this is not really funny with general > RS232/RS485 converters. > > Martin > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Tue Jul 25 13:37:14 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 14:37:14 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725115736.03706a38@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: <44C672EA.1080604@cox.net> Guillermo Rodriguez Garcia wrote: > At 11:25 25/07/2006, Martin Schoeberl wrote: >>Mmh, perhaps in a similar way as you configure timeouts? >>Isn't this 'just' a timeout value? > > Yes, but this is just a specific parameter that you can configure in a > specific type of UART (an EXAR UART). Other UARTs might be different. The > point I'm trying to make is that there are just too many parameters to > have an API for each specific case. In my earlier example/proposal, I included the ability for attributes of a port to be expressed as a collection of enumeration values for standard things. That would be fine for simple things like Input, Output, Sync, Async etc. When there are specific attributes of specific hardware, the vendor is going to have to provide a way to configure those attributes. One of the primary mechanisms in Java to do this is the JavaBean pattern that can be manifested in a Map type object when an API needs to preexist. So, we can provide an mechanism for propagating random attributes using a Map argument to a method such as public void setConfig( Map params ) throws IOException; public Map getConfig() throws IOException; Then, there is a conduit in and out of the driver that the user can use without needing more standards/spec'd code/API. This isn't much different than an ioctl(2) like mechanism, but it feels more Java like. A URL like mechanism, such as that which JDBC drivers use, could also be attractive. I've also wanted to replace java.net with the J2ME connection based mechanism as well. We might consider looking at the J2ME connector architecture to see if there is any gain in using some of that experience. Gregg Wonderly From gergg at cox.net Tue Jul 25 13:38:42 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 14:38:42 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> <44C5CD7E.9030903@sun.com> <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> Message-ID: <44C67342.9020402@cox.net> Guillermo Rodriguez Garcia wrote: > At 09:51 25/07/2006, Paul Klissner wrote: >>For example, if I am implementing class Foo in FooImpl.java, >>And Foo.java defines interface methods a(), b() and c(), >>FooImpl.java can also have public methods d(), e() and f(), which can >>be accessed from the application by casting a Foo object into >>a FooImpl object. This is one way to provide a back door without >>compromising the core API itself to do it. This puts the >>responsibility of breaking platform independence on the developers >>and not on the designers. > > Yes, that may be a good way to do it. The J2ME connector architecture is an example of a place where this is done. Gregg Wonderly From Paul.Klissner at Sun.COM Tue Jul 25 14:02:40 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Tue, 25 Jul 2006 13:02:40 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C67342.9020402@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> <44C5CD7E.9030903@sun.com> <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> <44C67342.9020402@cox.net> Message-ID: <44C678E0.90209@sun.com> Gregg Wonderly wrote: > Guillermo Rodriguez Garcia wrote: >> At 09:51 25/07/2006, Paul Klissner wrote: >>> For example, if I am implementing class Foo in FooImpl.java, >>> And Foo.java defines interface methods a(), b() and c(), >>> FooImpl.java can also have public methods d(), e() and f(), which can >>> be accessed from the application by casting a Foo object into >>> a FooImpl object. This is one way to provide a back door without >>> compromising the core API itself to do it. This puts the >>> responsibility of breaking platform independence on the developers >>> and not on the designers. >> Yes, that may be a good way to do it. > > The J2ME connector architecture is an example of a place where this is done. It's how I debugged my javax.usb implementations. Paul From Pawan.Kharbanda at dot.state.co.us Tue Jul 25 14:02:53 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 25 Jul 2006 14:02:53 -0600 Subject: [Rxtx] Strange error (show stopper) Message-ID: <939A619A756047469C41EE9BA51890FB0429DFA4@hqexchange3.dot.state.co.us> Joachim, I believe it's the same problem that I reported earlier (Thread deadlocks/Locked Ports), I am not a C person so don't know exactly whatz going in the native code but was able to find a workaround for right now by synchronizing the "interruptEventLoop" and "eventLoop" methods in the RXTXPort class. It helped but is not the right solution, I still find the deadlocks but not as often as I used too. A fix for this will be highly appreciated. I have some Test Classes that I have posted earlier to simulate the problem. ~pk -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Joachim Buechse Sent: Monday, July 24, 2006 2:13 AM To: RXTX Developers and Users Subject: Re: [Rxtx] Strange error (show stopper) The pthread_kill is followed by a sleep. When the sleep returns the structure is damaged. I did not find the source that overwrites the closing field - it is correctly set by the exiting drain thread. But something overwrites it afterwards. I currently believe that this existed for some time but was never seen because the previous versions did not rely on the structure to be in good shape when tearing down connections. However I may be completely wrong and it is an OSX problem. To help me find the source, it would be nice to get some indications what the 2 debug lines I suggested return on other platforms. Joachim On 24.07.2006, at 05:27, Trent Jarvi wrote: > On Sat, 22 Jul 2006, Joachim Buechse wrote: > >> I just discovered a strange error in RXTX on OSX. SerialDemo.java >> manages to corrupt the event_info_structure by a simple >> OpenPort,ClosePort - this could be in relation to the deadlock >> problem that was reported recently. >> >> Could anyone try to reproduce this on Solaris or some other system >> which is neither WIN32 nor Linux (ie which uses a drain thread). >> >> In SerialImp.c : RXTXPort(interruptEventLoop) >> >> Apparently the event_info_structure gets corrupted shortly after >> >> pthread_kill(index->drain_tid, SIGABRT); >> >> In particular, the index->closing flag gets overwritten by a pointer >> value. > > Hi Joachim > > Interesting. I did run many tests with that code on may OSs. To be > fair, the tests are just starting to get into good shape again. I'm > still tagging releases with a bit of feel and not enough process. > I'll look at this some more tomorrow night. > > The SIGABRT was added recently as part of the close speedups. > Thats from > memory. I can provide the exact patch that introduced that tomorrow. > > -- > Trent Jarvi > tjarvi at qbang.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Jul 25 17:42:23 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 18:42:23 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153840929.44c6372186f67@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> Message-ID: <44C6AC5F.3060107@cox.net> Guillermo Rodriguez wrote: > The problem with this is that there is no guarantee that a single call > to the write method of the OutputStream associated with a javax.comm > SerialPort will translate to a single write to the underlying device > driver -- this depends on the javax.comm implementation. More specifically, it depends on a software layer that would targeted specifically at solving this problem for RS-485 and other transports which have blocking or packetizing issues. There are many. In amatuer radio, we have TNCs (radio modems) which will block things using newline separators in some modes, and 0xc0 in others. Gregg Wonderly From gergg at cox.net Tue Jul 25 17:46:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 18:46:11 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C63A37.8080406@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> <44C60EB9.5000803@gmail.com> <44C63A37.8080406@sun.com> Message-ID: <44C6AD43.1090302@cox.net> Paul Klissner wrote: > Also that would imply two downloads to install any given > bus support, which might not be the end of the world. > And maybe two JSRs? Why are we hovering around this "downloads" issue? If we create a JSR that covers everything needed for javax.comm compatibility, does that still imply that it would be an unincluded, optional part of the JVM? If that is still something that people will tolerate, I'm a little lost for words. Still today, I can use the old javax.comm support. If we're just going to recreate the same concerns, issues and limitations, then what's the point? Gregg Wonderly From gergg at cox.net Tue Jul 25 17:48:42 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 18:48:42 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <00c801c6b000$33a68f00$0c28a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <44C6ADDA.5040208@cox.net> Martin Schoeberl wrote: > I completely agree - it's still a stream and not a packet. > > This is similar to a single write to a TCP/IP socket. There > is no guarantee that you get this data as a single packet/single > read on the other side. However, I've seen a lot of programs > assuming that this happens ;-) For nearly forever, serialport drivers have operated in the mode that they send either everything up to the divider char, or a single char. This was specifically done for protocols such as modbus which have 1 1/2 bit time delays indicating end of packet. This kind of thing is something that needs to be maintained for serial protocols to work. A user has to have a way to send a single "packet" of data and make sure that it flows out of the uart uninterrupted. Gregg Wonderly From gergg at cox.net Tue Jul 25 18:03:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 19:03:11 -0500 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <939A619A756047469C41EE9BA51890FB0429DFA4@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB0429DFA4@hqexchange3.dot.state.co.us> Message-ID: <44C6B13F.1000306@cox.net> Kharbanda, Pawan wrote: > Joachim, > I believe it's the same problem that I reported earlier (Thread > deadlocks/Locked Ports), I am not a C person so don't know exactly whatz > going in the native code but was able to find a workaround for right now > by synchronizing the "interruptEventLoop" and "eventLoop" methods in the > RXTXPort class. It helped but is not the right solution, I still find > the deadlocks but not as often as I used too. > > A fix for this will be highly appreciated. I have some Test Classes that > I have posted earlier to simulate the problem. You can send SIGQUIT (signal #3) to unix JVMs to get a stacktrace of where all the threads are at and who owns what locks. Also, on windows, you can run the JVM in a DOS window and use CTRL-BREAK to get the stack trace. This won't go beyond the native level, but it might expose what you need to know. Gregg Wonderly From tjarvi at qbang.org Tue Jul 25 22:21:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 22:21:22 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6AC5F.3060107@cox.net> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: On Tue, 25 Jul 2006, Gregg Wonderly wrote: > Guillermo Rodriguez wrote: >> The problem with this is that there is no guarantee that a single call >> to the write method of the OutputStream associated with a javax.comm >> SerialPort will translate to a single write to the underlying device >> driver -- this depends on the javax.comm implementation. > > More specifically, it depends on a software layer that would targeted > specifically at solving this problem for RS-485 and other transports which have > blocking or packetizing issues. There are many. In amatuer radio, we have TNCs > (radio modems) which will block things using newline separators in some modes, > and 0xc0 in others. > I had looked into RS-485 some. It is daunting without proper hardware. One option is to do a native local tcpip/udp server to remove most of the the 'java issues.' Realtime patches comming down the pipe make it tempting to jump into the tarpit of failures. Beyond that, we should be very explicit about what type of RS-485 hardware we do support and it should not involve things that we have to control DTR/RTS in almost realtime (<20 ms). There are going to be people wanting < $5/EURO winmodem type solutions that will be nothing but problems. Thats doable by hacking kernel drivers but it will never get into mainstream kernels. I do not think thats reasonable from java and is even questionable in typical C. It will work fine until you start oracle... It would be nice to get RS-485 support in. Things like controlling low cost devices in houses, ... But cutting out the hardware isn't a viable solution in java. -- Trent Jarvi tjarvi From tjarvi at qbang.org Tue Jul 25 22:40:36 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 22:40:36 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6AD43.1090302@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> <44C60EB9.5000803@gmail.com> <44C63A37.8080406@sun.com> <44C6AD43.1090302@cox.net> Message-ID: On Tue, 25 Jul 2006, Gregg Wonderly wrote: > Paul Klissner wrote: >> Also that would imply two downloads to install any given >> bus support, which might not be the end of the world. >> And maybe two JSRs? > > Why are we hovering around this "downloads" issue? If we create a JSR that > covers everything needed for javax.comm compatibility, does that still imply > that it would be an unincluded, optional part of the JVM? If that is still > something that people will tolerate, I'm a little lost for words. Still today, > I can use the old javax.comm support. If we're just going to recreate the same > concerns, issues and limitations, then what's the point? > I don't have a problem with Sun shipping rxtx or whatever it becomes. They may have some legacy issues :) Just poking fun. The current state does not work for java users. Not having w32 support means about 80+% of the users do not have support. The rxtx w32 support is heavily influenced by cygwin so it wont change license out of respect for that project. If you really hate life and the LGPL, you can do a w32 port and the rest will just fall into place while you chase windows bugs for 5 years. Anything that dances around w32 support is just an academic waste of time. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Tue Jul 25 22:41:21 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 23:41:21 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: <44C6F271.2020604@cox.net> Trent Jarvi wrote: > I had looked into RS-485 some. It is daunting without proper hardware. > One option is to do a native local tcpip/udp server to remove most of the > the 'java issues.' Realtime patches comming down the pipe make it tempting > to jump into the tarpit of failures. Trent, there is not a way for a non-realtime OS to drive 485 hardware without the hardware taking care of the timing issues. But, a non-realtime OS can support software APIs which let the developer express in an API the types of things that a piece of hardware is capable of. Then we can have an API, and the hardware people and the OS people will provide the solutions where possible. > It would be nice to get RS-485 support in. Things like controlling > low cost devices in houses, ... But cutting out the hardware isn't a > viable solution in java. The 485 hardware devices will have to have non-realtime requirements associated with the controlling mechanisms. There are some of those. I'm mostly interested in having a 485 API for realtime java and/or the aJile and other uC environments which can provide realtime environments. Gregg Wonderly From tjarvi at qbang.org Tue Jul 25 22:54:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 22:54:44 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6F271.2020604@cox.net> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <44C6F271.2020604@cox.net> Message-ID: On Tue, 25 Jul 2006, Gregg Wonderly wrote: > Trent Jarvi wrote: >> I had looked into RS-485 some. It is daunting without proper hardware. >> One option is to do a native local tcpip/udp server to remove most of the >> the 'java issues.' Realtime patches comming down the pipe make it tempting >> to jump into the tarpit of failures. > > Trent, there is not a way for a non-realtime OS to drive 485 hardware without > the hardware taking care of the timing issues. But, a non-realtime OS can > support software APIs which let the developer express in an API the types of > things that a piece of hardware is capable of. Then we can have an API, and the > hardware people and the OS people will provide the solutions where possible. > >> It would be nice to get RS-485 support in. Things like controlling >> low cost devices in houses, ... But cutting out the hardware isn't a >> viable solution in java. > > The 485 hardware devices will have to have non-realtime requirements associated > with the controlling mechanisms. There are some of those. I'm mostly > interested in having a 485 API for realtime java and/or the aJile and other uC > environments which can provide realtime environments. > Hi Gregg I do not disagree with you but I have a problem with this (realtime java and/or the aJile and other Uc environements) being something I may be hearing bugs about 5 years from now. Is this really something that should be in the API or is it something that would make a nice niche market for support and services? Do the two really go together? If you like that market and I think there is a niche market there, great. This is a good area for SPI type interfaces where you could support it but it was not provided by default. -- Trent Jarvi tjarvi at qbang.org From guille at sms.nl Wed Jul 26 00:39:47 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 08:39:47 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C672EA.1080604@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> Message-ID: <7.0.1.0.0.20060726083751.03633188@sms.nl> At 21:37 25/07/2006, Gregg Wonderly wrote: >Guillermo Rodriguez Garcia wrote: > > At 11:25 25/07/2006, Martin Schoeberl wrote: > >>Mmh, perhaps in a similar way as you configure timeouts? > >>Isn't this 'just' a timeout value? > > > > Yes, but this is just a specific parameter that you can configure in a > > specific type of UART (an EXAR UART). Other UARTs might be different. The > > point I'm trying to make is that there are just too many parameters to > > have an API for each specific case. > >In my earlier example/proposal, I included the ability for >attributes of a port >to be expressed as a collection of enumeration values for standard >things. That >would be fine for simple things like Input, Output, Sync, Async >etc. When there >are specific attributes of specific hardware, the vendor is going to have to >provide a way to configure those attributes. One of the primary >mechanisms in >Java to do this is the JavaBean pattern that can be manifested in a Map type >object when an API needs to preexist. So, we can provide an mechanism for >propagating random attributes using a Map argument to a method such as > >public void setConfig( Map params ) throws IOException; >public Map getConfig() throws IOException; > >Then, there is a conduit in and out of the driver that the user can >use without >needing more standards/spec'd code/API. > >This isn't much different than an ioctl(2) like mechanism, This is exactly what I was thinking while reading your mail :) >but it feels more Java like. It would do the job as well and I would be happy with that. However Paul's proposal where implementation classes extend the core API as necessary might be more elegant (for the same reason that it is more elegant than ioctl) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Wed Jul 26 00:41:40 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 08:41:40 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6AC5F.3060107@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: <7.0.1.0.0.20060726084016.03633040@sms.nl> At 01:42 26/07/2006, Gregg Wonderly wrote: >Guillermo Rodriguez wrote: > > The problem with this is that there is no guarantee that a single call > > to the write method of the OutputStream associated with a javax.comm > > SerialPort will translate to a single write to the underlying device > > driver -- this depends on the javax.comm implementation. > >More specifically, it depends on a software layer that would targeted >specifically at solving this problem for RS-485 and other transports >which have >blocking or packetizing issues. There are many. In amatuer radio, >we have TNCs >(radio modems) which will block things using newline separators in >some modes, >and 0xc0 in others. Right. I meant that in general one cannot assume that writes to a stream will translate 1:1 to writes in every layer of the protocol stack (this is most often not the case.) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Wed Jul 26 00:44:57 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 08:44:57 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6ADDA.5040208@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> <44C6ADDA.5040208@cox.net> Message-ID: <7.0.1.0.0.20060726084203.036cd2b8@sms.nl> At 01:48 26/07/2006, Gregg Wonderly wrote: >Martin Schoeberl wrote: > > I completely agree - it's still a stream and not a packet. > > > > This is similar to a single write to a TCP/IP socket. There > > is no guarantee that you get this data as a single packet/single > > read on the other side. However, I've seen a lot of programs > > assuming that this happens ;-) > >For nearly forever, serialport drivers have operated in the mode >that they send >either everything up to the divider char, or a single char. This was >specifically done for protocols such as modbus which have 1 1/2 bit >time delays >indicating end of packet. This kind of thing is something that needs to be >maintained for serial protocols to work. A user has to have a way to send a >single "packet" of data and make sure that it flows out of the uart >uninterrupted. Even that is sometimes difficult to achieve. If the whole packet does not fit in the UART FIFOs, then the driver may have a hard time making sure that all of the data flows out uninterrupted, unless 1/ you have a RTOS with a response time that is fast enough to refill the FIFO before it empties, and/or 2/ you can tolerate a 'stop the world' approach where ints are globally disabled while the packet is being sent (not nice) (just a side comment) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From tjarvi at qbang.org Wed Jul 26 00:48:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 26 Jul 2006 00:48:29 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060726084016.03633040@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <7.0.1.0.0.20060726084016.03633040@sms.nl> Message-ID: On Wed, 26 Jul 2006, Guillermo Rodriguez Garcia wrote: > At 01:42 26/07/2006, Gregg Wonderly wrote: >> Guillermo Rodriguez wrote: >>> The problem with this is that there is no guarantee that a single call >>> to the write method of the OutputStream associated with a javax.comm >>> SerialPort will translate to a single write to the underlying device >>> driver -- this depends on the javax.comm implementation. >> >> More specifically, it depends on a software layer that would targeted >> specifically at solving this problem for RS-485 and other transports >> which have >> blocking or packetizing issues. There are many. In amatuer radio, >> we have TNCs >> (radio modems) which will block things using newline separators in >> some modes, >> and 0xc0 in others. > > Right. I meant that in general one cannot assume that writes to a stream > will translate 1:1 to writes in every layer of the protocol stack (this is > most often not the case.) > Hi Guillermo This sounds like a dead end to me. People using commapi want a a write, an interrupt and data. The kernel being a big problem these days. There are _much_ better ways to do things like protocol stacks. This is not how EIA232 works in the real world. -- Trent Jarvi tjarvi From guille at sms.nl Wed Jul 26 01:02:09 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 09:02:09 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <7.0.1.0.0.20060726084016.03633040@sms.nl> Message-ID: <7.0.1.0.0.20060726090154.036dd708@sms.nl> At 08:48 26/07/2006, Trent Jarvi wrote: >On Wed, 26 Jul 2006, Guillermo Rodriguez Garcia wrote: > > > At 01:42 26/07/2006, Gregg Wonderly wrote: > >> Guillermo Rodriguez wrote: > >>> The problem with this is that there is no guarantee that a single call > >>> to the write method of the OutputStream associated with a javax.comm > >>> SerialPort will translate to a single write to the underlying device > >>> driver -- this depends on the javax.comm implementation. > >> > >> More specifically, it depends on a software layer that would targeted > >> specifically at solving this problem for RS-485 and other transports > >> which have > >> blocking or packetizing issues. There are many. In amatuer radio, > >> we have TNCs > >> (radio modems) which will block things using newline separators in > >> some modes, > >> and 0xc0 in others. > > > > Right. I meant that in general one cannot assume that writes to a stream > > will translate 1:1 to writes in every layer of the protocol stack (this is > > most often not the case.) > > > >Hi Guillermo > >This sounds like a dead end to me. People using commapi want a a write, >an interrupt and data. The kernel being a big problem these days. > >There are _much_ better ways to do things like protocol stacks. This is >not how EIA232 works in the real world. Yes, this is exactly what I'm saying. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From Luis.Moreira at jet.uk Wed Jul 26 01:34:42 2006 From: Luis.Moreira at jet.uk (Luis Moreira) Date: Wed, 26 Jul 2006 08:34:42 +0100 Subject: [Rxtx] Portability Message-ID: Hi Guys, I managed to get the RXTX package to work on my PC, but the question is, if I need to distribute my program to someone that does not know much about java how do I get the program to work on their System? Best regards Luis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/3e3c2058/attachment-0337.html From joachim at buechse.de Wed Jul 26 02:18:19 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 26 Jul 2006 10:18:19 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <44C667EC.2070602@ergotech.com> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> <44C667EC.2070602@ergotech.com> Message-ID: I may not have been very clear with my suggestion: The "mandatory" flush after write was only regarding RS485. If an application does not use flush after write (today), it is damned to fail anyway. The Outputstream interface makes no guarentee what so ever, that any data will be writen before you call flush. So in fact flush is already mandatory unless you dont care if your data is ever transmitted. I don't see how sending on flush for RS485 would be less efficient. If you are concerned about the additional function call you may want to specify on which platform/VM you are working. A function call in java even on slow PCs is in the microsecond range. So if your concern is, that writes should be forwarded as soon as possible, well then follow any write by a flush. I haven't done any JavaME serial programming, but from my experience with implementing Ymodem over RS232+USB, all I can say is this: Either you have your data ready when it is demanded and you can write it with a single write(+flush) or your application will be slow. So yes, you need to get data on the wire as quick as possible, the solutions are manyfold but an additional (flush) function call will hardly make your application slower. Regards, Joachim On 25.07.2006, at 20:50, Jim Redman wrote: > The horror! This would be terribly inefficient. Especially in serial > protocols you need to start getting bits on the wire as soon as > possible. It could also have some timeout implications. > > Jim > > Joachim Buechse wrote: >> Just trigger writing on flush(). It is perfectly legal for an >> Outputstream implementation to do do nothing until flush is called >> and the documentation of OutputStream.flush reads: >> >> "Flushes this output stream and forces any buffered output bytes to >> be written out. The general contract of flush is that calling it is >> an indication that, if any bytes previously written have been >> buffered by the implementation of the output stream, such bytes >> should immediately be written to their intended destination." >> >> As RS485 is a "dont speak up unless requested" protocol, a mandatory >> flush after write seems like the way to go to me >> >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). >> >> Regards, >> Joachim >> >> PS: It is great to see all the motivation that is brought forward on >> this list regarding the future. It would be great if only 10% of that >> motivation could be transformed into a cleanup and extension of the >> existing code. The current code access model seems rather >> inappropriate for the prototyping of the ideas beeing presented. >> Trent can we get a "contributions" branch with "free" access. >> >> >> On 25.07.2006, at 17:37, Martin Schoeberl wrote: >> >>>>> Martin Schoeberl wrote: >>>>>> We can model it platform independent with two methods: >>>>>> >>>>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>>>> on the underlying platform to switch to RS485 transmit mode and >>>>>> back. >>>>> Or, do what is typically done, and use a single write operation >>>>> as the >>>>> indication of a 'packet' that will let the underlying RS-485/422 >>>>> driver >>>>> assert >>>>> the appropriate signalling. >>>> The problem with this is that there is no guarantee that a single >>>> call >>>> to the write method of the OutputStream associated with a >>>> javax.comm >>>> SerialPort will translate to a single write to the underlying >>>> device >>>> driver -- this depends on the javax.comm implementation. >>>> >>> I completely agree - it's still a stream and not a packet. >>> >>> This is similar to a single write to a TCP/IP socket. There >>> is no guarantee that you get this data as a single packet/single >>> read on the other side. However, I've seen a lot of programs >>> assuming that this happens ;-) >>> >>> Martin >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Jul 26 04:28:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 26 Jul 2006 06:28:33 -0400 Subject: [Rxtx] Should we defer JSR support of RS485? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: Hi All, Would it make sense to focus the JSR on rock solid serial and parallel port support? Can the RS485 people live with unofficial support, at least until we get the JSR accepted and the implementation rock solid? Thanks! - Doug From gergg at cox.net Wed Jul 26 08:49:21 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 26 Jul 2006 09:49:21 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <44C6F271.2020604@cox.net> Message-ID: <44C780F1.8020506@cox.net> Trent Jarvi wrote: > I do not disagree with you but I have a problem with this (realtime java > and/or the aJile and other Uc environements) being something I may be > hearing bugs about 5 years from now. Is this really something that should > be in the API or is it something that would make a nice niche market for > support and services? Do the two really go together? The question is whether there needs to be two, three or five ways to do the same thing, or can we distill it down to one so that software working in one environment can work in all. > If you like that market and I think there is a niche market there, great. > This is a good area for SPI type interfaces where you could support it but > it was not provided by default. SPI is supported natively on the aJile processors. Systronix provides an API for using the SPI lines defined for that use. Adding extra slave selects is not part of their API. There are plenty of places where this stuff is getting used. In the C world of uC, there are 500 ways to do the same thing because everyone wants to be as close to the hardware as possible. The trumpet of the Java platform proclaims write once, run anywhere. Thats been a powerful impetus to me and others to use the language. I really do appreciate that I don't have to think about non-application related programming tasks as much as I did in C and C++. It's possible to pick a reasonable level of abstraction that provide opportunity to expand in the future while accounting for the small in the present. But, we have to all get together with a desire to accomplish this, have good constructive conversation and feedback, and get it done. Gregg Wonderly From gergg at cox.net Wed Jul 26 08:56:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 26 Jul 2006 09:56:11 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060726083751.03633188@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> Message-ID: <44C7828B.7040904@cox.net> Guillermo Rodriguez Garcia wrote: > It would do the job as well and I would be happy with that. However > Paul's proposal where implementation classes extend the core API as > necessary might be more elegant (for the same reason that it is more > elegant than ioctl) Right, but my argument was that this demanded that the classes preexist at the time I am writing the software. I have to be able to compile against them. The Map mechanism would allow me to write software that worked with any hardware. The person deploying my software into their environment with their hardware would then just provide a set of configuration values that my software would pass into the API. That's the point I'm trying to make. I'm on the fence about a Map vs a subclass with methods. I can see it both ways. But, as a JDBC user, I've learned to appreciate a single API with Properties passed in. As a Jini user I've learned to appreciate the Configuration mechanisms that Jini 2.x has. I can write code in my configuration file to instantiate and configure the system at deployment time! Gregg Wonderly From joachim at buechse.de Wed Jul 26 09:37:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 26 Jul 2006 17:37:27 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C7828B.7040904@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> <44C7828B.7040904@cox.net> Message-ID: <08E356DB-AC3F-46FC-952B-82D5ABB15926@buechse.de> Unless you are working with J2ME, you can just as well do what you describe using reflection (ie a JavaBean strategy). A Map can change at runtime, an interface can not. Regards, Joachim On 26.07.2006, at 16:56, Gregg Wonderly wrote: > Guillermo Rodriguez Garcia wrote: >> It would do the job as well and I would be happy with that. However >> Paul's proposal where implementation classes extend the core API as >> necessary might be more elegant (for the same reason that it is more >> elegant than ioctl) > > Right, but my argument was that this demanded that the classes > preexist at the > time I am writing the software. I have to be able to compile > against them. > > The Map mechanism would allow me to write software that worked with > any > hardware. The person deploying my software into their environment > with their > hardware would then just provide a set of configuration values that > my software > would pass into the API. > > That's the point I'm trying to make. I'm on the fence about a Map > vs a subclass > with methods. I can see it both ways. But, as a JDBC user, I've > learned to > appreciate a single API with Properties passed in. As a Jini user > I've learned > to appreciate the Configuration mechanisms that Jini 2.x has. I > can write code > in my configuration file to instantiate and configure the system at > deployment > time! > > config/ConfigurationFile.html> > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Paul.Klissner at Sun.COM Wed Jul 26 12:11:37 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 26 Jul 2006 11:11:37 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C780F1.8020506@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <44C6F271.2020604@cox.net> <44C780F1.8020506@cox.net> Message-ID: <44C7B059.1060302@sun.com> Gregg Wonderly wrote: > Trent Jarvi wrote: >> I do not disagree with you but I have a problem with this (realtime java >> and/or the aJile and other Uc environements) being something I may be >> hearing bugs about 5 years from now. Is this really something that should >> be in the API or is it something that would make a nice niche market for >> support and services? Do the two really go together? > > The question is whether there needs to be two, three or five ways to do the same > thing, or can we distill it down to one so that software working in one > environment can work in all. > >> If you like that market and I think there is a niche market there, great. >> This is a good area for SPI type interfaces where you could support it but >> it was not provided by default. > > SPI is supported natively on the aJile processors. Systronix provides an API > for using the SPI lines defined for that use. Adding extra slave selects is not > part of their API. > > There are plenty of places where this stuff is getting used. In the C world of > uC, there are 500 ways to do the same thing because everyone wants to be as > close to the hardware as possible. > > The trumpet of the Java platform proclaims write once, run anywhere. Thats been > a powerful impetus to me and others to use the language. I really do appreciate > that I don't have to think about non-application related programming tasks as > much as I did in C and C++. > > It's possible to pick a reasonable level of abstraction that provide opportunity > to expand in the future while accounting for the small in the present. > > But, we have to all get together with a desire to accomplish this, have good > constructive conversation and feedback, and get it done. I agree that whatever approach we take should involve settling on the scope and then seeking to create a reasonably complete set of abstractions to generalize and make platform independent, and then refine that list as corner cases appear. For whichever bus(ses) we support, it will be standards-based functionality we're trying to support, with device-specific functionality hidden in the driver and not passed through as direct driver-oriented commands via the API. Paul > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Paul.Klissner at Sun.COM Wed Jul 26 12:23:56 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 26 Jul 2006 11:23:56 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C7828B.7040904@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> <44C7828B.7040904@cox.net> Message-ID: <44C7B33C.8090005@sun.com> Gregg Wonderly wrote: > Guillermo Rodriguez Garcia wrote: >> It would do the job as well and I would be happy with that. However >> Paul's proposal where implementation classes extend the core API as >> necessary might be more elegant (for the same reason that it is more >> elegant than ioctl) > > Right, but my argument was that this demanded that the classes preexist at the > time I am writing the software. I have to be able to compile against them. > > The Map mechanism would allow me to write software that worked with any > hardware. The person deploying my software into their environment with their > hardware would then just provide a set of configuration values that my software > would pass into the API. > > That's the point I'm trying to make. I'm on the fence about a Map vs a subclass > with methods. I can see it both ways. But, as a JDBC user, I've learned to > appreciate a single API with Properties passed in. As a Jini user I've learned > to appreciate the Configuration mechanisms that Jini 2.x has. I can write code > in my configuration file to instantiate and configure the system at deployment > time! I don't think this is a problem as long as the implementation specific stuff is handled by controlling through vehicles outside the API. The application code layered over the API should be written such that it can run on any platform and with any generic device of the class the API claims to support. The problem with the ioctl is it's proneness for abuse and invitation to proliferate the space with non-portable applications. If the implementation requires a configuration file to be passed through the API then the application can run on platform A, B and C, which all have the same type of device, fine, and then with a different configuration file, could run on D, E and F with other hardware, that seems reasonable. What if there are multiple devices on a system of different types? There needs to be a way to get the right configuration file to associate with the right device, and the application should seamlessly work with either. The application code layered over the API should not have to be aware of the configuration file or the programmatic peculiarities of the underlying hardware. Paul From joachim at buechse.de Wed Jul 26 12:59:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 26 Jul 2006 20:59:06 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C7B33C.8090005@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> <44C7828B.7040904@cox.net> <44C7B33C.8090005@sun.com> Message-ID: <1A34B6D0-43B2-4F73-A39F-004B3D100CE9@buechse.de> Paul honestly I think you are to extreme - Often enough a USER is very well capable of indentifying which "config file" needs to be choosen to set up the device he owns. This file can be accepted from the application as a "configuration parameter" and passed on to the driver. One very typical example are AT-command sequences. Terminal programs know nothing about their meaning - still they happily pass them on to do their magic. Best regards, Joachim On 26.07.2006, at 20:23, Paul Klissner wrote: > Gregg Wonderly wrote: >> Guillermo Rodriguez Garcia wrote: >>> It would do the job as well and I would be happy with that. However >>> Paul's proposal where implementation classes extend the core API as >>> necessary might be more elegant (for the same reason that it is more >>> elegant than ioctl) >> >> Right, but my argument was that this demanded that the classes >> preexist at the >> time I am writing the software. I have to be able to compile >> against them. >> >> The Map mechanism would allow me to write software that worked >> with any >> hardware. The person deploying my software into their environment >> with their >> hardware would then just provide a set of configuration values >> that my software >> would pass into the API. >> >> That's the point I'm trying to make. I'm on the fence about a Map >> vs a subclass >> with methods. I can see it both ways. But, as a JDBC user, I've >> learned to >> appreciate a single API with Properties passed in. As a Jini user >> I've learned >> to appreciate the Configuration mechanisms that Jini 2.x has. I >> can write code >> in my configuration file to instantiate and configure the system >> at deployment >> time! > > I don't think this is a problem as long as the implementation specific > stuff is handled by controlling through vehicles outside the API. > The application code layered over the API should be written such that > it can run on any platform and with any generic device of the class > the API claims to support. > > The problem with the ioctl is it's proneness for abuse and invitation > to proliferate the space with non-portable applications. > > If the implementation requires a configuration file to be passed > through > the API then the application can run on platform A, B and C, which all > have the same type of device, fine, and then with a different > configuration > file, could run on D, E and F with other hardware, that seems > reasonable. > > What if there are multiple devices on a system of different types? > There needs to be a way to get the right configuration file to > associate > with the right device, and the application should seamlessly work > with either. > The application code layered over the API should not have to be aware > of the configuration file or the programmatic peculiarities of the > underlying hardware. > > Paul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From savagobr at yahoo.com Wed Jul 26 13:15:13 2006 From: savagobr at yahoo.com (Adenilson Cavalcanti) Date: Wed, 26 Jul 2006 12:15:13 -0700 (PDT) Subject: [Rxtx] Strange error (show stopper) - Fedora Core 5 is ok! Message-ID: <20060726191513.28407.qmail@web53802.mail.yahoo.com> Dear Joachim Buechse I'm pretty new to this list (actually, first post) but got curious about the issue that you reported. If a undertood the code correctly, SerialImp.c -> interruptEventLoop only calls pthread_kill when compiled for MacOSX. Anyway, I changed the code to print field values of structure object 'index' and got this results: 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 CLOSING=0 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 CLOSING=1 Which I think seems to be o.k. (I must also comment that I'm running FC5, kernel 2.6.15, gcc 4.1.1, jdk 1.5.0_06). Bellow you will find where in source code I printed the debug information. I was wondering why in Linux is not necessary to call pthread_kill (of course I did read the comments about "output buffer empty" but don't get it...). Any comments? Best regards Savago //---------------------------------------------------------------------------------------------- Changed code. //---------------------------------------------------------------------------------------------- /** XXX: DEBUG INFO*/ snprintf(message, sizeof(message), "1 interrupted thread for FD=%i PTR=%i CLOSING=%i\n", index->fd, index, index->closing ); report(message); #ifdef TIOCSERGETLSR index->closing=1; #endif /* TIOCSERGETLSR */ #ifdef WIN32 termios_interrupt_event_loop( index->fd, 1 ); #endif /* WIN32 */ #if !defined(TIOCSERGETLSR) && !defined(WIN32) . . . #endif /** XXX: DEBUG INFO*/ snprintf(message, sizeof(message), "2 interrupted thread for FD=%i PTR=%i CLOSING=%i\n", index->fd, index, index->closing ); report(message); report("interruptEventLoop: interrupted\n"); //---------------------------------------------------------------------------------------------- OUTPUT: 15:00:24:******* report_serial_events: sending DATA_AVAILABLE 15:00:24:******* reporting data available 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 CLOSING=0 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 CLOSING=1 15:00:24:******* interruptEventLoop: interrupted 15:00:24:******* eventLoop: got interrupt 15:00:24:******* setDTR( 0 ) 15:00:24:******* setDSR( 0 ) 15:00:24:******* >nativeClose pid 15:00:24:******* nativeClose: pid 15:00:24:******* nativeClose: discarding remaining datai (tcflush) 15:00:24:******* nativeClose: calling close 15:00:24:******* fhs_unlock: Removing LockFile 15:00:24:******* nativeClose: Delete jclazz 15:00:24:******* nativeClose: release filename 15:00:24:******* fhs_unlock: Removing LockFile //---------------------------------------------------------------------------------------------- --------------------------------- How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone call rates. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/ad116f14/attachment-0336.html From savagobr at yahoo.com Wed Jul 26 13:23:05 2006 From: savagobr at yahoo.com (Adenilson Cavalcanti) Date: Wed, 26 Jul 2006 12:23:05 -0700 (PDT) Subject: [Rxtx] Locked ports - to Kharbanda Message-ID: <20060726192305.23957.qmail@web53807.mail.yahoo.com> Dear Kharbanda I'm trying to reproduce the bug that you reported (the deadlock one) but dont get it. What I did was write a java app that continuously open/close a port (/dev/ttyS0) within 1 second for this operation. The program keeps running fine, no lock until now. I'm wondering if you could send me a sample app that could help me to reproduce this bug? Best regards Savago --------------------------------- Yahoo! Music Unlimited - Access over 1 million songs.Try it free. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/c56bc64a/attachment-0336.html From Pawan.Kharbanda at dot.state.co.us Wed Jul 26 13:41:13 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Wed, 26 Jul 2006 13:41:13 -0600 Subject: [Rxtx] Locked ports - to Kharbanda Message-ID: <939A619A756047469C41EE9BA51890FB0429E08B@hqexchange3.dot.state.co.us> Savago, I have attached the Test class that i wrote to replicate the locking/threading problem with RXTX in Redhat Linux. Please follow the following instructions to replicate the problem. I don't know if you will be able to replicate using one Serial port or not, i was able to reproduced it using 3 or 4 ports constantly. Instructions: In the TestOpenClosePort.java please change the Serial Ports names(Add the ports installed on your machine). Then compile your java file and run as "java TestOpenClosePort 100" (100 is the no of times you want to open and close the port in one single thread). I have tested this with the Digi Boxes and able to replicate this over and over in Single JVM. Thanks ~pk ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Adenilson Cavalcanti Sent: Wednesday, July 26, 2006 1:23 PM To: rxtx at qbang.org Subject: [Rxtx] Locked ports - to Kharbanda Dear Kharbanda I'm trying to reproduce the bug that you reported (the deadlock one) but dont get it. What I did was write a java app that continuously open/close a port (/dev/ttyS0) within 1 second for this operation. The program keeps running fine, no lock until now. I'm wondering if you could send me a sample app that could help me to reproduce this bug? Best regards Savago ________________________________ Yahoo! Music Unlimited - Access over 1 million songs. Try it free. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/c581de54/attachment-0336.html -------------- next part -------------- A non-text attachment was scrubbed... Name: TestOpenClosePort.java Type: application/octet-stream Size: 6038 bytes Desc: TestOpenClosePort.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/c581de54/TestOpenClosePort-0336.obj From joachim at buechse.de Wed Jul 26 16:01:31 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 27 Jul 2006 00:01:31 +0200 Subject: [Rxtx] Strange error (show stopper) - Fedora Core 5 is ok! In-Reply-To: <20060726191513.28407.qmail@web53802.mail.yahoo.com> References: <20060726191513.28407.qmail@web53802.mail.yahoo.com> Message-ID: Linux offers a feature (TIOCSERGETLSR) that allows to check if all data has been sent. This feature does not exist on OSX, BSD, Solaris and probably some other systems. For these systems RXTX uses a separate thread that calls tc_drain() - on return of this call all data has been written. The pthread_kill is used to guarantee that the drain thread has been canceled. On Linux there is no forced "wait" between the setting of the "closing" flag and the end of the procedure. The test should to be done on a BSD or Solaris system. But maybe you could add a usleep (50000) just before the second sprintf. This might in fact be helpful to see if the problem exists on Linux as well. Thanks, Joachim On 26.07.2006, at 21:15, Adenilson Cavalcanti wrote: > Dear Joachim Buechse > > I'm pretty new to this list (actually, first post) but got curious > about the issue that you reported. > > If a undertood the code correctly, SerialImp.c -> > interruptEventLoop only calls pthread_kill when compiled for MacOSX. > > Anyway, I changed the code to print field values of structure > object 'index' and got this results: > > 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 > CLOSING=0 > 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 > CLOSING=1 > > Which I think seems to be o.k. (I must also comment that I'm > running FC5, kernel 2.6.15, gcc 4.1.1, jdk 1.5.0_06). > > Bellow you will find where in source code I printed the debug > information. > > I was wondering why in Linux is not necessary to call pthread_kill > (of course I did read the comments about "output buffer empty" but > don't get it...). Any comments? > > Best regards > > Savago > > //-------------------------------------------------------------------- > -------------------------- > Changed code. > //-------------------------------------------------------------------- > -------------------------- > /** XXX: DEBUG INFO*/ > snprintf(message, sizeof(message), "1 interrupted thread for FD= > %i PTR=%i CLOSING=%i\n", > index->fd, index, index->closing ); > report(message); > > #ifdef TIOCSERGETLSR > index->closing=1; > #endif /* TIOCSERGETLSR */ > #ifdef WIN32 > termios_interrupt_event_loop( index->fd, 1 ); > #endif /* WIN32 */ > #if !defined(TIOCSERGETLSR) && !defined(WIN32) > . > . > . > #endif > /** XXX: DEBUG INFO*/ > snprintf(message, sizeof(message), "2 interrupted thread for FD= > %i PTR=%i CLOSING=%i\n", > index->fd, index, index->closing ); > report(message); > > report("interruptEventLoop: interrupted\n"); > > //-------------------------------------------------------------------- > -------------------------- > OUTPUT: > > 15:00:24:******* report_serial_events: sending DATA_AVAILABLE > 15:00:24:******* reporting data available > 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 > CLOSING=0 > 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 > CLOSING=1 > 15:00:24:******* interruptEventLoop: interrupted > 15:00:24:******* eventLoop: got interrupt > 15:00:24:******* setDTR( 0 ) > 15:00:24:******* setDSR( 0 ) > 15:00:24:******* >nativeClose pid > 15:00:24:******* nativeClose: pid > 15:00:24:******* nativeClose: discarding remaining datai (tcflush) > 15:00:24:******* nativeClose: calling close > 15:00:24:******* fhs_unlock: Removing LockFile > 15:00:24:******* nativeClose: Delete jclazz > 15:00:24:******* nativeClose: release filename > 15:00:24:******* fhs_unlock: Removing LockFile > //-------------------------------------------------------------------- > -------------------------- > > How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone > call rates. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jul 26 19:34:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 26 Jul 2006 19:34:11 -0600 (MDT) Subject: [Rxtx] Strange error (show stopper) - Fedora Core 5 is ok! In-Reply-To: References: <20060726191513.28407.qmail@web53802.mail.yahoo.com> Message-ID: It is also possible to undefine TIOCSERGETLSR on Linux. It would be nice if BSD and Solaris made the line status register available but it isn't really a standard. On Thu, 27 Jul 2006, Joachim Buechse wrote: > Linux offers a feature (TIOCSERGETLSR) that allows to check if all > data has been sent. This feature does not exist on OSX, BSD, Solaris > and probably some other systems. For these systems RXTX uses a > separate thread that calls tc_drain() - on return of this call all > data has been written. The pthread_kill is used to guarantee that the > drain thread has been canceled. > > On Linux there is no forced "wait" between the setting of the > "closing" flag and the end of the procedure. The test should to be > done on a BSD or Solaris system. But maybe you could add a usleep > (50000) just before the second sprintf. This might in fact be helpful > to see if the problem exists on Linux as well. > > Thanks, > Joachim > > > On 26.07.2006, at 21:15, Adenilson Cavalcanti wrote: > >> Dear Joachim Buechse >> >> I'm pretty new to this list (actually, first post) but got curious >> about the issue that you reported. >> >> If a undertood the code correctly, SerialImp.c -> >> interruptEventLoop only calls pthread_kill when compiled for MacOSX. >> >> Anyway, I changed the code to print field values of structure >> object 'index' and got this results: >> >> 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 >> CLOSING=0 >> 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 >> CLOSING=1 >> >> Which I think seems to be o.k. (I must also comment that I'm >> running FC5, kernel 2.6.15, gcc 4.1.1, jdk 1.5.0_06). >> >> Bellow you will find where in source code I printed the debug >> information. >> >> I was wondering why in Linux is not necessary to call pthread_kill >> (of course I did read the comments about "output buffer empty" but >> don't get it...). Any comments? >> >> Best regards >> >> Savago >> >> //-------------------------------------------------------------------- >> -------------------------- >> Changed code. >> //-------------------------------------------------------------------- >> -------------------------- >> /** XXX: DEBUG INFO*/ >> snprintf(message, sizeof(message), "1 interrupted thread for FD= >> %i PTR=%i CLOSING=%i\n", >> index->fd, index, index->closing ); >> report(message); >> >> #ifdef TIOCSERGETLSR >> index->closing=1; >> #endif /* TIOCSERGETLSR */ >> #ifdef WIN32 >> termios_interrupt_event_loop( index->fd, 1 ); >> #endif /* WIN32 */ >> #if !defined(TIOCSERGETLSR) && !defined(WIN32) >> . >> . >> . >> #endif >> /** XXX: DEBUG INFO*/ >> snprintf(message, sizeof(message), "2 interrupted thread for FD= >> %i PTR=%i CLOSING=%i\n", >> index->fd, index, index->closing ); >> report(message); >> >> report("interruptEventLoop: interrupted\n"); >> >> //-------------------------------------------------------------------- >> -------------------------- >> OUTPUT: >> >> 15:00:24:******* report_serial_events: sending DATA_AVAILABLE >> 15:00:24:******* reporting data available >> 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 >> CLOSING=0 >> 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 >> CLOSING=1 >> 15:00:24:******* interruptEventLoop: interrupted >> 15:00:24:******* eventLoop: got interrupt >> 15:00:24:******* setDTR( 0 ) >> 15:00:24:******* setDSR( 0 ) >> 15:00:24:******* >nativeClose pid >> 15:00:24:******* nativeClose: pid >> 15:00:24:******* nativeClose: discarding remaining datai (tcflush) >> 15:00:24:******* nativeClose: calling close >> 15:00:24:******* fhs_unlock: Removing LockFile >> 15:00:24:******* nativeClose: Delete jclazz >> 15:00:24:******* nativeClose: release filename >> 15:00:24:******* fhs_unlock: Removing LockFile >> //-------------------------------------------------------------------- >> -------------------------- >> >> How low will we go? Check out Yahoo! Messengers low PC-to-Phone >> call rates. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From guille at sms.nl Thu Jul 27 00:30:47 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 27 Jul 2006 08:30:47 +0200 Subject: [Rxtx] more RS485 (was: Strange error (show stopper) - Fedora Core 5 is ok!) In-Reply-To: References: <20060726191513.28407.qmail@web53802.mail.yahoo.com> Message-ID: <7.0.1.0.0.20060727082321.036f10d0@sms.nl> At 00:01 27/07/2006, Joachim Buechse wrote: >Linux offers a feature (TIOCSERGETLSR) that allows to check if all >data has been sent. Just a side note: This is one of the things that is useful when one needs to control external RS232 to RS485 converters with the RTS or DTR lines. The above lets you look at the transmit shift register to know if/when the last character has been completely shifted out ('transmit shift register empty' is a different thing than 'output FIFO empty' and than 'software output buffer empty'). This is something you currently cannot do from your application using rxtx. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From gergg at cox.net Thu Jul 27 11:08:32 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 27 Jul 2006 12:08:32 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C7B33C.8090005@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> <44C7828B.7040904@cox.net> <44C7B33C.8090005@sun.com> Message-ID: <44C8F310.2040107@cox.net> Paul Klissner wrote: > What if there are multiple devices on a system of different types? > There needs to be a way to get the right configuration file to associate > with the right device, and the application should seamlessly work with either. > The application code layered over the API should not have to be aware > of the configuration file or the programmatic peculiarities of the > underlying hardware. If the configuration mechanism is the standard and must be supported, then every device will have to have such a configuration object. The configuration object would be the per device mechanism with a real API on that object. I'll use the Jini ConfigurationFile syntax here as an example: com2 { driver = "name.of.device.driver.class"; config = new com.deviceco.rs485.Parameters( ... arguments to parameter construction ... ); } then the API would ask for the driver and configuration for device com2, and have all the things needed to make the correct device used with the correct configuration. Gregg Wonderly From fredm at alum.mit.edu Fri Jul 28 04:32:56 2006 From: fredm at alum.mit.edu (Fred G. Martin) Date: Fri, 28 Jul 2006 06:32:56 -0400 Subject: [Rxtx] precompiled for Intel Mac? Message-ID: Dear RXTX'ers, Would there be a precompiled binary of the older 2.0-7pre1 version (javax.comm namespace) rxtx for the Intel Mac platform? Would I just need the libSerial.jnilib file? Thank you, Fred From savagobr at yahoo.com Fri Jul 28 09:34:35 2006 From: savagobr at yahoo.com (Adenilson Cavalcanti) Date: Fri, 28 Jul 2006 08:34:35 -0700 (PDT) Subject: [Rxtx] Strange error (show stopper) - FC5 still ok! Message-ID: <20060728153435.41645.qmail@web53815.mail.yahoo.com> Friends I repeated the test, both undefining TIOCSERGETLSR in SerialImp.h as also adding a sleep in function 'interruptEventLoop' and it still is working fine. Later I can test it in pcbsd (based on FreeBSD 6) on my notebook. So far, I think that we can say that in Linux this error doesn't happen. Best regards Savago //------------------------------------------------------------------------ Result with #undef TIOCSERGETLSR 11:08:11:******* 1 interrupted thread for FD=51 PTR=-1321354040 CLOSING=0 11:08:11:******* 2 interrupted thread for FD=51 PTR=-1321354040 CLOSING=1 Result with usleep(50000) 11:14:57:******* 1 interrupted thread for FD=51 PTR=-1322914604 CLOSING=0 11:14:57:******* 2 interrupted thread for FD=51 PTR=-1322914604 CLOSING=1 --------------------------------- How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone call rates. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060728/acd6aec1/attachment-0334.html From joachim at buechse.de Fri Jul 28 12:48:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 28 Jul 2006 20:48:33 +0200 Subject: [Rxtx] precompiled for Intel Mac? In-Reply-To: References: Message-ID: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> There will be. However not before we have figured out some remaining issues. Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 28.07.2006, at 12:32, Fred G. Martin wrote: > Dear RXTX'ers, > > Would there be a precompiled binary of the older 2.0-7pre1 version > (javax.comm namespace) rxtx for the Intel Mac platform? > > Would I just need the libSerial.jnilib file? > > Thank you, > Fred > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From fredm at alum.mit.edu Fri Jul 28 15:30:38 2006 From: fredm at alum.mit.edu (Fred G. Martin) Date: Fri, 28 Jul 2006 17:30:38 -0400 Subject: [Rxtx] precompiled for Intel Mac? In-Reply-To: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> References: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> Message-ID: <4616ED35-24BC-4FD3-90FB-81CAA851FB08@alum.mit.edu> May I ask another way--- can it [easily] be built from the 2.0-7pre1 sources? Fred On Jul 28, 2006, at 2:48 PM, Joachim Buechse wrote: > There will be. However not before we have figured out some remaining > issues. > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 28.07.2006, at 12:32, Fred G. Martin wrote: > >> Dear RXTX'ers, >> >> Would there be a precompiled binary of the older 2.0-7pre1 version >> (javax.comm namespace) rxtx for the Intel Mac platform? >> >> Would I just need the libSerial.jnilib file? >> >> Thank you, >> Fred >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Fri Jul 28 21:04:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 28 Jul 2006 21:04:45 -0600 (MDT) Subject: [Rxtx] precompiled for Intel Mac? In-Reply-To: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> References: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> Message-ID: On Fri, 28 Jul 2006, Joachim Buechse wrote: > There will be. However not before we have figured out some remaining > issues. > Joachim > Joachim and I are trying to get together to work out the remaining issues. I'll be looking at some w32 issues this weekend - a lovely job everyone should do exactly once. There are a few details that need attention. The summer vacation schedual is keeping things at a slow pace. This will be the first free weekend I've had in a while. I'm also gathering a list of things to do on Linux and Solaris which so far isn't too big but there are some that can be problems depending upon your use. Bugzilla is also your friend for bugs that are not getting attention right away. All bugs are interesting but sometimes forgotten on the mail list. I do go through all the bugs in bugzilla one by one now and then. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jul 29 05:18:25 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 29 Jul 2006 07:18:25 -0400 Subject: [Rxtx] The new JSR and RS485 - Moderator Ruling In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: Hi All, It has been several days since I asked the below question. There has not been much in the way of response. Therefore, I am using my new-age radioactive mutant moderator super-powers to make a (non-final) decision that: 1. We can live with unofficial RS485 support for a while, 2. The JSR specification that we embark upon will focus on serial and parallel ports and 3. We may revisit the RS485 question, in the future. Thanks! - Doug Date: Wed, 26 Jul 2006 06:28:33 -0400 From: "Dr. Douglas Lyon" Subject: Should we defer JSR support of RS485? To: RXTX Developers and Users , lyon at docjava.com Original-recipient: rfc822;dlyon at optonline.net Hi All, Would it make sense to focus the JSR on rock solid serial and parallel port support? Can the RS485 people live with unofficial support, at least until we get the JSR accepted and the implementation rock solid? Thanks! - Doug From naranjo.manuel at gmail.com Sat Jul 29 07:59:10 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Sat, 29 Jul 2006 10:59:10 -0300 Subject: [Rxtx] The new JSR and RS485 - Moderator Ruling In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: <44CB69AE.8030104@gmail.com> +1 Totally agree, Manuel > Hi All, > > It has been several days since I asked the below question. > There has not been much in the way of response. > Therefore, I am using my new-age radioactive > mutant moderator super-powers to > make a (non-final) decision that: > 1. We can live with unofficial RS485 support for a while, > 2. The JSR specification that we embark upon will focus on > serial and parallel ports and > 3. We may revisit the RS485 question, in the future. > > Thanks! > - Doug > > > Date: Wed, 26 Jul 2006 06:28:33 -0400 > From: "Dr. Douglas Lyon" > Subject: Should we defer JSR support of RS485? > To: RXTX Developers and Users , lyon at docjava.com > Original-recipient: rfc822;dlyon at optonline.net > > Hi All, > > Would it make sense to focus the JSR on rock solid > serial and parallel port support? > > Can the RS485 people live with unofficial support, at least until > we get the JSR accepted and the implementation rock solid? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Sat Jul 29 14:21:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 29 Jul 2006 14:21:32 -0600 (MDT) Subject: [Rxtx] The new JSR and RS485 - Moderator Ruling In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: Hi Doug At this time, I agree. RS485 is interesting and I would be intested in participating in future discussions/plans with RS485. On Sat, 29 Jul 2006, Dr. Douglas Lyon wrote: > Hi All, > > It has been several days since I asked the below question. > There has not been much in the way of response. > Therefore, I am using my new-age radioactive > mutant moderator super-powers to > make a (non-final) decision that: > 1. We can live with unofficial RS485 support for a while, > 2. The JSR specification that we embark upon will focus on > serial and parallel ports and > 3. We may revisit the RS485 question, in the future. > > Thanks! > - Doug > > > Date: Wed, 26 Jul 2006 06:28:33 -0400 > From: "Dr. Douglas Lyon" > Subject: Should we defer JSR support of RS485? > To: RXTX Developers and Users , lyon at docjava.com > Original-recipient: rfc822;dlyon at optonline.net > > Hi All, > > Would it make sense to focus the JSR on rock solid > serial and parallel port support? > > Can the RS485 people live with unofficial support, at least until > we get the JSR accepted and the implementation rock solid? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Sun Jul 30 04:28:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 30 Jul 2006 06:28:49 -0400 Subject: [Rxtx] interfaces vs. abstract classes Message-ID: Hi All, I was thinking that the new JSR might be more interface oriented and less abstract class oriented. For example, instead of subclassing CommPort, perhaps we should implement a CommPortInterface. How would this look? I don't know. But, perhaps, it would look something like this: package gnu.io; import java.io.InputStream; import java.io.IOException; import java.io.OutputStream; /** * User: lyon * Date: Jul 30, 2006 * Time: 5:19:55 AM * Copyright DocJava, Inc. 2005. */ public interface CommPortInterface { void enableReceiveFraming(int f) throws UnsupportedCommOperationException; void disableReceiveFraming(); boolean isReceiveFramingEnabled(); int getReceiveFramingByte(); void disableReceiveTimeout(); void enableReceiveTimeout(int time) throws UnsupportedCommOperationException; boolean isReceiveTimeoutEnabled(); int getReceiveTimeout(); void enableReceiveThreshold(int thresh) throws UnsupportedCommOperationException; void disableReceiveThreshold(); int getReceiveThreshold(); boolean isReceiveThresholdEnabled(); void setInputBufferSize(int size); int getInputBufferSize(); void setOutputBufferSize(int size); int getOutputBufferSize(); void close(); InputStream getInputStream() throws IOException; OutputStream getOutputStream() throws IOException; String getName(); } Then, we can use: /** * CommPort */ public abstract class CommPort implements CommPortInterface And replace uses of CommPort with uses of CommPortInterface.... package gnu.io; import java.io.FileDescriptor; /** * User: lyon * Date: Jul 30, 2006 * Time: 5:40:20 AM * Copyright DocJava, Inc. 2005. */ public interface CommPortIdentifierInterface { int PORT_SERIAL = 1; int PORT_PARALLEL = 2; int PORT_I2C = 3; int PORT_RS485 = 4; int PORT_RAW = 5; void addPortOwnershipListener(CommPortOwnershipListener c); String getCurrentOwner(); String getName(); int getPortType(); boolean isCurrentlyOwned(); CommPortInterface open(FileDescriptor f) throws UnsupportedCommOperationExce ption; CommPortInterface open(String TheOwner, int i) throws PortInUseException; void removePortOwnershipListener(CommPortOwnershipListener c); } If we continue in this vain, the SerialPort should have an interface that it implements, called (due to my lack of imagination) the SerialPortInterface package gnu.io; import java.util.TooManyListenersException; /** * User: lyon * Date: Jul 30, 2006 * Time: 5:56:35 AM * Copyright DocJava, Inc. 2005. */ public interface SerialPortInterface extends CommPortInterface { int DATABITS_5 = 5; int DATABITS_6 = 6; int DATABITS_7 = 7; int DATABITS_8 = 8; int PARITY_NONE = 0; int PARITY_ODD = 1; int PARITY_EVEN = 2; int PARITY_MARK = 3; int PARITY_SPACE = 4; int STOPBITS_1 = 1; int STOPBITS_2 = 2; int STOPBITS_1_5 = 3; int FLOWCONTROL_NONE = 0; int FLOWCONTROL_RTSCTS_IN = 1; int FLOWCONTROL_RTSCTS_OUT = 2; int FLOWCONTROL_XONXOFF_IN = 4; int FLOWCONTROL_XONXOFF_OUT = 8; void setSerialPortParams(int b, int d, int s, int p) throws UnsupportedCommOperationException; int getBaudRate(); int getDataBits(); int getStopBits(); int getParity(); void setFlowControlMode(int flowcontrol) throws UnsupportedCommOperationException; int getFlowControlMode(); boolean isDTR(); void setDTR(boolean state); void setRTS(boolean state); boolean isCTS(); boolean isDSR(); boolean isCD(); boolean isRI(); boolean isRTS(); void sendBreak(int duration); void addEventListener(SerialPortEventListener lsnr) throws TooManyListenersException; void removeEventListener(); void notifyOnDataAvailable(boolean enable); void notifyOnOutputEmpty(boolean enable); void notifyOnCTS(boolean enable); void notifyOnDSR(boolean enable); void notifyOnRingIndicator(boolean enable); void notifyOnCarrierDetect(boolean enable); void notifyOnOverrunError(boolean enable); void notifyOnParityError(boolean enable); void notifyOnFramingError(boolean enable); void notifyOnBreakInterrupt(boolean enable); byte getParityErrorChar() throws UnsupportedCommOperationException; boolean setParityErrorChar(byte b) throws UnsupportedCommOperationException; byte getEndOfInputChar() throws UnsupportedCommOperationException; boolean setEndOfInputChar(byte b) throws UnsupportedCommOperationException; boolean setUARTType(String type, boolean test) throws UnsupportedCommOperationException; String getUARTType() throws UnsupportedCommOperationException; boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException; int getBaudBase() throws UnsupportedCommOperationException; boolean setDivisor(int Divisor) throws UnsupportedCommOperationException; int getDivisor() throws UnsupportedCommOperationException; boolean setLowLatency() throws UnsupportedCommOperationException; boolean getLowLatency() throws UnsupportedCommOperationException; boolean setCallOutHangup(boolean NoHup) throws UnsupportedCommOperationException; boolean getCallOutHangup() throws UnsupportedCommOperationException; } And, of course, you need a parallel port: package gnu.io; import java.util.TooManyListenersException; /** * User: lyon * Date: Jul 30, 2006 * Time: 6:14:02 AM * Copyright DocJava, Inc. 2005. */ public interface ParallelPortInterface extends CommPortInterface { int LPT_MODE_ANY = 0; int LPT_MODE_SPP = 1; int LPT_MODE_PS2 = 2; int LPT_MODE_EPP = 3; int LPT_MODE_ECP = 4; int LPT_MODE_NIBBLE = 5; int getMode(); int setMode(int mode) throws UnsupportedCommOperationException; void restart(); void suspend(); boolean isPaperOut(); boolean isPrinterBusy(); boolean isPrinterError(); boolean isPrinterSelected(); boolean isPrinterTimedOut(); int getOutputBufferFree(); void addEventListener(ParallelPortEventListener lsnr) throws TooManyListenersException; void removeEventListener(); void notifyOnError(boolean enable); void notifyOnBuffer(boolean enable); } Now, I have refactored my code to take advantage of these interfaces. And have done very limited testing. The problem is that we have some static methods in classes like CommPortIdentifier that don't refactor into interfaces cleanly. I don't know what to do about that... What do people think about the idea of using interfaces rather than abstract classes for making the system a little more component oriented? Thanks! - Doug From tjarvi at qbang.org Sun Jul 30 10:13:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 30 Jul 2006 10:13:06 -0600 (MDT) Subject: [Rxtx] interfaces vs. abstract classes In-Reply-To: References: Message-ID: Hi Doug, I don't see a big advantage one way or another for the interfaces. One thing that should be added but not supported initially on all platforms is event notification of devices becomming physically available and vanishing. This is not the same as digging into USB. If the OS can provide a clean event driven method and provides a proper interface, it is of great use to people dealing with USB and Serial and Parallel Dongles. On Sun, 30 Jul 2006, Dr. Douglas Lyon wrote: > Hi All, > I was thinking that the new JSR might be more > interface oriented and less abstract class oriented. > > For example, instead of subclassing CommPort, perhaps > we should implement a CommPortInterface. > > How would this look? > > I don't know. But, perhaps, it would look something like this: > package gnu.io; > > import java.io.InputStream; > import java.io.IOException; > import java.io.OutputStream; > > /** > * User: lyon > * Date: Jul 30, 2006 > * Time: 5:19:55 AM > * Copyright DocJava, Inc. 2005. > */ > public interface CommPortInterface { > void enableReceiveFraming(int f) > throws UnsupportedCommOperationException; > > void disableReceiveFraming(); > > boolean isReceiveFramingEnabled(); > > int getReceiveFramingByte(); > > void disableReceiveTimeout(); > > void enableReceiveTimeout(int time) > throws UnsupportedCommOperationException; > > boolean isReceiveTimeoutEnabled(); > > int getReceiveTimeout(); > > void enableReceiveThreshold(int thresh) > throws UnsupportedCommOperationException; > > void disableReceiveThreshold(); > > int getReceiveThreshold(); > > boolean isReceiveThresholdEnabled(); > > void setInputBufferSize(int size); > > int getInputBufferSize(); > > void setOutputBufferSize(int size); > > int getOutputBufferSize(); > > void close(); > > InputStream getInputStream() throws IOException; > > OutputStream getOutputStream() throws IOException; > > String getName(); > } > > Then, we can use: > /** > * CommPort > */ > public abstract class CommPort implements CommPortInterface > > And replace uses of CommPort with uses of CommPortInterface.... > package gnu.io; > > import java.io.FileDescriptor; > > /** > * User: lyon > * Date: Jul 30, 2006 > * Time: 5:40:20 AM > * Copyright DocJava, Inc. 2005. > */ > public interface CommPortIdentifierInterface { > int PORT_SERIAL = 1; > int PORT_PARALLEL = 2; > int PORT_I2C = 3; > int PORT_RS485 = 4; > int PORT_RAW = 5; > > void addPortOwnershipListener(CommPortOwnershipListener c); > > String getCurrentOwner(); > > String getName(); > > int getPortType(); > > boolean isCurrentlyOwned(); > > CommPortInterface open(FileDescriptor f) throws > UnsupportedCommOperationExce > ption; > > CommPortInterface open(String TheOwner, int i) > throws PortInUseException; > > void removePortOwnershipListener(CommPortOwnershipListener c); > } > > If we continue in this vain, the SerialPort should have an interface that > it implements, called (due to my lack of imagination) the SerialPortInterface > > package gnu.io; > > import java.util.TooManyListenersException; > > /** > * User: lyon > * Date: Jul 30, 2006 > * Time: 5:56:35 AM > * Copyright DocJava, Inc. 2005. > */ > public interface SerialPortInterface extends CommPortInterface { > int DATABITS_5 = 5; > int DATABITS_6 = 6; > int DATABITS_7 = 7; > int DATABITS_8 = 8; > int PARITY_NONE = 0; > int PARITY_ODD = 1; > int PARITY_EVEN = 2; > int PARITY_MARK = 3; > int PARITY_SPACE = 4; > int STOPBITS_1 = 1; > int STOPBITS_2 = 2; > int STOPBITS_1_5 = 3; > int FLOWCONTROL_NONE = 0; > int FLOWCONTROL_RTSCTS_IN = 1; > int FLOWCONTROL_RTSCTS_OUT = 2; > int FLOWCONTROL_XONXOFF_IN = 4; > int FLOWCONTROL_XONXOFF_OUT = 8; > > void setSerialPortParams(int b, int d, int s, int p) > throws UnsupportedCommOperationException; > > int getBaudRate(); > > int getDataBits(); > > int getStopBits(); > > int getParity(); > > void setFlowControlMode(int flowcontrol) > throws UnsupportedCommOperationException; > > int getFlowControlMode(); > > boolean isDTR(); > > void setDTR(boolean state); > > void setRTS(boolean state); > > boolean isCTS(); > > boolean isDSR(); > > boolean isCD(); > > boolean isRI(); > > boolean isRTS(); > > void sendBreak(int duration); > > void addEventListener(SerialPortEventListener lsnr) > throws TooManyListenersException; > > void removeEventListener(); > > void notifyOnDataAvailable(boolean enable); > > void notifyOnOutputEmpty(boolean enable); > > void notifyOnCTS(boolean enable); > > void notifyOnDSR(boolean enable); > > void notifyOnRingIndicator(boolean enable); > > void notifyOnCarrierDetect(boolean enable); > > void notifyOnOverrunError(boolean enable); > > void notifyOnParityError(boolean enable); > > void notifyOnFramingError(boolean enable); > > void notifyOnBreakInterrupt(boolean enable); > > byte getParityErrorChar() > throws UnsupportedCommOperationException; > > boolean setParityErrorChar(byte b) > throws UnsupportedCommOperationException; > > byte getEndOfInputChar() > throws UnsupportedCommOperationException; > > boolean setEndOfInputChar(byte b) > throws UnsupportedCommOperationException; > > boolean setUARTType(String type, boolean test) > throws UnsupportedCommOperationException; > > String getUARTType() > throws UnsupportedCommOperationException; > > boolean setBaudBase(int BaudBase) > throws UnsupportedCommOperationException; > > int getBaudBase() > throws UnsupportedCommOperationException; > > boolean setDivisor(int Divisor) > throws UnsupportedCommOperationException; > > int getDivisor() > throws UnsupportedCommOperationException; > > boolean setLowLatency() > throws UnsupportedCommOperationException; > > boolean getLowLatency() > throws UnsupportedCommOperationException; > > boolean setCallOutHangup(boolean NoHup) > throws UnsupportedCommOperationException; > > boolean getCallOutHangup() > throws UnsupportedCommOperationException; > } > > And, of course, you need a parallel port: > package gnu.io; > > import java.util.TooManyListenersException; > > /** > * User: lyon > * Date: Jul 30, 2006 > * Time: 6:14:02 AM > * Copyright DocJava, Inc. 2005. > */ > public interface ParallelPortInterface extends CommPortInterface { > int LPT_MODE_ANY = 0; > int LPT_MODE_SPP = 1; > int LPT_MODE_PS2 = 2; > int LPT_MODE_EPP = 3; > int LPT_MODE_ECP = 4; > int LPT_MODE_NIBBLE = 5; > > int getMode(); > > int setMode(int mode) > throws UnsupportedCommOperationException; > > void restart(); > > void suspend(); > > boolean isPaperOut(); > > boolean isPrinterBusy(); > > boolean isPrinterError(); > > boolean isPrinterSelected(); > > boolean isPrinterTimedOut(); > > int getOutputBufferFree(); > > void addEventListener(ParallelPortEventListener lsnr) > throws TooManyListenersException; > > void removeEventListener(); > > void notifyOnError(boolean enable); > > void notifyOnBuffer(boolean enable); > } > > Now, I have refactored my code to take advantage of these interfaces. > And have done very limited testing. The problem is that we have some > static methods in > classes like CommPortIdentifier that don't refactor into interfaces cleanly. > > I don't know what to do about that... > > What do people think about the idea of using interfaces rather than > abstract classes for making the system a little more component oriented? > > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From berkland at spamcop.net Sun Jul 30 15:15:59 2006 From: berkland at spamcop.net (Doug Berkland) Date: Sun, 30 Jul 2006 17:15:59 -0400 Subject: [Rxtx] interfaces vs. abstract classes In-Reply-To: <269e40090607301408q41759906k6e45f0dd33618655@mail.gmail.com> References: <269e40090607301408q41759906k6e45f0dd33618655@mail.gmail.com> Message-ID: <269e40090607301415p3238e51eyce4b124f385c1918@mail.gmail.com> I think the interfaces are a good idea. They will allow more flexibility if someone needs to create a modified implementation. I just hope that all of this will end up in the javax.comm package instead of gnu.io. From gergg at cox.net Sun Jul 30 16:30:37 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 30 Jul 2006 17:30:37 -0500 Subject: [Rxtx] interfaces vs. abstract classes In-Reply-To: <269e40090607301415p3238e51eyce4b124f385c1918@mail.gmail.com> References: <269e40090607301408q41759906k6e45f0dd33618655@mail.gmail.com> <269e40090607301415p3238e51eyce4b124f385c1918@mail.gmail.com> Message-ID: <44CD330D.20608@cox.net> Doug Berkland wrote: > I think the interfaces are a good idea. They will allow more > flexibility if someone needs to create a modified implementation. I > just hope that all of this will end up in the javax.comm package > instead of gnu.io. You can provide an abstract class that implements the interface, but defers on the implementation details to allow porting parties the ability to reuse common code with less variations on the behavior that users experience. Please don't include anything in the interface that can't be described in 100% accuracy and perform identically on all possible ports, or throw a well described compatibility exception. Gregg Wonderly From lyon at docjava.com Sun Jul 30 17:27:13 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 30 Jul 2006 19:27:13 -0400 Subject: [Rxtx] interfaces vs abstract classes Message-ID: Hi All, If you ever want to use serial ports with RMI, a nice set of interfaces will be required. On the other hand, perhaps nobody wants that. On the other, other hand, there are some areas where we could really use some API clean-up. This could be a chance to shape the JSR with really clean interfaces with well defined semantics and some good Javadoc. For example: I2CPort, RS485Port and SerialPort all begin with duplicate code. We can put all the constants in a nice interface, as appears below. I have added a little Javadoc. Would someone like to finish it up? So far, I have not added any new features, other than documentation and refactoring. >More importantly is the philosophical start point for a >specification in a JSR; >that is speaking to the future: >Interfaces describe capabilities; >Classes implement capabilities; Methods execute capabilities. >In the long run, a plug-in based system can be used to substitute >implementation >but retain the use of the interface. > >So, use inheritance for internal code reuse and interfaces for >contract definition. > >As the famous GoF book says: > >Prefer interfaces over inheritance. > >Use interfaces as a design-time resource when you are planning your system. >It is almost always useful to define a contract of functionality for >a given set of features. Clients of such a contract should never >have to bother with details of actual implementations. - DL public interface SerialPortInterface extends CommPortInterface { int DATABITS_5 = 5; int DATABITS_6 = 6; int DATABITS_7 = 7; int DATABITS_8 = 8; int PARITY_NONE = 0; int PARITY_ODD = 1; int PARITY_EVEN = 2; int PARITY_MARK = 3; int PARITY_SPACE = 4; int STOPBITS_1 = 1; int STOPBITS_2 = 2; int STOPBITS_1_5 = 3; int FLOWCONTROL_NONE = 0; int FLOWCONTROL_RTSCTS_IN = 1; int FLOWCONTROL_RTSCTS_OUT = 2; int FLOWCONTROL_XONXOFF_IN = 4; int FLOWCONTROL_XONXOFF_OUT = 8; /** * @return true if the DTR bit is set. * * @see #setDTR */ boolean isCTS(); /** * @return true if the DTR bit is set. * */ boolean isDSR(); /** * @return true if the CD bit is set. * */ boolean isCD(); /** * @return true if the RI bit is set. * */ boolean isRI(); /** * @return true if the RTS bit is set. * * @see #setRTS */ boolean isRTS(); /** would someone like to write some nice javadoc for the following? */ void addEventListener(SerialPortEventListener lsnr) throws TooManyListenersException; void removeEventListener(); void notifyOnDataAvailable(boolean enable); void notifyOnOutputEmpty(boolean enable); void notifyOnCTS(boolean enable); void notifyOnDSR(boolean enable); void notifyOnRingIndicator(boolean enable); void notifyOnCarrierDetect(boolean enable); void notifyOnOverrunError(boolean enable); void notifyOnParityError(boolean enable); void notifyOnFramingError(boolean enable); void notifyOnBreakInterrupt(boolean enable); byte getParityErrorChar() throws UnsupportedCommOperationException; boolean setParityErrorChar(byte b) throws UnsupportedCommOperationException; byte getEndOfInputChar() throws UnsupportedCommOperationException; boolean setEndOfInputChar(byte b) throws UnsupportedCommOperationException; boolean setUARTType(String type, boolean test) throws UnsupportedCommOperationException; String getUARTType() throws UnsupportedCommOperationException; boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException; int getBaudBase() throws UnsupportedCommOperationException; boolean setDivisor(int Divisor) throws UnsupportedCommOperationException; int getDivisor() throws UnsupportedCommOperationException; boolean setLowLatency() throws UnsupportedCommOperationException; boolean getLowLatency() throws UnsupportedCommOperationException; boolean setCallOutHangup(boolean NoHup) throws UnsupportedCommOperationException; boolean getCallOutHangup() throws UnsupportedCommOperationException; /** * @return the current baud rate */ int getBaudRate(); /** * @return the current number of data bits: DATABITS_5, DATABITS_6, * DATABITS_7, or DATABITS_8. */ int getDataBits(); /** * @return the current number of stop bits: STOPBITS_1, STOPBITS_2, or * STOPBITS_1_5. */ int getStopBits(); /** * @return the current parity scheme: PARITY_NONE, PARITY_ODD, * PARITY_EVEN, PARITY_MARK or PARITY_SPACE. */ int getParity(); /** * Sends a break of the specified duration. * * @param millis the duration in milliseconds */ void sendBreak(int millis); /** * Sets the flow control mode. * * @param flowcontrol a bitmask combination of FLOWCONTROL_NONE, * FLOWCONTROL_RTSCTS_IN, FLOWCONTROL_RTSCTS_OUT, * FLOWCONTROL_XONXOFF_IN, and/or FLOWCONTROL_XONXOFF_OUT. */ void setFlowControlMode(int flowcontrol); /** * @return the current flow control mode as a bitmask of * FLOWCONTROL_NONE, FLOWCONTROL_RTSCTS_IN, FLOWCONTROL_RTSCTS_OUT, * FLOWCONTROL_XONXOFF_IN, and/or FLOWCONTROL_XONXOFF_OUT. */ int getFlowControlMode(); /** * Set the Receive Fifo trigger level. * If the UART has a FIFO and if it can have programmable trigger * levels, then this method will cause the UART to raise an interrupt * after trigger bytes have been received. * * @param trigger the trigger level * @deprecated */ void setRcvFifoTrigger(int trigger); /** * Sets the serial port parameters. * * @param baudRate the baud rate * @param dataBits the number of data bits: DATABITS_5, * DATABITS_6, DATABITS_7, or DATABITS_8 * @param stopBits the number of stop bits: STOPBITS_1, * STOPBITS_2, or STOPBITS_1_5 * @param parity the parity schema: PARITY_NONE, PARITY_ODD, * PARITY_EVEN, PARITY_MARK or PARITY_SPACE * @throws UnsupportedCommOperationException */ void setSerialPortParams(int baudRate, int dataBits, int stopBits, int parity) throws UnsupportedCommOperationException; /** * Sets or clears the DTR bit in the UART. * * @param dtr the Data Terminal Ready bit value * @see #isDTR */ void setDTR(boolean dtr); /** * @return true if the DTR bit is set. * * @see #setDTR */ boolean isDTR(); /** * Sets or clears the RTS bit in the UART. * * @param rts the Request To Send bit value */ void setRTS(boolean rts); } Here is the CommPortInterface: public interface CommPortInterface { /** * @return the name of this port. * */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is disabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } From tjarvi at qbang.org Sun Jul 30 17:43:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 30 Jul 2006 17:43:13 -0600 (MDT) Subject: [Rxtx] RMI In-Reply-To: References: Message-ID: On Sun, 30 Jul 2006, Dr. Douglas Lyon wrote: > Hi All, > > If you ever want to use serial ports with RMI, > a nice set of interfaces will be required. > So this would eventually lead to j2ee beans and such. The security model would have to be examined for this. Often there are tens of thousands of dollars in instrumentation or even cash drawers/POS sitting on the other end of the cable. A serial port should be no less secure than a hard drive. I think security is going to be OK but then we are opening up for a bunch of questions about how to get it working. That puts us in a position of answering how to bypass security with RMI to access hard drives [or serial ports]. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Jul 30 21:48:01 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 30 Jul 2006 22:48:01 -0500 Subject: [Rxtx] RMI In-Reply-To: References: Message-ID: <44CD7D71.2080306@cox.net> Trent Jarvi wrote: > On Sun, 30 Jul 2006, Dr. Douglas Lyon wrote: >>If you ever want to use serial ports with RMI, >>a nice set of interfaces will be required. > > So this would eventually lead to j2ee beans and such. > > The security model would have to be examined for this. Often there are > tens of thousands of dollars in instrumentation or even cash drawers/POS > sitting on the other end of the cable. > > A serial port should be no less secure than a hard drive. I think > security is going to be OK but then we are opening up for a bunch of > questions about how to get it working. > > That puts us in a position of answering how to bypass security with RMI to > access hard drives [or serial ports]. This really depends on whether you want those streams to be visible remotely, directly or not. I think that it is poor engineering practice for any Remote access to directly expose the raw hardware/stream/data. You need to have choices on how to transport and encapsulate data streams. This is the power of the RMI programming model. Mobile code can put computational activities on the client instead of the server. The next generation of RMI, with all of the security features you need was developed by the original RMI team and some others, and is the Jini Extensible Remote Invocation (JERI) stack that is available in Jini 2.0 and later versions (http://www.jini.org and http://starterkit.dev.java.net). One of the primary things that JERI provides is an authentication and authorization mechanism that is activated at deployment time, instead of being coded into the libraries. Gregg Wonderly From guille at sms.nl Mon Jul 31 03:17:29 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Mon, 31 Jul 2006 11:17:29 +0200 Subject: [Rxtx] interfaces vs. abstract classes In-Reply-To: References: Message-ID: <7.0.1.0.0.20060731111659.0363b620@sms.nl> At 12:28 30/07/2006, Dr. Douglas Lyon wrote: >Hi All, >I was thinking that the new JSR might be more >interface oriented and less abstract class oriented. > >For example, instead of subclassing CommPort, perhaps >we should implement a CommPortInterface. > >How would this look? Will it break backwards compatibility? Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From lyon at docjava.com Mon Jul 31 04:57:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 31 Jul 2006 06:57:39 -0400 Subject: [Rxtx] Rxtx RMI/SSL In-Reply-To: <44CD7D71.2080306@cox.net> References: <44CD7D71.2080306@cox.net> Message-ID: Hi All, Networked based serial ports are a nice option for java clients that do not need (or want) native method drivers installed. Applications include web-controlled robotics, network-based modems, auto-dialing addressbooks (remote dialers), remote sensing, etc. If you are behind a firewall, you may not feel the need for RMI/SSL security. After all, hacking into a serial port behind a firewall does seem a bit over-the-top. On the other hand, for those who feel they want to go over the Internet; I have been playing around with RMI over SSL. Here is a paper on the topic: http://show.docjava.com:8086/pub/document/jot/rjs.pdf Remote Job Submission Security by Pawel Krepstzul and Douglas A. Lyon, in Journal of Object Technology, vol. 5, no. 1, Janurary-February 2006, pp. 13-29. From the programmer point-of-view the SSL part is not quite transparent, but, given proper diligence, can be made somewhat secure. Naturally, you can put the exchange in a high-level of abstraction. I guess it really depends on the application. The question of how level-of-abstraction impacts security, remains open. You may observe a trend toward RMI based API's by looking at JAI (Java Advanced Imaging). Cheers! - Doug >Trent Jarvi wrote: >> On Sun, 30 Jul 2006, Dr. Douglas Lyon wrote: >>>If you ever want to use serial ports with RMI, >>>a nice set of interfaces will be required. >> >> So this would eventually lead to j2ee beans and such. >> >> The security model would have to be examined for this. Often there are >> tens of thousands of dollars in instrumentation or even cash drawers/POS >> sitting on the other end of the cable. >> >> A serial port should be no less secure than a hard drive. I think >> security is going to be OK but then we are opening up for a bunch of >> questions about how to get it working. >> >> That puts us in a position of answering how to bypass security with RMI to >> access hard drives [or serial ports]. > >This really depends on whether you want those streams to be visible remotely, >directly or not. I think that it is poor engineering practice for any Remote >access to directly expose the raw hardware/stream/data. You need to have >choices on how to transport and encapsulate data streams. This is >the power of >the RMI programming model. Mobile code can put computational >activities on the >client instead of the server. > >The next generation of RMI, with all of the security features you need was >developed by the original RMI team and some others, and is the Jini Extensible >Remote Invocation (JERI) stack that is available in Jini 2.0 and >later versions >(http://www.jini.org and http://starterkit.dev.java.net). > >One of the primary things that JERI provides is an authentication and >authorization mechanism that is activated at deployment time, instead of being >coded into the libraries. > >Gregg Wonderly >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Mon Jul 31 07:16:51 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 31 Jul 2006 15:16:51 +0200 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> Message-ID: <1154351811.44ce02c3a5539@webmail.eatserver.nl> Hi Doug, I understand. Note that we are not only concerned about source compatibility, but also about binary compatibility (which would be preserved as well with this approach if I understood correctly) Best regards, Guillermo Quoting "Dr. Douglas Lyon" : > Hi All, > At present I have a prototype version of the libraries that I am > testing that contains the Interfaces, with growing Javadoc. > I have been refactoring my code to take advantage of these > interfaces, but, in the interest of backward compatibility, > have left the abstract classes, for those who want to continue > to use and test them. So there is 100% backward compatibility. > > My goal is to identify the features of the class specification and > provide good documentation for them. I think this is seen most clearly in > the below code. This has ZERO impact on existing code that > seeks to make use of the CommPort class. > > I am adding interfaces and documentation to arrive at a specification. > Abstract methods and constants move from the abstract class into the > interface, but then the abstract class implements the interface. > > To the API user, it should have no effect. > > Cheers! > - Doug > > > public interface CommPortIdentifierInterface { > > int PORT_I2C = 3; > int PORT_RS485 = 4; > int PORT_RAW = 5; > /** > * RS-232 serial port. > */ > int PORT_SERIAL = 1; > /** > * IEEE 1284 parallel port. > */ > int PORT_PARALLEL = 2; > > > > /** > * @return the port name, typically an OS-dependent hardware label. > * > */ > String getName(); > > /** > * @return the port type, PORT_SERIAL or PORT_PARALLEL. > */ > int getPortType() > ; > > /** > * @return the current owner of this port. > */ > String getCurrentOwner() > ; > > /** > * @return true if this port is currently owned. > */ > boolean isCurrentlyOwned() ; > > /** > * @return communications port. > * If the port is in use by another application, it will be notified > * with a PORT_OWNERSHIP_REQUESTED event. If the current owner closes > * the port, then this method will succeed. Otherwise a > * PortInUseException will be thrown. > * @param appName the name of the application requesting the port > * @param timeout number of miliseconds to wait for the port to open > * @throws PortInUseException > */ > CommPortInterface open(String appName, int timeout) > throws PortInUseException; > > /** > * @return a port using a file descriptor. > * @param fd the file descriptor > * @exception UnsupportedCommOperationException if the platform does > not > * support this functionality > */ > CommPortInterface open(FileDescriptor fd) > throws UnsupportedCommOperationException; > > /** > * Adds the specified listener to the list of ownership listeners for > * this port. > * @param listener the ownership listener to add > */ > void addPortOwnershipListener(CommPortOwnershipListener listener); > > /** > * Removes the specified listener from the list of ownership listeners > for > * this port. > * @param listener the ownership listener to remove > */ > void removePortOwnershipListener(CommPortOwnershipListener listener); > } > public abstract class CommPort implements CommPortInterface { > protected String name; > private final static boolean debug = false; > > public void close() { > if (debug) System.out.println("CommPort:close()"); > > try { > CommPortIdentifierInterface cp = > CommPortIdentifier.getPortIdentifier(this); > if (cp != null) > > CommPortIdentifier.getPortIdentifier(this).internalClosePort(); > } > catch (NoSuchPortException e) { > e.printStackTrace(); > } > } > > public String getName() { > if (debug) System.out.println("CommPort:getName()"); > return (name); > } > > public String toString() { > if (debug) System.out.println("CommPort:toString()"); > return (name); > } > } > >At 12:28 30/07/2006, Dr. Douglas Lyon wrote: > >>Hi All, > >>I was thinking that the new JSR might be more > >>interface oriented and less abstract class oriented. > >> > >>For example, instead of subclassing CommPort, perhaps > >>we should implement a CommPortInterface. > >> > >>How would this look? > > > >Will it break backwards compatibility? > > > >Guillermo > >-- > >Guillermo Rodriguez Garcia > > > >Snijder Micro Systems phone +31-493-351020 > >G. Rodriguez Garcia fax +31-493-351530 > >Visser 25 email guille at sms.nl > >NL5751 BL Deurne > >The Netherlands http://www.snijder.com > > -- http://www.snijder.com/ SNIJDER Micro Systems From lyon at docjava.com Mon Jul 31 07:44:29 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 31 Jul 2006 09:44:29 -0400 Subject: [Rxtx] Do interfaces break backwards BINARY compatibility? Welcome to the serial ports of tomorrow! In-Reply-To: <1154351811.44ce02c3a5539@webmail.eatserver.nl> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> Message-ID: Hi All, The jar file, comm.jar, will change in the sense that there will be new byte codes for Interfaces and the abstract classes byte codes will change. However, the native methods are left unchanged. The goal is to specify "what is" via interfaces, minimizing the impact on the API. This enables RXTX to be a reference implementation of the interface specification. If the JSR is accepted and the interfaces become a part of the javax.comm package, then rxtx could implement the javax.comm specification. Thus, my VISION of the FUTURE (ta da): javax.comm programmers code to the javax.comm interfaces and use a factory method to get an RXTX-based driver. Does that sort of make sense? Thanks! - Doug >Hi Doug, > >I understand. Note that we are not only concerned about source >compatibility, but also about binary compatibility (which would be >preserved as well with this approach if I understood correctly) > >Best regards, >Guillermo > >Quoting "Dr. Douglas Lyon" : > >> Hi All, >> At present I have a prototype version of the libraries that I am >> testing that contains the Interfaces, with growing Javadoc. >> I have been refactoring my code to take advantage of these >> interfaces, but, in the interest of backward compatibility, >> have left the abstract classes, for those who want to continue >> to use and test them. So there is 100% backward compatibility. >> >> My goal is to identify the features of the class specification and >> provide good documentation for them. I think this is seen most clearly in >> the below code. This has ZERO impact on existing code that >> seeks to make use of the CommPort class. >> >> I am adding interfaces and documentation to arrive at a specification. >> Abstract methods and constants move from the abstract class into the >> interface, but then the abstract class implements the interface. >> >> To the API user, it should have no effect. >> >> Cheers! >> - Doug >> >> >> public interface CommPortIdentifierInterface { >> >> int PORT_I2C = 3; >> int PORT_RS485 = 4; >> int PORT_RAW = 5; >> /** >> * RS-232 serial port. >> */ >> int PORT_SERIAL = 1; >> /** >> * IEEE 1284 parallel port. >> */ >> int PORT_PARALLEL = 2; >> >> >> >> /** >> * @return the port name, typically an OS-dependent hardware label. >> * >> */ >> String getName(); >> >> /** >> * @return the port type, PORT_SERIAL or PORT_PARALLEL. >> */ >> int getPortType() >> ; >> >> /** >> * @return the current owner of this port. >> */ >> String getCurrentOwner() >> ; >> >> /** >> * @return true if this port is currently owned. >> */ >> boolean isCurrentlyOwned() ; >> >> /** >> * @return communications port. >> * If the port is in use by another application, it will be notified >> * with a PORT_OWNERSHIP_REQUESTED event. If the current owner closes >> * the port, then this method will succeed. Otherwise a >> * PortInUseException will be thrown. >> * @param appName the name of the application requesting the port >> * @param timeout number of miliseconds to wait for the port to open >> * @throws PortInUseException >> */ >> CommPortInterface open(String appName, int timeout) >> throws PortInUseException; >> >> /** >> * @return a port using a file descriptor. >> * @param fd the file descriptor >> * @exception UnsupportedCommOperationException if the platform does >> not >> * support this functionality >> */ >> CommPortInterface open(FileDescriptor fd) >> throws UnsupportedCommOperationException; >> >> /** >> * Adds the specified listener to the list of ownership listeners for >> * this port. >> * @param listener the ownership listener to add >> */ >> void addPortOwnershipListener(CommPortOwnershipListener listener); > > >> /** >> * Removes the specified listener from the list of ownership listeners >> for >> * this port. >> * @param listener the ownership listener to remove >> */ >> void removePortOwnershipListener(CommPortOwnershipListener listener); >> } >> public abstract class CommPort implements CommPortInterface { >> protected String name; >> private final static boolean debug = false; >> >> public void close() { >> if (debug) System.out.println("CommPort:close()"); >> >> try { >> CommPortIdentifierInterface cp = >> CommPortIdentifier.getPortIdentifier(this); >> if (cp != null) >>???????????????? >> CommPortIdentifier.getPortIdentifier(this).internalClosePort(); >> } >> catch (NoSuchPortException e) { >> e.printStackTrace(); >> } >> } >> >> public String getName() { >> if (debug) System.out.println("CommPort:getName()"); >> return (name); >> } >> >> public String toString() { >> if (debug) System.out.println("CommPort:toString()"); >> return (name); >> } >> } >> >At 12:28 30/07/2006, Dr. Douglas Lyon wrote: >> >>Hi All, >> >>I was thinking that the new JSR might be more >> >>interface oriented and less abstract class oriented. >> >> >> >>For example, instead of subclassing CommPort, perhaps >> >>we should implement a CommPortInterface. >> >> >> >>How would this look? >> > >> >Will it break backwards compatibility? >> > >> >Guillermo >> >-- >> >Guillermo Rodriguez Garcia >> > >> >Snijder Micro Systems phone +31-493-351020 >> >G. Rodriguez Garcia fax +31-493-351530 >> >Visser 25 email guille at sms.nl >> >NL5751 BL Deurne >> >The Netherlands http://www.snijder.com >> >> > > >-- >http://www.snijder.com/ >SNIJDER Micro Systems From berkland at spamcop.net Mon Jul 31 07:57:50 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 31 Jul 2006 09:57:50 -0400 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <1154351811.44ce02c3a5539@webmail.eatserver.nl> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> Message-ID: <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> Adding interfaces does not break any kind of compatibility. Java is more forgiving when it comes to this kind of change than languages that are compiled into native code. As long as the implementing class has the same name, same package, and all of the same methods (with the same signatures) you can add on anything you wish, including implementing additional interfaces. On 7/31/06, Guillermo Rodriguez wrote: > Hi Doug, > > I understand. Note that we are not only concerned about source > compatibility, but also about binary compatibility (which would be > preserved as well with this approach if I understood correctly) > > Best regards, > Guillermo From gergg at cox.net Mon Jul 31 08:12:20 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 31 Jul 2006 09:12:20 -0500 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> Message-ID: <44CE0FC4.9010307@cox.net> Doug Berkland wrote: > Adding interfaces does not break any kind of compatibility. Java is > more forgiving when it comes to this kind of change than languages > that are compiled into native code. As long as the implementing class > has the same name, same package, and all of the same methods (with the > same signatures) you can add on anything you wish, including > implementing additional interfaces. Check the Serialization compatibility guidelines for more information on exactly what binary compatibility requires, and what things can change in an interface and/or class which won't break things. Gregg Wonderly From berkland at spamcop.net Mon Jul 31 09:13:00 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 31 Jul 2006 11:13:00 -0400 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <44CE0FC4.9010307@cox.net> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> <44CE0FC4.9010307@cox.net> Message-ID: <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> As far as I can tell, nothing in either RXTX or Sun's JavaCOMM implements Serializable. Therefore, there are no worries from that either. (I can't think of a reason anything in JavaCOMM should implement Serializable either.) On 7/31/06, Gregg Wonderly wrote: > Doug Berkland wrote: > > Adding interfaces does not break any kind of compatibility. Java is > > more forgiving when it comes to this kind of change than languages > > that are compiled into native code. As long as the implementing class > > has the same name, same package, and all of the same methods (with the > > same signatures) you can add on anything you wish, including > > implementing additional interfaces. > > Check the Serialization compatibility guidelines for more information on exactly > what binary compatibility requires, and what things can change in an interface > and/or class which won't break things. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From berkland at spamcop.net Mon Jul 31 09:20:48 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 31 Jul 2006 11:20:48 -0400 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> <44CE0FC4.9010307@cox.net> <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> Message-ID: <269e40090607310820s15f2eee8j903e077917d7fc72@mail.gmail.com> Correction: Nothing except the classes extending Exception and Event implement Serializable. On 7/31/06, Doug Berkland wrote: > As far as I can tell, nothing in either RXTX or Sun's JavaCOMM > implements Serializable. Therefore, there are no worries from that > either. (I can't think of a reason anything in JavaCOMM should > implement Serializable either.) > > On 7/31/06, Gregg Wonderly wrote: > > Doug Berkland wrote: > > > Adding interfaces does not break any kind of compatibility. Java is > > > more forgiving when it comes to this kind of change than languages > > > that are compiled into native code. As long as the implementing class > > > has the same name, same package, and all of the same methods (with the > > > same signatures) you can add on anything you wish, including > > > implementing additional interfaces. > > > > Check the Serialization compatibility guidelines for more information on exactly > > what binary compatibility requires, and what things can change in an interface > > and/or class which won't break things. > > > > Gregg Wonderly > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > From gergg at cox.net Mon Jul 31 11:21:19 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 31 Jul 2006 12:21:19 -0500 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> <44CE0FC4.9010307@cox.net> <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> Message-ID: <44CE3C0F.3080408@cox.net> Doug Berkland wrote: > As far as I can tell, nothing in either RXTX or Sun's JavaCOMM > implements Serializable. Therefore, there are no worries from that > either. (I can't think of a reason anything in JavaCOMM should > implement Serializable either.) Any interface in javax.comm can become implemented by a serializable object. Thus, if someone wants to provide remote access to a serial port, then they might (and I think this is not wise) choose to subclass and add Serializable to the interface list. It's that kind of Serialization compatibility that I'm talking about. Gregg Wonderly From rwelty at suespammers.org Mon Jul 31 19:53:12 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 31 Jul 2006 21:53:12 -0400 Subject: [Rxtx] Application Name? Message-ID: <44CEB408.7040407@suespammers.org> trying to get my app running on a Mac OS X powerbook, when the following is executed as the first thing inside the run method of a Thread: try { port = (SerialPort) selectedPort.open( this.getClass().getName(), 2000); } catch ( PortInUseException ex){ ex.printStackTrace(); return; } i get the following: gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at com.krusty_motorsports.scale.monitor.ScaleWatcher.run(ScaleWatcher.java:143) i've not seen any documentation suggesting that rxtx would be finicky about application names... thanks for any suggestions, richard From stevebeemonkey at monkey-media.co.uk Wed Jul 5 05:59:02 2006 From: stevebeemonkey at monkey-media.co.uk (steve@monkey-media.co.uk) Date: Wed, 5 Jul 2006 04:59:02 -0700 Subject: [Rxtx] No output on WinXP Message-ID: <1152100742.44aba986565e7@www.webmail.ezpublishing.com> Hi there, I've installed RXTX 2.1.7 under Win XP, copying the .jar and .dll files according to the instructions given. I've changed the javax.comm import to gnu.io, but when I run the following code the only output I get is: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Then the program ends, without listing any of the ports. What am I doing wrong? Cheers, Steve Here's my code: ---------------------------------------- import gnu.io.*; import java.util.*; public class PortList { public static void main(String [] args) { Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while(portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); if( portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("Serial port: " + portId.getName()); } else if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { System.out.println("Parallel port: " + portId.getName()); } else System.out.println("Other port: " + portId.getName()); } } } ------------------------------- From tjarvi at qbang.org Wed Jul 5 07:57:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 5 Jul 2006 07:57:22 -0600 (MDT) Subject: [Rxtx] No output on WinXP In-Reply-To: <1152100742.44aba986565e7@www.webmail.ezpublishing.com> References: <1152100742.44aba986565e7@www.webmail.ezpublishing.com> Message-ID: On Wed, 5 Jul 2006, steve at monkey-media.co.uk wrote: > > > Hi there, > > I've installed RXTX 2.1.7 under Win XP, copying the .jar and .dll files > according to the instructions given. > > I've changed the javax.comm import to gnu.io, but when I run the following code > the only output I get is: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Then the program ends, without listing any of the ports. > > What am I doing wrong? > > Cheers, > > Steve > > Here's my code: > > ---------------------------------------- > > import gnu.io.*; > import java.util.*; > > public class PortList > { > public static void main(String [] args) > { > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > while(portList.hasMoreElements()) { > CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); > if( portId.getPortType() == > CommPortIdentifier.PORT_SERIAL) > { > System.out.println("Serial port: " + > portId.getName()); > } else if (portId.getPortType() == > CommPortIdentifier.PORT_PARALLEL) > { > System.out.println("Parallel port: " + > portId.getName()); > } else > System.out.println("Other port: " + > portId.getName()); > } > } > } > > ------------------------------- > If you have a port open with another terminal such as hyperterminal or even another copy of your application using rxtx, the port will not be enumerated. rxtx enumerates ports by opening prospective ports and doing a timed out read. If the port is open by another application, the open will fail. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Wed Jul 5 15:44:05 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Wed, 5 Jul 2006 15:44:05 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EA89@hqexchange3.dot.state.co.us> Trent, I did put some debug statements and the "index" returned to me in the while loop is "0" (see the code below) and it gets into the infinite loop, I can put a break statement but don't know the ramifications of it. Can you explain in what scenarios the index can be "0" or are we somehow in the native code loosing refrences to the indexes? Thanks Again Pawan Kharbanda while( searching ) { index = master_index; if( index ) { while( index->fd != fd && index->next ) index = index->next; if ( index->fd == fd ) searching = 0; } else report("Index"+index"x"); <<<<<< The code gets to this statement and index is returned as "0" and I don't see anyway to break out of this looop after. if( searching ) { report("@"); usleep(1000); } } -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, June 29, 2006 6:21 AM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports > Here is how you can test if you have resources/ test environment. > Write a program and try to open/close different ports(I will say have > a minimum of four) randomly and very frequently(may be 30 seconds), I > am pretty sure you will see the deadlocks and it happens in the native > call to interrptEventLoop in RXTXPort.java in removeEventListener() > method call. Hi Pawan I'll try to find a way to reproduce this. One thing to note is that you are using different kernel drivers (digi) to perform this task. So I probably will not be able to reproduce the exact same environment. In general, multiport kernel drivers have been tested far less than typical serial drivers. This may or may not be an issue. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Wed Jul 5 18:50:01 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Wed, 5 Jul 2006 18:50:01 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EA96@hqexchange3.dot.state.co.us> Trent, Sorry for so many emails, but as I mentioned earlier I will write a test to replicate the Locking problem. I am attaching a Java file to replicate the problem. You need atleast 4-5 ports to simulate the problem. Here is how to run the program. In the TestOpenClosePort.java please change the Serial Ports names(Add the ports installed on your machine). Then compile your java file and run as "java TestOpenClosePort 100" (100 is the no of times you want to open and close the port in one single thread). I have tested this with the Digi Boxes and able to replicate this over and over in Single JVM. Hope this test helps track down the problem. Thanks Pawan Kharbanda -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, June 29, 2006 6:21 AM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports > Here is how you can test if you have resources/ test environment. > Write a program and try to open/close different ports(I will say have > a minimum of four) randomly and very frequently(may be 30 seconds), I > am pretty sure you will see the deadlocks and it happens in the native > call to interrptEventLoop in RXTXPort.java in removeEventListener() > method call. Hi Pawan I'll try to find a way to reproduce this. One thing to note is that you are using different kernel drivers (digi) to perform this task. So I probably will not be able to reproduce the exact same environment. In general, multiport kernel drivers have been tested far less than typical serial drivers. This may or may not be an issue. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: TestOpenClosePort.java Type: application/octet-stream Size: 6038 bytes Desc: TestOpenClosePort.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060705/82f8488f/TestOpenClosePort-0358.obj From tjarvi at qbang.org Wed Jul 5 22:48:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 5 Jul 2006 22:48:52 -0600 (MDT) Subject: [Rxtx] Locked Ports In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3EA89@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03F3EA89@hqexchange3.dot.state.co.us> Message-ID: On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did put some debug statements and the "index" returned to me in > the while loop is "0" (see the code below) and it gets into the infinite > loop, I can put a break statement but don't know the ramifications of > it. Can you explain in what scenarios the index can be "0" or are we > somehow in the native code loosing refrences to the indexes? > > Thanks Again > Pawan Kharbanda > > while( searching ) > { > index = master_index; > > if( index ) > { > while( index->fd != fd && > index->next ) index = index->next; > if ( index->fd == fd ) searching = 0; > } > else > report("Index"+index"x"); <<<<<< The code gets > to this statement and index is returned as "0" and I don't see anyway to > break out of this looop after. > if( searching ) > { > report("@"); > usleep(1000); > } > } > Hi Pawan I am reading with interest :) So it sounds like this is a thread safe problem. The thing I don't understand here is open and close are synchronized in RXTXPort.java. I thought that would prevent any thread problems with the linked list. Looking closer, the linked list is actually populated in eventLoop/MonitorThread which is not synchronized. So you may be able to synchronize on an object in RXTXPort.java. A seperate native call would probably be required for the initalization to prevent a deadlock. A solution might involve making finalize_event_info_struct() and initialise_event_info_struct() [uk spelling?] thread safe with glib. http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads.html#id2786034 glib also has more robust linked lists which could be used. Thats the indirectly the problem found in termios.c for windows. The disadvantage is we would require linking to glib which is another step for systems that don't come with it. The advantage would be reduced code size we have to maintain. We could borrow bits of glib as the licenses are the same. Another solution might be to just use pthread_mutex_lock and unlock. http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html I don't think that would work on windows though. It would require linking cygwin.dll which would not work with nonGPL projects in practice. -- Trent Jarvi tjarvi From neville_seed at yahoo.com Thu Jul 6 06:42:29 2006 From: neville_seed at yahoo.com (neville seed) Date: Thu, 6 Jul 2006 05:42:29 -0700 (PDT) Subject: [Rxtx] port to palm OS? Message-ID: <20060706124230.55790.qmail@web51015.mail.yahoo.com> hello. Has rxtx been ported to PalmOS? regards neville __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From neville_seed at yahoo.com Thu Jul 6 06:43:44 2006 From: neville_seed at yahoo.com (neville seed) Date: Thu, 6 Jul 2006 05:43:44 -0700 (PDT) Subject: [Rxtx] example code Message-ID: <20060706124344.5063.qmail@web51013.mail.yahoo.com> hello. Could anyone provide me with example code of how to read from the serial port. regards neville __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From naranjo.manuel at gmail.com Thu Jul 6 06:48:20 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Thu, 06 Jul 2006 09:48:20 -0300 Subject: [Rxtx] port to palm OS? In-Reply-To: <20060706124230.55790.qmail@web51015.mail.yahoo.com> References: <20060706124230.55790.qmail@web51015.mail.yahoo.com> Message-ID: <44AD0694.1090703@gmail.com> neville seed wrote: > hello. > > Has rxtx been ported to PalmOS? > > regards > neville > I'm interested on this. Do you need rxtx ported to J2ME or to Superwaba?. Superwaba has it owns implementation of a serial port, but it is not rxtx. Regards, Manuel From joachim at buechse.de Thu Jul 6 07:20:57 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 6 Jul 2006 15:20:57 +0200 Subject: [Rxtx] port to palm OS? In-Reply-To: <20060706124230.55790.qmail@web51015.mail.yahoo.com> References: <20060706124230.55790.qmail@web51015.mail.yahoo.com> Message-ID: Which version of PalmOS are you targeting? I have been doing some Java on PalmOS programming for the Palm Vx using the JVM from Esmertec. The problem there was, that PalmOS can only process one kernel call at a time (it is (was?) not a multithreading OS). Threads were implemented by the VM. In a situation like this, any kind of "abort" mechanism is very difficult to handle - from what I know about the RXTX code and the way close() would have to be implemented it's the same as rewriting RXTX. Newer versions of PalmOS might have improved in this respect... Best regards, Joachim On 06.07.2006, at 14:42, neville seed wrote: > hello. > > Has rxtx been ported to PalmOS? > > regards > neville > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From neville_seed at yahoo.com Thu Jul 6 08:23:29 2006 From: neville_seed at yahoo.com (neville seed) Date: Thu, 6 Jul 2006 07:23:29 -0700 (PDT) Subject: [Rxtx] port to palm OS? In-Reply-To: Message-ID: <20060706142329.91625.qmail@web51005.mail.yahoo.com> The palmOS would be version 5.x however i am new to both palm and java. As such I would have to find out any questions. --- Joachim Buechse wrote: > Which version of PalmOS are you targeting? > > I have been doing some Java on PalmOS programming > for the Palm Vx > using the JVM from Esmertec. The problem there was, > that PalmOS can > only process one kernel call at a time (it is (was?) > not a > multithreading OS). Threads were implemented by the > VM. In a > situation like this, any kind of "abort" mechanism > is very difficult > to handle - from what I know about the RXTX code and > the way close() > would have to be implemented it's the same as > rewriting RXTX. Newer > versions of PalmOS might have improved in this > respect... > > Best regards, > Joachim > > On 06.07.2006, at 14:42, neville seed wrote: > > > hello. > > > > Has rxtx been ported to PalmOS? > > > > regards > > neville > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From jhaysonn at gmail.com Thu Jul 6 08:58:07 2006 From: jhaysonn at gmail.com (jhaysonn pathak) Date: Thu, 6 Jul 2006 10:58:07 -0400 Subject: [Rxtx] RXTX install (jhaysonn pathak) Message-ID: Thanks for the install tip. I figured out how to do the cvs update, but in my MACOSX_IDE dir I didn't have any Xcode folders and searching my computer, I only have 3 Xcode folders (one for application support, one for Max/MSP and one in developer tools). I have tried building each of the different *.xcodeproj files and in eachone they have little toolbox looking items that are in red (i assume that means it can't find them). Some of them I manage to locate but some of them just aren't on my computer. In any event, I still can't find the libserial.jnilib. After the update I read the README.OSX and it did make it seem a lot easier, but for the future, if I finally create a libserial.jnilib I don't know what the 'JavaVM' is in reference to this line "Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required)." PS - How do I uninstall everything RXTX so that I can try and re-download and re-install everything? From joachim at buechse.de Thu Jul 6 09:12:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 6 Jul 2006 17:12:24 +0200 Subject: [Rxtx] RXTX install (jhaysonn pathak) In-Reply-To: References: Message-ID: <98F15662-544D-41B5-8229-BB1DB6B6FD43@buechse.de> The Java VM ist the Java Virtual Machine. It runs your application. For the rest of your message ... your description is much to unprecise to help. To start, you could describe what IS in the MACOSX_IDE folder and its subfolders. On 06.07.2006, at 16:58, jhaysonn pathak wrote: > Thanks for the install tip. I figured out how to do the cvs update, > but in my MACOSX_IDE dir I didn't have any Xcode folders and searching > my computer, I only have 3 Xcode folders (one for application support, > one for Max/MSP and one in developer tools). I have tried building > each of the different *.xcodeproj files and in eachone they have > little toolbox looking items that are in red (i assume that means it > can't find them). Some of them I manage to locate but some of them > just aren't on my computer. In any event, I still can't find the > libserial.jnilib. > > After the update I read the README.OSX and it did make it seem a lot > easier, but for the future, if I finally create a libserial.jnilib I > don't know what the 'JavaVM' is in reference to this line > > "Put > libSerial.jnilib > in the directory of the application (the JavaVM will find it > there). Add > RXTXComm.jar > to the application classpath or include the classes in the > application jar. > (Some applications already include the RXTX classes in their > application jar, > in which case only the file libSerial.jnilib is required)." > > PS - How do I uninstall everything RXTX so that I can try and > re-download and re-install everything? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jul 6 09:20:16 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 6 Jul 2006 17:20:16 +0200 Subject: [Rxtx] RXTX install (jhaysonn pathak) In-Reply-To: References: Message-ID: <8F03CA0E-44F4-434F-AA7E-3A8B5054AA6F@buechse.de> Rethinking about your problem... I think you should try a cvs up -d Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 06.07.2006, at 16:58, jhaysonn pathak wrote: > Thanks for the install tip. I figured out how to do the cvs update, > but in my MACOSX_IDE dir I didn't have any Xcode folders and searching > my computer, I only have 3 Xcode folders (one for application support, > one for Max/MSP and one in developer tools). I have tried building > each of the different *.xcodeproj files and in eachone they have > little toolbox looking items that are in red (i assume that means it > can't find them). Some of them I manage to locate but some of them > just aren't on my computer. In any event, I still can't find the > libserial.jnilib. > > After the update I read the README.OSX and it did make it seem a lot > easier, but for the future, if I finally create a libserial.jnilib I > don't know what the 'JavaVM' is in reference to this line > > "Put > libSerial.jnilib > in the directory of the application (the JavaVM will find it > there). Add > RXTXComm.jar > to the application classpath or include the classes in the > application jar. > (Some applications already include the RXTX classes in their > application jar, > in which case only the file libSerial.jnilib is required)." > > PS - How do I uninstall everything RXTX so that I can try and > re-download and re-install everything? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Thu Jul 6 10:19:17 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Thu, 06 Jul 2006 13:19:17 -0300 Subject: [Rxtx] port to palm OS? In-Reply-To: <20060706142329.91625.qmail@web51005.mail.yahoo.com> References: <20060706142329.91625.qmail@web51005.mail.yahoo.com> Message-ID: <44AD3805.3010609@gmail.com> neville seed wrote: > The palmOS would be version 5.x however i am new to > both palm and java. As such I would have to find out > any questions. > Hello if you are new you could use Superwaba, url: www.superwaba.com, which is not exactly Java but works great, and has a serial port. If you need any more info please let me know. Manuel From Pawan.Kharbanda at dot.state.co.us Thu Jul 6 12:49:50 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 6 Jul 2006 12:49:50 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EB11@hqexchange3.dot.state.co.us> Trent, I did made the eventLoop() call in the Monitor Thread synchronized, it improved but still see the same problem. Your comment > A solution might involve making finalize_event_info_struct() and > initialise_event_info_struct() [uk spelling?] thread safe with glib. I didn't follow this how I can implement this. I am not a C guy, can you help me understand how I can implement this? Thanks Pawan Kharbanda -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, July 05, 2006 10:49 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did put some debug statements and the "index" returned to me in > the while loop is "0" (see the code below) and it gets into the > infinite loop, I can put a break statement but don't know the > ramifications of it. Can you explain in what scenarios the index can > be "0" or are we somehow in the native code loosing refrences to the indexes? > > Thanks Again > Pawan Kharbanda > > while( searching ) > { > index = master_index; > > if( index ) > { > while( index->fd != fd && > index->next ) index = index->next; > if ( index->fd == fd ) searching = 0; > } > else > report("Index"+index"x"); <<<<<< The code gets to this statement > and index is returned as "0" and I don't see anyway to break out of > this looop after. > if( searching ) > { > report("@"); > usleep(1000); > } > } > Hi Pawan I am reading with interest :) So it sounds like this is a thread safe problem. The thing I don't understand here is open and close are synchronized in RXTXPort.java. I thought that would prevent any thread problems with the linked list. Looking closer, the linked list is actually populated in eventLoop/MonitorThread which is not synchronized. So you may be able to synchronize on an object in RXTXPort.java. A seperate native call would probably be required for the initalization to prevent a deadlock. A solution might involve making finalize_event_info_struct() and initialise_event_info_struct() [uk spelling?] thread safe with glib. http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. html#id2786034 glib also has more robust linked lists which could be used. Thats the indirectly the problem found in termios.c for windows. The disadvantage is we would require linking to glib which is another step for systems that don't come with it. The advantage would be reduced code size we have to maintain. We could borrow bits of glib as the licenses are the same. Another solution might be to just use pthread_mutex_lock and unlock. http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html I don't think that would work on windows though. It would require linking cygwin.dll which would not work with nonGPL projects in practice. -- Trent Jarvi tjarvi _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From zhanglong at adventnet.com Wed Jul 5 20:44:18 2006 From: zhanglong at adventnet.com (zhanglong) Date: Thu, 06 Jul 2006 10:44:18 +0800 Subject: [Rxtx] rxtx can not read data from serialport Message-ID: <44AC7902.8070407@adventnet.com> Dear sir, When I use rxrx2.1-7-bin-r2?I can write data into serialport,But can not read data from serialport on windowsXP. I can not write and read data from serialport on Redhat Linux9.0. I can get serialport list on my machine.And no error with open serialport. I can get and read data from serialport on windowsXP with SUN's javacomm20-win32.zip. How can I read data on windows and write,read data on Linux with rxtx? Best Regards, Zhanglong From tjarvi at qbang.org Thu Jul 6 19:07:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 19:07:13 -0600 (MDT) Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: <44AC7902.8070407@adventnet.com> References: <44AC7902.8070407@adventnet.com> Message-ID: On Thu, 6 Jul 2006, zhanglong wrote: > Dear sir, > > When I use rxrx2.1-7-bin-r2??I can write data into serialport,But can > not read data from serialport on windowsXP. > I can not write and read data from serialport on Redhat Linux9.0. > I can get serialport list on my machine.And no error with open serialport. > > I can get and read data from serialport on windowsXP with SUN's > javacomm20-win32.zip. > > How can I read data on windows and write,read data on Linux with rxtx? > > Hi Zhanglong Make sure that you specify the flow control, timeout and threshold that you want. The defaults may vary between rxtx and Sun. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jul 6 19:10:25 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 19:10:25 -0600 (MDT) Subject: [Rxtx] Controlling Individual Signals DTR and RTS In-Reply-To: References: Message-ID: On Thu, 29 Jun 2006, Chris Pine wrote: > Dear Moussa Ba, > I hope I am not being too forward, but we are having the exact same > issue with needing to control DTR from RXTX in Linux. Did you ever have any > luck figuring it out? > > Thank you very much for your time, > Hi Chris Are you using an unusual serial port? It could be that the port does not support DTR/RTS. Especially if its an inexpensive USB->Serial dongle. I'll double check Linux tomorrow but I'm fairly sure it works. I have verified windows after a questions like yours. Some multiport cards and usb dongles do not support everything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jul 6 19:17:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 19:17:09 -0600 (MDT) Subject: [Rxtx] Locked Ports In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3EB11@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03F3EB11@hqexchange3.dot.state.co.us> Message-ID: Hi Pawan There is an example of doing this in the link I provided below. They make a pointer to the function they want to be thread safe and then use that with the glib functions. I'm not ready to just toss out a quick hack because I'd like to think through this a bit to make sure I understand what types of problems we may run into. The code still hung in the same place after synchronizing the eventLoop? I think that eventLoop needs to be refactored to pull out the initialization code so people do not need to run the monitor. On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did made the eventLoop() call in the Monitor Thread synchronized, it > improved but still see the same problem. > > Your comment >> A solution might involve making finalize_event_info_struct() and >> initialise_event_info_struct() [uk spelling?] thread safe with glib. > > I didn't follow this how I can implement this. I am not a C guy, can you > help me understand how I can implement this? > > Thanks > Pawan Kharbanda > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Wednesday, July 05, 2006 10:49 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] Locked Ports > > On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > >> Trent, >> I did put some debug statements and the "index" returned to me in >> the while loop is "0" (see the code below) and it gets into the >> infinite loop, I can put a break statement but don't know the >> ramifications of it. Can you explain in what scenarios the index can >> be "0" or are we somehow in the native code loosing refrences to the > indexes? >> >> Thanks Again >> Pawan Kharbanda >> >> while( searching ) >> { >> index = master_index; >> >> if( index ) >> { >> while( index->fd != fd && >> index->next ) index = index->next; >> if ( index->fd == fd ) searching = 0; >> } >> else >> report("Index"+index"x"); <<<<<< The code gets > to this statement >> and index is returned as "0" and I don't see anyway to break out of >> this looop after. >> if( searching ) >> { >> report("@"); >> usleep(1000); >> } >> } >> > > Hi Pawan > > I am reading with interest :) > > So it sounds like this is a thread safe problem. > > The thing I don't understand here is open and close are synchronized in > RXTXPort.java. I thought that would prevent any thread problems with > the linked list. Looking closer, the linked list is actually populated > in eventLoop/MonitorThread which is not synchronized. > > So you may be able to synchronize on an object in RXTXPort.java. A > seperate native call would probably be required for the initalization to > prevent a deadlock. > > A solution might involve making finalize_event_info_struct() and > initialise_event_info_struct() [uk spelling?] thread safe with glib. > > http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. > html#id2786034 > > glib also has more robust linked lists which could be used. Thats the > indirectly the problem found in termios.c for windows. The disadvantage > is we would require linking to glib which is another step for systems > that don't come with it. The advantage would be reduced code size we > have to maintain. We could borrow bits of glib as the licenses are the > same. > > Another solution might be to just use pthread_mutex_lock and unlock. > > http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html > > I don't think that would work on windows though. It would require > linking cygwin.dll which would not work with nonGPL projects in > practice. > > -- > Trent Jarvi > tjarvi > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Pawan.Kharbanda at dot.state.co.us Thu Jul 6 21:46:08 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 6 Jul 2006 21:46:08 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EB35@hqexchange3.dot.state.co.us> Trent, Just curious to know if you were able to replicate the problem with my example? Pawan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, July 06, 2006 7:17 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports Hi Pawan There is an example of doing this in the link I provided below. They make a pointer to the function they want to be thread safe and then use that with the glib functions. I'm not ready to just toss out a quick hack because I'd like to think through this a bit to make sure I understand what types of problems we may run into. The code still hung in the same place after synchronizing the eventLoop? I think that eventLoop needs to be refactored to pull out the initialization code so people do not need to run the monitor. On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did made the eventLoop() call in the Monitor Thread synchronized, > it improved but still see the same problem. > > Your comment >> A solution might involve making finalize_event_info_struct() and >> initialise_event_info_struct() [uk spelling?] thread safe with glib. > > I didn't follow this how I can implement this. I am not a C guy, can > you help me understand how I can implement this? > > Thanks > Pawan Kharbanda > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Wednesday, July 05, 2006 10:49 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] Locked Ports > > On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > >> Trent, >> I did put some debug statements and the "index" returned to me in >> the while loop is "0" (see the code below) and it gets into the >> infinite loop, I can put a break statement but don't know the >> ramifications of it. Can you explain in what scenarios the index can >> be "0" or are we somehow in the native code loosing refrences to the > indexes? >> >> Thanks Again >> Pawan Kharbanda >> >> while( searching ) >> { >> index = master_index; >> >> if( index ) >> { >> while( index->fd != fd && >> index->next ) index = index->next; >> if ( index->fd == fd ) searching = 0; >> } >> else >> report("Index"+index"x"); <<<<<< The code gets > to this statement >> and index is returned as "0" and I don't see anyway to break out of >> this looop after. >> if( searching ) >> { >> report("@"); >> usleep(1000); >> } >> } >> > > Hi Pawan > > I am reading with interest :) > > So it sounds like this is a thread safe problem. > > The thing I don't understand here is open and close are synchronized > in RXTXPort.java. I thought that would prevent any thread problems > with the linked list. Looking closer, the linked list is actually > populated in eventLoop/MonitorThread which is not synchronized. > > So you may be able to synchronize on an object in RXTXPort.java. A > seperate native call would probably be required for the initalization > to prevent a deadlock. > > A solution might involve making finalize_event_info_struct() and > initialise_event_info_struct() [uk spelling?] thread safe with glib. > > http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. > html#id2786034 > > glib also has more robust linked lists which could be used. Thats the > indirectly the problem found in termios.c for windows. The > disadvantage is we would require linking to glib which is another step > for systems that don't come with it. The advantage would be reduced > code size we have to maintain. We could borrow bits of glib as the > licenses are the same. > > Another solution might be to just use pthread_mutex_lock and unlock. > > http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html > > I don't think that would work on windows though. It would require > linking cygwin.dll which would not work with nonGPL projects in > practice. > > -- > Trent Jarvi > tjarvi > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jul 6 21:53:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 21:53:49 -0600 (MDT) Subject: [Rxtx] Locked Ports In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3EB35@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03F3EB35@hqexchange3.dot.state.co.us> Message-ID: Pawan: I'm sure I can reproduce the problem. What you have described makes very good sense and has changed how I think about rxtx. 64 ports. Take your design specs and write 'open source' on them. On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > Trent, > Just curious to know if you were able to replicate the problem > with my example? > > Pawan > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Thursday, July 06, 2006 7:17 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] Locked Ports > > > Hi Pawan > > There is an example of doing this in the link I provided below. They > make a pointer to the function they want to be thread safe and then use > that with the glib functions. > > I'm not ready to just toss out a quick hack because I'd like to think > through this a bit to make sure I understand what types of problems we > may run into. > > The code still hung in the same place after synchronizing the eventLoop? > > > > > I think that eventLoop needs to be refactored to pull out the > initialization code so people do not need to run the monitor. > > On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > >> Trent, >> I did made the eventLoop() call in the Monitor Thread synchronized, >> it improved but still see the same problem. >> >> Your comment >>> A solution might involve making finalize_event_info_struct() and >>> initialise_event_info_struct() [uk spelling?] thread safe with glib. >> >> I didn't follow this how I can implement this. I am not a C guy, can >> you help me understand how I can implement this? >> >> Thanks >> Pawan Kharbanda >> >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > >> Of Trent Jarvi >> Sent: Wednesday, July 05, 2006 10:49 PM >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] Locked Ports >> >> On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: >> >>> Trent, >>> I did put some debug statements and the "index" returned to me in >>> the while loop is "0" (see the code below) and it gets into the >>> infinite loop, I can put a break statement but don't know the >>> ramifications of it. Can you explain in what scenarios the index can >>> be "0" or are we somehow in the native code loosing refrences to the >> indexes? >>> >>> Thanks Again >>> Pawan Kharbanda >>> >>> while( searching ) >>> { >>> index = master_index; >>> >>> if( index ) >>> { >>> while( index->fd != fd && >>> index->next ) index = index->next; >>> if ( index->fd == fd ) searching = 0; >>> } >>> else >>> report("Index"+index"x"); <<<<<< The code gets >> to this statement >>> and index is returned as "0" and I don't see anyway to break out of >>> this looop after. >>> if( searching ) >>> { >>> report("@"); >>> usleep(1000); >>> } >>> } >>> >> >> Hi Pawan >> >> I am reading with interest :) >> >> So it sounds like this is a thread safe problem. >> >> The thing I don't understand here is open and close are synchronized >> in RXTXPort.java. I thought that would prevent any thread problems >> with the linked list. Looking closer, the linked list is actually >> populated in eventLoop/MonitorThread which is not synchronized. >> >> So you may be able to synchronize on an object in RXTXPort.java. A >> seperate native call would probably be required for the initalization >> to prevent a deadlock. >> >> A solution might involve making finalize_event_info_struct() and >> initialise_event_info_struct() [uk spelling?] thread safe with glib. >> >> > http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. >> html#id2786034 >> >> glib also has more robust linked lists which could be used. Thats the > >> indirectly the problem found in termios.c for windows. The >> disadvantage is we would require linking to glib which is another step > >> for systems that don't come with it. The advantage would be reduced >> code size we have to maintain. We could borrow bits of glib as the >> licenses are the same. >> >> Another solution might be to just use pthread_mutex_lock and unlock. >> >> http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html >> >> I don't think that would work on windows though. It would require >> linking cygwin.dll which would not work with nonGPL projects in >> practice. >> >> -- >> Trent Jarvi >> tjarvi >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pascal at quies.net Fri Jul 7 08:45:59 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Fri, 7 Jul 2006 16:45:59 +0200 Subject: [Rxtx] Java installer Message-ID: <200607071645.59765.pascal@quies.net> Hello everybody, We need a *simple* installer for the RXTX extension. I'm working on a pure Java installer right now. Let's get this thing working over the weekend. The license of choise is the modified BSD license. My plan is to make a JAR with: * the RXTX binaries * a simple API to detect any installed version * a simple Swing installer * a executeable detector: java -jar communicationapi.jar detect javax.comm * a executable installer: java -jar communicationapi.jar install gnu.io * Java 1.2 compatible Comments? _The Java API_: class CommunicationAPI { CommunicationAPI() CommunicationAPI(String path) boolean available() boolean supportsRS232() boolean supportsRS485() boolean supportsI2C() boolean supportsIEEE1280() static void main(String[] args) static boolean installRXTX(boolean headless) } Comments? To get this working we need binaries. Who is having what? The package from the official site has the following: * Linux: i686, x86_64, ia64 * Solaris: sparc32, sparc64 * Windows: i386 Now that's a start. I had to modify the code (what a mess!) to get it working on OpenBSD but I don't have the time to get it working for every platform. Any help here? From j.a.horsmeier at wanadoo.nl Fri Jul 7 09:11:24 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Fri, 7 Jul 2006 17:11:24 +0200 Subject: [Rxtx] Java installer In-Reply-To: <200607071645.59765.pascal@quies.net> Message-ID: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> > Pascal S. de Kloe wrote: > We need a *simple* installer for the RXTX extension. > I'm working on a pure Java installer right now. Let's get > this thing working > over the weekend. The license of choise is the modified BSD license. > > My plan is to make a JAR with: > * the RXTX binaries > * a simple API to detect any installed version > * a simple Swing installer > * a executeable detector: java -jar communicationapi.jar > detect javax.comm > * a executable installer: java -jar communicationapi.jar > install gnu.io > * Java 1.2 compatible > > Comments? Have a look at IzPack: http://www.izforge.com/izpack/ I use it all the time to install rxtx as part of our application. kind regards, Jos From brian at mbari.org Fri Jul 7 10:01:27 2006 From: brian at mbari.org (Brian Schlining) Date: Fri, 7 Jul 2006 09:01:27 -0700 Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: <44AC7902.8070407@adventnet.com> References: <44AC7902.8070407@adventnet.com> Message-ID: On Jul 5, 2006, at 7:44 PM, zhanglong wrote: > Dear sir, > > When I use rxrx2.1-7-bin-r2?I can write data into serialport,But can > not read data from serialport on windowsXP. > I can not write and read data from serialport on Redhat Linux9.0. > I can get serialport list on my machine.And no error with open > serialport. > > I can get and read data from serialport on windowsXP with SUN's > javacomm20-win32.zip. > > How can I read data on windows and write,read data on Linux with rxtx? On windows, if all else fails you may need to use this flow control: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_IN); Also, for some command/response applications that I've tried with RXTX, I find that if I write to the serialport and then immediately try to read from it I get byte arrays filled with zeros, no matter what I set the recieveTimeout to (this has occurred on both Mac OS X and Windows). The workaround that I found was to very briefly put the I/O thread to sleep, like so: // DO set up and get I/O streams //in = serialPort.getInputStream(); //out = serialPort.getOutputStream(); out.write(someByteArray); try { Thread.sleep(10); catch (InterruptedException e) { // handle exception } in.read(anotherByteArray); Note: I've never had to put the thread to sleep using Java comm, only with RXTX. Anyone know why this might be? Cheers B Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060707/f0799573/attachment-0356.html From pascal at quies.net Fri Jul 7 16:55:03 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 00:55:03 +0200 Subject: [Rxtx] Java installer In-Reply-To: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> Message-ID: <200607080055.04501.pascal@quies.net> Op vrijdag 7 juli 2006 17:11, schreef Jos A. Horsmeier: > > Pascal S. de Kloe wrote: > > > > We need a *simple* installer for the RXTX extension. > > I'm working on a pure Java installer right now. Let's get > > this thing working > > over the weekend. The license of choise is the modified BSD license. > > > > My plan is to make a JAR with: > > * the RXTX binaries > > * a simple API to detect any installed version > > * a simple Swing installer > > * a executeable detector: java -jar communicationapi.jar > > detect javax.comm > > * a executable installer: java -jar communicationapi.jar > > install gnu.io > > * Java 1.2 compatible > > > > Comments? > > Have a look at IzPack: http://www.izforge.com/izpack/ > I use it all the time to install rxtx as part of our application. Hello Jos, Thanks for the idea. Could you publish the IzPack configuration and the binaries? That would be very helpful since the current installation procedure is somewhat "unprofessional". ;) IzPack is great but this API is a little more than that. It allows java applications who require the extension to detect available versions and install RXTX on the fly if needed. Is Izpack: * able to install binaries for the right platform (os + hardware architecture)? * Java 1.2 compatible * able to run from the command line? I need as many pre-compiled binaries as possible. Could you help me with that? The detection system already works. Thanks again, Pascal PS Is the gnu.io namespace still necessary? I couldn't find the problem. From naranjo.manuel at gmail.com Fri Jul 7 17:04:31 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 07 Jul 2006 20:04:31 -0300 Subject: [Rxtx] Java installer In-Reply-To: <200607080055.04501.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: <44AEE87F.60202@gmail.com> Pascal: I will be a little short with my answer but very informative :) > Could you publish the IzPack configuration and the binaries? That would be > very helpful since the current installation procedure is > somewhat "unprofessional". ;) > > IzPack is great but this API is a little more than that. It allows java > applications who require the extension to detect available versions and > install RXTX on the fly if needed. > > Is Izpack: > * able to install binaries for the right platform (os + hardware > architecture)? Yes. > * Java 1.2 compatible Yes of course > * able to run from the command line? Yes, and can run from command line detecting which is the underlaying os. I have attached an old version of one of my installer, I can't find the last one, but it is like this one. In this you will see how to detect the OS and architecture and install binaries for that plataform. Regards, Manuel -------------- next part -------------- A non-text attachment was scrubbed... Name: installer.xml Type: text/xml Size: 4683 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060707/fbc3be3c/installer-0356.xml From pascal at quies.net Fri Jul 7 18:35:29 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 02:35:29 +0200 Subject: [Rxtx] Java installer In-Reply-To: <44AEE87F.60202@gmail.com> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <44AEE87F.60202@gmail.com> Message-ID: <200607080235.29486.pascal@quies.net> Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: > > Is Izpack: > > * able to install binaries for the right platform (os + hardware > > architecture)? > > Yes. > > > * Java 1.2 compatible > > Yes of course > > > * able to run from the command line? > > Yes, and can run from command line detecting which is the underlaying os. > I have attached an old version of one of my installer, I can't find the > last one, but it is like this one. In this you will see how to detect > the OS and architecture and install binaries for that plataform. > Regards, > Manuel You are right. IzPack looks like the right tool for this job. As far as I can see there is no commandline support but I'll get over it. ;) I'll link my detection system to the IzPack installation procedure and publish the results. From tjarvi at qbang.org Fri Jul 7 19:00:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 7 Jul 2006 19:00:56 -0600 (MDT) Subject: [Rxtx] Controlling Individual Signals DTR and RTS In-Reply-To: References: Message-ID: On Thu, 6 Jul 2006, Trent Jarvi wrote: > On Thu, 29 Jun 2006, Chris Pine wrote: > >> Dear Moussa Ba, >> I hope I am not being too forward, but we are having the exact same >> issue with needing to control DTR from RXTX in Linux. Did you ever have any >> luck figuring it out? >> >> Thank you very much for your time, >> > > Hi Chris > > Are you using an unusual serial port? It could be that the port does not > support DTR/RTS. Especially if its an inexpensive USB->Serial dongle. > > I'll double check Linux tomorrow but I'm fairly sure it works. I have > verified windows after a questions like yours. Some multiport cards and > usb dongles do not support everything. > I double checked that DTR and RTS are working. The system was a 64 bit opteron with an inexexpensive dual port serial card. Suse 9.3 rxtx 2.1-7 (final). I just used the demo SerialBlackBox that used to come with commapi modified to use rxtx 2.1. The serial card was a NetMos PCI NM9835CV with a 16C550 high speed UART dual port. These are not expensive cards. Everything worked fine. I could see the voltage flipping back and forth on the scope for both DTR(pin 4) and CTS(pin 7). You are not the first to report problems. But everytime I try to reproduce the problem, it appears to work. I suspect it is either hardware or kernel driver related and not specific to RXTX. Note that playing with RTS and DTR with hardware flow control enabled does not make sense as those pins are used for the flow control. I've not looked at many USB serial dongles but I have noticed that some are not as good as others. I think one lacked DTR/CTS support. Another one appeared to be fully functional. The one I noticed no issues with was the Hawking Tech HUC232S on windows. I did not test it on Mac OS X or Linux. The same variability can be observed with multiport serial cards. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jul 7 19:15:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 7 Jul 2006 19:15:06 -0600 (MDT) Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: References: <44AC7902.8070407@adventnet.com> Message-ID: On Fri, 7 Jul 2006, Brian Schlining wrote: > Also, for some command/response applications that I've tried with RXTX, I > find that if I write to the serialport and then immediately try to read from > it I get byte arrays filled with zeros, no matter what I set the > recieveTimeout to (this has occurred on both Mac OS X and Windows). The > workaround that I found was to very briefly put the I/O thread to sleep, like > so: > > // DO set up and get I/O streams > //in = serialPort.getInputStream(); > //out = serialPort.getOutputStream(); > > out.write(someByteArray); > try { > Thread.sleep(10); > catch (InterruptedException e) { > // handle exception > } > in.read(anotherByteArray); > > Note: I've never had to put the thread to sleep using Java comm, only with > RXTX. Anyone know why this might be? Hi Brian Interesting. Is this something that can be reproduced with a loopback connection or something commonly available? I was unaware of this behavior. Is it restricted to something that quickly opens, writes, reads and closes the port by chance? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jul 7 19:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 7 Jul 2006 19:39:37 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607080055.04501.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > Is the gnu.io namespace still necessary? I couldn't find the problem. Hi Pascal CommAPI is a little different in that it was grandfathered into the javax namespace with its own license at the time. It is my understanding that if CommAPI went through the JSR process, anyone would _clearly_ be able to implement a javax.comm package and RXTX would then be one of the first to do so. I believe Doug has expressed some interest in RXTX trying to work with the JSR process. Besides the license questions, there is the fact that RXTX has extensions to CommAPI which could cause confusion in the namespace. Not being a lawyer and *really* not liking to talk to lawyers in my free time, it is better to be safe than sorry. The lawyers tend to come in wolf packs when they do come. There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay there as long as we are just geeks trying to figure out if a license does or does not allow us to implement in the javax.comm namespace. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Sat Jul 8 05:30:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 13:30:24 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: <200607081330.24381.pascal@quies.net> Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > > Is the gnu.io namespace still necessary? I couldn't find the problem. > > Hi Pascal > > CommAPI is a little different in that it was grandfathered into the javax > namespace with its own license at the time. > > It is my understanding that if CommAPI went through the JSR process, > anyone would _clearly_ be able to implement a javax.comm package and RXTX > would then be one of the first to do so. I believe Doug has expressed > some interest in RXTX trying to work with the JSR process. > > Besides the license questions, there is the fact that RXTX has extensions > to CommAPI which could cause confusion in the namespace. Not being a > lawyer and *really* not liking to talk to lawyers in my free time, it is > better to be safe than sorry. The lawyers tend to come in wolf packs > when they do come. > > There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay > there as long as we are just geeks trying to figure out if a license does > or does not allow us to implement in the javax.comm namespace. Nicely said. :) The whole point of namespaces is to create a universal registry of, in this case, classes. This gnu.io namespace is very inconvenient. We feel the same way about lawyers. However I'd like to go into the details of the license (see attachment) if you don't mind? The first license does not apply since RXTX does not use the software. The second one at point 3 specifies our options. > 3. You may not modify the Java Platform Interface ("JPI", identified as > classes contained within the "java" package or any subpackages of the > "java" package), by creating additional classes within the JPI or otherwise > causing the addition to or modification of the classes in the JPI. RXTX is a extension. > In the event that you create an additional class and associated API(s) > which (i) extends the functionality of the Java platform, and (ii) is > exposed to third party software developers for the purpose of developing > additional software which invokes such additional API, you must promptly > publish broadly an accurate specification for such API for free use by all > developers. That's the way we operate. :) > You may not create, or authorize your licensees to create additional > classes, interfaces, or subpackages that are in any way identified as > "java", "javax", "sun" or similar convention as specified by Sun in any > naming convention designation. They don't want additional components in the Communication API since they don't want a mess in theire namespace. So we *can* use javax.comm for the core: javax.comm.CommDriver javax.comm.CommPort javax.comm.CommPortIdentifier javax.comm.CommPortOwnershipListener javax.comm.NoSuchPortException javax.comm.PortInUseException javax.comm.UnsupportedCommOperationException ...and for the default hardware support: javax.comm.SerialPort javax.comm.SerialPortEvent javax.comm.SerialPortEventListener javax.comm.ParralelPort javax.comm.ParralelPortEvent javax.comm.ParralelPortEventListener ...but RXTX aditional hardware support has to go somewhere else like: org.rxtx.RS485Port org.rxtx.RS485PortEvent org.rxtx.RS485PortEventListener org.rxtx.I2CPort org.rxtx.I2CPortEvent org.rxtx.I2CPortEventListener Right? -------------- next part -------------- Sun Microsystems, Inc. Binary Code License Agreement READ THE TERMS OF THIS AGREEMENT AND ANY PROVIDED SUPPLEMENTAL LICENSE TERMS (COLLECTIVELY "AGREEMENT") CAREFULLY BEFORE OPENING THE SOFTWARE MEDIA PACKAGE. BY OPENING THE SOFTWARE MEDIA PACKAGE, YOU AGREE TO THE TERMS OF THIS AGREEMENT. IF YOU ARE ACCESSING THE SOFTWARE ELECTRONICALLY, INDICATE YOUR ACCEPTANCE OF THESE TERMS BY SELECTING THE "ACCEPT" BUTTON AT THE END OF THIS AGREEMENT. IF YOU DO NOT AGREE TO ALL THESE TERMS, PROMPTLY RETURN THE UNUSED SOFTWARE TO YOUR PLACE OF PURCHASE FOR A REFUND OR, IF THE SOFTWARE IS ACCESSED ELECTRONICALLY, SELECT THE "DECLINE" BUTTON AT THE END OF THIS AGREEMENT. 1. LICENSE TO USE. Sun grants you a non-exclusive and non-transferable license for the internal use only of the accompanying software and documentation and any error corrections provided by Sun (collectively "Software"), by the number of users and the class of computer hardware for which the corresponding fee has been paid. 2. RESTRICTIONS. Software is confidential and copyrighted. Title to Software and all associated intellectual property rights is retained by Sun and/or its licensors. Except as specifically authorized in any Supplemental License Terms, you may not make copies of Software, other than a single copy of Software for archival purposes. Unless enforcement is prohibited by applicable law, you may not modify, decompile, or reverse engineer Software. Licensee acknowledges that Licensed Software is not designed or intended for use in the design, construction, operation or maintenance of any nuclear facility. Sun Microsystems, Inc. disclaims any express or implied warranty of fitness for such uses. No right, title or interest in or to any trademark, service mark, logo or trade name of Sun or its licensors is granted under this Agreement. 3. LIMITED WARRANTY. Sun warrants to you that for a period of ninety (90) days from the date of purchase, as evidenced by a copy of the receipt, the media on which Software is furnished (if any) will be free of defects in materials and workmanship under normal use. Except for the foregoing, Software is provided "AS IS". Your exclusive remedy and Sun's entire liability under this limited warranty will be at Sun's option to replace Software media or refund the fee paid for Software. 4. DISCLAIMER OF WARRANTY. UNLESS SPECIFIED IN THIS AGREEMENT, ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT THESE DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. 5.LIMITATION OF LIABILITY. TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF OR RELATED TO THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. In no event will Sun's liability to you, whether in contract, tort (including negligence), or otherwise, exceed the amount paid by you for Software under this Agreement. The foregoing limitations will apply even if the above stated warranty fails of its essential purpose. 6. TERMINATION. This Agreement is effective until terminated. You may terminate this Agreement at any time by destroying all copies of Software. This Agreement will terminate immediately without notice from Sun if you fail to comply with any provision of this Agreement. Upon Termination, you must destroy all copies of Software. 7. EXPORT REGULATIONS. All Software and technical data delivered under this Agreement are subject to US export control laws and may be subject to export or import regulations in other countries. You agree to comply strictly with all such laws and regulations and acknowledge that you have the responsibility to obtain such licenses to export, re-export, or import as may be required after delivery to you. 8. U.S. GOVERNMENT RESTRICTED RIGHTS. If Software is being acquired by or on behalf of the U.S. Government or by a U.S. Government prime contractor or subcontractor (at any tier), then the Government's rights in Software and accompanying documentation will be only as set forth in this Agreement; this is in accordance with 48 CFR 227.7201 through 227.7202-4 (for Department of Defense (DOD) acquisitions) and with 48 CFR 2.101 and 12.212 (for non-DOD acquisitions). 9. GOVERNING LAW. Any action related to this Agreement will be governed by California law and controlling U.S. federal law. No choice of law rules of any jurisdiction will apply. 10, SEVERABILITY. If any provision of this Agreement is held to be unenforceable, this Agreement will remain in effect with the provision omitted, unless omission would frustrate the intent of the parties, in which case this Agreement will immediately terminate. 11. INTEGRATION This Agreement is the entire agreement between you and Sun relating to its subject matter. It supersedes all prior or contemporaneous oral or written communications, proposals, representations and warranties and prevails over any conflicting or additional terms of any quote, order, acknowledgment, or other communication between the parties relating to its subject matter during the term of this Agreement. No modification of this Agreement will be binding, unless in writing and signed by an authorized representative of each party. JAVA OPTIONAL PACKAGE JAVAX.COMM 3.0 SUPPLEMENTAL LICENSE TERMS These supplemental license terms ("Supplemental Terms") add to or modify the terms of the Binary Code License Agreement (collectively, the "Agreement"). Capitalized terms not defined in these Supplemental Terms shall have the same meanings ascribed to them in the Agreement. These Supplemental Terms shall supersede any inconsistent or conflicting terms in the Agreement, or in any license contained within the Software. 1. Software Internal Use and Development License Grant. Subject to the terms and conditions of this Agreement, including, but not limited to Section 3 (Java(TM) Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce internally and use internally the binary form of the Software, complete and unmodified, for the sole purpose of designing, developing and testing your Java applets and applications ("Programs"). 2. License to Distribute Software. In addition to the license granted in Section 1 (Software Internal Use and Development License Grant) of these Supplemental Terms, subject to the terms and conditions of this Agreement, including but not limited to, Section 3 (Java Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce and distribute the Software in binary code form only, provided that you (i) distribute the Software complete and unmodified and only bundled as part of your Programs, (ii) do not distribute additional software intended to replace any component(s) of the Software, (iii) do not remove or alter any proprietary legends or notices contained in the Software, (iv) only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (v) agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software. 3. Java Technology Restrictions. You may not modify the Java Platform Interface ("JPI", identified as classes contained within the "java" package or any subpackages of the "java" package), by creating additional classes within the JPI or otherwise causing the addition to or modification of the classes in the JPI. In the event that you create an additional class and associated API(s) which (i) extends the functionality of the Java platform, and (ii) is exposed to third party software developers for the purpose of developing additional software which invokes such additional API, you must promptly publish broadly an accurate specification for such API for free use by all developers. You may not create, or authorize your licensees to create additional classes, interfaces, or subpackages that are in any way identified as "java", "javax", "sun" or similar convention as specified by Sun in any naming convention designation. 4. Trademarks and Logos. You acknowledge and agree as between you and Sun that Sun owns the SUN, SOLARIS, JAVA, JINI, FORTE, and iPLANET trademarks and all SUN, SOLARIS, JAVA, JINI, FORTE, and iPLANET-related trademarks, service marks, logos and other brand designations ("Sun Marks"), and you agree to comply with the Sun Trademark and Logo Usage Requirements currently located at http://www.sun.com/policies/trademarks. Any use you make of the Sun Marks inures to Sun's benefit. 5. Source Code. Software may contain source code that is provided solely for reference purposes pursuant to the terms of this Agreement. Source code may not be redistributed unless expressly provided for in this Agreement. 6. Termination for Infringement. Either party may terminate this Agreement immediately should any Software become, or in either party's opinion be likely to become, the subject of a claim of infringement of any intellectual property right. For inquiries please contact: Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, California 95054. (LFI#143217/Form ID#011801) From tjarvi at qbang.org Sat Jul 8 10:12:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 10:12:55 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607081330.24381.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <200607081330.24381.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> Is the gnu.io namespace still necessary? I couldn't find the problem. >> >> Hi Pascal >> >> CommAPI is a little different in that it was grandfathered into the javax >> namespace with its own license at the time. >> >> It is my understanding that if CommAPI went through the JSR process, >> anyone would _clearly_ be able to implement a javax.comm package and RXTX >> would then be one of the first to do so. I believe Doug has expressed >> some interest in RXTX trying to work with the JSR process. >> >> Besides the license questions, there is the fact that RXTX has extensions >> to CommAPI which could cause confusion in the namespace. Not being a >> lawyer and *really* not liking to talk to lawyers in my free time, it is >> better to be safe than sorry. The lawyers tend to come in wolf packs >> when they do come. >> >> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay >> there as long as we are just geeks trying to figure out if a license does >> or does not allow us to implement in the javax.comm namespace. > > Nicely said. :) > > The whole point of namespaces is to create a universal registry of, in this > case, classes. This gnu.io namespace is very inconvenient. > > We feel the same way about lawyers. However I'd like to go into the details of > the license (see attachment) if you don't mind? > > The first license does not apply since RXTX does not use the software. The > second one at point 3 specifies our options. > >> 3. You may not modify the Java Platform Interface ("JPI", identified as >> classes contained within the "java" package or any subpackages of the >> "java" package), by creating additional classes within the JPI or otherwise >> causing the addition to or modification of the classes in the JPI. > > RXTX is a extension. > >> In the event that you create an additional class and associated API(s) >> which (i) extends the functionality of the Java platform, and (ii) is >> exposed to third party software developers for the purpose of developing >> additional software which invokes such additional API, you must promptly >> publish broadly an accurate specification for such API for free use by all >> developers. > > That's the way we operate. :) > >> You may not create, or authorize your licensees to create additional >> classes, interfaces, or subpackages that are in any way identified as >> "java", "javax", "sun" or similar convention as specified by Sun in any >> naming convention designation. > > They don't want additional components in the Communication API since they > don't want a mess in theire namespace. > > So we *can* use javax.comm for the core: > javax.comm.CommDriver > javax.comm.CommPort > javax.comm.CommPortIdentifier > javax.comm.CommPortOwnershipListener > javax.comm.NoSuchPortException > javax.comm.PortInUseException > javax.comm.UnsupportedCommOperationException > > ...and for the default hardware support: > javax.comm.SerialPort > javax.comm.SerialPortEvent > javax.comm.SerialPortEventListener > javax.comm.ParralelPort > javax.comm.ParralelPortEvent > javax.comm.ParralelPortEventListener > > ...but RXTX aditional hardware support has to go somewhere else like: > org.rxtx.RS485Port > org.rxtx.RS485PortEvent > org.rxtx.RS485PortEventListener > org.rxtx.I2CPort > org.rxtx.I2CPortEvent > org.rxtx.I2CPortEventListener > > Right? > I do not disagree with anything you said :) RXTX and Sun agree with each other almost completely but not exactly. I think there are three uses of CommAPI and Sun is mainly interested in one. 1) Point of sale. This is the direction Sun is going with limited resources thats causing some problems. They would obviously cause fewer problems with more resources just like rxtx would work with them better with more resources. I'm sure if you talk to people in this area they are very optimitsic about what CommAPI could be. 2) Instrument Control. This is my area of interest as its my job too. I'm still formulating opinions here and it is far to early to say much but I'm very optimistic about what CommAPI could be. 3) Hobby and other hardware control. Circuts, road signs, rxtx in cell phones controlling TVs, you name it. People asking about palm, wince, embeded hardware. This is why I thought it was important to open source rxtx in the beginning and still find it my primary motive to read rxtx email every morning and evening. The optimism here is abundant and self explained. Nothing would make me happier than having someone get a working demo of controlling LEDs with parallel ports that could be used by people learning. So everyone agrees with almost everything. Nobody is looking for conflicts. But these various interests have not been _clearly_ formalized. Licenses are tools for manipulating behavior. Until the above is clearly in line with each other, the license will be a tool for lawyers to cause problems for people working for free. This is why I support a move to go through the JSR process and formalize the relationship. My concern is not really Sun comming after RXTX with Lawyers. I have a great deal of respect for Sun going back to their sunsite project. My concern is how lawyers think. They look at the intent which is not all in line. Then I get what feels like insane conference calls that cost companies over $2000 an hour which pisses me off to no end. Companies paying lawyers to take time from developers for free. This really does happen when a fortune 50 company developer asks their legal department if they can use rxtx. I don't have enough bullets for that. The way you avoid this is formalize everones intent so lawyers don't make conference call meetings in outlook. I want to put those lawyers out of work and if it takes a little discomfort, thats perfectly fine. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Sat Jul 8 11:44:40 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 19:44:40 +0200 Subject: [Rxtx] Fwd: Re: Java installer Message-ID: <200607081944.41123.pascal@quies.net> For some reason the first mail failed... ---------- Doorgestuurd bericht ---------- Subject: Re: [Rxtx] Java installer Date: zaterdag 8 juli 2006 17:18 From: "Pascal S. de Kloe" To: RXTX Developers and Users Hello Manuel, In case of a JDK the installation goes into the "jre" directory. I can't find a simple way to get this information into a variable of IzPack. (see attachment) Do you have a idea? Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: > Pascal: > I will be a little short with my answer but very informative :) > > > Could you publish the IzPack configuration and the binaries? That would > > be very helpful since the current installation procedure is > > somewhat "unprofessional". ;) > > > > IzPack is great but this API is a little more than that. It allows java > > applications who require the extension to detect available versions and > > install RXTX on the fly if needed. > > > > Is Izpack: > > * able to install binaries for the right platform (os + hardware > > architecture)? > > Yes. > > > * Java 1.2 compatible > > Yes of course > > > * able to run from the command line? > > Yes, and can run from command line detecting which is the underlaying os. > I have attached an old version of one of my installer, I can't find the > last one, but it is like this one. In this you will see how to detect > the OS and architecture and install binaries for that plataform. > Regards, > Manuel ------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: izpack.xml Type: text/xml Size: 1401 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060708/413315d2/izpack-0355.xml From joachim at buechse.de Sat Jul 8 10:02:18 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 8 Jul 2006 18:02:18 +0200 Subject: [Rxtx] Java installer In-Reply-To: <200607080055.04501.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: <7D4FA261-44FA-4A6E-8EB9-7A7B0116BB2C@buechse.de> Hello Pascal, as soon as the 2.1.8 version is "released" I'll happily provide you with a precompiled library for Mac OSX. The currently tagged version is 2.17 which has a non standard implementation for OSX. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 08.07.2006, at 00:55, Pascal S. de Kloe wrote: > > I need as many pre-compiled binaries as possible. > Could you help me with that? > > The detection system already works. > > Thanks again, > > Pascal > > > PS > Is the gnu.io namespace still necessary? I couldn't find the problem. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 8 09:18:09 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 17:18:09 +0200 Subject: [Rxtx] Java installer In-Reply-To: <44AEE87F.60202@gmail.com> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <44AEE87F.60202@gmail.com> Message-ID: <200607081718.09605.pascal@quies.net> Hello Manuel, In case of a JDK the installation goes into the "jre" directory. I can't find a simple way to get this information into a variable of IzPack. (see attachment) Do you have a idea? Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: > Pascal: > I will be a little short with my answer but very informative :) > > > Could you publish the IzPack configuration and the binaries? That would > > be very helpful since the current installation procedure is > > somewhat "unprofessional". ;) > > > > IzPack is great but this API is a little more than that. It allows java > > applications who require the extension to detect available versions and > > install RXTX on the fly if needed. > > > > Is Izpack: > > * able to install binaries for the right platform (os + hardware > > architecture)? > > Yes. > > > * Java 1.2 compatible > > Yes of course > > > * able to run from the command line? > > Yes, and can run from command line detecting which is the underlaying os. > I have attached an old version of one of my installer, I can't find the > last one, but it is like this one. In this you will see how to detect > the OS and architecture and install binaries for that plataform. > Regards, > Manuel -------------- next part -------------- A non-text attachment was scrubbed... Name: izpack.xml Type: text/xml Size: 1401 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060708/fa6f5a81/izpack-0355.xml From naranjo.manuel at gmail.com Sat Jul 8 12:52:23 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 15:52:23 -0300 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607081944.41123.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> Message-ID: <44AFFEE7.3090306@gmail.com> Pascal: I can't get exactly your point, but my installer was to avoid modifying the users JDK or JRE. Download this app made by me, and you will get my point: http://www.aircable.net/downloads/AIRcable_Configuration_Utility_v0.2_ALPHA_1.zip, this app bundles RXTX library inside the zip file, and does not need RXTX installed on the Users system. Manuel > For some reason the first mail failed... > > > ---------- Doorgestuurd bericht ---------- > > Subject: Re: [Rxtx] Java installer > Date: zaterdag 8 juli 2006 17:18 > From: "Pascal S. de Kloe" > To: RXTX Developers and Users > > Hello Manuel, > > In case of a JDK the installation goes into the "jre" directory. > I can't find a simple way to get this information into a variable of IzPack. > (see attachment) > > Do you have a idea? > > Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: >> Pascal: >> I will be a little short with my answer but very informative :) >> >>> Could you publish the IzPack configuration and the binaries? That would >>> be very helpful since the current installation procedure is >>> somewhat "unprofessional". ;) >>> >>> IzPack is great but this API is a little more than that. It allows java >>> applications who require the extension to detect available versions and >>> install RXTX on the fly if needed. >>> >>> Is Izpack: >>> * able to install binaries for the right platform (os + hardware >>> architecture)? >> Yes. >> >>> * Java 1.2 compatible >> Yes of course >> >>> * able to run from the command line? >> Yes, and can run from command line detecting which is the underlaying os. >> I have attached an old version of one of my installer, I can't find the >> last one, but it is like this one. In this you will see how to detect >> the OS and architecture and install binaries for that plataform. >> Regards, >> Manuel > > ------------------------------------------------------- > > > ------------------------------------------------------------------------ > > > > > RXTX > 2... > http://www.rxtx.org/ > 1.2 > uninstallRXTX > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Jul 8 12:53:32 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 15:53:32 -0300 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607081944.41123.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> Message-ID: <44AFFF2C.8090005@gmail.com> Even more, the variable ${CURRENT_JRE} referees to the actuall JVM as far as I know, so you will have no difference in installing towards a JDK. > For some reason the first mail failed... > > > ---------- Doorgestuurd bericht ---------- > > Subject: Re: [Rxtx] Java installer > Date: zaterdag 8 juli 2006 17:18 > From: "Pascal S. de Kloe" > To: RXTX Developers and Users > > Hello Manuel, > > In case of a JDK the installation goes into the "jre" directory. > I can't find a simple way to get this information into a variable of IzPack. > (see attachment) > > Do you have a idea? > > Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: >> Pascal: >> I will be a little short with my answer but very informative :) >> >>> Could you publish the IzPack configuration and the binaries? That would >>> be very helpful since the current installation procedure is >>> somewhat "unprofessional". ;) >>> >>> IzPack is great but this API is a little more than that. It allows java >>> applications who require the extension to detect available versions and >>> install RXTX on the fly if needed. >>> >>> Is Izpack: >>> * able to install binaries for the right platform (os + hardware >>> architecture)? >> Yes. >> >>> * Java 1.2 compatible >> Yes of course >> >>> * able to run from the command line? >> Yes, and can run from command line detecting which is the underlaying os. >> I have attached an old version of one of my installer, I can't find the >> last one, but it is like this one. In this you will see how to detect >> the OS and architecture and install binaries for that plataform. >> Regards, >> Manuel > > ------------------------------------------------------- > > > ------------------------------------------------------------------------ > > > > > RXTX > 2... > http://www.rxtx.org/ > 1.2 > uninstallRXTX > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Jul 8 12:54:22 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 15:54:22 -0300 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <200607081330.24381.pascal@quies.net> Message-ID: <44AFFF5E.50603@gmail.com> > > I do not disagree with anything you said :) > > RXTX and Sun agree with each other almost completely but not exactly. I > think there are three uses of CommAPI and Sun is mainly interested in one. > > 1) Point of sale. This is the direction Sun is going with limited > resources thats causing some problems. They would obviously cause fewer > problems with more resources just like rxtx would work with them better > with more resources. I'm sure if you talk to people in this area they are > very optimitsic about what CommAPI could be. > > 2) Instrument Control. This is my area of interest as its my job too. I'm > still formulating opinions here and it is far to early to say much but I'm > very optimistic about what CommAPI could be. > > 3) Hobby and other hardware control. Circuts, road signs, rxtx in cell > phones controlling TVs, you name it. People asking about palm, wince, > embeded hardware. This is why I thought it was important to open source > rxtx in the beginning and still find it my primary motive to read rxtx > email every morning and evening. The optimism here is abundant and self > explained. Nothing would make me happier than having someone get a > working demo of controlling LEDs with parallel ports that could be used by > people learning. > > So everyone agrees with almost everything. Nobody is looking for > conflicts. But these various interests have not been _clearly_ > formalized. Licenses are tools for manipulating behavior. Until the > above is clearly in line with each other, the license will be a tool for > lawyers to cause problems for people working for free. This is why I > support a move to go through the JSR process and formalize the > relationship. > > My concern is not really Sun comming after RXTX with Lawyers. I have a > great deal of respect for Sun going back to their sunsite project. My > concern is how lawyers think. They look at the intent which is not all in > line. Then I get what feels like insane conference calls that cost > companies over $2000 an hour which pisses me off to no end. Companies > paying lawyers to take time from developers for free. This really does > happen when a fortune 50 company developer asks their legal department if > they can use rxtx. I don't have enough bullets for that. > > The way you avoid this is formalize everones intent so lawyers don't > make conference call meetings in outlook. I want to put those lawyers out > of work and if it takes a little discomfort, thats perfectly fine. > > -- > Trent Jarvi > tjarvi at qbang.org > > Trent: GREAT MAIL, I hate lawyers too. From naranjo.manuel at gmail.com Sat Jul 8 07:52:47 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 10:52:47 -0300 Subject: [Rxtx] Java installer In-Reply-To: <200607080235.29486.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <44AEE87F.60202@gmail.com> <200607080235.29486.pascal@quies.net> Message-ID: <44AFB8AF.50403@gmail.com> > > You are right. IzPack looks like the right tool for this job. > > As far as I can see there is no commandline support but I'll get over it. ;) Actually there is a way to execute native app in the Underlaying OS. Check out the JavaDOC and all the documentation given by them. If you need to also generate warper around the jar files, check this projects out: http://launch4j.sourceforge.net and http://jsmooth.sourceforge.net/ I have been able to make and exe with jsmooth that does not need to have RXTX installed if you want I can send the source of it. But it is simple. Do not put the jar inside the exe file, and add to the classpath relative paths to rxtx jar and then your jar file, and then add to the JVM command line (I can't remeber the actual name of it :P) -Djava.library.path=bin\ (Or were ever you installed the binary package). I have tryied doing the same with Java Comm from Sun but it actually is imposible, the main difference to me that make me move to RXTX, was that there is no need to have the javax.comm.properties file, which gave me lot of headaches. Regards, Manuel. From naranjo.manuel at gmail.com Sat Jul 8 08:03:58 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 11:03:58 -0300 Subject: [Rxtx] License question. Message-ID: <44AFBB4E.70808@gmail.com> Hi: I have a question, haven't you ever thought about changing RXTX license from GNU/GPL to a more open license like Apache v2 or BSD like?. As far as I understand if I make an application that uses RXTX libraries, I must release my app under the GNU/GPL. I have no problem with that in fact I'm an Open Source user and defender. The fact is that in same cases the applications made by one, could get into hands of a company that needs to release a Closed Source app. I understand that using GNU/GPL do not give you the power to do this, but a more "open" license like Apache does. By "open" I mean that the license respects the Open Source license, but also lives the user the opportunity to use the library in closed source programs. I have seen that there is an exception to the license that applies to RXTX v2.0-5 and above, the only problem with it is that Java Comm Api (the jar file) needs the file javax.comm.properties installed correctly, which in lot of cases is a headache. RXTX jar does not need this, actually I think that RXTX is more user friendly than Java Comm. Maybe there has been a discussion like this before, but I just wanted to ask, and to get an answer that is adequate to our time. Regards, Manuel From pascal at quies.net Sat Jul 8 14:03:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:03:13 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <44AFFF2C.8090005@gmail.com> References: <200607081944.41123.pascal@quies.net> <44AFFF2C.8090005@gmail.com> Message-ID: <200607082203.13696.pascal@quies.net> Op zaterdag 8 juli 2006 20:53, schreef Manuel Naranjo: > Even more, the variable ${CURRENT_JRE} referees to the actuall JVM as > far as I know, so you will have no difference in installing towards a JDK. As far as the installation instructions go the location of the libraries is the following. Windows * JRE: $JAVA_HOME/bin/ * JDK: $JAVA_HOME/jre/bin/ UNIX * JRE: $JAVA_HOME/lib/ * JRE: $JAVA_HOME/jre/lib/ From pascal at quies.net Sat Jul 8 14:04:50 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:04:50 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <44AFFEE7.3090306@gmail.com> References: <200607081944.41123.pascal@quies.net> <44AFFEE7.3090306@gmail.com> Message-ID: <200607082204.50712.pascal@quies.net> Op zaterdag 8 juli 2006 20:52, schreef Manuel Naranjo: > Pascal: > I can't get exactly your point, but my installer was to avoid modifying > the users JDK or JRE. Download this app made by me, and you will get my > point: > http://www.aircable.net/downloads/AIRcable_Configuration_Utility_v0.2_ALPHA >_1.zip, this app bundles RXTX library inside the zip file, and does not need > RXTX installed on the Users system. > Manuel I didn't get the point indeed and I still don't get it. :$ The installation instructions state that RXTX.jar must be in the classpath and the libraries should go as my previous mail stated. Do you have another way? I don't have Windows so i can't run that EXE. From pascal at quies.net Sat Jul 8 14:05:40 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:05:40 +0200 Subject: [Rxtx] Java installer In-Reply-To: <7D4FA261-44FA-4A6E-8EB9-7A7B0116BB2C@buechse.de> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <7D4FA261-44FA-4A6E-8EB9-7A7B0116BB2C@buechse.de> Message-ID: <200607082205.40527.pascal@quies.net> Op zaterdag 8 juli 2006 18:02, schreef Joachim Buechse: > as soon as the 2.1.8 version is "released" I'll happily provide you ? > with a precompiled library for Mac OSX. The currently tagged version ? > is 2.17 which has a non standard implementation for OSX. Perfect! :) Do you have a idea when that will be? Like this month? From pascal at quies.net Sat Jul 8 14:14:44 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:14:44 +0200 Subject: [Rxtx] Java installer In-Reply-To: <44AFB8AF.50403@gmail.com> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080235.29486.pascal@quies.net> <44AFB8AF.50403@gmail.com> Message-ID: <200607082214.45115.pascal@quies.net> Op zaterdag 8 juli 2006 15:52, schreef Manuel Naranjo: > > You are right. IzPack looks like the right tool for this job. > > > > As far as I can see there is no commandline support but I'll get over it. > > ;) > > Actually there is a way to execute native app in the Underlaying OS. > Check out the JavaDOC and all the documentation given by them. > If you need to also generate warper around the jar files, check this > projects out: > http://launch4j.sourceforge.net and http://jsmooth.sourceforge.net/ > I have been able to make and exe with jsmooth that does not need to > have RXTX installed if you want I can send the source of it. But it is > simple. > Do not put the jar inside the exe file, and add to the classpath > relative paths to rxtx jar and then your jar file, and then add to the > JVM command line (I can't remeber the actual name of it :P) > -Djava.library.path=bin\ (Or were ever you installed the binary package). > I have tryied doing the same with Java Comm from Sun but it actually is > imposible, the main difference to me that make me move to RXTX, was that > there is no need to have the javax.comm.properties file, which gave me > lot of headaches. > Regards, > Manuel. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Those are verry interresting and impressive tools for Windows. However, I wanted (and still do) a universal installer for all supported platforms as a single JAR. IzPack seemed quite suitable but it is limited and not well written so I'me still searching... Thanks for the help though. :) From pascal at quies.net Sat Jul 8 14:19:59 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:19:59 +0200 Subject: [Rxtx] License question. In-Reply-To: <44AFBB4E.70808@gmail.com> References: <44AFBB4E.70808@gmail.com> Message-ID: <200607082219.59514.pascal@quies.net> I thought of the same thing. The modified BSD license would certainly make it more eazy and acceptable for Sun to include RXTX in theire products. Unfortunately in general people who chose GPL don't like other licenses. ;) Op zaterdag 8 juli 2006 16:03, schreef Manuel Naranjo: > Hi: > I have a question, haven't you ever thought about changing RXTX license > from GNU/GPL to a more open license like Apache v2 or BSD like?. > As far as I understand if I make an application that uses RXTX > libraries, I must release my app under the GNU/GPL. I have no problem > with that in fact I'm an Open Source user and defender. > The fact is that in same cases the applications made by one, could get > into hands of a company that needs to release a Closed Source app. I > understand that using GNU/GPL do not give you the power to do this, but > a more "open" license like Apache does. By "open" I mean that the > license respects the Open Source license, but also lives the user the > opportunity to use the library in closed source programs. > I have seen that there is an exception to the license that applies to > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > (the jar file) needs the file javax.comm.properties installed correctly, > which in lot of cases is a headache. RXTX jar does not need this, > actually I think that RXTX is more user friendly than Java Comm. > Maybe there has been a discussion like this before, but I just wanted to > ask, and to get an answer that is adequate to our time. > Regards, > Manuel > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jul 8 15:30:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 15:30:31 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <44AFBB4E.70808@gmail.com> References: <44AFBB4E.70808@gmail.com> Message-ID: On Sat, 8 Jul 2006, Manuel Naranjo wrote: > Hi: > I have a question, haven't you ever thought about changing RXTX license > from GNU/GPL to a more open license like Apache v2 or BSD like?. > As far as I understand if I make an application that uses RXTX > libraries, I must release my app under the GNU/GPL. I have no problem > with that in fact I'm an Open Source user and defender. > The fact is that in same cases the applications made by one, could get > into hands of a company that needs to release a Closed Source app. I > understand that using GNU/GPL do not give you the power to do this, but > a more "open" license like Apache does. By "open" I mean that the > license respects the Open Source license, but also lives the user the > opportunity to use the library in closed source programs. > I have seen that there is an exception to the license that applies to > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > (the jar file) needs the file javax.comm.properties installed correctly, > which in lot of cases is a headache. RXTX jar does not need this, > actually I think that RXTX is more user friendly than Java Comm. > Maybe there has been a discussion like this before, but I just wanted to > ask, and to get an answer that is adequate to our time. > Regards, > Manuel Hi Manuel As one of the primary copyright 'owners' and a representative of all the people who have worked on RXTX I feel very compelled to comment on this. I often observe this misconception and just ignore it. RXTX is very commercial friendly both in open and closed source. The license is LGPL not GPL. This allows for linking to any application you like without sharing yoru application code. It is not unlike Apache or BSD in that sense. I like the BSD license but not in this case. The difference is you can not keep your changes to rxtx itself if your product is distributed in practice. To me this makes no sense and is a basic flaw in BSD licensing for libraries. I have _no_ intentions of "competing" with various incarnations of RXTX. If you use RXTX in your commercial application, I hope for two things. First I want you to do well for using rxtx even if you somehow compete with me in the commercial world. Second I want to see changes to RXTX come back to RXTX so we all do well for choosing RXTX. This is not possible with the BSD, MIT ... licenses. They result in multiple forks from the code and this is used to disrupt 'standards' by companies you would recognize (I no longer mention any company when saying bad things without fair notice). Your code is your code. Thats how the LGPL works. But don't take RXTX and fork it where I or anyone else that has worked on RXTX can see it. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Sat Jul 8 16:06:17 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 00:06:17 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> Message-ID: <200607090006.18197.pascal@quies.net> Op zaterdag 8 juli 2006 23:30, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Manuel Naranjo wrote: > > Hi: > > I have a question, haven't you ever thought about changing RXTX license > > from GNU/GPL to a more open license like Apache v2 or BSD like?. > > As far as I understand if I make an application that uses RXTX > > libraries, I must release my app under the GNU/GPL. I have no problem > > with that in fact I'm an Open Source user and defender. > > The fact is that in same cases the applications made by one, could get > > into hands of a company that needs to release a Closed Source app. I > > understand that using GNU/GPL do not give you the power to do this, but > > a more "open" license like Apache does. By "open" I mean that the > > license respects the Open Source license, but also lives the user the > > opportunity to use the library in closed source programs. > > I have seen that there is an exception to the license that applies to > > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > > (the jar file) needs the file javax.comm.properties installed correctly, > > which in lot of cases is a headache. RXTX jar does not need this, > > actually I think that RXTX is more user friendly than Java Comm. > > Maybe there has been a discussion like this before, but I just wanted to > > ask, and to get an answer that is adequate to our time. > > Regards, > > Manuel > > Hi Manuel > > As one of the primary copyright 'owners' and a representative of all the > people who have worked on RXTX I feel very compelled to comment on this. > I often observe this misconception and just ignore it. > > RXTX is very commercial friendly both in open and closed source. The > license is LGPL not GPL. This allows for linking to any application you > like without sharing yoru application code. It is not unlike Apache or > BSD in that sense. I like the BSD license but not in this case. > > The difference is you can not keep your changes to rxtx itself if your > product is distributed in practice. To me this makes no sense and is a > basic flaw in BSD licensing for libraries. I have _no_ intentions of > "competing" with various incarnations of RXTX. If you use RXTX in your > commercial application, I hope for two things. First I want you to do > well for using rxtx even if you somehow compete with me in the commercial > world. Second I want to see changes to RXTX come back to RXTX so we all > do well for choosing RXTX. > > This is not possible with the BSD, MIT ... licenses. They result in > multiple forks from the code and this is used to disrupt 'standards' by > companies you would recognize (I no longer mention any company when > saying bad things without fair notice). > > Your code is your code. Thats how the LGPL works. But don't take RXTX > and fork it where I or anyone else that has worked on RXTX can see it. > > -- > Trent Jarvi Hallo Trent, The BSD license wants to give and GPL wants to improve the public available content. What do you prefer? If you build the code to provide everyone a better experience then the BSD license would be suitable since the business acceptance is much higher. If you see this as a crucial component to build a complete free Java infrastructure that has no place for commerce then the GPL would be better In both situations RXTX will be free. I say that the chance a company would not contribute does not outweight the chance that the API is less available to the users. The entire API is a dead end. Mustang has USB support. Please let's make this as good as it gets. From tjarvi at qbang.org Sat Jul 8 16:09:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 16:09:31 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <200607082219.59514.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > I thought of the same thing. The modified BSD license would certainly make it > more eazy and acceptable for Sun to include RXTX in theire products. > > Unfortunately in general people who chose GPL don't like other licenses. ;) > If Sun can not accept the license, thats their problem. I have no problem with Sun distributing RXTX and working with the community. I've even stepped down as then primary and given that power to Doug to facilitate different opinions. For licensing changes, I am the primary copyright owner and have very strong opinions though I have a great deal of respect for everyone that has contributed to RXTX. Sun has their process and we have our process - screwy but a process and real. RXTX is not going to rubber stamp into any company without process that gives major power to the contributors to RXTX. There is a community here and it is not Sun's. (It isn't "gnu" either; the license is closest) This isn't about Trent. He is a wierd guy you should fear. That said, I'm not fundamentally against Sun distributing RXTX and changing package names. What I am fundametally against is multiple RXTXs. There isnt enough space for that game. -- Trent Jarvi tarvi at qbang.org From pascal at quies.net Sat Jul 8 16:25:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 00:25:24 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> Message-ID: <200607090025.24884.pascal@quies.net> Op zondag 9 juli 2006 00:09, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > > I thought of the same thing. The modified BSD license would certainly > > make it more eazy and acceptable for Sun to include RXTX in theire > > products. > > > > Unfortunately in general people who chose GPL don't like other licenses. > > ;) > > If Sun can not accept the license, thats their problem. > > I have no problem with Sun distributing RXTX and working with the > community. I've even stepped down as then primary and given that power to > Doug to facilitate different opinions. For licensing changes, I am the > primary copyright owner and have very strong opinions though I have a > great deal of respect for everyone that has contributed to RXTX. > > Sun has their process and we have our process - screwy but a process and > real. RXTX is not going to rubber stamp into any company without process > that gives major power to the contributors to RXTX. There is a community > here and it is not Sun's. (It isn't "gnu" either; the license is closest) > This isn't about Trent. He is a wierd guy you should fear. Hahaha, I found him very reasonable. The LGPL is not going to prevent forks. Any company which would take the code and keep little improvements to theirselves is stupid since they throw away a great deal of support and they know it. RXTX works. It needs a huge cleanup and more strict platform definitions but that's just a matter of time. What do you have to loose? From tjarvi at qbang.org Sat Jul 8 16:33:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 16:33:32 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <200607090025.24884.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> <200607090025.24884.pascal@quies.net> Message-ID: On Sun, 9 Jul 2006, Pascal S. de Kloe wrote: > Op zondag 9 juli 2006 00:09, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> I thought of the same thing. The modified BSD license would certainly >>> make it more eazy and acceptable for Sun to include RXTX in theire >>> products. >>> >>> Unfortunately in general people who chose GPL don't like other licenses. >>> ;) >> >> If Sun can not accept the license, thats their problem. >> >> I have no problem with Sun distributing RXTX and working with the >> community. I've even stepped down as then primary and given that power to >> Doug to facilitate different opinions. For licensing changes, I am the >> primary copyright owner and have very strong opinions though I have a >> great deal of respect for everyone that has contributed to RXTX. >> >> Sun has their process and we have our process - screwy but a process and >> real. RXTX is not going to rubber stamp into any company without process >> that gives major power to the contributors to RXTX. There is a community >> here and it is not Sun's. (It isn't "gnu" either; the license is closest) >> This isn't about Trent. He is a wierd guy you should fear. > > Hahaha, I found him very reasonable. > > The LGPL is not going to prevent forks. No it will not, but it will allow for you or me to view forks and absorb them. It renders forks of RXTX useless at the price of whatever product is shipped. I would ask that you consider the larger picture here. Termios and DCB are almost dead but almost being used like a VISA interface. Everyone just wants it to work but it does not always. So your proposal is to make mulitiple deal protocols? -- Trent Jarvi tjarvi at qbang.org From naranjo.manuel at gmail.com Sat Jul 8 17:20:44 2006 From: naranjo.manuel at gmail.com (Naranjo Manuel Francisco) Date: Sat, 8 Jul 2006 20:20:44 -0300 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> Message-ID: <360bc8300607081620x4e5d0f23h88fef8d81e6b6a0b@mail.gmail.com> Sorry, my mistake then, I thought the license was GPL not LGPL, I guess I readed some thing badly. I have readed all the emails, and you are right, there is no need for a Fork of RXTX, I think it works right as it is. So I can make my app Apache v2 with out any worry, because RXTX is LGPL :), great then. From tjarvi at qbang.org Sat Jul 8 17:57:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 17:57:05 -0600 (MDT) Subject: [Rxtx] License question ver2. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> <200607090025.24884.pascal@quies.net> Message-ID: Are there any more questions relating to this subject? From tjarvi at qbang.org Sat Jul 8 21:14:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 21:14:09 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <200607090006.18197.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607090006.18197.pascal@quies.net> Message-ID: On Sun, 9 Jul 2006, Pascal S. de Kloe wrote: > Op zaterdag 8 juli 2006 23:30, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Manuel Naranjo wrote: >>> Hi: >>> I have a question, haven't you ever thought about changing RXTX license >>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>> As far as I understand if I make an application that uses RXTX >>> libraries, I must release my app under the GNU/GPL. I have no problem >>> with that in fact I'm an Open Source user and defender. >>> The fact is that in same cases the applications made by one, could get >>> into hands of a company that needs to release a Closed Source app. I >>> understand that using GNU/GPL do not give you the power to do this, but >>> a more "open" license like Apache does. By "open" I mean that the >>> license respects the Open Source license, but also lives the user the >>> opportunity to use the library in closed source programs. >>> I have seen that there is an exception to the license that applies to >>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>> (the jar file) needs the file javax.comm.properties installed correctly, >>> which in lot of cases is a headache. RXTX jar does not need this, >>> actually I think that RXTX is more user friendly than Java Comm. >>> Maybe there has been a discussion like this before, but I just wanted to >>> ask, and to get an answer that is adequate to our time. >>> Regards, >>> Manuel >> >> Hi Manuel >> >> As one of the primary copyright 'owners' and a representative of all the >> people who have worked on RXTX I feel very compelled to comment on this. >> I often observe this misconception and just ignore it. >> >> RXTX is very commercial friendly both in open and closed source. The >> license is LGPL not GPL. This allows for linking to any application you >> like without sharing yoru application code. It is not unlike Apache or >> BSD in that sense. I like the BSD license but not in this case. >> >> The difference is you can not keep your changes to rxtx itself if your >> product is distributed in practice. To me this makes no sense and is a >> basic flaw in BSD licensing for libraries. I have _no_ intentions of >> "competing" with various incarnations of RXTX. If you use RXTX in your >> commercial application, I hope for two things. First I want you to do >> well for using rxtx even if you somehow compete with me in the commercial >> world. Second I want to see changes to RXTX come back to RXTX so we all >> do well for choosing RXTX. >> >> This is not possible with the BSD, MIT ... licenses. They result in >> multiple forks from the code and this is used to disrupt 'standards' by >> companies you would recognize (I no longer mention any company when >> saying bad things without fair notice). >> >> Your code is your code. Thats how the LGPL works. But don't take RXTX >> and fork it where I or anyone else that has worked on RXTX can see it. >> >> -- >> Trent Jarvi > > Hallo Trent, > > The BSD license wants to give and GPL wants to improve the public available > content. What do you prefer? > > If you build the code to provide everyone a better experience then the BSD > license would be suitable since the business acceptance is much higher. > If you see this as a crucial component to build a complete free Java > infrastructure that has no place for commerce then the GPL would be better > In both situations RXTX will be free. > > I say that the chance a company would not contribute does not outweight the > chance that the API is less available to the users. > The entire API is a dead end. Mustang has USB support. Please let's make this > as good as it gets. Hi Pascal I can not speak for any company here. I just happen to have become interesting to companies. With RXTX, the intent has always been to improve functionality. I don't play between the two worlds except for borrowing a scope at late in the evening. Thats rxtx and there is nothing else going on. Note that the RXTX library is LGPL. I would be interested in knowing where the GPL confusion comes from. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Jul 9 04:46:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 09 Jul 2006 06:46:49 -0400 Subject: [Rxtx] Java installer In-Reply-To: <200607082214.45115.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080235.29486.pascal@quies.net> <44AFB8AF.50403@gmail.com> <200607082214.45115.pascal@quies.net> Message-ID: Hi All, The problem of improving Java's ability to install and configure applications is a topic of current research. Configuration is a loaded word. When I think of configuration, I think, discover the properties of the operating environment and configure the software to work within that environment. Properties may include, but are not limited to, number and kind of monitors, serial ports, JVM versions, native method libs, graphics cards, graphics libs, write access to directories, changing the default screen saver (a new research topic) etc. There are two deployment solutions I can think of, please correct me, if I have left something out: 1. A source code distro with build tools (i.e., make and or ant) that enable the user to do a build for the target platform. 2. A binary distro built for each platform. Now, Java (in theory), is compile once, run anywhere. This assumes you don't use native methods. Once you start using native methods, you end up with many builds of the libs (one for each supported platform). Assuming you want binary distros for each platform, then you are faced with how to deploy them. Here are two basic approaches I know: 1. Build an application installer 2. Build a web-start distribution Some would argue for the application installer, as this is what many people are used to. Others will argue for a web-start distro. For a JNI-based application, like one that makes use of RXTX, I don't know which approach is "better". To know, one must first establish what "better" means. I think there must be (at least) two properties here: 1. Minimal installation effort 2. Trust. For minimal installation effort, I think that I should be able to download software, on demand, and just run it. Updates are obtained with minimal effort. Everything just works. And on all platforms that I use. For trust, I want to make sure I know the author and am able to hold someone accountable for application creation. I need to be able to thwart man-in-the-middle attacks and assure my user-base that I have signed off on my software. I have been making use of web-start, as a multi-year experiment. I have had mixed results. Particularly with more complex installs that make use of Java3d. In my view, several open problems remain. And cross-platform testing is needed for each major new application, platform, or major native method revision. On the other hand, I have had some good results with Java web start and RXTX. I can cite: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Which is an address book program that should identify your serial port and enable dialing via the modem. The web start system seems to be able to adapt to multiple operating environments. The question of how well this deploys remains open. It should work on mac, windows and linux. If people want to try it and give me feedback, I would appreciate it. Deployment is semi-automatic using Project Initium. This is described in: http://show.docjava.com:8086/pub/document/jot/web.pdf and http://show.docjava.com:8086/pub/document/jot/initium.pdf Thanks! - Doug >Op zaterdag 8 juli 2006 15:52, schreef Manuel Naranjo: >> > You are right. IzPack looks like the right tool for this job. >> > >> > As far as I can see there is no commandline support but I'll get over it. >> > ;) >> >> Actually there is a way to execute native app in the Underlaying OS. >> Check out the JavaDOC and all the documentation given by them. >> If you need to also generate warper around the jar files, check this > > projects out: > > http://launch4j.sourceforge.net and http://jsmooth.sourceforge.net/ > > I have been able to make and exe with jsmooth that does not need to >> have RXTX installed if you want I can send the source of it. But it is >> simple. >> Do not put the jar inside the exe file, and add to the classpath >> relative paths to rxtx jar and then your jar file, and then add to the >> JVM command line (I can't remeber the actual name of it :P) > > -Djava.library.path=bin\ (Or were ever you installed the binary package). >> I have tryied doing the same with Java Comm from Sun but it actually is >> imposible, the main difference to me that make me move to RXTX, was that >> there is no need to have the javax.comm.properties file, which gave me >> lot of headaches. >> Regards, >> Manuel. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >Those are verry interresting and impressive tools for Windows. >However, I wanted (and still do) a universal installer for all supported >platforms as a single JAR. IzPack seemed quite suitable but it is limited and >not well written so I'me still searching... > >Thanks for the help though. :) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 9 05:15:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 13:15:13 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607090006.18197.pascal@quies.net> Message-ID: <200607091315.14053.pascal@quies.net> Op zondag 9 juli 2006 05:14, schreef Trent Jarvi: > Hi Pascal > > I can not speak for any company here. I just happen to have become > interesting to companies. > > With RXTX, the intent has always been to improve functionality. > > I don't play between the two worlds except for borrowing a scope at late > in the evening. Thats rxtx and there is nothing else going on. > > Note that the RXTX library is LGPL. I would be interested in knowing > where the GPL confusion comes from. Hi Trent, The license is stated clearly everywhere so don't worry. You are right that the LGPL should not be a problem for companies. The problem is, especially in larger companies, that the people who take the decissions think differend. When they hear about the demands of the license they rather spend "some" money on a commercial solution just to be sure because the trouble it might cause is not worth it. From pascal at quies.net Sun Jul 9 05:15:41 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 13:15:41 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607090025.24884.pascal@quies.net> Message-ID: <200607091315.41848.pascal@quies.net> Op zondag 9 juli 2006 00:33, schreef Trent Jarvi: > I would ask that you consider the larger picture here. Termios and DCB > are almost dead but almost being used like a VISA interface. Everyone > just wants it to work but it does not always. > > So your proposal is to make mulitiple deal protocols? No, nothing like that. Just use native calls where possible. I'll send you some things this week anyway. From pascal at quies.net Sun Jul 9 05:52:11 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 13:52:11 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607082214.45115.pascal@quies.net> Message-ID: <200607091352.11696.pascal@quies.net> Op zondag 9 juli 2006 12:46, schreef Dr. Douglas Lyon: > Hi All, > The problem of improving Java's ability to > install and configure applications is a topic of current research. > > Configuration is a loaded word. When I think of configuration, > I think, discover the properties of the operating environment and > configure the software to work within that environment. > > Properties may include, but are not limited to, number and > kind of monitors, serial ports, JVM versions, native method libs, > graphics cards, graphics libs, write access to directories, > changing the default screen saver (a new research topic) etc. > > There are two deployment solutions I can think of, > please correct me, if I have left something out: > 1. A source code distro with build tools (i.e., make and or ant) that > enable the user to do a build for the target platform. > 2. A binary distro built for each platform. > > Now, Java (in theory), is compile once, run anywhere. This assumes you > don't use native methods. Once you start using native methods, > you end up with many builds of the libs (one for each supported platform). > > Assuming you want binary distros for each platform, then you are faced with > how to deploy them. Here are two basic approaches I know: > 1. Build an application installer > 2. Build a web-start distribution > > Some would argue for the application installer, as this is what > many people are used to. Others will argue for a web-start distro. > > For a JNI-based application, like one that makes use of RXTX, > I don't know which approach is "better". To know, one must > first establish what "better" means. I think there must be (at least) two > properties here: > 1. Minimal installation effort > 2. Trust. > > For minimal installation effort, I think that I should be able to download > software, on demand, and just run it. Updates are obtained with minimal > effort. Everything just works. And on all platforms that I use. > > For trust, I want to make sure I know the author and am able to hold > someone accountable for application creation. I need to be able to thwart > man-in-the-middle > attacks and assure my user-base that I have signed off on my software. > > I have been making > use of web-start, as a multi-year experiment. > > I have had mixed results. Particularly with more complex installs > that make use of Java3d. In my view, several open problems remain. > And cross-platform testing is needed for each major new application, > platform, or major native method revision. > > On the other hand, I have had some good results with Java web start > and RXTX. I can cite: > http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jn >lp Which is an address book program that should identify your > serial port and enable dialing via the modem. > > The web start system seems to be able to adapt to multiple operating > environments. The question of how well this deploys remains open. > > It should work on mac, windows and linux. If people want to try it > and give me feedback, I would appreciate it. > > Deployment is semi-automatic using Project Initium. This is described in: > http://show.docjava.com:8086/pub/document/jot/web.pdf > and > http://show.docjava.com:8086/pub/document/jot/initium.pdf > > Thanks! > - Doug Hello Dough, We are bumping into the same problems. Youre web-based plan is definitely the way to go. I still didn't find a way to get around two IzPack problems without hacking into the code and it's taking too long so I started again on the inital plan. The CommunicationAPI class does leave the trust thing up to the implementation. This means that users can download and run the JAR and other applications can include the jar to install things if needed. If you could "Initum" this process then RXTX has no installating limits anymore. From joachim at buechse.de Sun Jul 9 07:13:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 9 Jul 2006 15:13:34 +0200 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44AFBB4E.70808@gmail.com> References: <44AFBB4E.70808@gmail.com> Message-ID: <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> Manuel, a simple way to avoid the javax.comm.properties file is to include a class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } into your application jar file and make sure, that you include the javax.comm jar after it. That's all you need. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 08.07.2006, at 16:03, Manuel Naranjo wrote: > Hi: > I have a question, haven't you ever thought about changing RXTX > license > from GNU/GPL to a more open license like Apache v2 or BSD like?. > As far as I understand if I make an application that uses RXTX > libraries, I must release my app under the GNU/GPL. I have no problem > with that in fact I'm an Open Source user and defender. > The fact is that in same cases the applications made by one, could get > into hands of a company that needs to release a Closed Source app. I > understand that using GNU/GPL do not give you the power to do this, > but > a more "open" license like Apache does. By "open" I mean that the > license respects the Open Source license, but also lives the user the > opportunity to use the library in closed source programs. > I have seen that there is an exception to the license that applies to > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > (the jar file) needs the file javax.comm.properties installed > correctly, > which in lot of cases is a headache. RXTX jar does not need this, > actually I think that RXTX is more user friendly than Java Comm. > Maybe there has been a discussion like this before, but I just > wanted to > ask, and to get an answer that is adequate to our time. > Regards, > Manuel > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Sun Jul 9 07:19:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 9 Jul 2006 15:19:43 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607082203.13696.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> <44AFFF2C.8090005@gmail.com> <200607082203.13696.pascal@quies.net> Message-ID: <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> Pascal, I would strongly suggest NOT to follow these installation instructions for OSX. It "poisons" the global Java VM with a specific implementation of RXTX. Plus: there is not one, but several Java VMs installed on every version of OSX. An application specific file and global preference pane defines which VM launches which application. There is really no good reason to install RXTX globally. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 08.07.2006, at 22:03, Pascal S. de Kloe wrote: > > As far as the installation instructions go the location of the > libraries is > the following. > > Windows > * JRE: $JAVA_HOME/bin/ > * JDK: $JAVA_HOME/jre/bin/ > > UNIX > * JRE: $JAVA_HOME/lib/ > * JRE: $JAVA_HOME/jre/lib/ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 9 09:01:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 17:01:24 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> References: <200607081944.41123.pascal@quies.net> <200607082203.13696.pascal@quies.net> <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> Message-ID: <200607091701.24661.pascal@quies.net> Op zondag 9 juli 2006 15:19, schreef Joachim Buechse: > Pascal, > > I would strongly suggest NOT to follow these installation > instructions for OSX. It "poisons" the global Java VM with a specific > implementation of RXTX. Plus: there is not one, but several Java VMs > installed on every version of OSX. An application specific file and > global preference pane defines which VM launches which application. > There is really no good reason to install RXTX globally. I see your points. How can you use the extension non-globally? I asked the same thing for Windows to Manuel. The system will allow you to detect any implementation. So the "poison" becomes a alternative. Applications can install the extension if needed to the current runtime with something like: CommunicationAPI comm = new CommunicationAPI(); if (! comm.available()) { if (comm.installRXTX()) restart(); else handleError("I need the extension!"); } From naranjo.manuel at gmail.com Sun Jul 9 10:36:21 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 09 Jul 2006 13:36:21 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> Message-ID: <44B13085.2000805@gmail.com> Joachim, Does that really work???? I will try it later, thanks :) Manuel > Manuel, > > a simple way to avoid the javax.comm.properties file is to include a > class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > into your application jar file and make sure, that you include the > javax.comm jar after it. That's all you need. > > Regards, > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 08.07.2006, at 16:03, Manuel Naranjo wrote: > >> Hi: >> I have a question, haven't you ever thought about changing RXTX >> license >> from GNU/GPL to a more open license like Apache v2 or BSD like?. >> As far as I understand if I make an application that uses RXTX >> libraries, I must release my app under the GNU/GPL. I have no problem >> with that in fact I'm an Open Source user and defender. >> The fact is that in same cases the applications made by one, could get >> into hands of a company that needs to release a Closed Source app. I >> understand that using GNU/GPL do not give you the power to do this, >> but >> a more "open" license like Apache does. By "open" I mean that the >> license respects the Open Source license, but also lives the user the >> opportunity to use the library in closed source programs. >> I have seen that there is an exception to the license that applies to >> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >> (the jar file) needs the file javax.comm.properties installed >> correctly, >> which in lot of cases is a headache. RXTX jar does not need this, >> actually I think that RXTX is more user friendly than Java Comm. >> Maybe there has been a discussion like this before, but I just >> wanted to >> ask, and to get an answer that is adequate to our time. >> Regards, >> Manuel >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jul 9 10:50:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Jul 2006 10:50:11 -0600 (MDT) Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44B13085.2000805@gmail.com> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> Message-ID: I won't prevent people from discussing this hack. You can discuss anything on the list including things I do not agree with. But I do not agree with that hack. That is not in line with the history of RXTX respecting all that contribute including Sun. If you do this, it is your own thing. Agreeing to disagree is fine and usually the default here :). I just want to make it clear I do disagree. On Sun, 9 Jul 2006, Manuel Naranjo wrote: > Joachim, > Does that really work???? I will try it later, thanks :) > Manuel > >> Manuel, >> >> a simple way to avoid the javax.comm.properties file is to include a >> class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> into your application jar file and make sure, that you include the >> javax.comm jar after it. That's all you need. >> >> Regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 08.07.2006, at 16:03, Manuel Naranjo wrote: >> >>> Hi: >>> I have a question, haven't you ever thought about changing RXTX >>> license >>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>> As far as I understand if I make an application that uses RXTX >>> libraries, I must release my app under the GNU/GPL. I have no problem >>> with that in fact I'm an Open Source user and defender. >>> The fact is that in same cases the applications made by one, could get >>> into hands of a company that needs to release a Closed Source app. I >>> understand that using GNU/GPL do not give you the power to do this, >>> but >>> a more "open" license like Apache does. By "open" I mean that the >>> license respects the Open Source license, but also lives the user the >>> opportunity to use the library in closed source programs. >>> I have seen that there is an exception to the license that applies to >>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>> (the jar file) needs the file javax.comm.properties installed >>> correctly, >>> which in lot of cases is a headache. RXTX jar does not need this, >>> actually I think that RXTX is more user friendly than Java Comm. >>> Maybe there has been a discussion like this before, but I just >>> wanted to >>> ask, and to get an answer that is adequate to our time. >>> Regards, >>> Manuel >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From naranjo.manuel at gmail.com Sun Jul 9 11:43:33 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 09 Jul 2006 14:43:33 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> Message-ID: <44B14045.9030601@gmail.com> Trent: Do you know any other way, to use Java Comm API with RXTX with out the javax.comm.properties?. Have any information about how is the JSR going? Regards, Manuel > > I won't prevent people from discussing this hack. You can discuss > anything on the list including things I do not agree with. > > But I do not agree with that hack. That is not in line with the history > of RXTX respecting all that contribute including Sun. If you do this, > it is your own thing. > > Agreeing to disagree is fine and usually the default here :). I just > want to make it clear I do disagree. > > On Sun, 9 Jul 2006, Manuel Naranjo wrote: > >> Joachim, >> Does that really work???? I will try it later, thanks :) >> Manuel >> >>> Manuel, >>> >>> a simple way to avoid the javax.comm.properties file is to include a >>> class >>> >>> package com.sun.comm; >>> public class SolarisDriver extends gnu.io.RXTXCommDriver { >>> } >>> >>> into your application jar file and make sure, that you include the >>> javax.comm jar after it. That's all you need. >>> >>> Regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich >>> >>> >>> On 08.07.2006, at 16:03, Manuel Naranjo wrote: >>> >>>> Hi: >>>> I have a question, haven't you ever thought about changing RXTX >>>> license >>>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>>> As far as I understand if I make an application that uses RXTX >>>> libraries, I must release my app under the GNU/GPL. I have no problem >>>> with that in fact I'm an Open Source user and defender. >>>> The fact is that in same cases the applications made by one, could get >>>> into hands of a company that needs to release a Closed Source app. I >>>> understand that using GNU/GPL do not give you the power to do this, >>>> but >>>> a more "open" license like Apache does. By "open" I mean that the >>>> license respects the Open Source license, but also lives the user the >>>> opportunity to use the library in closed source programs. >>>> I have seen that there is an exception to the license that applies to >>>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>>> (the jar file) needs the file javax.comm.properties installed >>>> correctly, >>>> which in lot of cases is a headache. RXTX jar does not need this, >>>> actually I think that RXTX is more user friendly than Java Comm. >>>> Maybe there has been a discussion like this before, but I just >>>> wanted to >>>> ask, and to get an answer that is adequate to our time. >>>> Regards, >>>> Manuel >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Jul 9 11:53:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Jul 2006 11:53:19 -0600 (MDT) Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44B14045.9030601@gmail.com> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> Message-ID: Hi Manuel I do not know of another way. If you look at rxtx.org, even the compiled version is hard to find, always late and not what you want. At rxtx.org we just worry about the source and do a minimal effort to provide binaries. I'd love nothing more than someone to start selling RXTX binaries or working with us like Doug is to deliver the problems solved to users. The Free here is Freedom. Not price. There is a need for services rxtx.org is not able to provide well. That said I do not ever expect to recieve anything. It just makes sense for everyone to work together and compete outside of the source. On Sun, 9 Jul 2006, Manuel Naranjo wrote: > Trent: > Do you know any other way, to use Java Comm API with RXTX with out the > javax.comm.properties?. > Have any information about how is the JSR going? > Regards, > Manuel >> >> I won't prevent people from discussing this hack. You can discuss >> anything on the list including things I do not agree with. >> >> But I do not agree with that hack. That is not in line with the history >> of RXTX respecting all that contribute including Sun. If you do this, >> it is your own thing. >> >> Agreeing to disagree is fine and usually the default here :). I just >> want to make it clear I do disagree. >> >> On Sun, 9 Jul 2006, Manuel Naranjo wrote: >> >>> Joachim, >>> Does that really work???? I will try it later, thanks :) >>> Manuel >>> >>>> Manuel, >>>> >>>> a simple way to avoid the javax.comm.properties file is to include a >>>> class >>>> >>>> package com.sun.comm; >>>> public class SolarisDriver extends gnu.io.RXTXCommDriver { >>>> } >>>> >>>> into your application jar file and make sure, that you include the >>>> javax.comm jar after it. That's all you need. >>>> >>>> Regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >>>> >>>> >>>> On 08.07.2006, at 16:03, Manuel Naranjo wrote: >>>> >>>>> Hi: >>>>> I have a question, haven't you ever thought about changing RXTX >>>>> license >>>>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>>>> As far as I understand if I make an application that uses RXTX >>>>> libraries, I must release my app under the GNU/GPL. I have no problem >>>>> with that in fact I'm an Open Source user and defender. >>>>> The fact is that in same cases the applications made by one, could get >>>>> into hands of a company that needs to release a Closed Source app. I >>>>> understand that using GNU/GPL do not give you the power to do this, >>>>> but >>>>> a more "open" license like Apache does. By "open" I mean that the >>>>> license respects the Open Source license, but also lives the user the >>>>> opportunity to use the library in closed source programs. >>>>> I have seen that there is an exception to the license that applies to >>>>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>>>> (the jar file) needs the file javax.comm.properties installed >>>>> correctly, >>>>> which in lot of cases is a headache. RXTX jar does not need this, >>>>> actually I think that RXTX is more user friendly than Java Comm. >>>>> Maybe there has been a discussion like this before, but I just >>>>> wanted to >>>>> ask, and to get an answer that is adequate to our time. >>>>> Regards, >>>>> Manuel >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From naranjo.manuel at gmail.com Sun Jul 9 12:04:28 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 09 Jul 2006 15:04:28 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> Message-ID: <44B1452C.60208@gmail.com> Trent Jarvi wrote: > > Hi Manuel > > I do not know of another way. If you look at rxtx.org, even the > compiled version is hard to find, always late and not what you want. At > rxtx.org we just worry about the source and do a minimal effort to > provide binaries. Then that probes my theory, RXTX is much better than Java comm :) > I'd love nothing more than someone to start selling RXTX binaries or > working with us like Doug is to deliver the problems solved to users. > The Free here is Freedom. Not price. There is a need for services > rxtx.org is not able to provide well. That said I do not ever expect to > recieve anything. It just makes sense for everyone to work together and > compete outside of the source. I would like to contribute with the project giving support, I have worked using JSmooth and IzPack, and been able to make things that make RXTX easier to use and install. I will try to debug them, and send them to the mailing list, so you can do what ever you want with this :). Regards, Manuel From tjarvi at qbang.org Sun Jul 9 22:15:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Jul 2006 22:15:28 -0600 (MDT) Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44B1452C.60208@gmail.com> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> <44B1452C.60208@gmail.com> Message-ID: On Sun, 9 Jul 2006, Manuel Naranjo wrote: > Trent Jarvi wrote: >> >> Hi Manuel >> >> I do not know of another way. If you look at rxtx.org, even the >> compiled version is hard to find, always late and not what you want. At >> rxtx.org we just worry about the source and do a minimal effort to >> provide binaries. > Then that probes my theory, RXTX is much better than Java comm :) > >> I'd love nothing more than someone to start selling RXTX binaries or >> working with us like Doug is to deliver the problems solved to users. >> The Free here is Freedom. Not price. There is a need for services >> rxtx.org is not able to provide well. That said I do not ever expect to >> recieve anything. It just makes sense for everyone to work together and >> compete outside of the source. > I would like to contribute with the project giving support, I have > worked using JSmooth and IzPack, and been able to make things that make > RXTX easier to use and install. I will try to debug them, and send them > to the mailing list, so you can do what ever you want with this :). > Regards, Hi Manuel This is interesting. There are some checks and balances that we do at rxtx.org to make sure random material does not get in. It isn't personal just a low bar that must be crossed. After you get your changes in, you will know that others must cross the same bar. The basic question asked is "Does this change reflect the intent and work of those that have contributed to RXTX." Perhaps Doug is the best person to be the bar here. I'm more than willing to admit my limitations and obviously this is a limitation I face. If Doug is willing to take this task, I'd be glad to give him CVS write access which is more than overdue as he is the official maintainer now :) He then could optionally give you write access if your changes are fine and you represent a bar for new changes. I trust Doug. We do take the bar seriously as you can see. But it is not intended to prevent fair use of RXTX or prevent facilitating new uses. If we don't manage expectations here, there will be all sorts of problems and issues. -- Trent Jarvi tjarvi at qbang.org From zhanglong at adventnet.com Mon Jul 10 02:02:20 2006 From: zhanglong at adventnet.com (zhanglong) Date: Mon, 10 Jul 2006 16:02:20 +0800 Subject: [Rxtx] rxtx can not read data from serialport Message-ID: <44B2098C.6050407@adventnet.com> Dear brian and tjarvi, Thank you! After I set flowcontrol as FLOWCONTROL_RTSCTS_IN serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_IN); Then I can read and write data from serial port on Windows. But On linux9.0,No response,no data. I can get serialport list on my machine.And no error when I open serialport. I use Wevecom GSM modem device.I install Linux in VWware Workstation. And VWware Workstation install on windowsXP,So windowsXP and redhat Linux9.0 are on the same PC. On windows,I use COM1 serialport. On Linux,I use /dev/ttyS0 serialport. I hava test with SerialPort.FLOWCONTROL_XONXOFF_IN flow control,But still no data. How to set flow control,timeout and threshold on linux9.0? Thanks & Regards, Zhanglong -------------- next part -------------- A non-text attachment was scrubbed... Name: ListPort.java Type: text/x-java Size: 1659 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060710/334802b0/ListPort-0354.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: listport return on Windows and Linux.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060710/334802b0/listportreturnonWindowsandLinux-0354.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: TwoWaySerialComm.java Type: text/x-java Size: 3516 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060710/334802b0/TwoWaySerialComm-0354.bin From joachim at buechse.de Mon Jul 10 02:53:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 10 Jul 2006 10:53:09 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607091701.24661.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> <200607082203.13696.pascal@quies.net> <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> <200607091701.24661.pascal@quies.net> Message-ID: <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> The problem is, that once the libraries are installed in JAVA_HOME/ lib they will be loaded in preference to classes in your application classpath. If all you want is to use RXTX, then: - put the native lib in your application directory - include the javax.comm classes and RXTX classes in your application classpath - add the little stub class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } before the javax.comm classes in your application classpath. Alternatively you could also include the native lib in your application jar, extract it at runtime to a temp file, load it with System.load(). This will work on Windows and OSX. I didn't test it on Linux, but it should work. Regards, Joachim On 09.07.2006, at 17:01, Pascal S. de Kloe wrote: > Op zondag 9 juli 2006 15:19, schreef Joachim Buechse: >> Pascal, >> >> I would strongly suggest NOT to follow these installation >> instructions for OSX. It "poisons" the global Java VM with a specific >> implementation of RXTX. Plus: there is not one, but several Java VMs >> installed on every version of OSX. An application specific file and >> global preference pane defines which VM launches which application. >> There is really no good reason to install RXTX globally. > > I see your points. > How can you use the extension non-globally? I asked the same thing > for Windows > to Manuel. > > The system will allow you to detect any implementation. So the > "poison" > becomes a alternative. Applications can install the extension if > needed to > the current runtime with something like: > > CommunicationAPI comm = new CommunicationAPI(); > if (! comm.available()) { > if (comm.installRXTX()) > restart(); > else > handleError("I need the extension!"); > } > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jul 10 06:07:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 10 Jul 2006 06:07:23 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607081330.24381.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <200607081330.24381.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> Is the gnu.io namespace still necessary? I couldn't find the problem. >> >> Hi Pascal >> >> CommAPI is a little different in that it was grandfathered into the javax >> namespace with its own license at the time. >> >> It is my understanding that if CommAPI went through the JSR process, >> anyone would _clearly_ be able to implement a javax.comm package and RXTX >> would then be one of the first to do so. I believe Doug has expressed >> some interest in RXTX trying to work with the JSR process. >> >> Besides the license questions, there is the fact that RXTX has extensions >> to CommAPI which could cause confusion in the namespace. Not being a >> lawyer and *really* not liking to talk to lawyers in my free time, it is >> better to be safe than sorry. The lawyers tend to come in wolf packs >> when they do come. >> >> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay >> there as long as we are just geeks trying to figure out if a license does >> or does not allow us to implement in the javax.comm namespace. > > Nicely said. :) > > The whole point of namespaces is to create a universal registry of, in this > case, classes. This gnu.io namespace is very inconvenient. > > We feel the same way about lawyers. However I'd like to go into the details of > the license (see attachment) if you don't mind? > > The first license does not apply since RXTX does not use the software. The > second one at point 3 specifies our options. > >> 3. You may not modify the Java Platform Interface ("JPI", identified as >> classes contained within the "java" package or any subpackages of the >> "java" package), by creating additional classes within the JPI or otherwise >> causing the addition to or modification of the classes in the JPI. > > RXTX is a extension. > >> In the event that you create an additional class and associated API(s) >> which (i) extends the functionality of the Java platform, and (ii) is >> exposed to third party software developers for the purpose of developing >> additional software which invokes such additional API, you must promptly >> publish broadly an accurate specification for such API for free use by all >> developers. > > That's the way we operate. :) > >> You may not create, or authorize your licensees to create additional >> classes, interfaces, or subpackages that are in any way identified as >> "java", "javax", "sun" or similar convention as specified by Sun in any >> naming convention designation. > > They don't want additional components in the Communication API since they > don't want a mess in theire namespace. > > So we *can* use javax.comm for the core: > javax.comm.CommDriver > javax.comm.CommPort > javax.comm.CommPortIdentifier > javax.comm.CommPortOwnershipListener > javax.comm.NoSuchPortException > javax.comm.PortInUseException > javax.comm.UnsupportedCommOperationException > > ...and for the default hardware support: > javax.comm.SerialPort > javax.comm.SerialPortEvent > javax.comm.SerialPortEventListener > javax.comm.ParralelPort > javax.comm.ParralelPortEvent > javax.comm.ParralelPortEventListener > > ...but RXTX aditional hardware support has to go somewhere else like: > org.rxtx.RS485Port > org.rxtx.RS485PortEvent > org.rxtx.RS485PortEventListener > org.rxtx.I2CPort > org.rxtx.I2CPortEvent > org.rxtx.I2CPortEventListener > > Right? > The one thing this discussion does not cover is in SerialPort.java. See the extensions to commapi listed after the following line: /* ---------------------- end of commapi ------------------------ */ The intent is not to break commapi but it could be perceived as so. The extensions added have been placed there as requested by users of RXTX. It would be nice to discuss these modifications with Sun and perhaps have some added to the final version of CommAPI. Some of them may not make sense while others do. Some can not be implemented in a platform neutral fashion. It would not make sense for RXTX to just bring these into Sun's namespace without due process. This is why I am fundamentally apposed to people "poisoning" Sun's namespace with RXTX 2.1 although I understand that is not their intent. These modifications are not advertised and their use is discouraged. But they are there. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Mon Jul 10 06:47:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 10 Jul 2006 14:47:24 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607081330.24381.pascal@quies.net> Message-ID: <200607101447.25071.pascal@quies.net> Op maandag 10 juli 2006 14:07, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > > Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: > >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > >>> Is the gnu.io namespace still necessary? I couldn't find the problem. > >> > >> Hi Pascal > >> > >> CommAPI is a little different in that it was grandfathered into the > >> javax namespace with its own license at the time. > >> > >> It is my understanding that if CommAPI went through the JSR process, > >> anyone would _clearly_ be able to implement a javax.comm package and > >> RXTX would then be one of the first to do so. I believe Doug has > >> expressed some interest in RXTX trying to work with the JSR process. > >> > >> Besides the license questions, there is the fact that RXTX has > >> extensions to CommAPI which could cause confusion in the namespace. Not > >> being a lawyer and *really* not liking to talk to lawyers in my free > >> time, it is better to be safe than sorry. The lawyers tend to come in > >> wolf packs when they do come. > >> > >> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay > >> there as long as we are just geeks trying to figure out if a license > >> does or does not allow us to implement in the javax.comm namespace. > > > > Nicely said. :) > > > > The whole point of namespaces is to create a universal registry of, in > > this case, classes. This gnu.io namespace is very inconvenient. > > > > We feel the same way about lawyers. However I'd like to go into the > > details of the license (see attachment) if you don't mind? > > > > The first license does not apply since RXTX does not use the software. > > The second one at point 3 specifies our options. > > > >> 3. You may not modify the Java Platform Interface ("JPI", identified as > >> classes contained within the "java" package or any subpackages of the > >> "java" package), by creating additional classes within the JPI or > >> otherwise causing the addition to or modification of the classes in the > >> JPI. > > > > RXTX is a extension. > > > >> In the event that you create an additional class and associated API(s) > >> which (i) extends the functionality of the Java platform, and (ii) is > >> exposed to third party software developers for the purpose of developing > >> additional software which invokes such additional API, you must promptly > >> publish broadly an accurate specification for such API for free use by > >> all developers. > > > > That's the way we operate. :) > > > >> You may not create, or authorize your licensees to create additional > >> classes, interfaces, or subpackages that are in any way identified as > >> "java", "javax", "sun" or similar convention as specified by Sun in any > >> naming convention designation. > > > > They don't want additional components in the Communication API since they > > don't want a mess in theire namespace. > > > > So we *can* use javax.comm for the core: > > javax.comm.CommDriver > > javax.comm.CommPort > > javax.comm.CommPortIdentifier > > javax.comm.CommPortOwnershipListener > > javax.comm.NoSuchPortException > > javax.comm.PortInUseException > > javax.comm.UnsupportedCommOperationException > > > > ...and for the default hardware support: > > javax.comm.SerialPort > > javax.comm.SerialPortEvent > > javax.comm.SerialPortEventListener > > javax.comm.ParralelPort > > javax.comm.ParralelPortEvent > > javax.comm.ParralelPortEventListener > > > > ...but RXTX aditional hardware support has to go somewhere else like: > > org.rxtx.RS485Port > > org.rxtx.RS485PortEvent > > org.rxtx.RS485PortEventListener > > org.rxtx.I2CPort > > org.rxtx.I2CPortEvent > > org.rxtx.I2CPortEventListener > > > > Right? > > The one thing this discussion does not cover is in SerialPort.java. See > the extensions to commapi listed after the following line: > > /* ---------------------- end of commapi ------------------------ */ > > The intent is not to break commapi but it could be perceived as so. The > extensions added have been placed there as requested by users of RXTX. It > would be nice to discuss these modifications with Sun and perhaps have > some added to the final version of CommAPI. > > Some of them may not make sense while others do. Some can not be > implemented in a platform neutral fashion. It would not make sense > for RXTX to just bring these into Sun's namespace without due process. > > This is why I am fundamentally apposed to people "poisoning" Sun's > namespace with RXTX 2.1 although I understand that is not their intent. > > These modifications are not advertised and their use is discouraged. But > they are there. Hi Trent, So you are saying that gnu.io.SerialPort has some aditional methods over javax.comm.SerialPort? That does not change the API at all but it would be a problem if people would start using those methods in the javax.comm namespace in the same way like some people use the com.sun namespace. Could wrapper classes at javax.comm do the job? In that way RXTX stays in its namespace, javadoc can notice the aditional methods and the Communication API will be available as expected. From pascal at quies.net Mon Jul 10 06:48:09 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 10 Jul 2006 14:48:09 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> References: <200607081944.41123.pascal@quies.net> <200607091701.24661.pascal@quies.net> <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> Message-ID: <200607101448.09594.pascal@quies.net> Op maandag 10 juli 2006 10:53, schreef Joachim Buechse: > If all you want is to use RXTX, then: > > - put the native lib in your application directory > - include the javax.comm classes and RXTX classes in your application > classpath > - add the little stub class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > before the javax.comm classes in your application classpath. > > Alternatively you could also include the native lib in your > application jar, extract it at runtime to a temp file, load it with > System.load(). So java will load the native libraries automaticly if they are in the same directory as the Java application? Why isn't this very interresting information noticed in the documentation or is that too obvious and I simply didn't knew? From naranjo.manuel at gmail.com Mon Jul 10 06:56:10 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Mon, 10 Jul 2006 09:56:10 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> <44B1452C.60208@gmail.com> Message-ID: <44B24E6A.1010805@gmail.com> Trent Jarvi wrote: > On Sun, 9 Jul 2006, Manuel Naranjo wrote: > >> Trent Jarvi wrote: >>> Hi Manuel >>> >>> I do not know of another way. If you look at rxtx.org, even the >>> compiled version is hard to find, always late and not what you want. At >>> rxtx.org we just worry about the source and do a minimal effort to >>> provide binaries. >> Then that probes my theory, RXTX is much better than Java comm :) >> >>> I'd love nothing more than someone to start selling RXTX binaries or >>> working with us like Doug is to deliver the problems solved to users. >>> The Free here is Freedom. Not price. There is a need for services >>> rxtx.org is not able to provide well. That said I do not ever expect to >>> recieve anything. It just makes sense for everyone to work together and >>> compete outside of the source. >> I would like to contribute with the project giving support, I have >> worked using JSmooth and IzPack, and been able to make things that make >> RXTX easier to use and install. I will try to debug them, and send them >> to the mailing list, so you can do what ever you want with this :). >> Regards, > > > Hi Manuel > > This is interesting. There are some checks and balances that we do at > rxtx.org to make sure random material does not get in. It isn't personal > just a low bar that must be crossed. After you get your changes in, you > will know that others must cross the same bar. The basic question asked > is "Does this change reflect the intent and work of those that have > contributed to RXTX." > > Perhaps Doug is the best person to be the bar here. I'm more than willing > to admit my limitations and obviously this is a limitation I face. > > If Doug is willing to take this task, I'd be glad to give him CVS write > access which is more than overdue as he is the official maintainer now :) > He then could optionally give you write access if your changes are fine > and you represent a bar for new changes. I trust Doug. > > We do take the bar seriously as you can see. But it is not intended to > prevent fair use of RXTX or prevent facilitating new uses. If we don't > manage expectations here, there will be all sorts of problems and issues. > > -- > Trent Jarvi > tjarvi at qbang.org > > Trent, What I want to send you is not a modification to rxtx, it just a developers helper if you want to put a name to it. I have make an IzPack installer, which installs RXTX binaries depending on underlaying OS. And make an JSmooth warper that launches my app with out the need to have rxtx installed on the host JVM folder, it only need the RXTX to be in the bin\ of my app. I think this is more useful for Wiki than to the main project. Another thing I have experience in PalmOS programming, when ever I have time, I will investigate about the JNI of J2ME and try to port RXTX to Palm, I do not know when I will start, because I have a lot of work now. Regards, Manuel From christopher.dawes at the-logic-group.com Mon Jul 10 08:00:15 2006 From: christopher.dawes at the-logic-group.com (christopher.dawes@the-logic-group.com) Date: Mon, 10 Jul 2006 15:00:15 +0100 Subject: [Rxtx] Chris Dawes/Retaillogic/NISABA is out of the office. Message-ID: I will be out of the office starting 10/07/2006 and will not return until 11/07/2008. Hello, unfortunately I no longer work for The Logic Group, if you're trying to contact me on a work related issue please contact Pete Avery (pete.avery at the-logic-group.com) however if it is a personal matter please e-mail root at ants.me.uk or phone 07899 842 759. Thanks Christopher Dawes From tjarvi at qbang.org Mon Jul 10 08:19:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 10 Jul 2006 08:19:52 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607101447.25071.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607081330.24381.pascal@quies.net> <200607101447.25071.pascal@quies.net> Message-ID: On Mon, 10 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 10 juli 2006 14:07, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: >>>> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>>>> Is the gnu.io namespace still necessary? I couldn't find the problem. >>>> >>>> Hi Pascal >>>> >>>> CommAPI is a little different in that it was grandfathered into the >>>> javax namespace with its own license at the time. >>>> >>>> It is my understanding that if CommAPI went through the JSR process, >>>> anyone would _clearly_ be able to implement a javax.comm package and >>>> RXTX would then be one of the first to do so. I believe Doug has >>>> expressed some interest in RXTX trying to work with the JSR process. >>>> >>>> Besides the license questions, there is the fact that RXTX has >>>> extensions to CommAPI which could cause confusion in the namespace. Not >>>> being a lawyer and *really* not liking to talk to lawyers in my free >>>> time, it is better to be safe than sorry. The lawyers tend to come in >>>> wolf packs when they do come. >>>> >>>> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay >>>> there as long as we are just geeks trying to figure out if a license >>>> does or does not allow us to implement in the javax.comm namespace. >>> >>> Nicely said. :) >>> >>> The whole point of namespaces is to create a universal registry of, in >>> this case, classes. This gnu.io namespace is very inconvenient. >>> >>> We feel the same way about lawyers. However I'd like to go into the >>> details of the license (see attachment) if you don't mind? >>> >>> The first license does not apply since RXTX does not use the software. >>> The second one at point 3 specifies our options. >>> >>>> 3. You may not modify the Java Platform Interface ("JPI", identified as >>>> classes contained within the "java" package or any subpackages of the >>>> "java" package), by creating additional classes within the JPI or >>>> otherwise causing the addition to or modification of the classes in the >>>> JPI. >>> >>> RXTX is a extension. >>> >>>> In the event that you create an additional class and associated API(s) >>>> which (i) extends the functionality of the Java platform, and (ii) is >>>> exposed to third party software developers for the purpose of developing >>>> additional software which invokes such additional API, you must promptly >>>> publish broadly an accurate specification for such API for free use by >>>> all developers. >>> >>> That's the way we operate. :) >>> >>>> You may not create, or authorize your licensees to create additional >>>> classes, interfaces, or subpackages that are in any way identified as >>>> "java", "javax", "sun" or similar convention as specified by Sun in any >>>> naming convention designation. >>> >>> They don't want additional components in the Communication API since they >>> don't want a mess in theire namespace. >>> >>> So we *can* use javax.comm for the core: >>> javax.comm.CommDriver >>> javax.comm.CommPort >>> javax.comm.CommPortIdentifier >>> javax.comm.CommPortOwnershipListener >>> javax.comm.NoSuchPortException >>> javax.comm.PortInUseException >>> javax.comm.UnsupportedCommOperationException >>> >>> ...and for the default hardware support: >>> javax.comm.SerialPort >>> javax.comm.SerialPortEvent >>> javax.comm.SerialPortEventListener >>> javax.comm.ParralelPort >>> javax.comm.ParralelPortEvent >>> javax.comm.ParralelPortEventListener >>> >>> ...but RXTX aditional hardware support has to go somewhere else like: >>> org.rxtx.RS485Port >>> org.rxtx.RS485PortEvent >>> org.rxtx.RS485PortEventListener >>> org.rxtx.I2CPort >>> org.rxtx.I2CPortEvent >>> org.rxtx.I2CPortEventListener >>> >>> Right? >> >> The one thing this discussion does not cover is in SerialPort.java. See >> the extensions to commapi listed after the following line: >> >> /* ---------------------- end of commapi ------------------------ */ >> >> The intent is not to break commapi but it could be perceived as so. The >> extensions added have been placed there as requested by users of RXTX. It >> would be nice to discuss these modifications with Sun and perhaps have >> some added to the final version of CommAPI. >> >> Some of them may not make sense while others do. Some can not be >> implemented in a platform neutral fashion. It would not make sense >> for RXTX to just bring these into Sun's namespace without due process. >> >> This is why I am fundamentally apposed to people "poisoning" Sun's >> namespace with RXTX 2.1 although I understand that is not their intent. >> >> These modifications are not advertised and their use is discouraged. But >> they are there. > > Hi Trent, > > So you are saying that gnu.io.SerialPort has some aditional methods over > javax.comm.SerialPort? > That does not change the API at all but it would be a problem if people would > start using those methods in the javax.comm namespace in the same way like > some people use the com.sun namespace. > Could wrapper classes at javax.comm do the job? In that way RXTX stays in its > namespace, javadoc can notice the aditional methods and the Communication API > will be available as expected. Hi Pascal Yes. There are additional methods in gnu.io.SerialPort. We clearly mark those as extensions to CommAPI and discourage their use. There just isn't a way to get the intended functionality out of CommAPI without them. I think the right thing to do here may be to remove these methods to avoid unintentional polution of the javax namespace if people are going to be putting these classes in that namespace. The way people are using RXTX 2.1 is not the same as it was originally pictured. Thats fine but we need to be responsible. We need to prevent what could be a problem. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Mon Jul 10 08:57:10 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 10 Jul 2006 16:57:10 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101447.25071.pascal@quies.net> Message-ID: <200607101657.11223.pascal@quies.net> > Yes. There are additional methods in gnu.io.SerialPort. We clearly mark > those as extensions to CommAPI and discourage their use. There just isn't > a way to get the intended functionality out of CommAPI without them. If you don't want the users to use the methods then make them class protected (remove the word "public" before the method) and if you can't do that we might do the following: ---- SerialPort.java package javax.comm class SerialPort extends gnu.io.SerialPort { public void rxtxOnlyMethod() { throw new Error("Don't use this method here!\nUse gnu.io.SerialPort instead"); } ---- end From neville_seed at yahoo.com Mon Jul 10 10:20:12 2006 From: neville_seed at yahoo.com (neville seed) Date: Mon, 10 Jul 2006 09:20:12 -0700 (PDT) Subject: [Rxtx] writing first application and compiling In-Reply-To: Message-ID: <20060710162012.9888.qmail@web51015.mail.yahoo.com> Can anyone recommend a starting place for writing, compiling and uploading the first app, ie a simple hello world. It seems that the PALM SDK does not have a build environment. I am happy to develop under linux of windows. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From bob_tai2001 at yahoo.com Mon Jul 10 14:48:30 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 10 Jul 2006 13:48:30 -0700 (PDT) Subject: [Rxtx] Java installer Message-ID: <20060710204830.53745.qmail@web32810.mail.mud.yahoo.com> Hi Manuel, I found your post from the newsletter, hope I am not off topic. You mention there is a IZpack installer for Rxtx? I been waiting for this type of deplyment idea from Rxtx! is this documented in the web site? I am in windows environment but didn't want to create classpath for each workstation. I rather install :) I apologize for cutting into this topic. Bob > >Trent, >What I want to send you is not a modification to rxtx, it just a >developers helper if you want to put a name to it. I have make an IzPack installer, which installs RXTX binaries depending on underlaying OS. And make an JSmooth warper that launches my app with out the need to have rxtx installed on the host JVM folder, it only need the RXTX to be in the bin\ of my app. I think this is more useful for Wiki than to the main project. Another thing I have experience in PalmOS programming, when ever I have time, I will investigate about the JNI of J2ME and try to port RXTX to Palm, I do not know when I will start, because I have a lot of work now. Regards, Manuel __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From naranjo.manuel at gmail.com Mon Jul 10 15:10:21 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Mon, 10 Jul 2006 18:10:21 -0300 Subject: [Rxtx] Java installer In-Reply-To: <20060710204830.53745.qmail@web32810.mail.mud.yahoo.com> References: <20060710204830.53745.qmail@web32810.mail.mud.yahoo.com> Message-ID: <44B2C23D.8050901@gmail.com> Bob, Hi, not this is not a RXTX installer, I have develop an installer with IzPack which actually installs RXTX and my hole app, and I think this can be useful for RXTX users, Regards, Manuel > Hi Manuel, > > I found your post from the newsletter, hope I am not > off topic. You mention there is a IZpack installer > for Rxtx? I been waiting for this type of deplyment > idea from Rxtx! is this documented in the web site? > I am in windows environment but didn't want to create > classpath for each workstation. I rather install :) > > I apologize for cutting into this topic. > > Bob > >> Trent, >> What I want to send you is not a modification to > rxtx, it just a >> developers > helper if you want to put a name to it. I have make an > IzPack > installer, > which installs RXTX binaries depending on underlaying > OS. And make an > JSmooth warper that launches my app with out the need > to have rxtx > installed > on the host JVM folder, it only need the RXTX to be in > the bin\ of my > app. > I think this is more useful for Wiki than to the main > project. > Another thing I have experience in PalmOS programming, > when ever I have > time, > I will investigate about the JNI of J2ME and try to > port RXTX to Palm, > I do not know when I will start, because I have a lot > of work now. > Regards, > Manuel > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From brian at mbari.org Tue Jul 11 11:59:24 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 11 Jul 2006 10:59:24 -0700 Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: References: <44AC7902.8070407@adventnet.com> Message-ID: <485C28F0-CA08-4393-9E34-4C8E7F22C125@mbari.org> Hi Trent, On Jul 7, 2006, at 6:15 PM, Trent Jarvi wrote: > On Fri, 7 Jul 2006, Brian Schlining wrote: >> Also, for some command/response applications that I've tried with >> RXTX, I >> find that if I write to the serialport and then immediately try to >> read from >> it I get byte arrays filled with zeros, no matter what I set the >> recieveTimeout to (this has occurred on both Mac OS X and >> Windows). The >> workaround that I found was to very briefly put the I/O thread to >> sleep, like >> so: >> >> // DO set up and get I/O streams >> //in = serialPort.getInputStream(); >> //out = serialPort.getOutputStream(); >> >> out.write(someByteArray); >> try { >> Thread.sleep(10); >> catch (InterruptedException e) { >> // handle exception >> } >> in.read(anotherByteArray); >> >> Note: I've never had to put the thread to sleep using Java comm, >> only with >> RXTX. Anyone know why this might be? > > Hi Brian > > Interesting. Is this something that can be reproduced with a loopback > connection or something commonly available? I was unaware of this > behavior. Is it restricted to something that quickly opens, > writes, reads > and closes the port by chance? I've encountered this while using RXTX to talk to VCR's that support RS422; I've never tried it with a loopback connection. Note that connection setup is: PC[RS232] <---> RS232/422 Converter <---> VCR[RS422] The application I'm using it for opens a connection and keeps it open for the life of the application. It makes a lot of read and writes when running...probably about as fast as the VCR hardware supports; with Javacomm, I think it was on the order of an IO transaction every 40ms. However even if I perform an IO read/write every 2 seconds with RXTX I still encounter the same problem, so it's not a matter of the frequency of the IO transactions. If you want to look at the code a test example can be found at https://svn.sourceforge.net/svnroot/vars/trunk/vars/src/test/java/ test/org/mbari/vcr/SimpleReadRxtx.java. The actual production code is at https://svn.sourceforge.net/svnroot/vars/trunk/vars/src/main/java/ org/mbari/vcr/rs422/VCR.java. The methods that you might be interested in to see how the code is used are initComm(), sendCommand (), getResponse() in VCR.java. You'll notice Thread.sleep(IO_DELAY) sprinkled in the sendCommand() methods and getResponse(). Without that I get arrays of zeros returned. If the IO_DELAY is less than 15ms then sending commands works fine but reading the responses is not reliable; I mostly get problems when trying to read the last few bytes or a response. Again, everything works fine with Sun's Javacomm w/o the Thread.sleep() on windows. Also, FYI, I tried to run this on a Mac using RXTX 2.0, but I ran into thread synchronization issues. These issues went away when I switched to RXTX 2.1. Cheers B ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining MBARI Software Engineer brian at mbari.org (831)775-1855 http://www.mbari.org/staff/brian I went to the woods because I wished to live deliberately, to front only the essential facts of life, and see if I could not learn what it had to teach, and not, when I came to die, discover that I had not lived. ~ Henry Thoreau -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060711/59b607f3/attachment-0352.html From ajmas at sympatico.ca Wed Jul 12 13:46:51 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 12 Jul 2006 15:46:51 -0400 Subject: [Rxtx] writing first application and compiling Message-ID: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Take a look in the Wiki. I have added a couple of examples in there: http://rxtx.qbang.org/wiki/index.php/Examples Andre > > From: neville seed > Date: 2006/07/10 Mon PM 12:20:12 EDT > To: RXTX Developers and Users > Subject: [Rxtx] writing first application and compiling > > > Can anyone recommend a starting place for writing, > compiling and uploading the first app, ie a simple > hello world. > > It seems that the PALM SDK does not have a build > environment. I am happy to develop under linux of windows. > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Jul 12 19:22:25 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 12 Jul 2006 19:22:25 -0600 (MDT) Subject: [Rxtx] writing first application and compiling In-Reply-To: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Thank you for doing this Andre. I'm sure it will get well used by people learning. I think the old commapi examples are no longer easily available so these are really needed. On Wed, 12 Jul 2006, Andre-John Mas wrote: > Hi, > > Take a look in the Wiki. I have added a couple of examples in there: > > http://rxtx.qbang.org/wiki/index.php/Examples > > Andre > >> >> From: neville seed >> Date: 2006/07/10 Mon PM 12:20:12 EDT >> To: RXTX Developers and Users >> Subject: [Rxtx] writing first application and compiling >> >> >> Can anyone recommend a starting place for writing, >> compiling and uploading the first app, ie a simple >> hello world. >> >> It seems that the PALM SDK does not have a build >> environment. I am happy to develop under linux of windows. >> >> __________________________________________________ >> Do You Yahoo!? >> Tired of spam? Yahoo! Mail has the best spam protection around >> http://mail.yahoo.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Thu Jul 13 17:21:26 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Thu, 13 Jul 2006 19:21:26 -0400 Subject: [Rxtx] writing first application and compiling In-Reply-To: References: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <54D55D35-A143-43AA-AF03-B89ADE9B9246@sympatico.ca> No problems. I would also like to encourage anyone else to contribute other useful stuff they might have. On 12-Jul-06, at 21:22 , Trent Jarvi wrote: > > Thank you for doing this Andre. > > I'm sure it will get well used by people learning. I think the old > commapi examples are no longer easily available so these are really > needed. > > On Wed, 12 Jul 2006, Andre-John Mas wrote: > >> Hi, >> >> Take a look in the Wiki. I have added a couple of examples in there: >> >> http://rxtx.qbang.org/wiki/index.php/Examples >> >> Andre >> >>> >>> From: neville seed >>> Date: 2006/07/10 Mon PM 12:20:12 EDT >>> To: RXTX Developers and Users >>> Subject: [Rxtx] writing first application and compiling >>> >>> >>> Can anyone recommend a starting place for writing, >>> compiling and uploading the first app, ie a simple >>> hello world. >>> >>> It seems that the PALM SDK does not have a build >>> environment. I am happy to develop under linux of windows. >>> >>> __________________________________________________ >>> Do You Yahoo!? >>> Tired of spam? Yahoo! Mail has the best spam protection around >>> http://mail.yahoo.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Sat Jul 8 15:05:46 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sat, 08 Jul 2006 17:05:46 -0400 Subject: [Rxtx] License question. In-Reply-To: <200607082219.59514.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> Message-ID: <44B01E2A.9010207@suespammers.org> Pascal S. de Kloe wrote: > I thought of the same thing. The modified BSD license would certainly make it > more eazy and acceptable for Sun to include RXTX in theire products. > > Unfortunately in general people who chose GPL don't like other licenses. ;) i have a general preference for BSD, but i'll defend RXTX here. RXTX is LGPL, not GPL. they're different, look it up. richard From pascal at quies.net Sun Jul 16 17:40:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 17 Jul 2006 01:40:13 +0200 Subject: [Rxtx] Java installer In-Reply-To: <200607101657.11223.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> Message-ID: <200607170140.14116.pascal@quies.net> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: > > Yes. There are additional methods in gnu.io.SerialPort. We clearly mark > > those as extensions to CommAPI and discourage their use. There just > > isn't a way to get the intended functionality out of CommAPI without > > them. > > If you don't want the users to use the methods then make them class > protected (remove the word "public" before the method) and if you can't do > that we might do the following: > > ---- SerialPort.java > package javax.comm > > class SerialPort extends gnu.io.SerialPort { > > public void > rxtxOnlyMethod() { > throw new Error("Don't use this method here!\nUse gnu.io.SerialPort > instead"); > } > ---- end So how about it, Trent? Can we ship those classes with the next release? From pascal at quies.net Sun Jul 16 17:45:42 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 17 Jul 2006 01:45:42 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> References: <200607081944.41123.pascal@quies.net> <200607091701.24661.pascal@quies.net> <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> Message-ID: <200607170145.43156.pascal@quies.net> Op maandag 10 juli 2006 10:53, schreef Joachim Buechse: > Alternatively you could also include the native lib in your > application jar, extract it at runtime to a temp file, load it with > System.load(). That works indeed. :) I'll finish my "detection class" with such a loader and the RXTX package tomorrow. Then one can simply include the JAR in the classpath and run org.rxtx.CommunicationAPI.initialize() to make sure the API is available. From tjarvi at qbang.org Sun Jul 16 18:59:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 16 Jul 2006 18:59:06 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607170140.14116.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> <200607170140.14116.pascal@quies.net> Message-ID: On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>> Yes. There are additional methods in gnu.io.SerialPort. We clearly mark >>> those as extensions to CommAPI and discourage their use. There just >>> isn't a way to get the intended functionality out of CommAPI without >>> them. >> >> If you don't want the users to use the methods then make them class >> protected (remove the word "public" before the method) and if you can't do >> that we might do the following: >> >> ---- SerialPort.java >> package javax.comm >> >> class SerialPort extends gnu.io.SerialPort { >> >> public void >> rxtxOnlyMethod() { >> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >> instead"); >> } >> ---- end > > So how about it, Trent? > > Can we ship those classes with the next release? Hi Pascal I'm not going to say what people can or can not ship. I'm going to propose removing all of the above extensions from SerialPort.java. I think it is the best thing to do after cooling off a bit. But thats all I've considered at this point. I'm in favor of removing the extensions and staying in gnu.io which more importantly means staying at arms length from javax. I can remove the extensions, put a windows fix in, bump the versions and tag the releases without changing packages if everyone agrees to that. If people want to know why CommAPI has not gone through a JSR which makes it clear rxtx can be in javax.comm and explains how conformancy is determined, I do not think this is the right forum though you can freely do so. -- Trent Jarvi tjarvi at qbang.org From phillip at uow.edu.au Sun Jul 16 22:08:30 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Mon, 17 Jul 2006 14:08:30 +1000 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application" in Mac OSX Message-ID: Hi I downloaded RXTX 2.1-7r2 http://rxtx.org/ (latest download), found the MacOSX folder, manually installed RXTXcomm.jar and librxtxSerial.jnilib in / Library/Java/Extensions and manually setup /var/spool/ucp and became a member of it. I have tried two programs (both built in XCode - TwoWaySerialComm and SerialDemo). Both can find the serial ports but throw a 'port in use exception' with the error "Unknown Application" when I try to open the port. The following is part of the code of TwoWaySerialComm void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { System.out.println("Current owner is " + portIdentifier.getCurrentOwner()); System.out.println("Name is " + this.getClass().getName()); CommPort commPort = portIdentifier.open(this.getClass ().getName(),2000); //throws exception if ( commPort instanceof SerialPort ) The method connect is called from main: public static void main ( String[] args ) { try { listPorts(); (new TwoWaySerialComm()).connect("/dev/tty.KeySerial1"); The following is the console run log of a program TwoWaySerialComm [Session started at 2006-07-14 14:50:29 +1000.] Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.modem - Serial /dev/cu.modem - Serial /dev/tty.KeySerial1 - Serial /dev/cu.KeySerial1 - Serial /dev/tty.USA28X2b2P2.2 - Serial /dev/cu.USA28X2b2P2.2 - Serial 6 ports found Current owner is null Name is TwoWaySerialComm gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:48) at TwoWaySerialComm.main(TwoWaySerialComm.java:163) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at apple.launcher.LaunchRunner.run(LaunchRunner.java:88) at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:50) at apple.launcher.JavaApplicationLauncher.launch (JavaApplicationLauncher.java:52) TwoWaySerialComm has exited with status 0. I am stuck, Can you help me please. thanks Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From pascal at quies.net Mon Jul 17 06:12:09 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 17 Jul 2006 14:12:09 +0200 Subject: [Rxtx] JSR In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607170140.14116.pascal@quies.net> Message-ID: <200607171412.09571.pascal@quies.net> Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: > On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > > Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: > >>> Yes. There are additional methods in gnu.io.SerialPort. We clearly > >>> mark those as extensions to CommAPI and discourage their use. There > >>> just isn't a way to get the intended functionality out of CommAPI > >>> without them. > >> > >> If you don't want the users to use the methods then make them class > >> protected (remove the word "public" before the method) and if you can't > >> do that we might do the following: > >> > >> ---- SerialPort.java > >> package javax.comm > >> > >> class SerialPort extends gnu.io.SerialPort { > >> > >> public void > >> rxtxOnlyMethod() { > >> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort > >> instead"); > >> } > >> ---- end > > > > So how about it, Trent? > > > > Can we ship those classes with the next release? > > Hi Pascal > > I'm not going to say what people can or can not ship. I'm going to > propose removing all of the above extensions from SerialPort.java. I > think it is the best thing to do after cooling off a bit. > > But thats all I've considered at this point. I'm in favor of removing the > extensions and staying in gnu.io which more importantly means staying at > arms length from javax. > > I can remove the extensions, put a windows fix in, bump the versions and > tag the releases without changing packages if everyone agrees to that. > If people want to know why CommAPI has not gone through a JSR which makes > it clear rxtx can be in javax.comm and explains how conformancy is > determined, I do not think this is the right forum though you can freely > do so. Hi Trent, If I understand it correctly you don't want to put those javax.comm classes in the distribution until a JSR completes. :( Sun wants a JSR too to change the API: > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. How about it? I can spend 5 hours a week. From tjarvi at qbang.org Mon Jul 17 07:32:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 07:32:06 -0600 (MDT) Subject: [Rxtx] JSR In-Reply-To: <200607171412.09571.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607170140.14116.pascal@quies.net> <200607171412.09571.pascal@quies.net> Message-ID: On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: >> On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: >>> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>>> Yes. There are additional methods in gnu.io.SerialPort. We clearly >>>>> mark those as extensions to CommAPI and discourage their use. There >>>>> just isn't a way to get the intended functionality out of CommAPI >>>>> without them. >>>> >>>> If you don't want the users to use the methods then make them class >>>> protected (remove the word "public" before the method) and if you can't >>>> do that we might do the following: >>>> >>>> ---- SerialPort.java >>>> package javax.comm >>>> >>>> class SerialPort extends gnu.io.SerialPort { >>>> >>>> public void >>>> rxtxOnlyMethod() { >>>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>>> instead"); >>>> } >>>> ---- end >>> >>> So how about it, Trent? >>> >>> Can we ship those classes with the next release? >> >> Hi Pascal >> >> I'm not going to say what people can or can not ship. I'm going to >> propose removing all of the above extensions from SerialPort.java. I >> think it is the best thing to do after cooling off a bit. >> >> But thats all I've considered at this point. I'm in favor of removing the >> extensions and staying in gnu.io which more importantly means staying at >> arms length from javax. >> >> I can remove the extensions, put a windows fix in, bump the versions and >> tag the releases without changing packages if everyone agrees to that. >> If people want to know why CommAPI has not gone through a JSR which makes >> it clear rxtx can be in javax.comm and explains how conformancy is >> determined, I do not think this is the right forum though you can freely >> do so. > > Hi Trent, > > If I understand it correctly you don't want to put those javax.comm classes in > the distribution until a JSR completes. :( > > Sun wants a JSR too to change the API: >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. > > How about it? I can spend 5 hours a week. Yes. I'm all in favor of this. Dr. Doug Lyon is our fearless leader in these matters and has final say. He has asked everyone if they have an issue with going through the JSR. I have seen no responses though some may have responeded to him in private. I am now working for The MathWorks in a related field. To best represent the RXTX community, we have asked Doug to be the neutral maintainer. This does not mean he is taking on all the work like making releases. He has the ability to and the power. But thats not really spending his time efficiently. It does mean when there are decisions to be made that may have conflicts, he has final say. The easy solution :) is to bug Trent or Doug and see if they will just go into javax.comm namespace. The right solution is to work with Doug and try to get the JSR process completed. I'm willing to help too as time permits. I'm willing to work with Doug. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Jul 17 09:11:20 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 17 Jul 2006 11:11:20 -0400 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Message-ID: <20060717151120.RSBG13653.tomts36-srv.bellnexxia.net@smtp1.sympatico.ca> I am told that this is an issue that will be resolved in 2.1-8. The changes are already in version control, so you can use that. I have and it resolved the problem for me. Phillip McKerrow wrote: > > Hi > > I downloaded RXTX 2.1-7r2 http://rxtx.org/ (latest download), > found the MacOSX folder, > manually installed RXTXcomm.jar and librxtxSerial.jnilib in / > Library/Java/Extensions and > manually setup /var/spool/ucp and became a member of it. > > I have tried two programs (both built in XCode - TwoWaySerialComm and > SerialDemo). Both can find the serial ports but throw a 'port in use > exception' with the error "Unknown Application" when I try to open > the port. > > The following is part of the code of TwoWaySerialComm > void connect ( String portName ) throws Exception > { > CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > if ( portIdentifier.isCurrentlyOwned() ) > { > System.out.println("Error: Port is currently in use"); > } > else > { > System.out.println("Current owner is " + > portIdentifier.getCurrentOwner()); > System.out.println("Name is " + this.getClass().getName()); > CommPort commPort = portIdentifier.open(this.getClass > ().getName(),2000); //throws exception > > if ( commPort instanceof SerialPort ) > > > The method connect is called from main: > public static void main ( String[] args ) > { > try > { > listPorts(); > (new TwoWaySerialComm()).connect("/dev/tty.KeySerial1"); > > > The following is the console run log of a program TwoWaySerialComm > [Session started at 2006-07-14 14:50:29 +1000.] > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > /dev/tty.modem - Serial > /dev/cu.modem - Serial > /dev/tty.KeySerial1 - Serial > /dev/cu.KeySerial1 - Serial > /dev/tty.USA28X2b2P2.2 - Serial > /dev/cu.USA28X2b2P2.2 - Serial > 6 ports found > Current owner is null > Name is TwoWaySerialComm > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at TwoWaySerialComm.connect(TwoWaySerialComm.java:48) > at TwoWaySerialComm.main(TwoWaySerialComm.java:163) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at apple.launcher.LaunchRunner.run(LaunchRunner.java:88) > at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:50) > at apple.launcher.JavaApplicationLauncher.launch > (JavaApplicationLauncher.java:52) > > TwoWaySerialComm has exited with status 0. > > I am stuck, Can you help me please. > > thanks > Phillip > > > ---------------------------------------------------------------------- > Phillip McKerrow http:// > www.uow.edu.au/~phillip/ > School of Information Technology and Computer Science > University of Wollongong * > Northfields Avenue, * * > Wollongong, NSW, 2522. + > AUSTRALIA * the land of the > southern cross > tel : +61 2 4221 3771 fax : +61 2 4221 4170 > > God so loved the world that he gave his one and only Son (Jesus), > that whoever believes in him shall not perish but have eternal life. > John 3:16 > ---------------------------------------------------------------------- > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Mon Jul 17 10:34:14 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 17 Jul 2006 12:34:14 -0400 Subject: [Rxtx] summary of issues In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607170140.14116.pascal@quies.net> <200607171412.09571.pascal@quies.net> Message-ID: Hi All, As I see it, at this stage of the discussion, I think it would be helpful to summarize the concerns. Let me see if I can get this straight, and please correct me, if I am wrong: 1. Sun is making no progress on improving the CommAPI spec. 2. We are seeking to reinvigorate a JSR for the CommAPI in order to keep sun involved. 3. Meanwhile we are extending the RXTX API, with non- commAPI improvements. 4. People are worried that the improvements will be non-portable, when the commAPI re-activates. 5. I have asked for feedback on the JSR approach and obtained zero response. 6. My limited imagination does not see any drawback to taking the JSR approach (except, possibly, from the overhead of a committee, or some license issue that I do not understand). 7. http://www.jcp.org/en/jsr/detail?id=922 shows the status of the JSR now. Status: Withdrawn The sun contact is: vincent.zhang at sun.com I have written to Vincent at Sun to ask him what would be involved with reactivation of JSR 922. If I hear back I will let you know. If there are any objections or suggestions, please let me know. Thanks! - Doug >On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > >> Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: >>> On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: >>>> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>>>> Yes. There are additional methods in gnu.io.SerialPort. We clearly >>>>>> mark those as extensions to CommAPI and discourage their use. There >>>>>> just isn't a way to get the intended functionality out of CommAPI >>>>>> without them. >>>>> >>>>> If you don't want the users to use the methods then make them class >>>>> protected (remove the word "public" before the method) and if you can't >>>>> do that we might do the following: >>>>> >>>>> ---- SerialPort.java >>>>> package javax.comm >>>>> >>>>> class SerialPort extends gnu.io.SerialPort { >>>>> >>>>> public void >>>>> rxtxOnlyMethod() { >>>>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>>>> instead"); >>>>> } >>>>> ---- end >>>> >>>> So how about it, Trent? >>>> >>>> Can we ship those classes with the next release? >>> >>> Hi Pascal >>> >>> I'm not going to say what people can or can not ship. I'm going to >>> propose removing all of the above extensions from SerialPort.java. I >>> think it is the best thing to do after cooling off a bit. >>> >>> But thats all I've considered at this point. I'm in favor of removing the >>> extensions and staying in gnu.io which more importantly means staying at >>> arms length from javax. >>> >>> I can remove the extensions, put a windows fix in, bump the versions and >>> tag the releases without changing packages if everyone agrees to that. >>> If people want to know why CommAPI has not gone through a JSR which makes >>> it clear rxtx can be in javax.comm and explains how conformancy is >>> determined, I do not think this is the right forum though you can freely >>> do so. >> >> Hi Trent, >> >> If I understand it correctly you don't want to put those >>javax.comm classes in >> the distribution until a JSR completes. :( >> >> Sun wants a JSR too to change the API: >>> Ultimately the COMMAPI would be better served if a Java >>> Community Process JSR (http://www.jcp.org) was opened and >>> the COMMAPI was rearchitected to provide a more pluggable >>> framework to improve cross-platform support. Such an >>> architecture would embody a better defined and better >>> documented SPI interface, including a way for comm. ports >>> to be revealed to the client application through the API >>> via platform-aware plugins. Similarly, native code used >>> to access comm port in general could be handled more >>> flexibly using a plugin model, whereby on any platform, >>> multiple native modules could be in use simultaneously. >> >> How about it? I can spend 5 hours a week. > >Yes. I'm all in favor of this. Dr. Doug Lyon is our fearless leader in >these matters and has final say. He has asked everyone if they have an >issue with going through the JSR. I have seen no responses though some >may have responeded to him in private. > >I am now working for The MathWorks in a related field. To best represent >the RXTX community, we have asked Doug to be the neutral maintainer. >This does not mean he is taking on all the work like making releases. He >has the ability to and the power. But thats not really spending his time >efficiently. It does mean when there are decisions to be made that may >have conflicts, he has final say. > >The easy solution :) is to bug Trent or Doug and see if they will just go >into javax.comm namespace. The right solution is to work with Doug and >try to get the JSR process completed. I'm willing to help too as time >permits. > >I'm willing to work with Doug. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jul 17 11:31:58 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 17 Jul 2006 13:31:58 -0400 Subject: [Rxtx] JSR Message-ID: <20060717173158.USWI24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> In the meantime could these methods not be added to a child class. This way the extra functionality can be provided, but you would have to explictly check to see of the class is an RXTX specifc interface. For example: class RxTxCommPort extends CommPort { //RxTx specific methods } CommPort port = commPortIdentifierInstance.open(...); if ( port instanceof RxTxCommPort ) { // do RxTx specifc stuff } // continue doing usual stuff Andre > > From: "Pascal S. de Kloe" > Date: 2006/07/17 Mon AM 08:12:09 EDT > To: RXTX Developers and Users > Subject: [Rxtx] JSR > > Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: > > On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > > > Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: > > >>> Yes. There are additional methods in gnu.io.SerialPort. We clearly > > >>> mark those as extensions to CommAPI and discourage their use. There > > >>> just isn't a way to get the intended functionality out of CommAPI > > >>> without them. > > >> > > >> If you don't want the users to use the methods then make them class > > >> protected (remove the word "public" before the method) and if you can't > > >> do that we might do the following: > > >> > > >> ---- SerialPort.java > > >> package javax.comm > > >> > > >> class SerialPort extends gnu.io.SerialPort { > > >> > > >> public void > > >> rxtxOnlyMethod() { > > >> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort > > >> instead"); > > >> } > > >> ---- end > > > > > > So how about it, Trent? > > > > > > Can we ship those classes with the next release? > > > > Hi Pascal > > > > I'm not going to say what people can or can not ship. I'm going to > > propose removing all of the above extensions from SerialPort.java. I > > think it is the best thing to do after cooling off a bit. > > > > But thats all I've considered at this point. I'm in favor of removing the > > extensions and staying in gnu.io which more importantly means staying at > > arms length from javax. > > > > I can remove the extensions, put a windows fix in, bump the versions and > > tag the releases without changing packages if everyone agrees to that. > > If people want to know why CommAPI has not gone through a JSR which makes > > it clear rxtx can be in javax.comm and explains how conformancy is > > determined, I do not think this is the right forum though you can freely > > do so. > > Hi Trent, > > If I understand it correctly you don't want to put those javax.comm classes in > the distribution until a JSR completes. :( > > Sun wants a JSR too to change the API: > > Ultimately the COMMAPI would be better served if a Java > > Community Process JSR (http://www.jcp.org) was opened and > > the COMMAPI was rearchitected to provide a more pluggable > > framework to improve cross-platform support. Such an > > architecture would embody a better defined and better > > documented SPI interface, including a way for comm. ports > > to be revealed to the client application through the API > > via platform-aware plugins. Similarly, native code used > > to access comm port in general could be handled more > > flexibly using a plugin model, whereby on any platform, > > multiple native modules could be in use simultaneously. > > How about it? I can spend 5 hours a week. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From joachim at buechse.de Mon Jul 17 11:59:19 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 17 Jul 2006 19:59:19 +0200 Subject: [Rxtx] Bumping versions In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> <200607170140.14116.pascal@quies.net> Message-ID: <6ABAF770-41AE-4BA0-800D-2DCC8025FCA8@buechse.de> Hello Trent, I would appreciate if we could get to a version 2.1.8. In fact as several recent posting have shown, almost anyone working on OSX would appreciate getting there. Should anything be removed before that? I dont know. There is nothing wrong with having 2.1.9 following shortly after 2.1.8. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 17.07.2006, at 02:59, Trent Jarvi wrote: > On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > >> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>> Yes. There are additional methods in gnu.io.SerialPort. We >>>> clearly mark >>>> those as extensions to CommAPI and discourage their use. There >>>> just >>>> isn't a way to get the intended functionality out of CommAPI >>>> without >>>> them. >>> >>> If you don't want the users to use the methods then make them class >>> protected (remove the word "public" before the method) and if you >>> can't do >>> that we might do the following: >>> >>> ---- SerialPort.java >>> package javax.comm >>> >>> class SerialPort extends gnu.io.SerialPort { >>> >>> public void >>> rxtxOnlyMethod() { >>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>> instead"); >>> } >>> ---- end >> >> So how about it, Trent? >> >> Can we ship those classes with the next release? > > Hi Pascal > > I'm not going to say what people can or can not ship. I'm going to > propose removing all of the above extensions from SerialPort.java. I > think it is the best thing to do after cooling off a bit. > > But thats all I've considered at this point. I'm in favor of > removing the > extensions and staying in gnu.io which more importantly means > staying at > arms length from javax. > > I can remove the extensions, put a windows fix in, bump the > versions and > tag the releases without changing packages if everyone agrees to that. > If people want to know why CommAPI has not gone through a JSR which > makes > it clear rxtx can be in javax.comm and explains how conformancy is > determined, I do not think this is the right forum though you can > freely > do so. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jul 17 12:40:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 12:40:32 -0600 (MDT) Subject: [Rxtx] Bumping versions In-Reply-To: <6ABAF770-41AE-4BA0-800D-2DCC8025FCA8@buechse.de> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> <200607170140.14116.pascal@quies.net> <6ABAF770-41AE-4BA0-800D-2DCC8025FCA8@buechse.de> Message-ID: Hi Joachim I will work with you towards that. I'm going to the Linux Symposium this week which should mean I have time to tinker. I'll work on rxtx while riding in a carpool to Ottawa. On Mon, 17 Jul 2006, Joachim Buechse wrote: > Hello Trent, > > I would appreciate if we could get to a version 2.1.8. In fact as > several recent posting have shown, almost anyone working on OSX would > appreciate getting there. Should anything be removed before that? I > dont know. There is nothing wrong with having 2.1.9 following shortly > after 2.1.8. > > Regards, > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 17.07.2006, at 02:59, Trent Jarvi wrote: > >> On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: >> >>> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>>> Yes. There are additional methods in gnu.io.SerialPort. We >>>>> clearly mark >>>>> those as extensions to CommAPI and discourage their use. There >>>>> just >>>>> isn't a way to get the intended functionality out of CommAPI >>>>> without >>>>> them. >>>> >>>> If you don't want the users to use the methods then make them class >>>> protected (remove the word "public" before the method) and if you >>>> can't do >>>> that we might do the following: >>>> >>>> ---- SerialPort.java >>>> package javax.comm >>>> >>>> class SerialPort extends gnu.io.SerialPort { >>>> >>>> public void >>>> rxtxOnlyMethod() { >>>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>>> instead"); >>>> } >>>> ---- end >>> >>> So how about it, Trent? >>> >>> Can we ship those classes with the next release? >> >> Hi Pascal >> >> I'm not going to say what people can or can not ship. I'm going to >> propose removing all of the above extensions from SerialPort.java. I >> think it is the best thing to do after cooling off a bit. >> >> But thats all I've considered at this point. I'm in favor of >> removing the >> extensions and staying in gnu.io which more importantly means >> staying at >> arms length from javax. >> >> I can remove the extensions, put a windows fix in, bump the >> versions and >> tag the releases without changing packages if everyone agrees to that. >> If people want to know why CommAPI has not gone through a JSR which >> makes >> it clear rxtx can be in javax.comm and explains how conformancy is >> determined, I do not think this is the right forum though you can >> freely >> do so. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pascal at quies.net Mon Jul 17 17:54:56 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Tue, 18 Jul 2006 01:54:56 +0200 Subject: [Rxtx] summary of issues In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> Message-ID: <200607180154.56359.pascal@quies.net> Op maandag 17 juli 2006 18:34, schreef Dr. Douglas Lyon: > Hi All, > As I see it, at this stage of the discussion, I think it would be helpful > to summarize the concerns. Let me see if I can get this > straight, and please correct me, if I am wrong: Thank you. :) > 1. Sun is making no progress on improving the CommAPI spec. > 2. We are seeking to reinvigorate a JSR for the CommAPI in order > to keep sun involved. Sun wants a JSR becouse they have other concerns than a almost obsolete piece of hardware. > 3. Meanwhile we are extending the RXTX API, with non- > commAPI improvements. > 4. People are worried that the improvements will be non-portable, > when the commAPI re-activates. > 5. I have asked for feedback on the JSR approach and obtained > zero response. > 6. My limited imagination does not see any drawback to taking > the JSR approach (except, possibly, from the overhead of a committee, or > some license issue that I do not understand). > 7. http://www.jcp.org/en/jsr/detail?id=922 shows the status of the JSR now. > Status: Withdrawn > The sun contact is: vincent.zhang at sun.com > I have written to Vincent at Sun to ask him what would be involved with > reactivation of JSR 922. We don't need to communicate with the employees but we need a plan. We need a working implementation with a free license. They have offered us some ideas like in the 2.0.3 README (see attachment). Is there a plan based on the differences of the various platforms? Is there a API purposal? Is there a plan of the JNI? If not I am willing to help. I can write/represent the POSIX part with special interrest of the free UNIX systems. -------------- next part -------------- DISTRIBUTION NOTES: This distribution contains the comm.jar file original part of the COMMAPI 2.0.3 release. The 2.0.3 release itself is no longer distributed. comm.jar, which contains the comm API java class files (eg. Sun's binary implementation of the interface classes), is being made available, unsupported, with no obligation to fix bugs, at the request of the RXTX project. The RxTx project (http://www.rxtx.org), uses the comm.jar class files, but provides their own native library components to provide support for other platforms. The 2.0.3 comm.jar is being provided in this way because as of COMMAPI 3.x, the java binary implementation forked and became incompatible with the RxTx project's native code. Due to the lack of a clear business case, and to resource constraints, no additional resources are being provided to provide an alternative engineering solution at the time of writing. RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: Ultimately the COMMAPI would be better served if a Java Community Process JSR (http://www.jcp.org) was opened and the COMMAPI was rearchitected to provide a more pluggable framework to improve cross-platform support. Such an architecture would embody a better defined and better documented SPI interface, including a way for comm. ports to be revealed to the client application through the API via platform-aware plugins. Similarly, native code used to access comm port in general could be handled more flexibly using a plugin model, whereby on any platform, multiple native modules could be in use simultaneously. Since there are now various ways serial ports can be implemented and accessed, modular comm. port JNI native libraries would be of benefit insofar as removing the burden of over-generalization from any single native component, or inversely, by relieving the implicit constraint that comm. drivers be accessed only via a monolithic mechanism, such as the UNIX vnode interface. paul.klissner at sun.com 6/10/06 From tjarvi at qbang.org Mon Jul 17 18:24:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 18:24:47 -0600 (MDT) Subject: [Rxtx] summary of issues In-Reply-To: <200607180154.56359.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607180154.56359.pascal@quies.net> Message-ID: On Tue, 18 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 17 juli 2006 18:34, schreef Dr. Douglas Lyon: >> Hi All, >> As I see it, at this stage of the discussion, I think it would be helpful >> to summarize the concerns. Let me see if I can get this >> straight, and please correct me, if I am wrong: > > Thank you. :) > >> 1. Sun is making no progress on improving the CommAPI spec. >> 2. We are seeking to reinvigorate a JSR for the CommAPI in order >> to keep sun involved. > > Sun wants a JSR becouse they have other concerns than a almost obsolete piece > of hardware. > >> 3. Meanwhile we are extending the RXTX API, with non- >> commAPI improvements. >> 4. People are worried that the improvements will be non-portable, >> when the commAPI re-activates. >> 5. I have asked for feedback on the JSR approach and obtained >> zero response. >> 6. My limited imagination does not see any drawback to taking >> the JSR approach (except, possibly, from the overhead of a committee, or >> some license issue that I do not understand). >> 7. http://www.jcp.org/en/jsr/detail?id=922 shows the status of the JSR now. >> Status: Withdrawn >> The sun contact is: vincent.zhang at sun.com >> I have written to Vincent at Sun to ask him what would be involved with >> reactivation of JSR 922. > > We don't need to communicate with the employees but we need a plan. We need a > working implementation with a free license. They have offered us some ideas > like in the 2.0.3 README (see attachment). > > Is there a plan based on the differences of the various platforms? Is there a > API purposal? Is there a plan of the JNI? > > If not I am willing to help. I can write/represent the POSIX part with special > interrest of the free UNIX systems. > Not to put words in your mouth but it sounds like you would rather not be in javax.comm namespace at all and do something like a VFS for serial ports as suggested in the readme? Maybe call it a VCS for character streams. That sounds like a major version change rather than an incremental change. So a vote for cutting the ropes and floating in the current? rxtx 3.0 or whatever abandoning current application requirements and perhaps largely rewriting rxtx.. Thats possible and could happen at the same time. An email to Vincent sounds polite enough at this stage. -- Trent Jarvi tjarvi at qbang.org From phillip at uow.edu.au Mon Jul 17 19:33:19 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Tue, 18 Jul 2006 11:33:19 +1000 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application in Mac OSX" Message-ID: <7DBE5FEB-EA06-45BC-ABBE-A9990281E32D@uow.edu.au> Hi We found a workaround - Problem fixed by creating /var/lock directory - seems that they changed the directory from /var/spool/uucp for the lock file but didn't update the documentation. audfg5:~ phillip$ sudo mkdir /var/lock Password: audfg5:~ phillip$ ls -ld /var/lock drwxr-xr-x 2 root wheel 68 Jul 18 09:51 /var/lock audfg5:~ phillip$ sudo chmod 775 /var/lock audfg5:~ phillip$ ls -ld /var/lock drwxrwxr-x 2 root wheel 68 Jul 18 09:51 /var/lock audfg5:~ phillip$ sudo chgrp uucp /var/lock audfg5:~ phillip$ ls -ld /var/lock drwxrwxr-x 2 root uucp 68 Jul 18 09:51 /var/lock audfg5:~ phillip$ ls -l /var/lock total 8 -r--r--r-- 1 phillip uucp 11 Jul 18 09:58 LK.003.009.002 Now both programs work and we get a warning on the console: RXTX Warning: Removing stale lock file. /var/lock/LK.003.009.002 Do we still need the /var/spool/uucp directory?? thanks Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From tjarvi at qbang.org Mon Jul 17 19:40:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 19:40:26 -0600 (MDT) Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application in Mac OSX" In-Reply-To: <7DBE5FEB-EA06-45BC-ABBE-A9990281E32D@uow.edu.au> References: <7DBE5FEB-EA06-45BC-ABBE-A9990281E32D@uow.edu.au> Message-ID: On Tue, 18 Jul 2006, Phillip McKerrow wrote: > Hi > We found a workaround - Problem fixed by creating /var/lock directory > - seems that they changed the directory from /var/spool/uucp for the > lock file but didn't update the documentation. > > audfg5:~ phillip$ sudo mkdir /var/lock > Password: > audfg5:~ phillip$ ls -ld /var/lock > drwxr-xr-x 2 root wheel 68 Jul 18 09:51 /var/lock > audfg5:~ phillip$ sudo chmod 775 /var/lock > audfg5:~ phillip$ ls -ld /var/lock > drwxrwxr-x 2 root wheel 68 Jul 18 09:51 /var/lock > audfg5:~ phillip$ sudo chgrp uucp /var/lock > audfg5:~ phillip$ ls -ld /var/lock > drwxrwxr-x 2 root uucp 68 Jul 18 09:51 /var/lock > audfg5:~ phillip$ ls -l /var/lock > total 8 > -r--r--r-- 1 phillip uucp 11 Jul 18 09:58 LK.003.009.002 > > Now both programs work and we get a warning on the console: > RXTX Warning: Removing stale lock file. /var/lock/LK.003.009.002 > > Do we still need the /var/spool/uucp directory?? > [The new code in CVS will not use Lockfiles on Mac OS X.] The above can happen if you did not close the port before exiting the program. The warning is harmless. RXTX notes that the old program is not running and removes the stale lockfile. -- Trent Jarvi tjarvi at qbang.org From phillip at uow.edu.au Tue Jul 18 01:07:40 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Tue, 18 Jul 2006 17:07:40 +1000 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX Message-ID: Hi I am trying to run a precompiled Java program (JavaKit for setting up the TINI processor over a serial link from http://www.maxim-ic.com/ products/tini/software/downloads.cfm). It uses javax.comm for serial communication. 1. I downloaded the Sparc Solaris version of comm.jar and placed it in /Library/Java/Extensions with RXTXcomm.jar and librxtxSerial.jnilib. 2. I added a javax.com.properties file to /System/Library/Frameworks/ JavaVM.framework/Versions/CurrentJDK/Home/lib It is a text file with one line Driver=gnu.io.RXTXCommDriver 3. When I execute JavaKit it crashes with the following console output audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver (CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:109) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Exception in thread "main" java.lang.UnsatisfiedLinkError: isSessionActive at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts (Portmapping.java:155) at com.sun.comm.Portmapping.refreshPortDatabase (Portmapping.java:100) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:138) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ Home/lib/ext instead of /Library/Java/Extensions it makes no difference: If I use the generic version of comm,jar file from Sun, JavaKit brings up a gui but can't find the serial ports: The console output is: audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while loading driver gnu.io.RXTXCommDriver Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no SolarisSerialParallel in java.library.path Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while loading driver com.sun.comm.SolarisDriver Am I doing something wrong in my efforts to get this going? Should I have another file loaded somewhere or have I run into a bug in RXTX?? thanks again for your help. Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From joachim at buechse.de Tue Jul 18 02:53:38 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 18 Jul 2006 10:53:38 +0200 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: References: Message-ID: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> 2.1.7 is the gnu.io.* version. You need 2.0.7 ie the javax.comm.* version. --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 18.07.2006, at 09:07, Phillip McKerrow wrote: > Hi > > I am trying to run a precompiled Java program (JavaKit for setting up > the TINI processor over a serial link from http://www.maxim-ic.com/ > products/tini/software/downloads.cfm). It uses javax.comm for serial > communication. > > 1. I downloaded the Sparc Solaris version of comm.jar and placed it > in /Library/Java/Extensions with RXTXcomm.jar and > librxtxSerial.jnilib. > > 2. I added a javax.com.properties file to /System/Library/Frameworks/ > JavaVM.framework/Versions/CurrentJDK/Home/lib > It is a text file with one line > Driver=gnu.io.RXTXCommDriver > > 3. When I execute JavaKit it crashes with the following console output > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver > (CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:109) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > Exception in thread "main" java.lang.UnsatisfiedLinkError: > isSessionActive > at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > at com.sun.comm.Portmapping.registerCommPorts > (Portmapping.java:155) > at com.sun.comm.Portmapping.refreshPortDatabase > (Portmapping.java:100) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:138) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > > If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ > Home/lib/ext > instead of /Library/Java/Extensions it makes no difference: > > If I use the generic version of comm,jar file from Sun, JavaKit > brings up a gui but can't find the serial ports: The console > output is: > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while > loading driver gnu.io.RXTXCommDriver > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no > SolarisSerialParallel in java.library.path > Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while > loading driver com.sun.comm.SolarisDriver > > > Am I doing something wrong in my efforts to get this going? Should I > have another file loaded somewhere or have I run into a bug in RXTX?? > > thanks again for your help. > > Phillip > > > ---------------------------------------------------------------------- > Phillip McKerrow http:// > www.uow.edu.au/~phillip/ > School of Information Technology and Computer Science > University of Wollongong * > Northfields Avenue, * * > Wollongong, NSW, 2522. + > AUSTRALIA * the land of the > southern cross > tel : +61 2 4221 3771 fax : +61 2 4221 > 4170 > > God so loved the world that he gave his one and only Son (Jesus), > that whoever believes in him shall not perish but have eternal life. > John 3:16 > ---------------------------------------------------------------------- > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alex at det.ua.pt Tue Jul 18 03:29:15 2006 From: alex at det.ua.pt (Alexandre Mota) Date: Tue, 18 Jul 2006 10:29:15 +0100 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: Message-ID: Hello Edit the JavaKit.java in order to use the gnu.io and compile everything. If you have the RXTX already installed and working it will work. I am using it on linux and windows with jdk 1.5. Best Regards Alexandre -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Phillip McKerrow Sent: ter?a-feira, 18 de Julho de 2006 8:08 To: rxtx at qbang.org Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX Hi I am trying to run a precompiled Java program (JavaKit for setting up the TINI processor over a serial link from http://www.maxim-ic.com/ products/tini/software/downloads.cfm). It uses javax.comm for serial communication. 1. I downloaded the Sparc Solaris version of comm.jar and placed it in /Library/Java/Extensions with RXTXcomm.jar and librxtxSerial.jnilib. 2. I added a javax.com.properties file to /System/Library/Frameworks/ JavaVM.framework/Versions/CurrentJDK/Home/lib It is a text file with one line Driver=gnu.io.RXTXCommDriver 3. When I execute JavaKit it crashes with the following console output audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver (CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:109) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Exception in thread "main" java.lang.UnsatisfiedLinkError: isSessionActive at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts (Portmapping.java:155) at com.sun.comm.Portmapping.refreshPortDatabase (Portmapping.java:100) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:138) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ Home/lib/ext instead of /Library/Java/Extensions it makes no difference: If I use the generic version of comm,jar file from Sun, JavaKit brings up a gui but can't find the serial ports: The console output is: audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while loading driver gnu.io.RXTXCommDriver Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no SolarisSerialParallel in java.library.path Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while loading driver com.sun.comm.SolarisDriver Am I doing something wrong in my efforts to get this going? Should I have another file loaded somewhere or have I run into a bug in RXTX?? thanks again for your help. Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jul 18 04:52:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 18 Jul 2006 04:52:02 -0600 (MDT) Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: References: Message-ID: On Tue, 18 Jul 2006, Phillip McKerrow wrote: > Hi > > I am trying to run a precompiled Java program (JavaKit for setting up > the TINI processor over a serial link from http://www.maxim-ic.com/ > products/tini/software/downloads.cfm). It uses javax.comm for serial > communication. > > 1. I downloaded the Sparc Solaris version of comm.jar and placed it > in /Library/Java/Extensions with RXTXcomm.jar and > librxtxSerial.jnilib. > > 2. I added a javax.com.properties file to /System/Library/Frameworks/ > JavaVM.framework/Versions/CurrentJDK/Home/lib > It is a text file with one line > Driver=gnu.io.RXTXCommDriver > > 3. When I execute JavaKit it crashes with the following console output > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver > (CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:109) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > Exception in thread "main" java.lang.UnsatisfiedLinkError: > isSessionActive > at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > at com.sun.comm.Portmapping.registerCommPorts > (Portmapping.java:155) > at com.sun.comm.Portmapping.refreshPortDatabase > (Portmapping.java:100) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:138) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > > If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ > Home/lib/ext > instead of /Library/Java/Extensions it makes no difference: > > If I use the generic version of comm,jar file from Sun, JavaKit > brings up a gui but can't find the serial ports: The console output is: > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while > loading driver gnu.io.RXTXCommDriver > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no > SolarisSerialParallel in java.library.path > Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while > loading driver com.sun.comm.SolarisDriver > > > Am I doing something wrong in my efforts to get this going? Should I > have another file loaded somewhere or have I run into a bug in RXTX?? > > thanks again for your help. > RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for that. Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Tue Jul 18 16:14:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 18 Jul 2006 18:14:38 -0400 Subject: [Rxtx] jcp and jsr In-Reply-To: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> References: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> Message-ID: Hi All, I have been in touch with: Paul Klissner Please read what Paul writes below. I am not sure, but this might be a good chance for the RXTX group to take action. As to what we should write for the JSR, I am thinking about something in the javax.comm namespace. What is the collective feeling about that? Thanks! - Doug Paul writes: "I think a JSR should be opened, but I don't see any point in proceeding with 922, which never formed and expert group, or provided a specification or reference implementation. It was a placeholder, and the title wasn't even relevant. I think we should discuss our ideas about what we'd like to accomplish and javax.comm and see if we can reach an agreement. You would submit a JSR through the Java Community Process, and if you do, I'd like to represent Sun on the expert group, and contribute to the effort. We may want to start with a fresh specification, borrowing what we want from the current javax.com, adding what we need, and creating a reference implementation. Paul" From pascal at quies.net Tue Jul 18 18:12:26 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 02:12:26 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> Message-ID: <200607190212.27131.pascal@quies.net> Hi Dr., The namespace is the last thing we need to worry about. Let's start with the common goals. For instance the current API is not very object oriented. It might be a good idea to have a static set of objects available representing every supported port available on the system in realtime. Each object should clearly know its own state and its capabilities. To get a port there could be a method like synchronized void connect(PortUser) where PortUser is a interface which handles the interaction with a input and a output stream and listers like PortStillAvailableListener, PortBufferListener and a DataAvailableListener. What is the collective feeling about that? Op woensdag 19 juli 2006 00:14, schreef Dr. Douglas Lyon: > Hi All, > I have been in touch with: > Paul Klissner > Please read what Paul writes below. > I am not sure, but this might be a good chance for > the RXTX group to take action. > As to what we should write for the JSR, I am thinking > about something in the javax.comm namespace. > What is the collective feeling about that? > Thanks! > - Doug > > Paul writes: > "I think a JSR should be opened, but I don't see any point > in proceeding with 922, which never formed and expert group, > or provided a specification or reference implementation. > It was a placeholder, and the title wasn't even relevant. > > I think we should discuss our ideas about what we'd like > to accomplish and javax.comm and see if we can reach an > agreement. > > You would submit a JSR through the Java Community Process, > and if you do, I'd like to represent Sun on the expert group, > and contribute to the effort. We may want to start with > a fresh specification, borrowing what we want from the > current javax.com, adding what we need, and creating > a reference implementation. From phillip at uow.edu.au Tue Jul 18 23:44:25 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Wed, 19 Jul 2006 15:44:25 +1000 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application in Mac OSX" Message-ID: <7EEF3F56-A406-4532-BB3D-AA642A4818CA@uow.edu.au> > > Do we still need the /var/spool/uucp directory?? > > >> Trent Jarvi wrote >>[The new code in CVS will not use Lockfiles on Mac OS X.] Great, that should make installation easier. When will the next version be released? Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From phillip at uow.edu.au Wed Jul 19 00:14:26 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Wed, 19 Jul 2006 16:14:26 +1000 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: References: Message-ID: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> > > Edit the JavaKit.java in order to use the gnu.io and compile > everything. > > Alexandre > Unfotunately all I have is a .jar that contains it. I haven't found the source on their web site. > From: Joachim Buechse > 2.1.7 is the gnu.io.* version. You need 2.0.7 ie the javax.comm.* > version. > > RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for > that. > > Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. > > Trent Jarv I found the rxtx download page and downloaded rxtx-2.0-7pre1 (source/ Mac) The Install folder in ForPackageMaker has librxtxSerial.jnilib and java.com.properties but instead of RXTXComm.jar it has jcl.jar (I have no idea what is is for - it doesn't seem to be a replacement for RXTXCom.jar) I tried to run the XCode project to build it but there is a syntax error - nativeSetSerialPortParams returns a void not a jboolean. Also, there is no target to make RXTXComm.jar JNIEXPORT void JNICALL Java_gnu_io_RXTXPort_nativeSetSerialPortParams (JNIEnv *, jobject, jint, jint, jint, jint); Can you tell me where to find either a working copy of 2.0 for Mac OSX, or RXTXComm.jar or a working XCode project for Version 2. This is getting very frustrating. thanks Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From joachim at buechse.de Wed Jul 19 01:17:03 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 19 Jul 2006 09:17:03 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607190212.27131.pascal@quies.net> References: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> <200607190212.27131.pascal@quies.net> Message-ID: <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> The static objects will work for Windows and Linux, however for OSX they will create problems: - ports can appear and disappear at any time with VCP drivers for USB - the port names are not known until the usb-port is "plugged in" Please do not forget that tty ports can be opened by several applications concurrently. All of those will "loose" the port if anyone opens the corresponding cu port. As this naming based mechanism does not exist on Windows (maybe it does via an API) it should probably be reflected in the API. In other words there are "two levels of open": - Open for reading status lines (1) - Open for reading/writing data (2) I am not sure if state (1) should also allow the modification of certain status lines (ie to set a modem ready). I am also not sure if the api should unify corresponding cu. and tty. ports into one single port. Regards, Joachim On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: > For instance the current API is not very object oriented. > It might be a good idea to have a static set of objects available > representing > every supported port available on the system in realtime. Each > object should > clearly know its own state and its capabilities. To get a port > there could be > a method like synchronized void connect(PortUser) where PortUser is a > interface which handles the interaction with a input and a output > stream and > listers like PortStillAvailableListener, PortBufferListener and a > DataAvailableListener. > > What is the collective feeling about that? From joachim at buechse.de Wed Jul 19 01:29:53 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 19 Jul 2006 09:29:53 +0200 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> References: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> Message-ID: <2D32167B-3830-41D6-9FDD-462301F0453F@buechse.de> As you have already downloaded the source, just cd into the main folder and do a "cvs up -d" this will remove some outdated files and create a new XCode project which should compile without problems. You may also want to search the mail archive or checkout README.OSX for my suggestion on how to avoid the javax.comm.properties file by creating a class com.sun.comm.SolarisDriver. Regards, Joachim PS: I can feel your pain... it was the same for me. In fact I never understood why there are different native or java implementations for 2.0 and 2.1. The two versions could easily be unified by using the simplest of OO programing (intermediate abstract classes). But I guess at the time of branching the direction was not clear. Also the licences are not the same... On 19.07.2006, at 08:14, Phillip McKerrow wrote: >> RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for >> that. >> >> Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. >> >> Trent Jarv > > I found the rxtx download page and downloaded rxtx-2.0-7pre1 (source/ > Mac) > > The Install folder in ForPackageMaker has librxtxSerial.jnilib and > java.com.properties but instead of RXTXComm.jar it has jcl.jar (I > have no idea what is is for - it doesn't seem to be a replacement for > RXTXCom.jar) > > I tried to run the XCode project to build it but there is a syntax > error - nativeSetSerialPortParams returns a void not a jboolean. > Also, there is no target to make RXTXComm.jar > > JNIEXPORT void JNICALL Java_gnu_io_RXTXPort_nativeSetSerialPortParams > (JNIEnv *, jobject, jint, jint, jint, jint); > > Can you tell me where to find either a working copy of 2.0 for Mac > OSX, or RXTXComm.jar or a working XCode project for Version 2. This > is getting very frustrating. > > thanks > > Phillip > > ---------------------------------------------------------------------- > Phillip McKerrow http:// > www.uow.edu.au/~phillip/ > School of Information Technology and Computer Science > University of Wollongong * > Northfields Avenue, * * > Wollongong, NSW, 2522. + > AUSTRALIA * the land of the > southern cross > tel : +61 2 4221 3771 fax : +61 2 4221 > 4170 > > God so loved the world that he gave his one and only Son (Jesus), > that whoever believes in him shall not perish but have eternal life. > John 3:16 > ---------------------------------------------------------------------- > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alex at det.ua.pt Wed Jul 19 03:02:40 2006 From: alex at det.ua.pt (Alexandre Mota) Date: Wed, 19 Jul 2006 10:02:40 +0100 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> References: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> Message-ID: <44BDF530.5080502@det.ua.pt> Phillip McKerrow wrote: >>Edit the JavaKit.java in order to use the gnu.io and compile >>everything. >> >>Alexandre >> >> >> >Unfotunately all I have is a .jar that contains it. I haven't found >the source on their web site. > > > > Download http://files.dalsemi.com/pub/tini/tini1_17.tgz Decompress it and you will find the JavaKiTSrc.jar in the src dir. Decompress it with jar -xf JavaKitSrc.jar and you will get all the source files you need. Alexandre PS: Remenber that puting JavaKit into work is allways a pain... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060719/f5172a01/attachment-0345.html From lyon at docjava.com Wed Jul 19 05:27:47 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 19 Jul 2006 07:27:47 -0400 Subject: [Rxtx] RXTX binary for mac In-Reply-To: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> References: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> Message-ID: Hi All, I have some older RXTX binaries that are deployed in a webstart application. You can try it with: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp The libs are signed and packed for webstart disto by me. http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/ Shows them. - DL > > >> Edit the JavaKit.java in order to use the gnu.io and compile? >> everything. >> >> Alexandre >> >Unfotunately all I have is a .jar that contains it. I haven't found? >the source on their web site. > > >> From: Joachim Buechse >> 2.1.7 is the gnu.io.* version. You need 2.0.7 ie the javax.comm.* >> version. >> > >> RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for? >> that. >> >> Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. >> >> Trent Jarv > >I found the rxtx download page and downloaded rxtx-2.0-7pre1 (source/ >Mac) > >The Install folder in ForPackageMaker has librxtxSerial.jnilib and? >java.com.properties but instead of RXTXComm.jar it has jcl.jar (I? >have no idea what is is for - it doesn't seem to be a replacement for? >RXTXCom.jar) > >I tried to run the XCode project to build it but there is a syntax? >error - nativeSetSerialPortParams returns a void not a jboolean.?? >Also, there is no target to make RXTXComm.jar > >JNIEXPORT void JNICALL Java_gnu_io_RXTXPort_nativeSetSerialPortParams > (JNIEnv *, jobject, jint, jint, jint, jint); > >Can you tell me where to find either a working copy of 2.0 for Mac? >OSX, or RXTXComm.jar or a working XCode project for Version 2. This? >is getting very frustrating. > >thanks > >Phillip > >---------------------------------------------------------------------- >Phillip McKerrow http:// >www.uow.edu.au/~phillip/ >School of Information Technology and Computer Science >University of Wollongong * >Northfields Avenue, * * >Wollongong, NSW, 2522. + >AUSTRALIA * the land of the? >southern cross >tel : +61 2 4221 3771 fax : +61 2 4221 4170 > >God so loved the world that he gave his one and only Son (Jesus), >that whoever believes in him shall not perish but have eternal life. >John 3:16 >---------------------------------------------------------------------- > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Wed Jul 19 06:11:27 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 14:11:27 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> Message-ID: <200607191411.27566.pascal@quies.net> Hi Joachim, Thanks for the constructive critisism. :) Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: > The static objects will work for Windows and Linux, however for OSX > they will create problems: > - ports can appear and disappear at any time with VCP drivers for USB > - the port names are not known until the usb-port is "plugged in" Ports can appear and disappear on *any* OS with USB support. Some Linux distributions even create and remove devicefiles on the fly. With the current API you fetch a list of all available ports and then you try to cast one. What happens if the port is no longer available at that time? What happens if a port vanishes during the data transfer? Of course you can catch exceptions but that makes the code quite messy. The idea was to get a PortStillAvailableListener interface. In that way the implementation is free to handle a cleanup or wait for return routine in a OO way. The I/O streams should just lock. The word static was not ment as persistent but as Java static available. Considder the following: java.lang.hw.HardwareConfiguration { public enum PortType { RS232, I2C, etc. }; /** Gets the currently available ports of type {@code PortType}. */ public static java.lang.hw.Port[] getPorts(PortType); } com.example.Driver implements PortUser, implements PortStillAvailableListener { public portNoLongerAvailable(PortEvent event) { // cleanup & dismiss. } } com.example.Application { public static void main(String[] args) { Driver someDriver = new Driver(); Port radomPort = HardwareConfiguration.getPorts( HardwareConfiguration.PortType.RS232)[1]; myDevice.addStillAvailableListener(someDriver); myDevice.connect(someDriver); } } > Please do not forget that tty ports can be opened by several > applications concurrently. All of those will "loose" the port if > anyone opens the corresponding cu port. Indeed we need a good overview of the differences between the various platforms. Should we create a document or a Wiki for this purpose? FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: http://www.openbsd.org/cgi-bin/man.cgi?query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html Linux uses /var/lock: http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES Is there absolutely no way to get a lock under Windows? > As this naming based > mechanism does not exist on Windows (maybe it does via an API) it > should probably be reflected in the API. In other words there are > "two levels of open": > > - Open for reading status lines (1) > - Open for reading/writing data (2) > > I am not sure if state (1) should also allow the modification of > certain status lines (ie to set a modem ready). I'm not sure I understand. Do you mean canonical and noncanonical mode? How far is Windows with the canonical mode. Is it comparable to POSIX? > I am also not sure if > the api should unify corresponding cu. and tty. ports into one single > port. I think the API should hide low-level details like devicefiles. Who is participating anyway? Is it just the four of us? Cheers, Pascal > On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: > > For instance the current API is not very object oriented. > > It might be a good idea to have a static set of objects available > > representing > > every supported port available on the system in realtime. Each > > object should > > clearly know its own state and its capabilities. To get a port > > there could be > > a method like synchronized void connect(PortUser) where PortUser is a > > interface which handles the interaction with a input and a output > > stream and > > listers like PortStillAvailableListener, PortBufferListener and a > > DataAvailableListener. > > > > What is the collective feeling about that? From joachim at buechse.de Wed Jul 19 07:09:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 19 Jul 2006 15:09:27 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191411.27566.pascal@quies.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> Message-ID: <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> Pascal, I think that the PortNoLongerAvailableListener creates more problems than it solves. I think that exceptions are much better suited for this case. There might be an additional method "Port.isOpen" or "Port.isAvailable" which interested applications may call at times best suited. Most implementations will only find out, that a port disappeared when trying to read or write. Anything else would require polling with a high frequency or kernel hooks that do not exist (in POSIX). Any kind of call back like portNoLongerAvailable() creates the risk of deadlocks and races which require an involved implementation as the library does not know what it is calling (ie a user might try to call close from the callback which can block a very long time). Callbacks introduce concurrency which unneccessarily increases the complexity. Regards, Joachim On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: > Hi Joachim, > > Thanks for the constructive critisism. :) > > Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >> The static objects will work for Windows and Linux, however for OSX >> they will create problems: >> - ports can appear and disappear at any time with VCP drivers for USB >> - the port names are not known until the usb-port is "plugged in" > > Ports can appear and disappear on *any* OS with USB support. Some > Linux > distributions even create and remove devicefiles on the fly. > > With the current API you fetch a list of all available ports and > then you try > to cast one. What happens if the port is no longer available at > that time? > What happens if a port vanishes during the data transfer? Of course > you can > catch exceptions but that makes the code quite messy. > > The idea was to get a PortStillAvailableListener interface. In that > way the > implementation is free to handle a cleanup or wait for return > routine in a OO > way. The I/O streams should just lock. > > The word static was not ment as persistent but as Java static > available. > Considder the following: > > java.lang.hw.HardwareConfiguration { > public enum PortType { RS232, I2C, etc. }; > > /** Gets the currently available ports of type {@code PortType}. */ > public static java.lang.hw.Port[] getPorts(PortType); > } > > com.example.Driver implements PortUser, implements > PortStillAvailableListener > { > public portNoLongerAvailable(PortEvent event) { > // cleanup & dismiss. > } > } > > com.example.Application { > public static void main(String[] args) { > Driver someDriver = new Driver(); > Port radomPort = HardwareConfiguration.getPorts( > HardwareConfiguration.PortType.RS232)[1]; > myDevice.addStillAvailableListener(someDriver); > myDevice.connect(someDriver); > } > } > >> Please do not forget that tty ports can be opened by several >> applications concurrently. All of those will "loose" the port if >> anyone opens the corresponding cu port. > > Indeed we need a good overview of the differences between the various > platforms. Should we create a document or a Wiki for this purpose? > > FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: > http://www.openbsd.org/cgi-bin/man.cgi? > query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD > +Current&arch=i386&format=html > > Linux uses /var/lock: > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > Is there absolutely no way to get a lock under Windows? > >> As this naming based >> mechanism does not exist on Windows (maybe it does via an API) it >> should probably be reflected in the API. In other words there are >> "two levels of open": >> >> - Open for reading status lines (1) >> - Open for reading/writing data (2) >> >> I am not sure if state (1) should also allow the modification of >> certain status lines (ie to set a modem ready). > > I'm not sure I understand. Do you mean canonical and noncanonical > mode? > > How far is Windows with the canonical mode. Is it comparable to POSIX? > >> I am also not sure if >> the api should unify corresponding cu. and tty. ports into one single >> port. > > I think the API should hide low-level details like devicefiles. > > > Who is participating anyway? Is it just the four of us? > > Cheers, > > Pascal > > >> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>> For instance the current API is not very object oriented. >>> It might be a good idea to have a static set of objects available >>> representing >>> every supported port available on the system in realtime. Each >>> object should >>> clearly know its own state and its capabilities. To get a port >>> there could be >>> a method like synchronized void connect(PortUser) where PortUser >>> is a >>> interface which handles the interaction with a input and a output >>> stream and >>> listers like PortStillAvailableListener, PortBufferListener and a >>> DataAvailableListener. >>> >>> What is the collective feeling about that? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Wed Jul 19 08:33:08 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Wed, 19 Jul 2006 11:33:08 -0300 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191411.27566.pascal@quies.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> Message-ID: <44BE42A4.3030203@gmail.com> > Linux uses /var/lock: > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > Is there absolutely no way to get a lock under Windows? Indeed Windows block ports when someone open ones. Java Comm could manage this feature. > Who is participating anyway? Is it just the four of us? I can help too. Regards, Manuel From pascal at quies.net Wed Jul 19 09:01:17 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 17:01:17 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> References: <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> Message-ID: <200607191701.17607.pascal@quies.net> In the POSIX world things are simple. If any transaction fails with ENOTTY we lock the I/O streams and create a PortNoLongerAvailableEvent. We *might* even go so far as to start a thread which polls the tty say once a second afther a PortNoLongerAvailableEvent and kill it if there is succes with a PortAvailableAgainEvent but there won't be anything like deadlocks and races. I promise. ;) Methods like isOpen and isAvailable require polling which is exactly what we both don't want and they can't be reliable since it is a moment. A clean sepparation of the functional code and Listeners for events makes the code better readable and more flexible. PS If OS X has a notification system for changes in the available ports this OS specific functionality is more simple to implement too. Op woensdag 19 juli 2006 15:09, schreef Joachim Buechse: > Pascal, > > I think that the PortNoLongerAvailableListener creates more problems > than it solves. > > I think that exceptions are much better suited for this case. There > might be an additional method "Port.isOpen" or "Port.isAvailable" > which interested applications may call at times best suited. > > Most implementations will only find out, that a port disappeared when > trying to read or write. Anything else would require polling with a > high frequency or kernel hooks that do not exist (in POSIX). Any kind > of call back like portNoLongerAvailable() creates the risk of > deadlocks and races which require an involved implementation as the > library does not know what it is calling (ie a user might try to call > close from the callback which can block a very long time). Callbacks > introduce concurrency which unneccessarily increases the complexity. > > Regards, > Joachim From jredman at ergotech.com Wed Jul 19 09:20:39 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 09:20:39 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191411.27566.pascal@quies.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> Message-ID: <44BE4DC7.7@ergotech.com> Pascal S. de Kloe wrote: >> I am also not sure if >> the api should unify corresponding cu. and tty. ports into one single >> port. > > I think the API should hide low-level details like devicefiles. Not all ports have device files. It's long been my goal to add support for virtual serial ports, that is, serial ports on Ethernet terminal servers, for example integrating RFC2217. This means that the port name is some combination of an IP address and TCP port number. Nothing in /dev. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From brian at mbari.org Wed Jul 19 10:04:51 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 19 Jul 2006 09:04:51 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BE42A4.3030203@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <44BE42A4.3030203@gmail.com> Message-ID: <5FDA8DB5-FD08-4EAA-81A7-C46A7CF6FA18@mbari.org> >> Who is participating anyway? Is it just the four of us? > I'm not much of a POSIX or C guy. But I do a lot of OO design. I'm happy to throw my 2 cents in too. Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060719/404de230/attachment-0344.html From pascal at quies.net Wed Jul 19 10:16:16 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 18:16:16 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BE4DC7.7@ergotech.com> References: <200607191411.27566.pascal@quies.net> <44BE4DC7.7@ergotech.com> Message-ID: <200607191816.17099.pascal@quies.net> Op woensdag 19 juli 2006 17:20, schreef Jim Redman: > Pascal S. de Kloe wrote: > >> I am also not sure if > >> the api should unify corresponding cu. and tty. ports into one single > >> port. > > > > I think the API should hide low-level details like devicefiles. > > Not all ports have device files. It's long been my goal to add support > for virtual serial ports, that is, serial ports on Ethernet terminal > servers, for example integrating RFC2217. This means that the port name > is some combination of an IP address and TCP port number. Nothing in /dev. > > Jim This idea doesn't need any native calls at all, right? How would you like to realize that? Jini? I'm sure you knew that the server is already there: http://www.viara.cn/en/jts.htm From pascal at quies.net Wed Jul 19 10:17:12 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 18:17:12 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <5FDA8DB5-FD08-4EAA-81A7-C46A7CF6FA18@mbari.org> References: <44BE42A4.3030203@gmail.com> <5FDA8DB5-FD08-4EAA-81A7-C46A7CF6FA18@mbari.org> Message-ID: <200607191817.12769.pascal@quies.net> Op woensdag 19 juli 2006 18:04, schreef Brian Schlining: > >> Who is participating anyway? Is it just the four of us? > > I'm not much of a POSIX or C guy. But I do a lot of OO design. I'm > happy to throw my 2 cents in too. > > Brian Schlining > Software Engineer > http://www.mbari.org Excellent! :) We need a lot of opinions from all kinds of users. From jredman at ergotech.com Wed Jul 19 10:54:18 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 10:54:18 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191816.17099.pascal@quies.net> References: <200607191411.27566.pascal@quies.net> <44BE4DC7.7@ergotech.com> <200607191816.17099.pascal@quies.net> Message-ID: <44BE63BA.9090905@ergotech.com> Pascal, Pascal S. de Kloe wrote: > Op woensdag 19 juli 2006 17:20, schreef Jim Redman: >> Pascal S. de Kloe wrote: >>>> I am also not sure if >>>> the api should unify corresponding cu. and tty. ports into one single >>>> port. >>> I think the API should hide low-level details like devicefiles. >> Not all ports have device files. It's long been my goal to add support >> for virtual serial ports, that is, serial ports on Ethernet terminal >> servers, for example integrating RFC2217. This means that the port name >> is some combination of an IP address and TCP port number. Nothing in /dev. >> >> Jim > > This idea doesn't need any native calls at all, right? No native calls, it's just a Socket link. > > How would you like to realize that? I keep wondering that myself. I had in mind port names that are, for example, "192.168.0.99:3000". These would need to be added to the properties file (or the -D option). I'm open for suggestion. It's conceptually, it's the same as USB. Instead of USB->Serial it's Ethernet->Serial. The difference is that the USB devices create virtual serial ports within the OS. Some Ethernet devices also do this, but since, unlike USB communications, TCP/IP is supported natively within Java such a driver is unnecessary. > Jini? Is that still alive and kicking? > > I'm sure you knew that the server is already there: > > http://www.viara.cn/en/jts.htm Yes, that library is part of the plan. These devices are real serial ports. Somewhere, out in the Ether there's a DB9/DB25 cable with RS232/485 bits flowing over it. Since these are real ports, I'd like the ports to look like real serial ports (SerialPort) and not have to handle them as special cases. We have a bunch of code that deals with serial devices (PLCs, Barcode, Temperature Controllers, RFID, SECS, etc. etc.) and to rewrite each one of those to handle this case doesn't make much sense when the correct place to encapsulate a serial port is in the SerialPort layer. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From pascal at quies.net Wed Jul 19 12:44:01 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 20:44:01 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BE63BA.9090905@ergotech.com> References: <200607191816.17099.pascal@quies.net> <44BE63BA.9090905@ergotech.com> Message-ID: <200607192044.01966.pascal@quies.net> Op woensdag 19 juli 2006 18:54, schreef Jim Redman: > I keep wondering that myself. I had in mind port names that are, for > example, "192.168.0.99:3000". These would need to be added to the > properties file (or the -D option). > > I'm open for suggestion. Jini works very well especialy for ethernets like the one you describe. It's a shame that it never got the attention it deserves. > > Jini? > > Is that still alive and kicking? Not that it does matter becouse Java software doesn't need much maintenance. ;) Have a look at http://www.jini.org/. From Paul.Klissner at Sun.COM Wed Jul 19 15:45:38 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 14:45:38 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> Message-ID: <44BEA802.7060508@sun.com> Joachim Buechse wrote: > Pascal, > > I think that the PortNoLongerAvailableListener creates more problems > than it solves. > > I think that exceptions are much better suited for this case. There > might be an additional method "Port.isOpen" or "Port.isAvailable" > which interested applications may call at times best suited. > > Most implementations will only find out, that a port disappeared when > trying to read or write. Anything else would require polling with a > high frequency or kernel hooks that do not exist (in POSIX). Any kind > of call back like portNoLongerAvailable() creates the risk of > deadlocks and races which require an involved implementation as the > library does not know what it is calling (ie a user might try to call > close from the callback which can block a very long time). Callbacks > introduce concurrency which unneccessarily increases the complexity. I think we should find out what are the minimum requirements to get a JSR open, form an expert group, and get that group discussing these things in the JSR. I'm not pushing for Sun to sponsor it, as I think there is a community interest already and that it deserves an independent life and commitment. ACCESS EXCEPTIONS: ----------------- I agree, exceptions of this sort are the way to go. Exceptions are already simpler than having to err check at each function call, so a big improvement. No need to architect a more trouble prone complexity into the API. PROJECT SCOPE: ------------- Also, we should think carefully about what the scope of this project would be. Should it be javax."comm" which handles both serial and parallel (is parallel going by the wayside). Should it be split into two project: javax.EIA232 (or javax.RS232), and javax.IEEE1284? Should we differentiate between single-ended serial protocols, like EIA232, I2C, 2-WIRE, SPI, vs. quasi-multidrop and full multidrop busses such as EIA422, EIA432 and EIA485? If we really were to add I2C support to the API, we'd have to delve into the semantics more, because there could be some implicit decoding of the bus the API users would want to see. At this point, I'm thinking they're all different, and should be their own projects.. perhaps there could be an umbrella layer that abstracted out some of the generic issues like device ownership and access, perhaps not. javax.eia232 javax.eia485 or (javax.EIX4xx?) javax.i2c, javax.spi (or javax.chipbus?) DRIVER PLUGINS: -------------- Taking javax.eia232 for example, I think we need an architecture that allows for multiple plugins to provide multiple simultaneous drivers/adapters to allow for heterogeneous providers on a single system. For example, not only can there be USB based serial devices but networked serial devices, for example accessing devices on thin clients. PORTMAPPING: ----------- For Sun's javax.comm 3.0, we introduced a portmapping abstraction layer, that creates a mechansim to help administer the view (filtering)of available ports given to the application, and the name of such ports. I hope we can consider the right platform neutral way to accomplish that. In javax.comm as it is now, the API has to know where to go and look to find ports. In 3.x I added the ability to specify where to look for standard ports as properties to make it more flexible, but for our thin client platform, which can represent a very dynamic buffet of ports splayed in the leaf nodes of a tree that isn't good enough. That complicates things for the users (having to specify and manage unique and long path names to ports which can come and go), so there is an option whereby the user can configure something like "com1" such that on a thin client it represents the first port of the first USB/serial dongle connected. Javax.comm knows how to find that in the context of the current thin client, but the administrator doesn't have to worry about it. How to architect the API flexibly enough to allow for this kind of thing needs to be considered. Paul > > Regards, > Joachim > > On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: > >> Hi Joachim, >> >> Thanks for the constructive critisism. :) >> >> Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >>> The static objects will work for Windows and Linux, however for OSX >>> they will create problems: >>> - ports can appear and disappear at any time with VCP drivers for USB >>> - the port names are not known until the usb-port is "plugged in" >> Ports can appear and disappear on *any* OS with USB support. Some >> Linux >> distributions even create and remove devicefiles on the fly. >> >> With the current API you fetch a list of all available ports and >> then you try >> to cast one. What happens if the port is no longer available at >> that time? >> What happens if a port vanishes during the data transfer? Of course >> you can >> catch exceptions but that makes the code quite messy. >> >> The idea was to get a PortStillAvailableListener interface. In that >> way the >> implementation is free to handle a cleanup or wait for return >> routine in a OO >> way. The I/O streams should just lock. >> >> The word static was not ment as persistent but as Java static >> available. >> Considder the following: >> >> java.lang.hw.HardwareConfiguration { >> public enum PortType { RS232, I2C, etc. }; >> >> /** Gets the currently available ports of type {@code PortType}. */ >> public static java.lang.hw.Port[] getPorts(PortType); >> } >> >> com.example.Driver implements PortUser, implements >> PortStillAvailableListener >> { >> public portNoLongerAvailable(PortEvent event) { >> // cleanup & dismiss. >> } >> } >> >> com.example.Application { >> public static void main(String[] args) { >> Driver someDriver = new Driver(); >> Port radomPort = HardwareConfiguration.getPorts( >> HardwareConfiguration.PortType.RS232)[1]; >> myDevice.addStillAvailableListener(someDriver); >> myDevice.connect(someDriver); >> } >> } >> >>> Please do not forget that tty ports can be opened by several >>> applications concurrently. All of those will "loose" the port if >>> anyone opens the corresponding cu port. >> Indeed we need a good overview of the differences between the various >> platforms. Should we create a document or a Wiki for this purpose? >> >> FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: >> http://www.openbsd.org/cgi-bin/man.cgi? >> query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD >> +Current&arch=i386&format=html >> >> Linux uses /var/lock: >> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES >> >> Is there absolutely no way to get a lock under Windows? >> >>> As this naming based >>> mechanism does not exist on Windows (maybe it does via an API) it >>> should probably be reflected in the API. In other words there are >>> "two levels of open": >>> >>> - Open for reading status lines (1) >>> - Open for reading/writing data (2) >>> >>> I am not sure if state (1) should also allow the modification of >>> certain status lines (ie to set a modem ready). >> I'm not sure I understand. Do you mean canonical and noncanonical >> mode? >> >> How far is Windows with the canonical mode. Is it comparable to POSIX? >> >>> I am also not sure if >>> the api should unify corresponding cu. and tty. ports into one single >>> port. >> I think the API should hide low-level details like devicefiles. >> >> >> Who is participating anyway? Is it just the four of us? >> >> Cheers, >> >> Pascal >> >> >>> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>>> For instance the current API is not very object oriented. >>>> It might be a good idea to have a static set of objects available >>>> representing >>>> every supported port available on the system in realtime. Each >>>> object should >>>> clearly know its own state and its capabilities. To get a port >>>> there could be >>>> a method like synchronized void connect(PortUser) where PortUser >>>> is a >>>> interface which handles the interaction with a input and a output >>>> stream and >>>> listers like PortStillAvailableListener, PortBufferListener and a >>>> DataAvailableListener. >>>> >>>> What is the collective feeling about that? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Wed Jul 19 16:32:37 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 16:32:37 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEA802.7060508@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <44BEB305.3030208@ergotech.com> For one, I'd object to the splitting of 232 and 485 and question why it's necessary. Often the only difference between 232 access and 485 access is whether there's a converter attached to the serial port. Put another way, while 485 is multidrop, I think that's an application level issue rather than a driver level issue. If the issue is electrical, I don't think that it's possible to reliably support receiver switching of a 2-wire 485 network within Java, the timing is just too tight, so your stuck with requiring a 485 converter that automatically switches (not an onerous burden for us) or some OS level intervention. Anyway, if we're going to start differentiating at the electrical level we still support some current loop systems (Siemens S5 PLC if you care). Jim Paul Klissner wrote: > Joachim Buechse wrote: >> Pascal, >> >> I think that the PortNoLongerAvailableListener creates more problems >> than it solves. >> >> I think that exceptions are much better suited for this case. There >> might be an additional method "Port.isOpen" or "Port.isAvailable" >> which interested applications may call at times best suited. >> >> Most implementations will only find out, that a port disappeared when >> trying to read or write. Anything else would require polling with a >> high frequency or kernel hooks that do not exist (in POSIX). Any kind >> of call back like portNoLongerAvailable() creates the risk of >> deadlocks and races which require an involved implementation as the >> library does not know what it is calling (ie a user might try to call >> close from the callback which can block a very long time). Callbacks >> introduce concurrency which unneccessarily increases the complexity. > > I think we should find out what are the minimum requirements > to get a JSR open, form an expert group, and get that group > discussing these things in the JSR. I'm not pushing for > Sun to sponsor it, as I think there is a community interest > already and that it deserves an independent life and > commitment. > > ACCESS EXCEPTIONS: > ----------------- > I agree, exceptions of this sort are the way to go. > Exceptions are already simpler than having to err > check at each function call, so a big improvement. > No need to architect a more trouble prone complexity > into the API. > > PROJECT SCOPE: > ------------- > > Also, we should think carefully about what the scope of > this project would be. Should it be javax."comm" which > handles both serial and parallel (is parallel going by the > wayside). Should it be split into two project: > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > > Should we differentiate between single-ended serial > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > quasi-multidrop and full multidrop busses such as > EIA422, EIA432 and EIA485? If we really were to > add I2C support to the API, we'd have to delve into > the semantics more, because there could be some > implicit decoding of the bus the API users would > want to see. > > At this point, I'm thinking they're all different, > and should be their own projects.. perhaps there > could be an umbrella layer that abstracted out > some of the generic issues like device ownership > and access, perhaps not. > > javax.eia232 > javax.eia485 or (javax.EIX4xx?) > javax.i2c, javax.spi (or javax.chipbus?) > > DRIVER PLUGINS: > -------------- > Taking javax.eia232 for example, I think we need an > architecture that allows for multiple plugins to > provide multiple simultaneous drivers/adapters to > allow for heterogeneous providers on a single system. > For example, not only can there be USB based serial > devices but networked serial devices, for example > accessing devices on thin clients. > > PORTMAPPING: > ----------- > For Sun's javax.comm 3.0, we introduced a portmapping > abstraction layer, that creates a mechansim to help > administer the view (filtering)of available ports given > to the application, and the name of such ports. I hope we > can consider the right platform neutral way to > accomplish that. > > In javax.comm as it is now, the API has to know > where to go and look to find ports. In 3.x I added > the ability to specify where to look for standard > ports as properties to make it more flexible, but > for our thin client platform, which can represent > a very dynamic buffet of ports splayed in the > leaf nodes of a tree that isn't good enough. > That complicates things for the users (having > to specify and manage unique and long path names > to ports which can come and go), so there is > an option whereby the user can configure > something like "com1" such that on a thin client > it represents the first port of the first USB/serial > dongle connected. Javax.comm knows how to find > that in the context of the current thin client, > but the administrator doesn't have to worry about it. > > How to architect the API flexibly enough to allow > for this kind of thing needs to be considered. > > Paul > > > >> Regards, >> Joachim >> >> On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: >> >>> Hi Joachim, >>> >>> Thanks for the constructive critisism. :) >>> >>> Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >>>> The static objects will work for Windows and Linux, however for OSX >>>> they will create problems: >>>> - ports can appear and disappear at any time with VCP drivers for USB >>>> - the port names are not known until the usb-port is "plugged in" >>> Ports can appear and disappear on *any* OS with USB support. Some >>> Linux >>> distributions even create and remove devicefiles on the fly. >>> >>> With the current API you fetch a list of all available ports and >>> then you try >>> to cast one. What happens if the port is no longer available at >>> that time? >>> What happens if a port vanishes during the data transfer? Of course >>> you can >>> catch exceptions but that makes the code quite messy. >>> >>> The idea was to get a PortStillAvailableListener interface. In that >>> way the >>> implementation is free to handle a cleanup or wait for return >>> routine in a OO >>> way. The I/O streams should just lock. >>> >>> The word static was not ment as persistent but as Java static >>> available. >>> Considder the following: >>> >>> java.lang.hw.HardwareConfiguration { >>> public enum PortType { RS232, I2C, etc. }; >>> >>> /** Gets the currently available ports of type {@code PortType}. */ >>> public static java.lang.hw.Port[] getPorts(PortType); >>> } >>> >>> com.example.Driver implements PortUser, implements >>> PortStillAvailableListener >>> { >>> public portNoLongerAvailable(PortEvent event) { >>> // cleanup & dismiss. >>> } >>> } >>> >>> com.example.Application { >>> public static void main(String[] args) { >>> Driver someDriver = new Driver(); >>> Port radomPort = HardwareConfiguration.getPorts( >>> HardwareConfiguration.PortType.RS232)[1]; >>> myDevice.addStillAvailableListener(someDriver); >>> myDevice.connect(someDriver); >>> } >>> } >>> >>>> Please do not forget that tty ports can be opened by several >>>> applications concurrently. All of those will "loose" the port if >>>> anyone opens the corresponding cu port. >>> Indeed we need a good overview of the differences between the various >>> platforms. Should we create a document or a Wiki for this purpose? >>> >>> FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: >>> http://www.openbsd.org/cgi-bin/man.cgi? >>> query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD >>> +Current&arch=i386&format=html >>> >>> Linux uses /var/lock: >>> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES >>> >>> Is there absolutely no way to get a lock under Windows? >>> >>>> As this naming based >>>> mechanism does not exist on Windows (maybe it does via an API) it >>>> should probably be reflected in the API. In other words there are >>>> "two levels of open": >>>> >>>> - Open for reading status lines (1) >>>> - Open for reading/writing data (2) >>>> >>>> I am not sure if state (1) should also allow the modification of >>>> certain status lines (ie to set a modem ready). >>> I'm not sure I understand. Do you mean canonical and noncanonical >>> mode? >>> >>> How far is Windows with the canonical mode. Is it comparable to POSIX? >>> >>>> I am also not sure if >>>> the api should unify corresponding cu. and tty. ports into one single >>>> port. >>> I think the API should hide low-level details like devicefiles. >>> >>> >>> Who is participating anyway? Is it just the four of us? >>> >>> Cheers, >>> >>> Pascal >>> >>> >>>> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>>>> For instance the current API is not very object oriented. >>>>> It might be a good idea to have a static set of objects available >>>>> representing >>>>> every supported port available on the system in realtime. Each >>>>> object should >>>>> clearly know its own state and its capabilities. To get a port >>>>> there could be >>>>> a method like synchronized void connect(PortUser) where PortUser >>>>> is a >>>>> interface which handles the interaction with a input and a output >>>>> stream and >>>>> listers like PortStillAvailableListener, PortBufferListener and a >>>>> DataAvailableListener. >>>>> >>>>> What is the collective feeling about that? >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Paul.Klissner at Sun.COM Wed Jul 19 17:31:36 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 16:31:36 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEB305.3030208@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> Message-ID: <44BEC0D8.4050806@sun.com> Jim Redman wrote: > For one, I'd object to the splitting of 232 and 485 and question why > it's necessary. Often the only difference between 232 access and 485 > access is whether there's a converter attached to the serial port. > > Put another way, while 485 is multidrop, I think that's an application > level issue rather than a driver level issue. > > If the issue is electrical, I don't think that it's possible to reliably > support receiver switching of a 2-wire 485 network within Java, the > timing is just too tight, so your stuck with requiring a 485 converter > that automatically switches (not an onerous burden for us) or some OS > level intervention. > > Anyway, if we're going to start differentiating at the electrical level > we still support some current loop systems (Siemens S5 PLC if you care). > > Jim To be honest, I've not done anything with 422, 423 or 485, so I have no objection to keeping them together if there isn't enough of a protocol distinction to make it worth seperating them out. I'd just like to find another suitable name than javax.comm, unless the JSR wants to start with javax.comm 4.0, since all the previous 'major revisions' are accounted for. javax.serialport? Paul > > Paul Klissner wrote: >> Joachim Buechse wrote: >>> Pascal, >>> >>> I think that the PortNoLongerAvailableListener creates more problems >>> than it solves. >>> >>> I think that exceptions are much better suited for this case. There >>> might be an additional method "Port.isOpen" or "Port.isAvailable" >>> which interested applications may call at times best suited. >>> >>> Most implementations will only find out, that a port disappeared when >>> trying to read or write. Anything else would require polling with a >>> high frequency or kernel hooks that do not exist (in POSIX). Any kind >>> of call back like portNoLongerAvailable() creates the risk of >>> deadlocks and races which require an involved implementation as the >>> library does not know what it is calling (ie a user might try to call >>> close from the callback which can block a very long time). Callbacks >>> introduce concurrency which unneccessarily increases the complexity. >> I think we should find out what are the minimum requirements >> to get a JSR open, form an expert group, and get that group >> discussing these things in the JSR. I'm not pushing for >> Sun to sponsor it, as I think there is a community interest >> already and that it deserves an independent life and >> commitment. >> >> ACCESS EXCEPTIONS: >> ----------------- >> I agree, exceptions of this sort are the way to go. >> Exceptions are already simpler than having to err >> check at each function call, so a big improvement. >> No need to architect a more trouble prone complexity >> into the API. >> >> PROJECT SCOPE: >> ------------- >> >> Also, we should think carefully about what the scope of >> this project would be. Should it be javax."comm" which >> handles both serial and parallel (is parallel going by the >> wayside). Should it be split into two project: >> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >> >> Should we differentiate between single-ended serial >> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >> quasi-multidrop and full multidrop busses such as >> EIA422, EIA432 and EIA485? If we really were to >> add I2C support to the API, we'd have to delve into >> the semantics more, because there could be some >> implicit decoding of the bus the API users would >> want to see. >> >> At this point, I'm thinking they're all different, >> and should be their own projects.. perhaps there >> could be an umbrella layer that abstracted out >> some of the generic issues like device ownership >> and access, perhaps not. >> >> javax.eia232 >> javax.eia485 or (javax.EIX4xx?) >> javax.i2c, javax.spi (or javax.chipbus?) >> >> DRIVER PLUGINS: >> -------------- >> Taking javax.eia232 for example, I think we need an >> architecture that allows for multiple plugins to >> provide multiple simultaneous drivers/adapters to >> allow for heterogeneous providers on a single system. >> For example, not only can there be USB based serial >> devices but networked serial devices, for example >> accessing devices on thin clients. >> >> PORTMAPPING: >> ----------- >> For Sun's javax.comm 3.0, we introduced a portmapping >> abstraction layer, that creates a mechansim to help >> administer the view (filtering)of available ports given >> to the application, and the name of such ports. I hope we >> can consider the right platform neutral way to >> accomplish that. >> >> In javax.comm as it is now, the API has to know >> where to go and look to find ports. In 3.x I added >> the ability to specify where to look for standard >> ports as properties to make it more flexible, but >> for our thin client platform, which can represent >> a very dynamic buffet of ports splayed in the >> leaf nodes of a tree that isn't good enough. >> That complicates things for the users (having >> to specify and manage unique and long path names >> to ports which can come and go), so there is >> an option whereby the user can configure >> something like "com1" such that on a thin client >> it represents the first port of the first USB/serial >> dongle connected. Javax.comm knows how to find >> that in the context of the current thin client, >> but the administrator doesn't have to worry about it. >> >> How to architect the API flexibly enough to allow >> for this kind of thing needs to be considered. >> >> Paul >> >> >> >>> Regards, >>> Joachim >>> >>> On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: >>> >>>> Hi Joachim, >>>> >>>> Thanks for the constructive critisism. :) >>>> >>>> Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >>>>> The static objects will work for Windows and Linux, however for OSX >>>>> they will create problems: >>>>> - ports can appear and disappear at any time with VCP drivers for USB >>>>> - the port names are not known until the usb-port is "plugged in" >>>> Ports can appear and disappear on *any* OS with USB support. Some >>>> Linux >>>> distributions even create and remove devicefiles on the fly. >>>> >>>> With the current API you fetch a list of all available ports and >>>> then you try >>>> to cast one. What happens if the port is no longer available at >>>> that time? >>>> What happens if a port vanishes during the data transfer? Of course >>>> you can >>>> catch exceptions but that makes the code quite messy. >>>> >>>> The idea was to get a PortStillAvailableListener interface. In that >>>> way the >>>> implementation is free to handle a cleanup or wait for return >>>> routine in a OO >>>> way. The I/O streams should just lock. >>>> >>>> The word static was not ment as persistent but as Java static >>>> available. >>>> Considder the following: >>>> >>>> java.lang.hw.HardwareConfiguration { >>>> public enum PortType { RS232, I2C, etc. }; >>>> >>>> /** Gets the currently available ports of type {@code PortType}. */ >>>> public static java.lang.hw.Port[] getPorts(PortType); >>>> } >>>> >>>> com.example.Driver implements PortUser, implements >>>> PortStillAvailableListener >>>> { >>>> public portNoLongerAvailable(PortEvent event) { >>>> // cleanup & dismiss. >>>> } >>>> } >>>> >>>> com.example.Application { >>>> public static void main(String[] args) { >>>> Driver someDriver = new Driver(); >>>> Port radomPort = HardwareConfiguration.getPorts( >>>> HardwareConfiguration.PortType.RS232)[1]; >>>> myDevice.addStillAvailableListener(someDriver); >>>> myDevice.connect(someDriver); >>>> } >>>> } >>>> >>>>> Please do not forget that tty ports can be opened by several >>>>> applications concurrently. All of those will "loose" the port if >>>>> anyone opens the corresponding cu port. >>>> Indeed we need a good overview of the differences between the various >>>> platforms. Should we create a document or a Wiki for this purpose? >>>> >>>> FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: >>>> http://www.openbsd.org/cgi-bin/man.cgi? >>>> query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD >>>> +Current&arch=i386&format=html >>>> >>>> Linux uses /var/lock: >>>> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES >>>> >>>> Is there absolutely no way to get a lock under Windows? >>>> >>>>> As this naming based >>>>> mechanism does not exist on Windows (maybe it does via an API) it >>>>> should probably be reflected in the API. In other words there are >>>>> "two levels of open": >>>>> >>>>> - Open for reading status lines (1) >>>>> - Open for reading/writing data (2) >>>>> >>>>> I am not sure if state (1) should also allow the modification of >>>>> certain status lines (ie to set a modem ready). >>>> I'm not sure I understand. Do you mean canonical and noncanonical >>>> mode? >>>> >>>> How far is Windows with the canonical mode. Is it comparable to POSIX? >>>> >>>>> I am also not sure if >>>>> the api should unify corresponding cu. and tty. ports into one single >>>>> port. >>>> I think the API should hide low-level details like devicefiles. >>>> >>>> >>>> Who is participating anyway? Is it just the four of us? >>>> >>>> Cheers, >>>> >>>> Pascal >>>> >>>> >>>>> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>>>>> For instance the current API is not very object oriented. >>>>>> It might be a good idea to have a static set of objects available >>>>>> representing >>>>>> every supported port available on the system in realtime. Each >>>>>> object should >>>>>> clearly know its own state and its capabilities. To get a port >>>>>> there could be >>>>>> a method like synchronized void connect(PortUser) where PortUser >>>>>> is a >>>>>> interface which handles the interaction with a input and a output >>>>>> stream and >>>>>> listers like PortStillAvailableListener, PortBufferListener and a >>>>>> DataAvailableListener. >>>>>> >>>>>> What is the collective feeling about that? >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Wed Jul 19 18:03:40 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 18:03:40 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEC0D8.4050806@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> Message-ID: <44BEC85C.2030809@ergotech.com> Paul Klissner wrote: > I'd just like to find another suitable name than javax.comm, unless > the JSR wants to start with javax.comm 4.0, since all the previous > 'major revisions' are accounted for. javax.serialport? Which perhaps brings us back to what are we trying to fix and how badly. There are a number of 3rd party implementation of Java Comm, at least one from IBM - part of what was J9, now Websphere, or something (presumbly soon to get a name that has eclipse in it sometime soon). Esmertec has one, and there are few others rolling around. If RXTX is the only implementation of the JSR with no backward compatibility, we've just forked Java Serial support and we (for a least one) will be worse off. We won't be able to use the new support because of a lack of support on J2ME platforms that we have no control over and RXTX/current JavaComm will be in maintenance mode or unsupported on all other platforms. So, is there any chance of building a compatibility requirement into this. To pick are really bad example JDBC has support for a DataSource or a Driver. Could we have an ExcellentSerialPort with a fallback to a SerialPort on a class not found exception? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From pascal at quies.net Wed Jul 19 18:22:45 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Thu, 20 Jul 2006 02:22:45 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEC85C.2030809@ergotech.com> References: <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> Message-ID: <200607200222.46023.pascal@quies.net> Op donderdag 20 juli 2006 02:03, schreef Jim Redman: > Which perhaps brings us back to what are we trying to fix and how badly. The initail problem was the license. :) RXTX is sitting in this gnu.comm namespace and is afraid to go to javax.comm. Getting a JSR would solve this problem. And while we're at it we might as well improve the situation with the various platforms. I made some sugestions that where denied as too complex. Cheers, Pascal From Paul.Klissner at Sun.COM Wed Jul 19 19:09:35 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 18:09:35 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607200222.46023.pascal@quies.net> References: <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <200607200222.46023.pascal@quies.net> Message-ID: <44BED7CF.5080405@sun.com> Pascal S. de Kloe wrote: > Op donderdag 20 juli 2006 02:03, schreef Jim Redman: >> Which perhaps brings us back to what are we trying to fix and how badly. > > The initail problem was the license. :) > > RXTX is sitting in this gnu.comm namespace and is afraid to go to javax.comm. > Getting a JSR would solve this problem. > > And while we're at it we might as well improve the situation with the various > platforms. I made some sugestions that where denied as too complex. "Denied" is a bit harsh :) I'll re-examine your e-mails to see if my preferences change. It's not like your proposition has been put up to a formal vote, just discussion. Paul From Paul.Klissner at Sun.COM Wed Jul 19 19:28:47 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 18:28:47 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEC85C.2030809@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> Message-ID: <44BEDC4F.9030403@sun.com> Jim Redman wrote: > Paul Klissner wrote: >> I'd just like to find another suitable name than javax.comm, unless >> the JSR wants to start with javax.comm 4.0, since all the previous >> 'major revisions' are accounted for. javax.serialport? > > Which perhaps brings us back to what are we trying to fix and how badly. The goals I'm most interested in at the moment are: 1. A pluggable platform portmapping scheme wherein each platform can determine which ports to present to the application, and preferably as some configurable logical name. For example on the Sun Ray thin client platform, if an application aquiring a view of serial ports available on the system, it will be informed of Sun Ray serial ports if the application is running in a session currently directed to that particular Sun Ray unit, even though the serial port's device node happens to be server-side deeply nested in a leaf node. If the application is not running on a Sun Ray the port doesn't show up. The Sun Ray plugin would make the decision about when and which ports to present to the application. 2. Pluggable driver-side interface where multiple platform-specific drivers can be utilized simultaneously to introduce more flexibility with the back end. > There are a number of 3rd party implementation of Java Comm, at least > one from IBM - part of what was J9, now Websphere, or something > (presumbly soon to get a name that has eclipse in it sometime soon). > Esmertec has one, and there are few others rolling around. I have not been advocating gutting the API, since much of it is perfectly adequate. I'm not totally opposed to making substantial changes or improvements depending on other people's needs. There's no reason previous versions of javax.comm need to suddenly disappear if products need legacy support. > > If RXTX is the only implementation of the JSR with no backward > compatibility, we've just forked Java Serial support and we (for a least > one) will be worse off. We won't be able to use the new support because > of a lack of support on J2ME platforms that we have no control over and > RXTX/current JavaComm will be in maintenance mode or unsupported on all > other platforms. There can't be *that* many platforms this is ported to. And it will be no javax.usb. Seems like most of the standard platforms will be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, JDBC... > > So, is there any chance of building a compatibility requirement into > this. To pick are really bad example JDBC has support for a DataSource > or a Driver. Could we have an ExcellentSerialPort with a fallback to a > SerialPort on a class not found exception? Maybe, or maybe we just let people know what we are doing and try to figure out how to get their applications ported. Might not be that difficult. From my standpoint anyway, earthshaking changes aren't really necessary. Others might disagree. Paul From rwelty at averillpark.net Wed Jul 19 19:35:54 2006 From: rwelty at averillpark.net (Richard P. Welty) Date: Wed, 19 Jul 2006 21:35:54 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter Message-ID: <44BEDDFA.7020108@averillpark.net> I'm returning to the use of rxtx after 2 years off doing things that don't need serial ports. I'm trying to get my laptop (fedora core 1) talking to a set of portable auto scales through a Keyspan USB adapter (in my past use of rxtx, I had actual serial ports, but those days are long gone.) I have the keyspan kernel module loaded, and lsusb shows the device as correctly identified. I'm missing the bit of magic needed to get rxtx to provide the port in response to CommPortIdentifier.getPortIdentifiers() thanks in advance for any help, richard From jredman at ergotech.com Wed Jul 19 19:43:25 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 19:43:25 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BED7CF.5080405@sun.com> References: <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <200607200222.46023.pascal@quies.net> <44BED7CF.5080405@sun.com> Message-ID: <44BEDFBD.4020404@ergotech.com> Paul Klissner wrote: > Pascal S. de Kloe wrote: >> Op donderdag 20 juli 2006 02:03, schreef Jim Redman: >>> Which perhaps brings us back to what are we trying to fix and how badly. >> The initail problem was the license. :) >> >> RXTX is sitting in this gnu.comm namespace and is afraid to go to javax.comm. >> Getting a JSR would solve this problem. >> >> And while we're at it we might as well improve the situation with the various >> platforms. I made some sugestions that where denied as too complex. > > "Denied" is a bit harsh :) I'll re-examine your e-mails > to see if my preferences change. It's not like your > proposition has been put up to a formal vote, just discussion. OK, I'll officially float backwards compatibility in the form of "It should be possible to use anything that comes out of the JSR in place of an existing java comm implementation". I wonder if "Denied" is too harsh for that one :) Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From ajmas at sympatico.ca Wed Jul 19 19:47:06 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Wed, 19 Jul 2006 21:47:06 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEDDFA.7020108@averillpark.net> References: <44BEDDFA.7020108@averillpark.net> Message-ID: <35101C10-59A5-4F02-AEEE-DB69112F8130@sympatico.ca> Do you see an associated device in /dev ? On 19-Jul-06, at 21:35 , Richard P. Welty wrote: > I'm returning to the use of rxtx after 2 years off doing > things that don't need serial ports. > > I'm trying to get my laptop (fedora core 1) talking to a > set of portable auto scales through a Keyspan USB adapter > (in my past use of rxtx, I had actual serial ports, but those > days are long gone.) I have the keyspan kernel module loaded, > and lsusb shows the device as correctly identified. I'm missing > the bit of magic needed to get rxtx to provide the port > in response to CommPortIdentifier.getPortIdentifiers() > > thanks in advance for any help, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Wed Jul 19 19:54:03 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 19:54:03 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEDC4F.9030403@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> Message-ID: <44BEE23B.30908@ergotech.com> Paul, For the record we're STILL supporting some PersonalJava platforms. We're _almost_ at the point where we can assume that the platforms will have a Collections framework, but routinely compile with a 1.1 check so that we don't make that assumption unnecessarily. Of 50+ non-graphical Factory Automation JavaBeans we have 2 that require Java2 (Reporting and JavaScripting), and we have people asking for a back-port. Embedded platforms don't change in a hurry. Unlike desktop platforms, embedded systems are expected to last 5-10+ years. There are factory automation vendors in the pharmaceutical industry who are buying systems on eBay because that's the FDA validate platform. It must be that make/model, spec'd sometime in the mid-90's. So... If you make an incompatible change TODAY figure we can start using that code _at the earliest_ somewhere around 2012 or the low teens. Are we _really_ the only people on the list supporting embedded/factory automation platforms? Jim Paul Klissner wrote: > Jim Redman wrote: >> Paul Klissner wrote: >>> I'd just like to find another suitable name than javax.comm, unless >>> the JSR wants to start with javax.comm 4.0, since all the previous >>> 'major revisions' are accounted for. javax.serialport? >> Which perhaps brings us back to what are we trying to fix and how badly. > The goals I'm most interested in at the moment are: > > 1. A pluggable platform portmapping scheme wherein each platform > can determine which ports to present to the application, and > preferably as some configurable logical name. > > For example on the Sun Ray thin client platform, if an application > aquiring a view of serial ports available on the system, it will > be informed of Sun Ray serial ports if the application is running > in a session currently directed to that particular Sun Ray unit, > even though the serial port's device node happens to be server-side > deeply nested in a leaf node. If the application is not running on > a Sun Ray the port doesn't show up. The Sun Ray plugin would make > the decision about when and which ports to present to the application. > > 2. Pluggable driver-side interface where multiple platform-specific > drivers can be utilized simultaneously to introduce more flexibility > with the back end. > >> There are a number of 3rd party implementation of Java Comm, at least >> one from IBM - part of what was J9, now Websphere, or something >> (presumbly soon to get a name that has eclipse in it sometime soon). >> Esmertec has one, and there are few others rolling around. > > I have not been advocating gutting the API, since much of it is > perfectly adequate. I'm not totally opposed to making substantial > changes or improvements depending on other people's needs. There's > no reason previous versions of javax.comm need to suddenly disappear > if products need legacy support. > > >> If RXTX is the only implementation of the JSR with no backward >> compatibility, we've just forked Java Serial support and we (for a least >> one) will be worse off. We won't be able to use the new support because >> of a lack of support on J2ME platforms that we have no control over and >> RXTX/current JavaComm will be in maintenance mode or unsupported on all >> other platforms. > > There can't be *that* many platforms this is ported to. And it will > be no javax.usb. Seems like most of the standard platforms will > be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, > JDBC... > >> So, is there any chance of building a compatibility requirement into >> this. To pick are really bad example JDBC has support for a DataSource >> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >> SerialPort on a class not found exception? > > Maybe, or maybe we just let people know what we are doing and > try to figure out how to get their applications ported. Might not > be that difficult. From my standpoint anyway, earthshaking > changes aren't really necessary. Others might disagree. > > Paul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tod at todbot.com Wed Jul 19 19:59:52 2006 From: tod at todbot.com (Tod E. Kurt) Date: Wed, 19 Jul 2006 18:59:52 -0700 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEDDFA.7020108@averillpark.net> References: <44BEDDFA.7020108@averillpark.net> Message-ID: Hi, "lsusb" doesn't show if you have the proper drivers loaded for the specific USB device, just that a USB device is plugged in. The text identifiers sent by the USB device aren't used by the OS except for things like lsusb. Look at the output of "dmesg" or /var/log/messages and see if you have a lines that looks like: keyspan 1-1:1.0: Keyspan 1 port adapter converter detected usb 1-1: Keyspan 1 port adapter converter now attached to ttyUSB0 If you do, then you've got a serial port at "/dev/ttyUSB0", and you can use minicom or whatever (even RXTX!) to play with it. If you get a message like: usb.c: USB device 4 (vend/prod 0x06cd/0x0121) is not claimed by any active driver. Then the USB driver can't find the 'keyspan' driver. If you're sure you have this driver, then hotplug isn't working for some reason. You could try running the command: % sudo modprobe keyspan And see if anything useful happens. You should see the 'keyspan' driver when you type "lsmod" to list the currently loaded kernel modules. -=tod On Jul 19, 2006, at 6:35 PM, Richard P. Welty wrote: > I'm returning to the use of rxtx after 2 years off doing > things that don't need serial ports. > > I'm trying to get my laptop (fedora core 1) talking to a > set of portable auto scales through a Keyspan USB adapter > (in my past use of rxtx, I had actual serial ports, but those > days are long gone.) I have the keyspan kernel module loaded, > and lsusb shows the device as correctly identified. I'm missing > the bit of magic needed to get rxtx to provide the port > in response to CommPortIdentifier.getPortIdentifiers() > > thanks in advance for any help, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From rwelty at suespammers.org Wed Jul 19 20:05:18 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Wed, 19 Jul 2006 22:05:18 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <35101C10-59A5-4F02-AEEE-DB69112F8130@sympatico.ca> References: <44BEDDFA.7020108@averillpark.net> <35101C10-59A5-4F02-AEEE-DB69112F8130@sympatico.ca> Message-ID: <44BEE4DE.9080707@suespammers.org> Andr?-John Mas wrote: > Do you see an associated device in /dev ? Well, there are lots of /dev/ttyUSB devices, there, but nothing jumps out as having been assigned to the keyspan. But then, I'm not that knowledgable about the USB mapping here; this is the first time I've tried to use one this way and I'm on the steep part of the learning curve. richard From rwelty at suespammers.org Wed Jul 19 20:08:20 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Wed, 19 Jul 2006 22:08:20 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: References: <44BEDDFA.7020108@averillpark.net> Message-ID: <44BEE594.50402@suespammers.org> Tod E. Kurt wrote: > Then the USB driver can't find the 'keyspan' driver. If you're sure > you have this driver, then hotplug isn't working for some reason. > You could try running the command: Ok, it looks like the keyspan driver may be the problem; it's having some sort of problem loading it. I'll have to look into this further tomorrow night. thanks, richard From pascal at quies.net Wed Jul 19 20:11:21 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Thu, 20 Jul 2006 04:11:21 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEDFBD.4020404@ergotech.com> References: <44BED7CF.5080405@sun.com> <44BEDFBD.4020404@ergotech.com> Message-ID: <200607200411.22012.pascal@quies.net> Op donderdag 20 juli 2006 03:43, schreef Jim Redman: > Paul Klissner wrote: > > Pascal S. de Kloe wrote: > >> Op donderdag 20 juli 2006 02:03, schreef Jim Redman: > >>> Which perhaps brings us back to what are we trying to fix and how > >>> badly. > >> > >> The initail problem was the license. :) > >> > >> RXTX is sitting in this gnu.comm namespace and is afraid to go to > >> javax.comm. Getting a JSR would solve this problem. > >> > >> And while we're at it we might as well improve the situation with the > >> various platforms. I made some sugestions that where denied as too > >> complex. > > > > "Denied" is a bit harsh :) I'll re-examine your e-mails > > to see if my preferences change. It's not like your > > proposition has been put up to a formal vote, just discussion. > > OK, I'll officially float backwards compatibility in the form of "It > should be possible to use anything that comes out of the JSR in place of > an existing java comm implementation". > > I wonder if "Denied" is too harsh for that one :) > > Jim Hehehe. I don't have any troubles with people voting against my ideas at all so don't worry Paul. :) However, it is exactly the compatibilty thing where Jim is talking about what makes me want to make a *huge* change if any. From jredman at ergotech.com Wed Jul 19 20:25:50 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 20:25:50 -0600 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEE594.50402@suespammers.org> References: <44BEDDFA.7020108@averillpark.net> <44BEE594.50402@suespammers.org> Message-ID: <44BEE9AE.3030200@ergotech.com> Some who remembers this better than me please help. You also need something like: -Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3 When you start the application. This can be put in a properties files (where?). Jim Richard P. Welty wrote: > Tod E. Kurt wrote: > >> Then the USB driver can't find the 'keyspan' driver. If you're sure >> you have this driver, then hotplug isn't working for some reason. >> You could try running the command: > > Ok, it looks like the keyspan driver may be the problem; it's having > some sort of problem loading it. I'll have to look into this further > tomorrow night. > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From ajmas at sympatico.ca Wed Jul 19 20:32:52 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Wed, 19 Jul 2006 22:32:52 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEE9AE.3030200@ergotech.com> References: <44BEDDFA.7020108@averillpark.net> <44BEE594.50402@suespammers.org> <44BEE9AE.3030200@ergotech.com> Message-ID: Are you sure about this? I know on MacOS X no such configuration was needed. If this is indeed true, this is poor design, in this day and age of dynamic devices. On 19-Jul-06, at 22:25 , Jim Redman wrote: > Some who remembers this better than me please help. > > You also need something like: > > -Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyUSB0:/dev/ttyUSB1:/ > dev/ttyUSB2:/dev/ttyUSB3 > > When you start the application. This can be put in a properties files > (where?). > > Jim > > Richard P. Welty wrote: >> Tod E. Kurt wrote: >> >>> Then the USB driver can't find the 'keyspan' driver. If you're sure >>> you have this driver, then hotplug isn't working for some reason. >>> You could try running the command: >> >> Ok, it looks like the keyspan driver may be the problem; it's having >> some sort of problem loading it. I'll have to look into this further >> tomorrow night. >> >> thanks, >> richard >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Wed Jul 19 20:41:01 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Wed, 19 Jul 2006 22:41:01 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEE9AE.3030200@ergotech.com> References: <44BEDDFA.7020108@averillpark.net> <44BEE594.50402@suespammers.org> <44BEE9AE.3030200@ergotech.com> Message-ID: <44BEED3D.5020304@suespammers.org> Jim Redman wrote: > Some who remembers this better than me please help. > > You also need something like: > > -Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3 > > When you start the application. This can be put in a properties files > (where?). Thanks for all the help, guys. Thinking back on how this laptop came to be in its current state, I'm of the opinion a format and complete rebuild with a newer version of Fedora is in order before I waste any more time in diagnosis. The problems I'm seeing clearly have nothing to do with RXTX and everything to do with how many upgrades have been chained together getting this laptop from whereever I started (RH 7.0 or 7.1) to FC1. It could probably be fixed in place, but I shudder to think about the amount of time needed to figure out the proper fix. But the software I'm putting together will need to run on Y2K/XP and Mac OS X, so I'll be following portability and installer discussions on this list rather intently (http://scale-app.sourceforge.net for anyone who cares.) richard From Paul.Klissner at Sun.COM Wed Jul 19 22:53:53 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 21:53:53 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEE23B.30908@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> Message-ID: <44BF0C61.4020900@sun.com> Jim Redman wrote: > Paul, > > For the record we're STILL supporting some PersonalJava platforms. > We're _almost_ at the point where we can assume that the platforms will > have a Collections framework, but routinely compile with a 1.1 check so > that we don't make that assumption unnecessarily. Of 50+ non-graphical > Factory Automation JavaBeans we have 2 that require Java2 (Reporting and > JavaScripting), and we have people asking for a back-port. > > Embedded platforms don't change in a hurry. Unlike desktop platforms, > embedded systems are expected to last 5-10+ years. > > There are factory automation vendors in the pharmaceutical industry who > are buying systems on eBay because that's the FDA validate platform. It > must be that make/model, spec'd sometime in the mid-90's. > > So... If you make an incompatible change TODAY figure we can start using > that code _at the earliest_ somewhere around 2012 or the low teens. > > Are we _really_ the only people on the list supporting embedded/factory > automation platforms? > > Jim Do you provide your own implementation classes? Why can't you just continue to use 2.1 for the embedded platform until 2012 if you're locked down? Are you worried bugs won't get fixed? Sun might consider open sourcing the 2.1 Java source. I can't promise that, but it's been discussed and hasn't met resistance, except from me, because I wasn't super impressed with the code. I can probably be persuaded to champion open sourcing that and going through the process/legal machinations within Sun if it frees us to pursue a JSR for a new generation of javax.comm where we can have a chunk of common code in Open Source and each platform is simply responsible for it's platform specific plugins. I don't have many opinions about this set in stone because there are a lot of technical and pragmatic considerations such as yours the community has that I am probably not aware of or sufficiently sensitive to yet. I don't feel I really have the bird's eye view of all of this yet. The other thing is, I can only offer 10% of my time right now, according to my management, which is why I'm not pushing to be the spec lead for the JSR, and want only to be a participant to represent Sun's interests on the E.G. There is nothing sacred about Sun employees in the JCP as far as a JSR initiated by another entity is concerned. I am not the person everything needs to be cleared through. Ideas I have will pass or fail based on their merit and the community perception just like anyone else's. Paul > > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul Klissner wrote: >>>> I'd just like to find another suitable name than javax.comm, unless >>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>> 'major revisions' are accounted for. javax.serialport? >>> Which perhaps brings us back to what are we trying to fix and how badly. >> The goals I'm most interested in at the moment are: >> >> 1. A pluggable platform portmapping scheme wherein each platform >> can determine which ports to present to the application, and >> preferably as some configurable logical name. >> >> For example on the Sun Ray thin client platform, if an application >> aquiring a view of serial ports available on the system, it will >> be informed of Sun Ray serial ports if the application is running >> in a session currently directed to that particular Sun Ray unit, >> even though the serial port's device node happens to be server-side >> deeply nested in a leaf node. If the application is not running on >> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >> the decision about when and which ports to present to the application. >> >> 2. Pluggable driver-side interface where multiple platform-specific >> drivers can be utilized simultaneously to introduce more flexibility >> with the back end. >> >>> There are a number of 3rd party implementation of Java Comm, at least >>> one from IBM - part of what was J9, now Websphere, or something >>> (presumbly soon to get a name that has eclipse in it sometime soon). >>> Esmertec has one, and there are few others rolling around. >> I have not been advocating gutting the API, since much of it is >> perfectly adequate. I'm not totally opposed to making substantial >> changes or improvements depending on other people's needs. There's >> no reason previous versions of javax.comm need to suddenly disappear >> if products need legacy support. >> >> >>> If RXTX is the only implementation of the JSR with no backward >>> compatibility, we've just forked Java Serial support and we (for a least >>> one) will be worse off. We won't be able to use the new support because >>> of a lack of support on J2ME platforms that we have no control over and >>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>> other platforms. >> There can't be *that* many platforms this is ported to. And it will >> be no javax.usb. Seems like most of the standard platforms will >> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >> JDBC... >> >>> So, is there any chance of building a compatibility requirement into >>> this. To pick are really bad example JDBC has support for a DataSource >>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>> SerialPort on a class not found exception? >> Maybe, or maybe we just let people know what we are doing and >> try to figure out how to get their applications ported. Might not >> be that difficult. From my standpoint anyway, earthshaking >> changes aren't really necessary. Others might disagree. >> >> Paul >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From Paul.Klissner at Sun.COM Thu Jul 20 00:27:41 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 23:27:41 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BF0C61.4020900@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> Message-ID: <44BF225D.80104@sun.com> Paul Klissner wrote: > Jim Redman wrote: >> Paul, >> >> For the record we're STILL supporting some PersonalJava platforms. >> We're _almost_ at the point where we can assume that the platforms will >> have a Collections framework, but routinely compile with a 1.1 check so >> that we don't make that assumption unnecessarily. Of 50+ non-graphical >> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >> JavaScripting), and we have people asking for a back-port. >> >> Embedded platforms don't change in a hurry. Unlike desktop platforms, >> embedded systems are expected to last 5-10+ years. >> >> There are factory automation vendors in the pharmaceutical industry who >> are buying systems on eBay because that's the FDA validate platform. It >> must be that make/model, spec'd sometime in the mid-90's. >> >> So... If you make an incompatible change TODAY figure we can start using >> that code _at the earliest_ somewhere around 2012 or the low teens. >> >> Are we _really_ the only people on the list supporting embedded/factory >> automation platforms? >> >> Jim > > Do you provide your own implementation classes? > > Why can't you just continue to use 2.1 for the embedded platform until > 2012 if you're locked down? Are you worried bugs won't get fixed? > Sun might consider open sourcing the 2.1 Java source. Excuse me, I meant 2.0.3 > I can't promise > that, but it's been discussed and hasn't met resistance, except > from me, because I wasn't super impressed with the code. I can probably > be persuaded to champion open sourcing that and going through the > process/legal machinations within Sun if it frees us to pursue > a JSR for a new generation of javax.comm where we can have a chunk of > common code in Open Source and each platform is simply responsible > for it's platform specific plugins. > > I don't have many opinions about this set in stone because there > are a lot of technical and pragmatic considerations such as yours > the community has that I am probably not aware of or sufficiently > sensitive to yet. I don't feel I really have the bird's eye view > of all of this yet. > > The other thing is, I can only offer 10% of my time right now, > according to my management, which is why I'm not pushing to > be the spec lead for the JSR, and want only to be a participant > to represent Sun's interests on the E.G. There is nothing sacred > about Sun employees in the JCP as far as a JSR initiated by another > entity is concerned. I am not the person everything needs to be > cleared through. Ideas I have will pass or fail based on their > merit and the community perception just like anyone else's. > > Paul > >> Paul Klissner wrote: >>> Jim Redman wrote: >>>> Paul Klissner wrote: >>>>> I'd just like to find another suitable name than javax.comm, unless >>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>> 'major revisions' are accounted for. javax.serialport? >>>> Which perhaps brings us back to what are we trying to fix and how badly. >>> The goals I'm most interested in at the moment are: >>> >>> 1. A pluggable platform portmapping scheme wherein each platform >>> can determine which ports to present to the application, and >>> preferably as some configurable logical name. >>> >>> For example on the Sun Ray thin client platform, if an application >>> aquiring a view of serial ports available on the system, it will >>> be informed of Sun Ray serial ports if the application is running >>> in a session currently directed to that particular Sun Ray unit, >>> even though the serial port's device node happens to be server-side >>> deeply nested in a leaf node. If the application is not running on >>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>> the decision about when and which ports to present to the application. >>> >>> 2. Pluggable driver-side interface where multiple platform-specific >>> drivers can be utilized simultaneously to introduce more flexibility >>> with the back end. >>> >>>> There are a number of 3rd party implementation of Java Comm, at least >>>> one from IBM - part of what was J9, now Websphere, or something >>>> (presumbly soon to get a name that has eclipse in it sometime soon). >>>> Esmertec has one, and there are few others rolling around. >>> I have not been advocating gutting the API, since much of it is >>> perfectly adequate. I'm not totally opposed to making substantial >>> changes or improvements depending on other people's needs. There's >>> no reason previous versions of javax.comm need to suddenly disappear >>> if products need legacy support. >>> >>> >>>> If RXTX is the only implementation of the JSR with no backward >>>> compatibility, we've just forked Java Serial support and we (for a least >>>> one) will be worse off. We won't be able to use the new support because >>>> of a lack of support on J2ME platforms that we have no control over and >>>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>>> other platforms. >>> There can't be *that* many platforms this is ported to. And it will >>> be no javax.usb. Seems like most of the standard platforms will >>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>> JDBC... >>> >>>> So, is there any chance of building a compatibility requirement into >>>> this. To pick are really bad example JDBC has support for a DataSource >>>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>>> SerialPort on a class not found exception? >>> Maybe, or maybe we just let people know what we are doing and >>> try to figure out how to get their applications ported. Might not >>> be that difficult. From my standpoint anyway, earthshaking >>> changes aren't really necessary. Others might disagree. >>> >>> Paul >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Thu Jul 20 00:50:21 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 20 Jul 2006 08:50:21 +0200 Subject: [Rxtx] jcp and jsr Message-ID: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> Hi all, I work with SNIJDER Micro Systems. We're doing embedded Java and just heard about this discussion by way of Ted Kosan from the embedded Java community. We think Jim is right about the compatibility issues for embedded Java platforms. Our own embedded Java platform (see http://www.embedded-web.com ) uses a 3rd party implementation of javax.comm written by the JVM vendor. As Jim says, changes take much longer to propagate in the embedded space. If the 'new' javax.comm is not backwards compatible, embedded JVM vendors (esmertec, IBM, Tao Group, etc.) will probably evaluate whether it makes sense for them to support the new API. Some will eventually adopt it, but that will take time. Some will just stay with the current API, thus increasing the gap between embedded Java developers and desktop Java developers (different APIs to do the same thing) This is a very real problem in our opinion. Also taking into account that many desktop computers nowadays don't even have standard serial ports, I believe that the embedded Java community already gathers a significant share of the potential javax.comm users. I think backwards compatibility should be seriously considered. Best regards, Guillermo Jim Redman wrote: >Paul Klissner wrote: > > I'd just like to find another suitable name than javax.comm, unless > > the JSR wants to start with javax.comm 4.0, since all the previous > > 'major revisions' are accounted for. javax.serialport? > >Which perhaps brings us back to what are we trying to fix and how badly. > >There are a number of 3rd party implementation of Java Comm, at least >one from IBM - part of what was J9, now Websphere, or something >(presumbly soon to get a name that has eclipse in it sometime soon). >Esmertec has one, and there are few others rolling around. > >If RXTX is the only implementation of the JSR with no backward >compatibility, we've just forked Java Serial support and we (for a least >one) will be worse off. We won't be able to use the new support because >of a lack of support on J2ME platforms that we have no control over and >RXTX/current JavaComm will be in maintenance mode or unsupported on all >other platforms. > >So, is there any chance of building a compatibility requirement into >this. To pick are really bad example JDBC has support for a DataSource >or a Driver. Could we have an ExcellentSerialPort with a fallback to a >SerialPort on a class not found exception? > >Jim -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Thu Jul 20 00:57:04 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 20 Jul 2006 08:57:04 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> References: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> Message-ID: <7.0.1.0.0.20060720085221.036d88e8@sms.nl> Paul Klissner wrote: >Jim Redman wrote: > > Paul, > > > > For the record we're STILL supporting some PersonalJava platforms. > > We're _almost_ at the point where we can assume that the platforms will > > have a Collections framework, but routinely compile with a 1.1 check so > > that we don't make that assumption unnecessarily. Of 50+ non-graphical > > Factory Automation JavaBeans we have 2 that require Java2 (Reporting and > > JavaScripting), and we have people asking for a back-port. > > > > Embedded platforms don't change in a hurry. Unlike desktop platforms, > > embedded systems are expected to last 5-10+ years. > > > > There are factory automation vendors in the pharmaceutical industry who > > are buying systems on eBay because that's the FDA validate platform. It > > must be that make/model, spec'd sometime in the mid-90's. > > > > So... If you make an incompatible change TODAY figure we can start using > > that code _at the earliest_ somewhere around 2012 or the low teens. > > > > Are we _really_ the only people on the list supporting embedded/factory > > automation platforms? > > > > Jim > >Do you provide your own implementation classes? > >Why can't you just continue to use 2.1 for the embedded platform until >2012 if you're locked down? Are you worried bugs won't get fixed? If embedded platforms keep using the "old" (current) javax.comm API but the desktop Java world starts to use a new, backwards-incompatible API, then this will result in more trouble for embedded Java application developers as they will no longer be able to use the same API on desktop systems and embedded platforms. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Thu Jul 20 00:59:16 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 20 Jul 2006 08:59:16 +0200 Subject: [Rxtx] jcp and jsr Message-ID: <7.0.1.0.0.20060720085812.036d9c28@sms.nl> Pascal S. de Kloe wrote: >Who is participating anyway? Is it just the four of us? > >Cheers, > >Pascal We would be more than happy to participate if we can be of any help. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From Paul.Klissner at Sun.COM Thu Jul 20 02:23:42 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Thu, 20 Jul 2006 01:23:42 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <7.0.1.0.0.20060720085221.036d88e8@sms.nl> References: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> <7.0.1.0.0.20060720085221.036d88e8@sms.nl> Message-ID: <44BF3D8E.4030705@sun.com> Guillermo Rodriguez Garcia wrote: > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul, >>> >>> For the record we're STILL supporting some PersonalJava platforms. >>> We're _almost_ at the point where we can assume that the platforms will >>> have a Collections framework, but routinely compile with a 1.1 check so >>> that we don't make that assumption unnecessarily. Of 50+ non-graphical >>> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >>> JavaScripting), and we have people asking for a back-port. >>> >>> Embedded platforms don't change in a hurry. Unlike desktop platforms, >>> embedded systems are expected to last 5-10+ years. >>> >>> There are factory automation vendors in the pharmaceutical industry who >>> are buying systems on eBay because that's the FDA validate platform. It >>> must be that make/model, spec'd sometime in the mid-90's. >>> >>> So... If you make an incompatible change TODAY figure we can start using >>> that code _at the earliest_ somewhere around 2012 or the low teens. >>> >>> Are we _really_ the only people on the list supporting embedded/factory >>> automation platforms? >>> >>> Jim >> Do you provide your own implementation classes? >> >> Why can't you just continue to use 2.1 for the embedded platform until >> 2012 if you're locked down? Are you worried bugs won't get fixed? > > If embedded platforms keep using the "old" (current) javax.comm API but > the desktop Java world starts to use a new, backwards-incompatible API, > then this will result in more trouble for embedded Java application > developers as they will no longer be able to use the same API on desktop > systems and embedded platforms. OK, I understand the situation more clearly now. The kinds of changes I'm opting don't seem difficult to design in a backward compatible way. I haven't scrutinized the other requests on the list. I guess it will be interesting to hear what the proponents for other changes have to say. Paul > > Guillermo > > -- > Guillermo Rodriguez Garcia > > Snijder Micro Systems phone +31-493-351020 > G. Rodriguez Garcia fax +31-493-351530 > Visser 25 email guille at sms.nl > NL5751 BL Deurne > The Netherlands http://www.snijder.com > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jul 20 02:46:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 20 Jul 2006 10:46:09 +0200 Subject: [Rxtx] quo vadis API/namespace (Re: jcp and jsr) In-Reply-To: <44BEDC4F.9030403@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> Message-ID: Paul, for the first time in many months, I have the impression, that we have the same agenda;-) If the "driver-level"-api changes however "nobody" will be disappointed. However, regarding the user-level-api I disagree. As fundamental changes to the API have been suggested several times I must be ignoring something. I would be delighted to learn were the current API fails - i.e. what can not be done or is overly complex based on the current API. Of course it is better fun to start something from scratch, but unless there are really substantial gains from completely redesigning an API I don't see the point. The promise of Java is to write once (which I interpret as write against the same API for all platforms). Getting VM providers like esmertec to support a new/replacement API is not a simple task, it requires a business case which for the biggest part simply does not exist. If we keep the javax.comm namespace and keep the "user-level"-api a superset of the current PortIdentifier/Port-api, the same application can work against javax.comm 2.0/3.0/future.x. Of course a factory/wrapping approach can always unify different APIs but this adds more implementation/ testing complexity to every application. So in short: Unless we find a strong argument why javax.comm can't be used I prefer that we keep it. Unless we find a strong feature / use- case that can not be handled with (an extension of) the current CommPort/CommPortIndentifier I'd prefer to keep that as well. Regards, Joachim On 20.07.2006, at 03:28, Paul Klissner wrote: > The goals I'm most interested in at the moment are: > > 1. A pluggable platform portmapping scheme wherein each platform > can determine which ports to present to the application, and > preferably as some configurable logical name. > > For example on the Sun Ray thin client platform, if an application > aquiring a view of serial ports available on the system, it will > be informed of Sun Ray serial ports if the application is running > in a session currently directed to that particular Sun Ray unit, > even though the serial port's device node happens to be server-side > deeply nested in a leaf node. If the application is not running on > a Sun Ray the port doesn't show up. The Sun Ray plugin would make > the decision about when and which ports to present to the application. > > 2. Pluggable driver-side interface where multiple platform-specific > drivers can be utilized simultaneously to introduce more flexibility > with the back end. > >> There are a number of 3rd party implementation of Java Comm, at least >> one from IBM - part of what was J9, now Websphere, or something >> (presumbly soon to get a name that has eclipse in it sometime soon). >> Esmertec has one, and there are few others rolling around. > > I have not been advocating gutting the API, since much of it is > perfectly adequate. I'm not totally opposed to making substantial > changes or improvements depending on other people's needs. There's > no reason previous versions of javax.comm need to suddenly disappear > if products need legacy support. > > >> >> If RXTX is the only implementation of the JSR with no backward >> compatibility, we've just forked Java Serial support and we (for a >> least >> one) will be worse off. We won't be able to use the new support >> because >> of a lack of support on J2ME platforms that we have no control >> over and >> RXTX/current JavaComm will be in maintenance mode or unsupported >> on all >> other platforms. > > There can't be *that* many platforms this is ported to. And it will > be no javax.usb. Seems like most of the standard platforms will > be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, > JDBC... > >> >> So, is there any chance of building a compatibility requirement into >> this. To pick are really bad example JDBC has support for a >> DataSource >> or a Driver. Could we have an ExcellentSerialPort with a fallback >> to a >> SerialPort on a class not found exception? > > Maybe, or maybe we just let people know what we are doing and > try to figure out how to get their applications ported. Might not > be that difficult. From my standpoint anyway, earthshaking > changes aren't really necessary. Others might disagree. > > Paul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Luis.Moreira at jet.uk Thu Jul 20 03:56:38 2006 From: Luis.Moreira at jet.uk (Luis Moreira) Date: Thu, 20 Jul 2006 10:56:38 +0100 Subject: [Rxtx] problems with setting up Rxtx Message-ID: Hi Guys, I have just joined the list and I am very new to JAVA. I am investigating serial communications and I just realised that the JAVAX.COMM package does not support windows anymore. I then looked at alternatives and the RXTX package came up. The problem I have at the moment is not using the classes but, rather how to install RXTX package so that I can use the classes, what do I need to install to support it and how if I write a program using it, do I make it portable. Best regards Luis From lyon at docjava.com Thu Jul 20 07:16:55 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 20 Jul 2006 09:16:55 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> Message-ID: Hi All, There has been some discussion about plugins for serial communications. As I see it, what Java really needs is a NativeLibraryManager. This is a rather much larger charge than "just" RXTX. The RXTX basic mode of operation is that we associate static blocks of code with a "System.load". Failure occurs when the class containing such a block of code is loaded AND the native library is not found. What are some of the options? 1. Do nothing, let the program fail with an exception. 2. try to catch an UnsatisfiedLinkError as a part of making the driver. 3. Search the java.library.path to see if the driver is present (i.e., guard the input). 4. Other?? In the case of either step 2 or 3, we need to fix the lack of a library. What are the options for fixing a library? 1. Do nothing, but give the user an interesting error with instructions on what to do. 2. Attempt to find the library on the file system (perhaps with user help). 3. Attempt to download the library and install it (perhaps with user permission). 4. Attempt to internalize the library as a UUEncoded serialized object and install it (better ask the user, again!). 5. Other?? My attempts at making RXTX more robust on install have led to mixed results. Altering the java.library.path has led to a bit of byte-code engineering (as this is loaded at JVM start time). Internalizing of libraries is attractive, until you realize how many libraries are involved. Dyanmically changing libraries during development is very attractive, for developers, who are changing libraries often. It is also very interesting for those who want to control the version of the libraries in the run-time. For example, something like the following will guard the input to the system load: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getInstance() { if (driver != null) return driver; if (!NativeLibDetect.isLibInPath("rxtxSerial")) fixDriver(); if (NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } At the other extreme, something like: try { System.load("rxtxSerial"); } catch (UnsatisfiedLinkError e) { System.out.println("could not load lib"); } Will at least attempt to handle the missing lib, in a simple way. Perhaps some error handling is better than none. To fix the driver, I can beam it down from a web page, using: private static void fixDriver() { File tmpDir = new File( SystemUtils.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); try { UrlUtils.getUrl(getResourceUrl(), tmpDir); String nativeLib = getNativeLibName(); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(nativeLib); if (b == null) { System.out.println("could not get:" + nativeLib); return; } File f = getRxtxHome(); Futil.writeBytes(getRxtxLibFile(), b); SystemUtils.appendJavaLibraryPath(f); } catch (IOException e) { e.printStackTrace(); } } Where the libraries are stored in the hacky dispatch: private static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isMacOs()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); System.out.println("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } Appending to the library path is tricky, at run-time: public static void appendJavaLibraryPath(File p) { if (p.isFile()) System.out.println("warning: appendJavaLibraryPath:" + "only directories are findable:"+p); System.out.println("appending:"+p+" to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:"+System.getProperty(javaLibraryPa th)); } The key is altering the core visibility of the sys_paths in the class loader: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } No, it isn't simple (nor even easy) but once the API is set we have a kind of NativeLibraryManager that helps us to make libraries, like RXTX more robust. As far as I know, there is nothing quite like it (unless you all know differently). Is there any interest in this? Forgive me if this is too far off the beaten path, but the inability to load a native library remains a source of fragility in the RXTX system, IMHO. Thanks for your thoughts! - Doug From jredman at ergotech.com Thu Jul 20 08:06:41 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 20 Jul 2006 08:06:41 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BF0C61.4020900@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> Message-ID: <44BF8DF1.4040101@ergotech.com> Paul, The issue with a new, incompatible implementation is, as you've identified below, is support for the old API. Open sourcing would be helpful, but then someone (us?) would have to maintain the source through changing versions of Window, and RXTX on Linux platforms. Or we'd have to have to versions of our codebase, which doesn't appeal too much. The maintenance issue is not impossible, but I think that in essence I'm agreeing with a comment you made earlier. IF a huge change is required, then lets get on with it. However, if the changes that are required are just extensions and enhancements, with some low-level re-engineering, then can we keep a compatible high-level API so that people needing the new features can use an extended API and those who need cross-platform compatibility can continue to use the existing features. Jim Paul Klissner wrote: > Jim Redman wrote: >> Paul, >> >> For the record we're STILL supporting some PersonalJava platforms. >> We're _almost_ at the point where we can assume that the platforms will >> have a Collections framework, but routinely compile with a 1.1 check so >> that we don't make that assumption unnecessarily. Of 50+ non-graphical >> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >> JavaScripting), and we have people asking for a back-port. >> >> Embedded platforms don't change in a hurry. Unlike desktop platforms, >> embedded systems are expected to last 5-10+ years. >> >> There are factory automation vendors in the pharmaceutical industry who >> are buying systems on eBay because that's the FDA validate platform. It >> must be that make/model, spec'd sometime in the mid-90's. >> >> So... If you make an incompatible change TODAY figure we can start using >> that code _at the earliest_ somewhere around 2012 or the low teens. >> >> Are we _really_ the only people on the list supporting embedded/factory >> automation platforms? >> >> Jim > > Do you provide your own implementation classes? > > Why can't you just continue to use 2.1 for the embedded platform until > 2012 if you're locked down? Are you worried bugs won't get fixed? > Sun might consider open sourcing the 2.1 Java source. I can't promise > that, but it's been discussed and hasn't met resistance, except > from me, because I wasn't super impressed with the code. I can probably > be persuaded to champion open sourcing that and going through the > process/legal machinations within Sun if it frees us to pursue > a JSR for a new generation of javax.comm where we can have a chunk of > common code in Open Source and each platform is simply responsible > for it's platform specific plugins. > > I don't have many opinions about this set in stone because there > are a lot of technical and pragmatic considerations such as yours > the community has that I am probably not aware of or sufficiently > sensitive to yet. I don't feel I really have the bird's eye view > of all of this yet. > > The other thing is, I can only offer 10% of my time right now, > according to my management, which is why I'm not pushing to > be the spec lead for the JSR, and want only to be a participant > to represent Sun's interests on the E.G. There is nothing sacred > about Sun employees in the JCP as far as a JSR initiated by another > entity is concerned. I am not the person everything needs to be > cleared through. Ideas I have will pass or fail based on their > merit and the community perception just like anyone else's. > > Paul > >> Paul Klissner wrote: >>> Jim Redman wrote: >>>> Paul Klissner wrote: >>>>> I'd just like to find another suitable name than javax.comm, unless >>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>> 'major revisions' are accounted for. javax.serialport? >>>> Which perhaps brings us back to what are we trying to fix and how badly. >>> The goals I'm most interested in at the moment are: >>> >>> 1. A pluggable platform portmapping scheme wherein each platform >>> can determine which ports to present to the application, and >>> preferably as some configurable logical name. >>> >>> For example on the Sun Ray thin client platform, if an application >>> aquiring a view of serial ports available on the system, it will >>> be informed of Sun Ray serial ports if the application is running >>> in a session currently directed to that particular Sun Ray unit, >>> even though the serial port's device node happens to be server-side >>> deeply nested in a leaf node. If the application is not running on >>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>> the decision about when and which ports to present to the application. >>> >>> 2. Pluggable driver-side interface where multiple platform-specific >>> drivers can be utilized simultaneously to introduce more flexibility >>> with the back end. >>> >>>> There are a number of 3rd party implementation of Java Comm, at least >>>> one from IBM - part of what was J9, now Websphere, or something >>>> (presumbly soon to get a name that has eclipse in it sometime soon). >>>> Esmertec has one, and there are few others rolling around. >>> I have not been advocating gutting the API, since much of it is >>> perfectly adequate. I'm not totally opposed to making substantial >>> changes or improvements depending on other people's needs. There's >>> no reason previous versions of javax.comm need to suddenly disappear >>> if products need legacy support. >>> >>> >>>> If RXTX is the only implementation of the JSR with no backward >>>> compatibility, we've just forked Java Serial support and we (for a least >>>> one) will be worse off. We won't be able to use the new support because >>>> of a lack of support on J2ME platforms that we have no control over and >>>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>>> other platforms. >>> There can't be *that* many platforms this is ported to. And it will >>> be no javax.usb. Seems like most of the standard platforms will >>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>> JDBC... >>> >>>> So, is there any chance of building a compatibility requirement into >>>> this. To pick are really bad example JDBC has support for a DataSource >>>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>>> SerialPort on a class not found exception? >>> Maybe, or maybe we just let people know what we are doing and >>> try to figure out how to get their applications ported. Might not >>> be that difficult. From my standpoint anyway, earthshaking >>> changes aren't really necessary. Others might disagree. >>> >>> Paul >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Paul.Klissner at Sun.COM Thu Jul 20 09:31:38 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Thu, 20 Jul 2006 08:31:38 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BF8DF1.4040101@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> <44BF8DF1.4040101@ergotech.com> Message-ID: <44BFA1DA.10301@sun.com> Jim Redman wrote: > Paul, > > The issue with a new, incompatible implementation is, as you've > identified below, is support for the old API. Open sourcing would be > helpful, but then someone (us?) would have to maintain the source > through changing versions of Window, and RXTX on Linux platforms. Or > we'd have to have to versions of our codebase, which doesn't appeal too > much. > > The maintenance issue is not impossible, but I think that in essence I'm > agreeing with a comment you made earlier. > > IF a huge change is required, then lets get on with it. However, if the > changes that are required are just extensions and enhancements, with > some low-level re-engineering, then can we keep a compatible high-level > API so that people needing the new features can use an extended API and > those who need cross-platform compatibility can continue to use the > existing features. > > Jim Guillermo made a crystal clear case and I understand the problem that that will be caused by forking the API in any sense of the word. I only want to uphold Sun's interests and resolve the problems we ran into with the RXTX community when Sun added portmapping to 3.0, which was not easily undone and was implemented as kind of a hack because it wasn't directly supported by the javax.comm architection. As I mentioned previously the changes I want to make have primarily to do with adding platform-specific portmapping via plugins, and supporting multiple javax.comm backend drivers on the same host (some ports would use one driver, others ports might use another). Also I'd like to address some bugfixes that were done in Sun's version 3.0 (including better error reporting, and more robust code for locating configuration files). Besides that, I'm not aware of any deficiences, but I've glanced other e-mails where people have suggested some. It would be good to get a summary of everyone's wishes. I've stated mine. I given much thought to what it would take to properly address EIA-422, EIA-423 and EIA-485 (if any); but those would probably be extensions. Sounds like the differences might be transparent to the API. I'll look into that more. Paul > > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul, >>> >>> For the record we're STILL supporting some PersonalJava platforms. >>> We're _almost_ at the point where we can assume that the platforms will >>> have a Collections framework, but routinely compile with a 1.1 check so >>> that we don't make that assumption unnecessarily. Of 50+ non-graphical >>> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >>> JavaScripting), and we have people asking for a back-port. >>> >>> Embedded platforms don't change in a hurry. Unlike desktop platforms, >>> embedded systems are expected to last 5-10+ years. >>> >>> There are factory automation vendors in the pharmaceutical industry who >>> are buying systems on eBay because that's the FDA validate platform. It >>> must be that make/model, spec'd sometime in the mid-90's. >>> >>> So... If you make an incompatible change TODAY figure we can start using >>> that code _at the earliest_ somewhere around 2012 or the low teens. >>> >>> Are we _really_ the only people on the list supporting embedded/factory >>> automation platforms? >>> >>> Jim >> Do you provide your own implementation classes? >> >> Why can't you just continue to use 2.1 for the embedded platform until >> 2012 if you're locked down? Are you worried bugs won't get fixed? >> Sun might consider open sourcing the 2.1 Java source. I can't promise >> that, but it's been discussed and hasn't met resistance, except >> from me, because I wasn't super impressed with the code. I can probably >> be persuaded to champion open sourcing that and going through the >> process/legal machinations within Sun if it frees us to pursue >> a JSR for a new generation of javax.comm where we can have a chunk of >> common code in Open Source and each platform is simply responsible >> for it's platform specific plugins. >> >> I don't have many opinions about this set in stone because there >> are a lot of technical and pragmatic considerations such as yours >> the community has that I am probably not aware of or sufficiently >> sensitive to yet. I don't feel I really have the bird's eye view >> of all of this yet. >> >> The other thing is, I can only offer 10% of my time right now, >> according to my management, which is why I'm not pushing to >> be the spec lead for the JSR, and want only to be a participant >> to represent Sun's interests on the E.G. There is nothing sacred >> about Sun employees in the JCP as far as a JSR initiated by another >> entity is concerned. I am not the person everything needs to be >> cleared through. Ideas I have will pass or fail based on their >> merit and the community perception just like anyone else's. >> >> Paul >> >>> Paul Klissner wrote: >>>> Jim Redman wrote: >>>>> Paul Klissner wrote: >>>>>> I'd just like to find another suitable name than javax.comm, unless >>>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>>> 'major revisions' are accounted for. javax.serialport? >>>>> Which perhaps brings us back to what are we trying to fix and how badly. >>>> The goals I'm most interested in at the moment are: >>>> >>>> 1. A pluggable platform portmapping scheme wherein each platform >>>> can determine which ports to present to the application, and >>>> preferably as some configurable logical name. >>>> >>>> For example on the Sun Ray thin client platform, if an application >>>> aquiring a view of serial ports available on the system, it will >>>> be informed of Sun Ray serial ports if the application is running >>>> in a session currently directed to that particular Sun Ray unit, >>>> even though the serial port's device node happens to be server-side >>>> deeply nested in a leaf node. If the application is not running on >>>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>>> the decision about when and which ports to present to the application. >>>> >>>> 2. Pluggable driver-side interface where multiple platform-specific >>>> drivers can be utilized simultaneously to introduce more flexibility >>>> with the back end. >>>> >>>>> There are a number of 3rd party implementation of Java Comm, at least >>>>> one from IBM - part of what was J9, now Websphere, or something >>>>> (presumbly soon to get a name that has eclipse in it sometime soon). >>>>> Esmertec has one, and there are few others rolling around. >>>> I have not been advocating gutting the API, since much of it is >>>> perfectly adequate. I'm not totally opposed to making substantial >>>> changes or improvements depending on other people's needs. There's >>>> no reason previous versions of javax.comm need to suddenly disappear >>>> if products need legacy support. >>>> >>>> >>>>> If RXTX is the only implementation of the JSR with no backward >>>>> compatibility, we've just forked Java Serial support and we (for a least >>>>> one) will be worse off. We won't be able to use the new support because >>>>> of a lack of support on J2ME platforms that we have no control over and >>>>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>>>> other platforms. >>>> There can't be *that* many platforms this is ported to. And it will >>>> be no javax.usb. Seems like most of the standard platforms will >>>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>>> JDBC... >>>> >>>>> So, is there any chance of building a compatibility requirement into >>>>> this. To pick are really bad example JDBC has support for a DataSource >>>>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>>>> SerialPort on a class not found exception? >>>> Maybe, or maybe we just let people know what we are doing and >>>> try to figure out how to get their applications ported. Might not >>>> be that difficult. From my standpoint anyway, earthshaking >>>> changes aren't really necessary. Others might disagree. >>>> >>>> Paul >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From Paul.Klissner at Sun.COM Thu Jul 20 09:45:11 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Thu, 20 Jul 2006 08:45:11 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BFA1DA.10301@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> <44BF8DF1.4040101@ergotech.com> <44BFA1DA.10301@sun.com> Message-ID: <44BFA507.3020001@sun.com> Paul Klissner wrote: > Jim Redman wrote: >> Paul, >> >> The issue with a new, incompatible implementation is, as you've >> identified below, is support for the old API. Open sourcing would be >> helpful, but then someone (us?) would have to maintain the source >> through changing versions of Window, and RXTX on Linux platforms. Or >> we'd have to have to versions of our codebase, which doesn't appeal >> too much. >> >> The maintenance issue is not impossible, but I think that in essence >> I'm agreeing with a comment you made earlier. >> >> IF a huge change is required, then lets get on with it. However, if >> the changes that are required are just extensions and enhancements, >> with some low-level re-engineering, then can we keep a compatible >> high-level API so that people needing the new features can use an >> extended API and those who need cross-platform compatibility can >> continue to use the existing features. >> >> Jim > > Guillermo made a crystal clear case and I understand the problem > that that will be caused by forking the API in any sense of the > word. I only want to uphold Sun's interests and resolve the problems > we ran into with the RXTX community when Sun added portmapping > to 3.0, which was not easily undone and was implemented as kind > of a hack because it wasn't directly supported by the javax.comm > architection. ^^^"architecture" > > As I mentioned previously the changes I want to make have primarily > to do with adding platform-specific portmapping via plugins, > and supporting multiple javax.comm backend drivers on the same > host (some ports would use one driver, others ports might use another). > > Also I'd like to address some bugfixes that were done in Sun's > version 3.0 (including better error reporting, and more robust > code for locating configuration files). Besides that, I'm not > aware of any deficiences, but I've glanced other e-mails where > people have suggested some. It would be good to get a summary > of everyone's wishes. I've stated mine. > > I given much thought to what it would take to properly address ^^^haven't > EIA-422, EIA-423 and EIA-485 (if any); but those would > probably be extensions. Sounds like the differences might > be transparent to the API. I'll look into that more. > > Paul > > >> >> Paul Klissner wrote: >>> Jim Redman wrote: >>>> Paul, >>>> >>>> For the record we're STILL supporting some PersonalJava platforms. >>>> We're _almost_ at the point where we can assume that the platforms >>>> will have a Collections framework, but routinely compile with a 1.1 >>>> check so that we don't make that assumption unnecessarily. Of 50+ >>>> non-graphical Factory Automation JavaBeans we have 2 that require >>>> Java2 (Reporting and JavaScripting), and we have people asking for a >>>> back-port. >>>> >>>> Embedded platforms don't change in a hurry. Unlike desktop >>>> platforms, embedded systems are expected to last 5-10+ years. >>>> >>>> There are factory automation vendors in the pharmaceutical industry >>>> who are buying systems on eBay because that's the FDA validate >>>> platform. It must be that make/model, spec'd sometime in the mid-90's. >>>> >>>> So... If you make an incompatible change TODAY figure we can start >>>> using that code _at the earliest_ somewhere around 2012 or the low >>>> teens. >>>> >>>> Are we _really_ the only people on the list supporting >>>> embedded/factory automation platforms? >>>> >>>> Jim >>> Do you provide your own implementation classes? >>> >>> Why can't you just continue to use 2.1 for the embedded platform until >>> 2012 if you're locked down? Are you worried bugs won't get fixed? >>> Sun might consider open sourcing the 2.1 Java source. I can't promise >>> that, but it's been discussed and hasn't met resistance, except >>> from me, because I wasn't super impressed with the code. I can probably >>> be persuaded to champion open sourcing that and going through the >>> process/legal machinations within Sun if it frees us to pursue >>> a JSR for a new generation of javax.comm where we can have a chunk of >>> common code in Open Source and each platform is simply responsible >>> for it's platform specific plugins. >>> >>> I don't have many opinions about this set in stone because there >>> are a lot of technical and pragmatic considerations such as yours >>> the community has that I am probably not aware of or sufficiently >>> sensitive to yet. I don't feel I really have the bird's eye view >>> of all of this yet. >>> >>> The other thing is, I can only offer 10% of my time right now, >>> according to my management, which is why I'm not pushing to >>> be the spec lead for the JSR, and want only to be a participant >>> to represent Sun's interests on the E.G. There is nothing sacred >>> about Sun employees in the JCP as far as a JSR initiated by another >>> entity is concerned. I am not the person everything needs to be >>> cleared through. Ideas I have will pass or fail based on their >>> merit and the community perception just like anyone else's. >>> >>> Paul >>> >>>> Paul Klissner wrote: >>>>> Jim Redman wrote: >>>>>> Paul Klissner wrote: >>>>>>> I'd just like to find another suitable name than javax.comm, unless >>>>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>>>> 'major revisions' are accounted for. javax.serialport? >>>>>> Which perhaps brings us back to what are we trying to fix and how >>>>>> badly. >>>>> The goals I'm most interested in at the moment are: >>>>> >>>>> 1. A pluggable platform portmapping scheme wherein each platform >>>>> can determine which ports to present to the application, and >>>>> preferably as some configurable logical name. >>>>> >>>>> For example on the Sun Ray thin client platform, if an application >>>>> aquiring a view of serial ports available on the system, it will >>>>> be informed of Sun Ray serial ports if the application is running >>>>> in a session currently directed to that particular Sun Ray unit, >>>>> even though the serial port's device node happens to be server-side >>>>> deeply nested in a leaf node. If the application is not running on >>>>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>>>> the decision about when and which ports to present to the application. >>>>> >>>>> 2. Pluggable driver-side interface where multiple platform-specific >>>>> drivers can be utilized simultaneously to introduce more flexibility >>>>> with the back end. >>>>> >>>>>> There are a number of 3rd party implementation of Java Comm, at >>>>>> least one from IBM - part of what was J9, now Websphere, or >>>>>> something (presumbly soon to get a name that has eclipse in it >>>>>> sometime soon). Esmertec has one, and there are few others rolling >>>>>> around. >>>>> I have not been advocating gutting the API, since much of it is >>>>> perfectly adequate. I'm not totally opposed to making substantial >>>>> changes or improvements depending on other people's needs. There's >>>>> no reason previous versions of javax.comm need to suddenly disappear >>>>> if products need legacy support. >>>>> >>>>> >>>>>> If RXTX is the only implementation of the JSR with no backward >>>>>> compatibility, we've just forked Java Serial support and we (for a >>>>>> least one) will be worse off. We won't be able to use the new >>>>>> support because of a lack of support on J2ME platforms that we >>>>>> have no control over and RXTX/current JavaComm will be in >>>>>> maintenance mode or unsupported on all other platforms. >>>>> There can't be *that* many platforms this is ported to. And it will >>>>> be no javax.usb. Seems like most of the standard platforms will >>>>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>>>> JDBC... >>>>> >>>>>> So, is there any chance of building a compatibility requirement >>>>>> into this. To pick are really bad example JDBC has support for a >>>>>> DataSource or a Driver. Could we have an ExcellentSerialPort with >>>>>> a fallback to a SerialPort on a class not found exception? >>>>> Maybe, or maybe we just let people know what we are doing and >>>>> try to figure out how to get their applications ported. Might not >>>>> be that difficult. From my standpoint anyway, earthshaking >>>>> changes aren't really necessary. Others might disagree. >>>>> >>>>> Paul >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From jredman at ergotech.com Thu Jul 20 10:30:01 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 20 Jul 2006 10:30:01 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BFA507.3020001@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> <44BF8DF1.4040101@ergotech.com> <44BFA1DA.10301@sun.com> <44BFA507.3020001@sun.com> Message-ID: <44BFAF89.5010003@ergotech.com> Thast what hapens if you post late at nihgt nad erly in the moning as wel. :) Paul Klissner wrote: > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul, >>> >>> The issue with a new, incompatible implementation is, as you've >>> identified below, is support for the old API. Open sourcing would be >>> helpful, but then someone (us?) would have to maintain the source >>> through changing versions of Window, and RXTX on Linux platforms. Or >>> we'd have to have to versions of our codebase, which doesn't appeal >>> too much. >>> >>> The maintenance issue is not impossible, but I think that in essence >>> I'm agreeing with a comment you made earlier. >>> >>> IF a huge change is required, then lets get on with it. However, if >>> the changes that are required are just extensions and enhancements, >>> with some low-level re-engineering, then can we keep a compatible >>> high-level API so that people needing the new features can use an >>> extended API and those who need cross-platform compatibility can >>> continue to use the existing features. >>> >>> Jim >> Guillermo made a crystal clear case and I understand the problem >> that that will be caused by forking the API in any sense of the >> word. I only want to uphold Sun's interests and resolve the problems >> we ran into with the RXTX community when Sun added portmapping >> to 3.0, which was not easily undone and was implemented as kind >> of a hack because it wasn't directly supported by the javax.comm >> architection. > ^^^"architecture" >> As I mentioned previously the changes I want to make have primarily >> to do with adding platform-specific portmapping via plugins, >> and supporting multiple javax.comm backend drivers on the same >> host (some ports would use one driver, others ports might use another). >> >> Also I'd like to address some bugfixes that were done in Sun's >> version 3.0 (including better error reporting, and more robust >> code for locating configuration files). Besides that, I'm not >> aware of any deficiences, but I've glanced other e-mails where >> people have suggested some. It would be good to get a summary >> of everyone's wishes. I've stated mine. >> >> I given much thought to what it would take to properly address > ^^^haven't >> EIA-422, EIA-423 and EIA-485 (if any); but those would >> probably be extensions. Sounds like the differences might >> be transparent to the API. I'll look into that more. >> >> Paul >> >> >>> Paul Klissner wrote: >>>> Jim Redman wrote: >>>>> Paul, >>>>> >>>>> For the record we're STILL supporting some PersonalJava platforms. >>>>> We're _almost_ at the point where we can assume that the platforms >>>>> will have a Collections framework, but routinely compile with a 1.1 >>>>> check so that we don't make that assumption unnecessarily. Of 50+ >>>>> non-graphical Factory Automation JavaBeans we have 2 that require >>>>> Java2 (Reporting and JavaScripting), and we have people asking for a >>>>> back-port. >>>>> >>>>> Embedded platforms don't change in a hurry. Unlike desktop >>>>> platforms, embedded systems are expected to last 5-10+ years. >>>>> >>>>> There are factory automation vendors in the pharmaceutical industry >>>>> who are buying systems on eBay because that's the FDA validate >>>>> platform. It must be that make/model, spec'd sometime in the mid-90's. >>>>> >>>>> So... If you make an incompatible change TODAY figure we can start >>>>> using that code _at the earliest_ somewhere around 2012 or the low >>>>> teens. >>>>> >>>>> Are we _really_ the only people on the list supporting >>>>> embedded/factory automation platforms? >>>>> >>>>> Jim >>>> Do you provide your own implementation classes? >>>> >>>> Why can't you just continue to use 2.1 for the embedded platform until >>>> 2012 if you're locked down? Are you worried bugs won't get fixed? >>>> Sun might consider open sourcing the 2.1 Java source. I can't promise >>>> that, but it's been discussed and hasn't met resistance, except >>>> from me, because I wasn't super impressed with the code. I can probably >>>> be persuaded to champion open sourcing that and going through the >>>> process/legal machinations within Sun if it frees us to pursue >>>> a JSR for a new generation of javax.comm where we can have a chunk of >>>> common code in Open Source and each platform is simply responsible >>>> for it's platform specific plugins. >>>> >>>> I don't have many opinions about this set in stone because there >>>> are a lot of technical and pragmatic considerations such as yours >>>> the community has that I am probably not aware of or sufficiently >>>> sensitive to yet. I don't feel I really have the bird's eye view >>>> of all of this yet. >>>> >>>> The other thing is, I can only offer 10% of my time right now, >>>> according to my management, which is why I'm not pushing to >>>> be the spec lead for the JSR, and want only to be a participant >>>> to represent Sun's interests on the E.G. There is nothing sacred >>>> about Sun employees in the JCP as far as a JSR initiated by another >>>> entity is concerned. I am not the person everything needs to be >>>> cleared through. Ideas I have will pass or fail based on their >>>> merit and the community perception just like anyone else's. >>>> >>>> Paul >>>> >>>>> Paul Klissner wrote: >>>>>> Jim Redman wrote: >>>>>>> Paul Klissner wrote: >>>>>>>> I'd just like to find another suitable name than javax.comm, unless >>>>>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>>>>> 'major revisions' are accounted for. javax.serialport? >>>>>>> Which perhaps brings us back to what are we trying to fix and how >>>>>>> badly. >>>>>> The goals I'm most interested in at the moment are: >>>>>> >>>>>> 1. A pluggable platform portmapping scheme wherein each platform >>>>>> can determine which ports to present to the application, and >>>>>> preferably as some configurable logical name. >>>>>> >>>>>> For example on the Sun Ray thin client platform, if an application >>>>>> aquiring a view of serial ports available on the system, it will >>>>>> be informed of Sun Ray serial ports if the application is running >>>>>> in a session currently directed to that particular Sun Ray unit, >>>>>> even though the serial port's device node happens to be server-side >>>>>> deeply nested in a leaf node. If the application is not running on >>>>>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>>>>> the decision about when and which ports to present to the application. >>>>>> >>>>>> 2. Pluggable driver-side interface where multiple platform-specific >>>>>> drivers can be utilized simultaneously to introduce more flexibility >>>>>> with the back end. >>>>>> >>>>>>> There are a number of 3rd party implementation of Java Comm, at >>>>>>> least one from IBM - part of what was J9, now Websphere, or >>>>>>> something (presumbly soon to get a name that has eclipse in it >>>>>>> sometime soon). Esmertec has one, and there are few others rolling >>>>>>> around. >>>>>> I have not been advocating gutting the API, since much of it is >>>>>> perfectly adequate. I'm not totally opposed to making substantial >>>>>> changes or improvements depending on other people's needs. There's >>>>>> no reason previous versions of javax.comm need to suddenly disappear >>>>>> if products need legacy support. >>>>>> >>>>>> >>>>>>> If RXTX is the only implementation of the JSR with no backward >>>>>>> compatibility, we've just forked Java Serial support and we (for a >>>>>>> least one) will be worse off. We won't be able to use the new >>>>>>> support because of a lack of support on J2ME platforms that we >>>>>>> have no control over and RXTX/current JavaComm will be in >>>>>>> maintenance mode or unsupported on all other platforms. >>>>>> There can't be *that* many platforms this is ported to. And it will >>>>>> be no javax.usb. Seems like most of the standard platforms will >>>>>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>>>>> JDBC... >>>>>> >>>>>>> So, is there any chance of building a compatibility requirement >>>>>>> into this. To pick are really bad example JDBC has support for a >>>>>>> DataSource or a Driver. Could we have an ExcellentSerialPort with >>>>>>> a fallback to a SerialPort on a class not found exception? >>>>>> Maybe, or maybe we just let people know what we are doing and >>>>>> try to figure out how to get their applications ported. Might not >>>>>> be that difficult. From my standpoint anyway, earthshaking >>>>>> changes aren't really necessary. Others might disagree. >>>>>> >>>>>> Paul >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Thu Jul 20 10:31:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 20 Jul 2006 10:31:57 -0600 (MDT) Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEA802.7060508@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: > PROJECT SCOPE: > ------------- > > Also, we should think carefully about what the scope of > this project would be. Should it be javax."comm" which > handles both serial and parallel (is parallel going by the > wayside). Should it be split into two project: > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > > Should we differentiate between single-ended serial > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > quasi-multidrop and full multidrop busses such as > EIA422, EIA432 and EIA485? If we really were to > add I2C support to the API, we'd have to delve into > the semantics more, because there could be some > implicit decoding of the bus the API users would > want to see. > Hi Paul The way RXTX works, which is a fair representation of the people using the API, is complete support for RIA232, minimal support for IEEE1284. From what I understand, Sun was going along the same lines. If we combined both projects, we would have half a parallel port implementation. I see maybe 4 requests for features not in the parallel support a year. The other protocols should not be limited by a JSR which is going to be focused upon serial port interests. The IEA485 hacks in RXTX along with I2C and Raw should _not_ be considered a strong basis for extending the API to cover these protocols. If people want to do real implementations, they should not face a 'standard' which wasnt really focused upon their interests. I think we understand the parallel port issues fairly well but have not implemented many features and I don't know if we would. So a versatile API is favorable but I do not think we have the proper community to represent much more than Serial. We could provide a framework or maybe just a model for further work with other standards. -- Trent Jarvi tjarvi at qbang.org From naranjo.manuel at gmail.com Thu Jul 20 10:49:33 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Thu, 20 Jul 2006 13:49:33 -0300 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <44BFB41D.4010604@gmail.com> Trent Jarvi wrote: >> PROJECT SCOPE: >> ------------- >> >> Also, we should think carefully about what the scope of >> this project would be. Should it be javax."comm" which >> handles both serial and parallel (is parallel going by the >> wayside). Should it be split into two project: >> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >> >> Should we differentiate between single-ended serial >> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >> quasi-multidrop and full multidrop busses such as >> EIA422, EIA432 and EIA485? If we really were to >> add I2C support to the API, we'd have to delve into >> the semantics more, because there could be some >> implicit decoding of the bus the API users would >> want to see. >> > > Hi Paul > > The way RXTX works, which is a fair representation of the people using the > API, is complete support for RIA232, minimal support for IEEE1284. From > what I understand, Sun was going along the same lines. If we combined > both projects, we would have half a parallel port implementation. I see > maybe 4 requests for features not in the parallel support a year. > > The other protocols should not be limited by a JSR which is going to be > focused upon serial port interests. The IEA485 hacks in RXTX along with > I2C and Raw should _not_ be considered a strong basis for extending the > API to cover these protocols. If people want to do real implementations, > they should not face a 'standard' which wasnt really focused upon their > interests. I think we understand the parallel port issues fairly well but > have not implemented many features and I don't know if we would. > > So a versatile API is favorable but I do not think we have the proper > community to represent much more than Serial. We could provide a > framework or maybe just a model for further work with other standards. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Hi, I agree with Trent, as far as I have seen most projects that were using RXTX and Java Comm where designed to work only with Serial Ports. What is fact is that a Parallel port can not be modeled at all like a Serial Port, except that they both expose and Input Stream and an Output Stream. As I have read there is a huge market of embedded applications using port accessing. We could take two different aproaches with the JSR, one could be define a way to access every kind of port independent of the implementation of the port himself. We could access Serial, Parallel, I2C, USB, etc. But we will have huge problems with it, because we will have to face a lot of low level programming which of course will be platform dependent, and that is were the write one use everywhere of Java could dye. The other approach is to define an Api that only supports Serial Ports, compatible with the one that is defined in javax.comm 2.0, and make some classes that extend that packages, maybe even in another package, like AWT and JSWING do. We then could eventually extend to other kinds of ports but that will require a lot of work more. I'm not a person specialized on Informatical Engineering, so I do not think I can give a hand on Low Level programming, I do can help with the Java part, debugging and testing. Regards, Manuel From brian at mbari.org Thu Jul 20 11:19:33 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 20 Jul 2006 10:19:33 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <8BFCAB48-6302-44CD-ABF0-560BC04AD26E@mbari.org> > The way RXTX works, which is a fair representation of the people > using the > API, is complete support for RIA232, minimal support for IEEE1284. > From > what I understand, Sun was going along the same lines. If we combined > both projects, we would have half a parallel port implementation. > I see > maybe 4 requests for features not in the parallel support a year. > > The other protocols should not be limited by a JSR which is going > to be > focused upon serial port interests. The IEA485 hacks in RXTX along > with > I2C and Raw should _not_ be considered a strong basis for extending > the > API to cover these protocols. If people want to do real > implementations, > they should not face a 'standard' which wasnt really focused upon > their > interests. I think we understand the parallel port issues fairly > well but > have not implemented many features and I don't know if we would. > > So a versatile API is favorable but I do not think we have the proper > community to represent much more than Serial. We could provide a > framework or maybe just a model for further work with other standards. I agree completely. Folks use RXTX for serial ports. In my field (Oceanography), we uses RS232 to talk to nearly all our instruments. So we really need a great implementation of serial port communications in Java that runs on a variety of architectures. I'd prefer if the JSR focused on that. >> I given much thought to what it would take to properly address >> > ^^^haven't > >> EIA-422, EIA-423 and EIA-485 (if any); but those would >> probably be extensions. Sounds like the differences might >> be transparent to the API. I'll look into that more. I've had good luck using the current implementation of RXTX with RS422, although you'll need to use a pin converter. my 2 cents. Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060720/fb956c68/attachment-0343.html From pascal at quies.net Fri Jul 21 15:43:40 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Fri, 21 Jul 2006 23:43:40 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: Message-ID: <200607212343.40882.pascal@quies.net> Op donderdag 20 juli 2006 15:16, schreef Dr. Douglas Lyon: > Hi All, > There has been some discussion about plugins for serial communications. > > As I see it, what Java really needs is a NativeLibraryManager. This is > a rather much larger charge than "just" RXTX. > > The RXTX basic mode of operation is that we associate static > blocks of code with a "System.load". > > Failure occurs when the class containing such a block of code is > loaded AND the native library is not found. > > What are some of the options? > > 1. Do nothing, let the program fail with an exception. > 2. try to catch an UnsatisfiedLinkError as a part of making > the driver. > 3. Search the java.library.path to see if the driver is present > (i.e., guard the input). > 4. Other?? > > In the case of either step 2 or 3, we need to fix the lack of a library. > > What are the options for fixing a library? > 1. Do nothing, but give the user an interesting error with instructions on > what to do. > 2. Attempt to find the library on the file system (perhaps with user help). > 3. Attempt to download the library and install it (perhaps with user > permission). > 4. Attempt to internalize the library as a UUEncoded serialized object and > install it (better ask the user, again!). > 5. Other?? 5. Put the binaries together with the attached classes in a jar. Joachim told me that and it works! I forgot to publish the results. :$ ---- begin example import org.rxtx.CommunicationAPI; ... CommunicationAPI commExtension = new CommunicationAPI(); try { commExtenios.loadNativeLibraries(); } catch (Exception e) { // We *need* javax.comm } // Now we have the extension available. ... ---- end example Do you like it? Commens anyone? The path to the libraries is in the form of /native/rxtx/-/{libserial,libparallel} so /native/rxtx/windows-i386/libserial would do. I asked for binaries but only Joachim offered me help with OS X on the next release. Does anyone have javax.comm warper classes? -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 6781 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060721/b39a5592/CommunicationAPI-0342.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: PlatformNotSupportedException.java Type: text/x-java Size: 1621 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060721/b39a5592/PlatformNotSupportedException-0342.bin From pascal at quies.net Fri Jul 21 15:45:30 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Fri, 21 Jul 2006 23:45:30 +0200 Subject: [Rxtx] quo vadis API/namespace (Re: jcp and jsr) In-Reply-To: References: <44BEDC4F.9030403@sun.com> Message-ID: <200607212345.30495.pascal@quies.net> Op donderdag 20 juli 2006 10:46, schreef Joachim Buechse: > So in short: Unless we find a strong argument why javax.comm can't be > used I prefer that we keep it. Unless we find a strong feature / use- > case that can not be handled with (an extension of) the current > CommPort/CommPortIndentifier I'd prefer to keep that as well. I seem to be the only one who sees failures in the API so lets keep it that way. Now how do we get a JSR/lisence if we don't want any changes? :P From lyon at docjava.com Sat Jul 22 06:07:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 22 Jul 2006 08:07:03 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607212343.40882.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> Message-ID: Hi All, I like the idea of the native lib in a jar with other classes. An alternative I did not know would work. Now, if you place the rxtx classes and native library in the same jar, do they both have to be in any specific place in order to be found? In my approach, you can locate the native library at run-time, and you need not alter any environmental variables nor mangle the JDK home. Thus, each user can have a different native library, one for development and one for release, for example. Regards, - Doug >Op donderdag 20 juli 2006 15:16, schreef Dr. Douglas Lyon: >> Hi All, >> There has been some discussion about plugins for serial communications. >> >> As I see it, what Java really needs is a NativeLibraryManager. This is >> a rather much larger charge than "just" RXTX. >> >> The RXTX basic mode of operation is that we associate static >> blocks of code with a "System.load". >> >> Failure occurs when the class containing such a block of code is >> loaded AND the native library is not found. >> >> What are some of the options? >> >> 1. Do nothing, let the program fail with an exception. >> 2. try to catch an UnsatisfiedLinkError as a part of making >> the driver. >> 3. Search the java.library.path to see if the driver is present >> (i.e., guard the input). >> 4. Other?? >> >> In the case of either step 2 or 3, we need to fix the lack of a library. >> >> What are the options for fixing a library? >> 1. Do nothing, but give the user an interesting error with instructions on >> what to do. >> 2. Attempt to find the library on the file system (perhaps with user help). >> 3. Attempt to download the library and install it (perhaps with user >> permission). >> 4. Attempt to internalize the library as a UUEncoded serialized object and >> install it (better ask the user, again!). >> 5. Other?? > >5. Put the binaries together with the attached classes in a jar. > >Joachim told me that and it works! I forgot to publish the results. :$ > > >---- begin example >import org.rxtx.CommunicationAPI; > >... >CommunicationAPI commExtension = new CommunicationAPI(); >try { > commExtenios.loadNativeLibraries(); >} catch (Exception e) { > // We *need* javax.comm >} > >// Now we have the extension available. >... >---- end example > > >Do you like it? Commens anyone? > > >The path to the libraries is in the form >of /native/rxtx/-/{libserial,libparallel} >so /native/rxtx/windows-i386/libserial would do. > >I asked for binaries but only Joachim offered me help with OS X on the next >release. > >Does anyone have javax.comm warper classes? > >Attachment converted: PowerBookHd:CommunicationAPI.java (TEXT/ttxt) (001C1686) >Attachment converted: PowerBookHd:PlatformNotSupporte#1C1687.java >(TEXT/ttxt) (001C1687) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 22 07:06:06 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 15:06:06 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607212343.40882.pascal@quies.net> Message-ID: <200607221506.07140.pascal@quies.net> > Now, if you place the rxtx classes and native library in the same > jar, do they both have to be in any specific place in order to be found? Answer: > >The path to the libraries is in the form > >of /native/rxtx/-/{libserial,libparallel} > >so /native/rxtx/windows-i386/libserial would do. I'me looking for the various os.name and os.arch values right now. From lyon at docjava.com Sat Jul 22 08:06:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 22 Jul 2006 10:06:26 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607221506.07140.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> <200607221506.07140.pascal@quies.net> Message-ID: Hi All, Here is how I have arranged my signed versions of the native binaries: http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/windows/native.jar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/native.jar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/linux/native.jar Then I do: public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isMacOs()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); System.out.println("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } My new-age NativeLibraryManger concept-thang allows you to write stuff like: /** * This method fixes the driver by beaming over * to the tmp directory a native.jar file. * The native.jar file is signed and its * native libs are beamed over to the user home directory * ~/.rxtx/
* Finally, the java.library.path is altered to include
* ~/.rxtx/ */ private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), NativeLibraryManager.mapLibraryName("rxtxSerial")); } catch (IOException e) { e.printStackTrace(); } } I do a lazy singleton design pattern: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getInstance() { if (driver != null) return driver; if (!NativeLibraryManager.isLibInPath("rxtxSerial")) fixDriver(); if (NativeLibraryManager.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } I am at a cross-roads here, since a file-based distro might be preferable to a URL based distro. To make this really general, and to "remember" where the last version of a native library came from, I serialize a bean into user preferences The user can then store native libraries anywhere, remembering the location in the preferences. What is the general feeling about this? Thanks! - Doug > > Now, if you place the rxtx classes and native library in the same >> jar, do they both have to be in any specific place in order to be found? > >Answer: > >> >The path to the libraries is in the form >> >of /native/rxtx/-/{libserial,libparallel} >> >so /native/rxtx/windows-i386/libserial would do. > >I'me looking for the various os.name and os.arch values right now. >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Sat Jul 22 10:30:55 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 22 Jul 2006 11:30:55 -0500 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607212343.40882.pascal@quies.net> Message-ID: <44C252BF.6040404@cox.net> Dr. Douglas Lyon wrote: > Hi All, > I like the idea of the native lib in a jar with other classes. > An alternative I did not know would work. I have several applications that run with a security policy. In these applications, native library loading will require an appropriate FilePermission that should be known about ahead of time. The current native library implementation will require the native library to be extracted from the jar and written to disk, requiring a FilePermission("...","write") for that file, and then will also require read access to load the library. I personally don't want to give write access to a JVM for a shared library which can provide a point of abuse by errant code. Gregg Wonderly From gergg at cox.net Sat Jul 22 10:33:52 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 22 Jul 2006 11:33:52 -0500 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607212343.40882.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> Message-ID: <44C25370.9070506@cox.net> >Pascal S. de Kloe wrote: >>> I am also not sure if >>> the api should unify corresponding cu. and tty. ports into one single >>> port. >> >> I think the API should hide low-level details like devicefiles. > >Not all ports have device files. It's long been my goal to add support >for virtual serial ports, that is, serial ports on Ethernet terminal >servers, for example integrating RFC2217. This means that the port name >is some combination of an IP address and TCP port number. Nothing in /dev. What I think would make the most sense is a simple "device" enumeration Server Provider Interface that would bring port objects into the JVM based on the platform JVM providers knowledge of how to enumerate those ports. Application writers would provide a plugin using the SPI that would codify those devices into named entities that they are interested in. public interface HardwarePort { public String getName(); public String getHardwareID(); public String getManufacturer(); public List getCapabilities(); public Object getImplementation(); } public interface PortCapability { public String getDescription(); public CapabilityId getIdentifier(); } public enum CapabilityId { INPUT, // Can receive input OUTPUT, // Can send output ASYNCHRONOUS, // Can send and receive at the same time SYNCHRONOUS, // No synchronous I/O ADDRESSABLE // Port has an address associated } Then, you might imagine that the enumerated capabilities had a standardized/specified interface that you'd find implemented on ports that had such capabilities. The getImplementation() method would return the implementation class provided by the JVM provider that had all of the interfaces tied to it. These are just some quick thoughts, pick away at them. I am very interested in getting a new comm api in place which can provide the ability for all USB connected devices to have drivers provided as 100% java for all non-timing critical types of device interfaces. The JVM provider should have an SPI to write to which will enable them to abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into something that we can talk 100% java to. That's my big desire. Starting with something simple which gives a good start in that direction would be great! Gregg Wonderly From pascal at quies.net Sat Jul 22 10:43:27 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 18:43:27 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <44C252BF.6040404@cox.net> References: <44C252BF.6040404@cox.net> Message-ID: <200607221843.27765.pascal@quies.net> Op zaterdag 22 juli 2006 18:30, schreef Gregg Wonderly: > Dr. Douglas Lyon wrote: > > Hi All, > > I like the idea of the native lib in a jar with other classes. > > An alternative I did not know would work. > > I have several applications that run with a security policy. In these > applications, native library loading will require an appropriate > FilePermission that should be known about ahead of time. The current > native library implementation will require the native library to be > extracted from the jar and written to disk, requiring a > FilePermission("...","write") for that file, and then will also require > read access to load the library. I personally don't want to give write > access to a JVM for a shared library which can provide a point of abuse by > errant code. > > Gregg Wonderly That's indeed a pitty limitation. It creates a lot of possible exceptions too. On the other hand, any native lib passes the securiy model. Applications who can access hardware ports can be expected to create files, right? From pascal at quies.net Sat Jul 22 10:54:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 18:54:13 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607221506.07140.pascal@quies.net> Message-ID: <200607221854.13467.pascal@quies.net> Hi Dr., We're both trying to do the same thing. The CommunicationAPI does not only look at the OS but it also indexes the available hardware architectures and does not need OsUtils. Any Java 2 runtime will do. The plan was to make a single JAR with the binaries for all supported platforms, the RXTX gnu.io package and the javax.comm wrapers. A signed version would be nice. A few questions remain tough. Does anybody know how Sun uses the SunOS and Solaris identifiers for the Java property os.name? Op zaterdag 22 juli 2006 16:06, schreef Dr. Douglas Lyon: > Hi All, > Here is how I have arranged my signed versions of the native > binaries: > http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/windows/native.j >ar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/native.jar > http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/linux/native.jar > > Then I do: > public static URL getResourceUrl() throws MalformedURLException { > String rxtxUrl = "http://show.docjava.com:8086/" + > "book/cgij/code/jnlp/libs/rxtx/"; > if (OsUtils.isLinux()) > return new URL(rxtxUrl + "linux/native.jar"); > if (OsUtils.isMacOs()) > return new URL(rxtxUrl + "mac/native.jar"); > if (OsUtils.isWindows()) > return new URL(rxtxUrl + "windows/native.jar"); > System.out.println("no automatic install supported for this > platform. " + > "Please e-mail lyon at docjava.com with a bug report"); > return null; > } > > My new-age NativeLibraryManger concept-thang allows you to > write stuff like: > > /** > * This method fixes the driver by beaming over > * to the tmp directory a native.jar file. > * The native.jar file is signed and its > * native libs are beamed over to the user home directory > * ~/.rxtx/
> * Finally, the java.library.path is altered to include
> * ~/.rxtx/ > */ > private static void fixDriver() { > > try { > NativeLibraryManager.fixDriver(getResourceUrl(), > NativeLibraryManager.mapLibraryName("rxtxSerial")); > } catch (IOException e) { > e.printStackTrace(); > } > } > > I do a lazy singleton design pattern: > > public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public synchronized static RXTXCommDriver getInstance() { > if (driver != null) return driver; > if (!NativeLibraryManager.isLibInPath("rxtxSerial")) > fixDriver(); > if (NativeLibraryManager.isLibInPath("rxtxSerial")) { > driver = new RXTXCommDriver(); > driver.initialize(); > } > return driver; > } > > I am at a cross-roads here, since a file-based distro might be preferable > to a URL based distro. To make this really general, and to "remember" where > the last version of a native library came from, I serialize a bean into > user preferences > The user can then store native libraries anywhere, remembering the location > in the preferences. > > What is the general feeling about this? > > Thanks! > - Doug > > > > Now, if you place the rxtx classes and native library in the same > >> > >> jar, do they both have to be in any specific place in order to be > >> found? > > > >Answer: > >> >The path to the libraries is in the form > >> >of /native/rxtx/-/{libserial,libparallel} > >> >so /native/rxtx/windows-i386/libserial would do. > > > >I'me looking for the various os.name and os.arch values right now. > >_______________________________________________ > >Rxtx mailing list > >Rxtx at qbang.org > >http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Sat Jul 22 11:17:51 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 22 Jul 2006 19:17:51 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <44C252BF.6040404@cox.net> References: <200607212343.40882.pascal@quies.net> <44C252BF.6040404@cox.net> Message-ID: <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> We could easily have a stub method / flag that allows you to explicitly load the native library (via System.loadLibrary ie from the java.library.path). In this case the "auto-extraction" would not take place. On 22.07.2006, at 18:30, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> Hi All, >> I like the idea of the native lib in a jar with other classes. >> An alternative I did not know would work. > > I have several applications that run with a security policy. In these > applications, native library loading will require an appropriate > FilePermission > that should be known about ahead of time. The current native library > implementation will require the native library to be extracted from > the jar and > written to disk, requiring a FilePermission("...","write") for that > file, and > then will also require read access to load the library. I > personally don't want > to give write access to a JVM for a shared library which can > provide a point of > abuse by errant code. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 22 11:20:19 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 19:20:19 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607221506.07140.pascal@quies.net> Message-ID: <200607221920.20096.pascal@quies.net> The attachment setup.zip contains a very small update of CommunicationAPI and a good start with the various platforms. All we need to do is fill those directories with binaries. Various binaries are missing the pararlel library. Why is that? -------------- next part -------------- A non-text attachment was scrubbed... Name: setup.zip Type: application/x-zip Size: 8459 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060722/12770623/setup-0341.bin From gregg at cytetech.com Thu Jul 20 21:32:55 2006 From: gregg at cytetech.com (Gregg Wonderly) Date: Thu, 20 Jul 2006 22:32:55 -0500 Subject: [Rxtx] jcp and jsr Message-ID: <44C04AE7.9050800@cytetech.com> >Pascal S. de Kloe wrote: >>> I am also not sure if >>> the api should unify corresponding cu. and tty. ports into one single >>> port. >> >> I think the API should hide low-level details like devicefiles. > >Not all ports have device files. It's long been my goal to add support >for virtual serial ports, that is, serial ports on Ethernet terminal >servers, for example integrating RFC2217. This means that the port name >is some combination of an IP address and TCP port number. Nothing in /dev. What I think would make the most sense is a simple "device" enumeration Server Provider Interface that would bring port objects into the JVM based on the platform JVM providers knowledge of how to enumerate those ports. Application writers would provide a plugin using the SPI that would codify those devices into named entities that they are interested in. public interface HardwarePort { public String getName(); public String getHardwareID(); public String getManufacturer(); public List getCapabilities(); public Object getImplementation(); } public interface PortCapability { public String getDescription(); public CapabilityId getIdentifier(); } public enum CapabilityId { INPUT, // Can receive input OUTPUT, // Can send output ASYNCHRONOUS, // Can send and receive at the same time SYNCHRONOUS, // No synchronous I/O ADDRESSABLE // Port has an address associated } Then, you might imagine that the enumerated capabilities had a standardized/specified interface that you'd find implemented on ports that had such capabilities. The getImplementation() method would return the implementation class provided by the JVM provider that had all of the interfaces tied to it. These are just some quick thoughts, pick away at them. I am very interested in getting a new comm api in place which can provide the ability for all USB connected devices to have drivers provided as 100% java for all non-timing critical types of device interfaces. The JVM provider should have an SPI to write to which will enable them to abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into something that we can talk 100% java to. That's my big desire. Starting with something simple which gives a good start in that direction would be great! Gregg Wonderly From pascal at quies.net Sat Jul 22 11:32:03 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 19:32:03 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44C25370.9070506@cox.net> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> Message-ID: <200607221932.04194.pascal@quies.net> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: > >Pascal S. de Kloe wrote: > >>> I am also not sure if > >>> the api should unify corresponding cu. and tty. ports into one single > >>> port. > >> > >> I think the API should hide low-level details like devicefiles. > > > >Not all ports have device files. It's long been my goal to add support > >for virtual serial ports, that is, serial ports on Ethernet terminal > >servers, for example integrating RFC2217. This means that the port name > >is some combination of an IP address and TCP port number. Nothing in > > /dev. > > What I think would make the most sense is a simple "device" enumeration > Server Provider Interface that would bring port objects into the JVM based > on the platform JVM providers knowledge of how to enumerate those ports. > Application writers would provide a plugin using the SPI that would codify > those devices into named entities that they are interested in. > > public interface HardwarePort { > public String getName(); > public String getHardwareID(); > public String getManufacturer(); > public List getCapabilities(); > public Object getImplementation(); > } > > public interface PortCapability { > public String getDescription(); > public CapabilityId getIdentifier(); > } > > public enum CapabilityId { > INPUT, // Can receive input > OUTPUT, // Can send output > ASYNCHRONOUS, // Can send and receive at the same time > SYNCHRONOUS, // No synchronous I/O > ADDRESSABLE // Port has an address associated > } > > Then, you might imagine that the enumerated capabilities had a > standardized/specified interface that you'd find implemented on ports that > had such capabilities. > > The getImplementation() method would return the implementation class > provided by the JVM provider that had all of the interfaces tied to it. > > These are just some quick thoughts, pick away at them. > > I am very interested in getting a new comm api in place which can provide > the ability for all USB connected devices to have drivers provided as 100% > java for all non-timing critical types of device interfaces. > > The JVM provider should have an SPI to write to which will enable them to > abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into something > that we can talk 100% java to. > > That's my big desire. Starting with something simple which gives a good > start in that direction would be great! That was exactly my wish too. The point people brought up was: 1) It's too complex. 2) What does it solve? In both facts they are right. It'll take a *long* time to plan such a thing right but if it works you have a product. Anyway, I'd like to join. ;) From joachim at buechse.de Sat Jul 22 11:37:11 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 22 Jul 2006 19:37:11 +0200 Subject: [Rxtx] Strange error (show stopper) Message-ID: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> I just discovered a strange error in RXTX on OSX. SerialDemo.java manages to corrupt the event_info_structure by a simple OpenPort,ClosePort - this could be in relation to the deadlock problem that was reported recently. Could anyone try to reproduce this on Solaris or some other system which is neither WIN32 nor Linux (ie which uses a drain thread). In SerialImp.c : RXTXPort(interruptEventLoop) Apparently the event_info_structure gets corrupted shortly after pthread_kill(index->drain_tid, SIGABRT); In particular, the index->closing flag gets overwritten by a pointer value. **** Adding the following debugging code: pthread_kill(index->drain_tid, SIGABRT); sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i \n", index->fd, index, index->closing ); report( message ); /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ usleep(50 * 1000); sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i \n", index->fd, index, index->closing ); report( message ); **** gives me: 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 drain_loop: received EINTR------------------ drain_loop exiting --------------------- entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 eventLoop: got interrupt 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 **** Modifying SerialImp.h : event_info_struct by moving the prev*, next* pointers jmethodID checkMonitorThread; struct event_info_struct *dummy, *dummy2; fd_set rfds; struct timeval tv_sleep; int closing; struct event_info_struct *next, *prev; *** (ie replacing their original position with dummys and moving them *** behind the closing flag) results in this: 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 drain_loop: received EINTR------------------ drain_loop exiting --------------------- entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 eventLoop: got interrupt 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 *** I was not able to track down the problem. If anyone could check wether this happens on other platforms as well, we may get closer to a fix. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich From joachim at buechse.de Sat Jul 22 11:46:35 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 22 Jul 2006 19:46:35 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607221932.04194.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> Message-ID: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> It seems that Gregg's suggestion could be implemented without changing the existing "user-level" API of javax.comm. Most of the information suggested for HardwarePort is not accessible from within the POSSIX-API but this is a different story. It is clear that javax.comm can never provide a way to talk to all USB devices, simply because some USB devices have several endpoints. But it could provide a means of talking to devices that function as a bidirectional-pipe (ie any USB to serial bridge). Regards, Joachim On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>> Pascal S. de Kloe wrote: >>>>> I am also not sure if >>>>> the api should unify corresponding cu. and tty. ports into one >>>>> single >>>>> port. >>>> >>>> I think the API should hide low-level details like devicefiles. >>> >>> Not all ports have device files. It's long been my goal to add >>> support >>> for virtual serial ports, that is, serial ports on Ethernet terminal >>> servers, for example integrating RFC2217. This means that the >>> port name >>> is some combination of an IP address and TCP port number. >>> Nothing in >>> /dev. >> >> What I think would make the most sense is a simple "device" >> enumeration >> Server Provider Interface that would bring port objects into the >> JVM based >> on the platform JVM providers knowledge of how to enumerate those >> ports. >> Application writers would provide a plugin using the SPI that >> would codify >> those devices into named entities that they are interested in. >> >> public interface HardwarePort { >> public String getName(); >> public String getHardwareID(); >> public String getManufacturer(); >> public List getCapabilities(); >> public Object getImplementation(); >> } >> >> public interface PortCapability { >> public String getDescription(); >> public CapabilityId getIdentifier(); >> } >> >> public enum CapabilityId { >> INPUT, // Can receive input >> OUTPUT, // Can send output >> ASYNCHRONOUS, // Can send and receive at the same time >> SYNCHRONOUS, // No synchronous I/O >> ADDRESSABLE // Port has an address associated >> } >> >> Then, you might imagine that the enumerated capabilities had a >> standardized/specified interface that you'd find implemented on >> ports that >> had such capabilities. >> >> The getImplementation() method would return the implementation class >> provided by the JVM provider that had all of the interfaces tied >> to it. >> >> These are just some quick thoughts, pick away at them. >> >> I am very interested in getting a new comm api in place which can >> provide >> the ability for all USB connected devices to have drivers provided >> as 100% >> java for all non-timing critical types of device interfaces. >> >> The JVM provider should have an SPI to write to which will enable >> them to >> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >> something >> that we can talk 100% java to. >> >> That's my big desire. Starting with something simple which gives >> a good >> start in that direction would be great! > > That was exactly my wish too. > > The point people brought up was: > 1) It's too complex. > 2) What does it solve? > > In both facts they are right. It'll take a *long* time to plan such > a thing > right but if it works you have a product. Anyway, I'd like to join. ;) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Jul 22 11:55:23 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 22 Jul 2006 14:55:23 -0300 Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: <44C2668B.5080703@gmail.com> Joachim Buechse escribi?: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. > > It is clear that javax.comm can never provide a way to talk to all > USB devices, simply because some USB devices have several endpoints. > But it could provide a means of talking to devices that function as a > bidirectional-pipe (ie any USB to serial bridge). > > Regards, > Joachim Hi, About USB, why do not we contact the guys that make a library to support USB under Java from Linux? I think there is all ready an JSR for USB access, what we could do to this JSR is help to implement Usb access from other OSes. Regards, Manuel > > On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > >> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>> Pascal S. de Kloe wrote: >>>>>> I am also not sure if >>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>> single >>>>>> port. >>>>> I think the API should hide low-level details like devicefiles. >>>> Not all ports have device files. It's long been my goal to add >>>> support >>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>> servers, for example integrating RFC2217. This means that the >>>> port name >>>> is some combination of an IP address and TCP port number. >>>> Nothing in >>>> /dev. >>> What I think would make the most sense is a simple "device" >>> enumeration >>> Server Provider Interface that would bring port objects into the >>> JVM based >>> on the platform JVM providers knowledge of how to enumerate those >>> ports. >>> Application writers would provide a plugin using the SPI that >>> would codify >>> those devices into named entities that they are interested in. >>> >>> public interface HardwarePort { >>> public String getName(); >>> public String getHardwareID(); >>> public String getManufacturer(); >>> public List getCapabilities(); >>> public Object getImplementation(); >>> } >>> >>> public interface PortCapability { >>> public String getDescription(); >>> public CapabilityId getIdentifier(); >>> } >>> >>> public enum CapabilityId { >>> INPUT, // Can receive input >>> OUTPUT, // Can send output >>> ASYNCHRONOUS, // Can send and receive at the same time >>> SYNCHRONOUS, // No synchronous I/O >>> ADDRESSABLE // Port has an address associated >>> } >>> >>> Then, you might imagine that the enumerated capabilities had a >>> standardized/specified interface that you'd find implemented on >>> ports that >>> had such capabilities. >>> >>> The getImplementation() method would return the implementation class >>> provided by the JVM provider that had all of the interfaces tied >>> to it. >>> >>> These are just some quick thoughts, pick away at them. >>> >>> I am very interested in getting a new comm api in place which can >>> provide >>> the ability for all USB connected devices to have drivers provided >>> as 100% >>> java for all non-timing critical types of device interfaces. >>> >>> The JVM provider should have an SPI to write to which will enable >>> them to >>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>> something >>> that we can talk 100% java to. >>> >>> That's my big desire. Starting with something simple which gives >>> a good >>> start in that direction would be great! >> That was exactly my wish too. >> >> The point people brought up was: >> 1) It's too complex. >> 2) What does it solve? >> >> In both facts they are right. It'll take a *long* time to plan such >> a thing >> right but if it works you have a product. Anyway, I'd like to join. ;) >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Sat Jul 22 11:58:00 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Sat, 22 Jul 2006 13:58:00 -0400 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> Message-ID: <41E45C85-4A22-4C5B-915F-62ED36BACCF2@sympatico.ca> A couple of questions: - what version are you using? - does this happen with the version in cvs? Andre On 22-Jul-06, at 13:37 , Joachim Buechse wrote: > I just discovered a strange error in RXTX on OSX. SerialDemo.java > manages to corrupt the event_info_structure by a simple > OpenPort,ClosePort - this could be in relation to the deadlock > problem that was reported recently. > > Could anyone try to reproduce this on Solaris or some other system > which is neither WIN32 nor Linux (ie which uses a drain thread). > > In SerialImp.c : RXTXPort(interruptEventLoop) > > Apparently the event_info_structure gets corrupted shortly after > > pthread_kill(index->drain_tid, SIGABRT); > > In particular, the index->closing flag gets overwritten by a pointer > value. > > > **** Adding the following debugging code: > > pthread_kill(index->drain_tid, SIGABRT); > sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ > usleep(50 * 1000); > sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > > **** gives me: > > 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 > > **** Modifying SerialImp.h : event_info_struct by moving the > prev*, next* pointers > > jmethodID checkMonitorThread; > struct event_info_struct *dummy, *dummy2; > fd_set rfds; > struct timeval tv_sleep; > int closing; > struct event_info_struct *next, *prev; > > *** (ie replacing their original position with dummys and moving them > *** behind the closing flag) results in this: > > 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 > > > *** I was not able to track down the problem. If anyone could check > wether this happens on other platforms as well, we may get closer to > a fix. > > Regards, > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Paul.Klissner at Sun.COM Sat Jul 22 12:19:41 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Sat, 22 Jul 2006 11:19:41 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: <44C26C3D.8020501@sun.com> Joachim Buechse wrote: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. > > It is clear that javax.comm can never provide a way to talk to all > USB devices, simply because some USB devices have several endpoints. > But it could provide a means of talking to devices that function as a > bidirectional-pipe (ie any USB to serial bridge). If the 'back end' driver could be java as well an .so then driver's could be written using javax.usb, which is available currently for Linux. Paul > > Regards, > Joachim > > On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > >> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>> Pascal S. de Kloe wrote: >>>>>> I am also not sure if >>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>> single >>>>>> port. >>>>> I think the API should hide low-level details like devicefiles. >>>> Not all ports have device files. It's long been my goal to add >>>> support >>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>> servers, for example integrating RFC2217. This means that the >>>> port name >>>> is some combination of an IP address and TCP port number. >>>> Nothing in >>>> /dev. >>> What I think would make the most sense is a simple "device" >>> enumeration >>> Server Provider Interface that would bring port objects into the >>> JVM based >>> on the platform JVM providers knowledge of how to enumerate those >>> ports. >>> Application writers would provide a plugin using the SPI that >>> would codify >>> those devices into named entities that they are interested in. >>> >>> public interface HardwarePort { >>> public String getName(); >>> public String getHardwareID(); >>> public String getManufacturer(); >>> public List getCapabilities(); >>> public Object getImplementation(); >>> } >>> >>> public interface PortCapability { >>> public String getDescription(); >>> public CapabilityId getIdentifier(); >>> } >>> >>> public enum CapabilityId { >>> INPUT, // Can receive input >>> OUTPUT, // Can send output >>> ASYNCHRONOUS, // Can send and receive at the same time >>> SYNCHRONOUS, // No synchronous I/O >>> ADDRESSABLE // Port has an address associated >>> } >>> >>> Then, you might imagine that the enumerated capabilities had a >>> standardized/specified interface that you'd find implemented on >>> ports that >>> had such capabilities. >>> >>> The getImplementation() method would return the implementation class >>> provided by the JVM provider that had all of the interfaces tied >>> to it. >>> >>> These are just some quick thoughts, pick away at them. >>> >>> I am very interested in getting a new comm api in place which can >>> provide >>> the ability for all USB connected devices to have drivers provided >>> as 100% >>> java for all non-timing critical types of device interfaces. >>> >>> The JVM provider should have an SPI to write to which will enable >>> them to >>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>> something >>> that we can talk 100% java to. >>> >>> That's my big desire. Starting with something simple which gives >>> a good >>> start in that direction would be great! >> That was exactly my wish too. >> >> The point people brought up was: >> 1) It's too complex. >> 2) What does it solve? >> >> In both facts they are right. It'll take a *long* time to plan such >> a thing >> right but if it works you have a product. Anyway, I'd like to join. ;) >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 22 12:48:15 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 20:48:15 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607221920.20096.pascal@quies.net> References: <200607221920.20096.pascal@quies.net> Message-ID: <200607222048.16215.pascal@quies.net> http://quies.net/communicationapi.jar Fixed a few typo's and it works on Linux i386. It should also work on Windows i386. The rest is missing libParallel or more... -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 6664 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060722/5fd7c1ce/CommunicationAPI-0341.bin From Paul.Klissner at Sun.COM Sat Jul 22 12:53:12 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Sat, 22 Jul 2006 11:53:12 -0700 Subject: [Rxtx] jcp and jsr (libusb, javax.usb) In-Reply-To: <44C2668B.5080703@gmail.com> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> <44C2668B.5080703@gmail.com> Message-ID: <44C27418.1090309@sun.com> Manuel Naranjo wrote: > Joachim Buechse escribi?: >> It seems that Gregg's suggestion could be implemented without >> changing the existing "user-level" API of javax.comm. Most of the >> information suggested for HardwarePort is not accessible from within >> the POSSIX-API but this is a different story. >> >> It is clear that javax.comm can never provide a way to talk to all >> USB devices, simply because some USB devices have several endpoints. >> But it could provide a means of talking to devices that function as a >> bidirectional-pipe (ie any USB to serial bridge). >> >> Regards, >> Joachim > > Hi, > About USB, why do not we contact the guys that make a library to support > USB under Java from Linux? > I think there is all ready an JSR for USB access, what we could do to this > JSR is help to implement Usb access from other OSes. JAVAX.USB --------- javax.usb already a SourceForge project. I was Sun's rep on the expert group for JSR-80, javax.usb. I lived and breathed it for a 1.5 yrs working with spec lead from IBM on it. It's for real and the linux implementation works (not sure about the Win32 port on sourceforge). IBM even created a porting layer to simplify porting it to other platforms by implementing in Java all of the numerous 'clerical' functions of the API in Java so that the porting layer is absolutely minimal. The hardest part is managing the hotpluggable device tree topology as objects, and depending on one's platform or coding skills probably wouldn't take more than a week or two to get right. LIBUSB 1.0 (*NOT* libusb 0.1.8) ---------- There is also the native C library libusb. libusb 0.1.8 is weak, but libusb 1.0 under development holds the promise of being an extrordinarily robust C API to access USB devices through, and could definitely use some help getting people to port it to other platforms. I've attached the proposed libusb 1.0 API header which Sun worked with Johannes on for months before he went off into oblivion. The API has stalled and a fire might need to be lit under Johannes or it might need to be forked to get it moving again, but the spec for 1.0 is awesome, and this puppy is ready to turn into something sweet with some fresh blood on it. And it is a really good technology to become aquainted with... hint hint. Both of those APIs are really excellent and hold great promise for the community and use of USB technology in general. One of my goals, now which competes for my time with other higher priority projects was to layer an implementation of javax.usb over libusb 1.0, so that javax.usb would follow libusb to any platform and only one port would be required. But since libusb 1.0 is moving slowly, largely because the current sourceforge gatekeeper for the project, Johannes Erdfelt's lack of energy and sparse communication, it might be faster to simply port javax.usb to Mac OS, Win, Solaris and BSD if some people could get behind those, unless someone want's to get behind making libusb happen. >>>> >>>> public enum CapabilityId { >>>> INPUT, // Can receive input >>>> OUTPUT, // Can send output >>>> ASYNCHRONOUS, // Can send and receive at the same time >>>> SYNCHRONOUS, // No synchronous I/O >>>> ADDRESSABLE // Port has an address associated >>>> } My understanding is that synchronous/asynchronous refers to the way the data is clocked. I think FULLDUPLEX/HALFDUPLEX is what the author meant, or needs to be added. Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: libusb.h Type: text/x-sun-h-file Size: 26696 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060722/4a43e034/libusb-0341.bin From pascal at quies.net Sat Jul 22 17:53:31 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 01:53:31 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> References: <44C252BF.6040404@cox.net> <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> Message-ID: <200607230153.32328.pascal@quies.net> Hi Joachim, I'm not getting it. How do you easily get a "stub method / flag"? Op zaterdag 22 juli 2006 19:17, schreef Joachim Buechse: > We could easily have a stub method / flag that allows you to > explicitly load the native library (via System.loadLibrary ie from > the java.library.path). In this case the "auto-extraction" would not > take place. > > On 22.07.2006, at 18:30, Gregg Wonderly wrote: > > Dr. Douglas Lyon wrote: > >> Hi All, > >> I like the idea of the native lib in a jar with other classes. > >> An alternative I did not know would work. > > > > I have several applications that run with a security policy. In these > > applications, native library loading will require an appropriate > > FilePermission > > that should be known about ahead of time. The current native library > > implementation will require the native library to be extracted from > > the jar and > > written to disk, requiring a FilePermission("...","write") for that > > file, and > > then will also require read access to load the library. I > > personally don't want > > to give write access to a JVM for a shared library which can > > provide a point of > > abuse by errant code. > > > > Gregg Wonderly > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat Jul 22 18:46:33 2006 From: jredman at ergotech.com (Jim Redman) Date: Sat, 22 Jul 2006 18:46:33 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44C26C3D.8020501@sun.com> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> <44C26C3D.8020501@sun.com> Message-ID: <44C2C6E9.8020408@ergotech.com> Paul, I think that you've already proposed a "pluggable" underlying architecture and I think that this might be better implemented there. If you need some more examples, I'd like to have a Bluetooth interface (with dynamic discovery). Jim Paul Klissner wrote: > Joachim Buechse wrote: >> It seems that Gregg's suggestion could be implemented without >> changing the existing "user-level" API of javax.comm. Most of the >> information suggested for HardwarePort is not accessible from within >> the POSSIX-API but this is a different story. >> >> It is clear that javax.comm can never provide a way to talk to all >> USB devices, simply because some USB devices have several endpoints. >> But it could provide a means of talking to devices that function as a >> bidirectional-pipe (ie any USB to serial bridge). > > If the 'back end' driver could be java as well an .so > then driver's could be written using javax.usb, which > is available currently for Linux. > > Paul > > > >> Regards, >> Joachim >> >> On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: >> >>> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>>> Pascal S. de Kloe wrote: >>>>>>> I am also not sure if >>>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>>> single >>>>>>> port. >>>>>> I think the API should hide low-level details like devicefiles. >>>>> Not all ports have device files. It's long been my goal to add >>>>> support >>>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>>> servers, for example integrating RFC2217. This means that the >>>>> port name >>>>> is some combination of an IP address and TCP port number. >>>>> Nothing in >>>>> /dev. >>>> What I think would make the most sense is a simple "device" >>>> enumeration >>>> Server Provider Interface that would bring port objects into the >>>> JVM based >>>> on the platform JVM providers knowledge of how to enumerate those >>>> ports. >>>> Application writers would provide a plugin using the SPI that >>>> would codify >>>> those devices into named entities that they are interested in. >>>> >>>> public interface HardwarePort { >>>> public String getName(); >>>> public String getHardwareID(); >>>> public String getManufacturer(); >>>> public List getCapabilities(); >>>> public Object getImplementation(); >>>> } >>>> >>>> public interface PortCapability { >>>> public String getDescription(); >>>> public CapabilityId getIdentifier(); >>>> } >>>> >>>> public enum CapabilityId { >>>> INPUT, // Can receive input >>>> OUTPUT, // Can send output >>>> ASYNCHRONOUS, // Can send and receive at the same time >>>> SYNCHRONOUS, // No synchronous I/O >>>> ADDRESSABLE // Port has an address associated >>>> } >>>> >>>> Then, you might imagine that the enumerated capabilities had a >>>> standardized/specified interface that you'd find implemented on >>>> ports that >>>> had such capabilities. >>>> >>>> The getImplementation() method would return the implementation class >>>> provided by the JVM provider that had all of the interfaces tied >>>> to it. >>>> >>>> These are just some quick thoughts, pick away at them. >>>> >>>> I am very interested in getting a new comm api in place which can >>>> provide >>>> the ability for all USB connected devices to have drivers provided >>>> as 100% >>>> java for all non-timing critical types of device interfaces. >>>> >>>> The JVM provider should have an SPI to write to which will enable >>>> them to >>>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>>> something >>>> that we can talk 100% java to. >>>> >>>> That's my big desire. Starting with something simple which gives >>>> a good >>>> start in that direction would be great! >>> That was exactly my wish too. >>> >>> The point people brought up was: >>> 1) It's too complex. >>> 2) What does it solve? >>> >>> In both facts they are right. It'll take a *long* time to plan such >>> a thing >>> right but if it works you have a product. Anyway, I'd like to join. ;) >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From lyon at docjava.com Sun Jul 23 04:27:22 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 06:27:22 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607222048.16215.pascal@quies.net> References: <200607221920.20096.pascal@quies.net> <200607222048.16215.pascal@quies.net> Message-ID: The Class.forName is a static method. Therefore myClass.forName Should be Class.forName and myClass becomes an unused parameter. - DL >http://quies.net/communicationapi.jar > >Fixed a few typo's and it works on Linux i386. It should also work on Windows >i386. The rest is missing libParallel or more... > > >Attachment converted: PowerBookHd:CommunicationAPI 1.java >(TEXT/ttxt) (001C1A15) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Jul 23 04:32:45 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 06:32:45 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607222048.16215.pascal@quies.net> References: <200607221920.20096.pascal@quies.net> <200607222048.16215.pascal@quies.net> Message-ID: Also, the is Java2 check does not check if you are running under jdk1.5 - DL >http://quies.net/communicationapi.jar > >Fixed a few typo's and it works on Linux i386. It should also work on Windows >i386. The rest is missing libParallel or more... > > >Attachment converted: PowerBookHd:CommunicationAPI 1.java >(TEXT/ttxt) (001C1A15) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Jul 23 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 06:54:12 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607221843.27765.pascal@quies.net> References: <44C252BF.6040404@cox.net> <200607221843.27765.pascal@quies.net> Message-ID: Hi All, Perhaps Java web start can address Gregg's concerns. The native libs are placed into a signed jar for distribution. As to the assertion that serial-port based programs need file io abilities, that seems true, to me. Particularly for /dev/ttyN type native libs or libs that use lock files. The question of how to obtain a signed application that is given file-io authority may be settled by using a signing technology. Even applets can be signed, to enable improved access to the file system. What else can we try? Any ideas? Thanks! - Doug >Op zaterdag 22 juli 2006 18:30, schreef Gregg Wonderly: >> Dr. Douglas Lyon wrote: >> > Hi All, >> > I like the idea of the native lib in a jar with other classes. >> > An alternative I did not know would work. >> >> I have several applications that run with a security policy. In these >> applications, native library loading will require an appropriate >> FilePermission that should be known about ahead of time. The current >> native library implementation will require the native library to be >> extracted from the jar and written to disk, requiring a >> FilePermission("...","write") for that file, and then will also require >> read access to load the library. I personally don't want to give write >> access to a JVM for a shared library which can provide a point of abuse by >> errant code. >> >> Gregg Wonderly > >That's indeed a pitty limitation. It creates a lot of possible exceptions too. > >On the other hand, any native lib passes the securiy model. Applications who >can access hardware ports can be expected to create files, right? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 04:57:33 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 12:57:33 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607222048.16215.pascal@quies.net> Message-ID: <200607231257.34284.pascal@quies.net> Op zondag 23 juli 2006 12:27, schreef Dr. Douglas Lyon: > The Class.forName is a static method. Therefore > myClass.forName Should be Class.forName and > myClass becomes an unused parameter. > - DL Thank you. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 6625 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060723/00f3b627/CommunicationAPI-0341.bin From pascal at quies.net Sun Jul 23 05:02:59 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 13:02:59 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607222048.16215.pascal@quies.net> Message-ID: <200607231302.59252.pascal@quies.net> Op zondag 23 juli 2006 12:32, schreef Dr. Douglas Lyon: > Also, the is Java2 check does not check if you are running under > jdk1.5 > - DL Could you please explain? The JDK 1.5 will pass the check just fine. From lyon at docjava.com Sun Jul 23 05:34:10 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 07:34:10 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607221854.13467.pascal@quies.net> References: <200607221506.07140.pascal@quies.net> <200607221854.13467.pascal@quies.net> Message-ID: Hi All, Please call me Doug (the Dr. is for the classroom). Thanks! - Doug >Hi Dr., > >We're both trying to do the same thing. > >The CommunicationAPI does not only look at the OS but it also indexes the >available hardware architectures and does not need OsUtils. Any Java 2 >runtime will do. > >The plan was to make a single JAR with the binaries for all supported >platforms, the RXTX gnu.io package and the javax.comm wrapers. > >A signed version would be nice. > >A few questions remain tough. Does anybody know how Sun uses the SunOS and >Solaris identifiers for the Java property os.name? > > > >Op zaterdag 22 juli 2006 16:06, schreef Dr. Douglas Lyon: >> Hi All, >> Here is how I have arranged my signed versions of the native >> binaries: >> http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/windows/native.j >>ar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/native.jar >> http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/linux/native.jar >> >> Then I do: >> public static URL getResourceUrl() throws MalformedURLException { >> String rxtxUrl = "http://show.docjava.com:8086/" + >> "book/cgij/code/jnlp/libs/rxtx/"; >> if (OsUtils.isLinux()) >> return new URL(rxtxUrl + "linux/native.jar"); >> if (OsUtils.isMacOs()) >> return new URL(rxtxUrl + "mac/native.jar"); >> if (OsUtils.isWindows()) >> return new URL(rxtxUrl + "windows/native.jar"); >> System.out.println("no automatic install supported for this >> platform. " + >> "Please e-mail lyon at docjava.com with a bug report"); >> return null; >> } >> >> My new-age NativeLibraryManger concept-thang allows you to >> write stuff like: >> >> /** >> * This method fixes the driver by beaming over >> * to the tmp directory a native.jar file. >> * The native.jar file is signed and its >> * native libs are beamed over to the user home directory >> * ~/.rxtx/
>> * Finally, the java.library.path is altered to include
>> * ~/.rxtx/ >> */ >> private static void fixDriver() { >> >> try { >> NativeLibraryManager.fixDriver(getResourceUrl(), >> NativeLibraryManager.mapLibraryName("rxtxSerial")); >> } catch (IOException e) { >> e.printStackTrace(); >> } >> } >> >> I do a lazy singleton design pattern: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public synchronized static RXTXCommDriver getInstance() { >> if (driver != null) return driver; >> if (!NativeLibraryManager.isLibInPath("rxtxSerial")) >> fixDriver(); >> if (NativeLibraryManager.isLibInPath("rxtxSerial")) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> } >> return driver; >> } >> >> I am at a cross-roads here, since a file-based distro might be preferable >> to a URL based distro. To make this really general, and to "remember" where >> the last version of a native library came from, I serialize a bean into >> user preferences >> The user can then store native libraries anywhere, remembering the location >> in the preferences. >> >> What is the general feeling about this? >> >> Thanks! >> - Doug >> >> > > Now, if you place the rxtx classes and native library in the same >> >> >> >> jar, do they both have to be in any specific place in order to be >> >> found? >> > >> >Answer: >> >> >The path to the libraries is in the form >> >> >of /native/rxtx/-/{libserial,libparallel} >> >> >so /native/rxtx/windows-i386/libserial would do. >> > >> >I'me looking for the various os.name and os.arch values right now. >> >_______________________________________________ >> >Rxtx mailing list >> >Rxtx at qbang.org >> >http://mailman.qbang.org/mailman/listinfo/rxtx > > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 06:12:33 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 14:12:33 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607221843.27765.pascal@quies.net> Message-ID: <200607231412.34078.pascal@quies.net> Op zondag 23 juli 2006 12:54, schreef Dr. Douglas Lyon: > Hi All, > Perhaps Java web start can address Gregg's concerns. > The native libs are placed into a signed jar for distribution. > As to the assertion that serial-port based programs need file io > abilities, that seems true, to me. Particularly for /dev/ttyN type > native libs or libs that use lock files. > The question of how to obtain a signed application that is given > file-io authority may be settled by using a signing technology. > > Even applets can be signed, to enable improved access to the file > system. > > What else can we try? Any ideas? It might be a good idea to use a more optimized version for youre networked applications. These native libraries are huge for some reason. Can you build a "downloader"? From lyon at docjava.com Sun Jul 23 06:46:43 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 08:46:43 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607231302.59252.pascal@quies.net> References: <200607222048.16215.pascal@quies.net> <200607231302.59252.pascal@quies.net> Message-ID: public static void main(String[] args) { System.out.println("isJava2="+System.getProperty("java.version")); } Prints out 1.5_06 on my system, but you seem to need the "1.2" to be present on the system...right? RXTX does work under 1.5, at least on my system. - DL >Op zondag 23 juli 2006 12:32, schreef Dr. Douglas Lyon: >> Also, the is Java2 check does not check if you are running under >> jdk1.5 >> - DL > >Could you please explain? >The JDK 1.5 will pass the check just fine. >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Jul 23 06:58:02 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 08:58:02 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607231412.34078.pascal@quies.net> References: <200607221843.27765.pascal@quies.net> <200607231412.34078.pascal@quies.net> Message-ID: Hi All, Yes, I do have a download, as to the question of "huge": ls -al native.jar -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar 28kbytes is not really huge, right? In fact, if you uncompress the jar, you get: -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so Which is almost 80kbytes, so the jar is 40% of the native libs size, and it is signed. At least on the Linux version, it is smaller. I did not check the other versions. And with java web start, the JNLP only downloads the native jar if it is new or changed. And it only downloads the native jar used for the target platform. Here is how the jnlp looks, FYI... addbk.JAddressBook.Main DocJava, Inc. I have been playing around with "eager" and "lazy" directives, but I can't really tell the difference. Cheers! - Doug >Op zondag 23 juli 2006 12:54, schreef Dr. Douglas Lyon: >> Hi All, >> Perhaps Java web start can address Gregg's concerns. >> The native libs are placed into a signed jar for distribution. >> As to the assertion that serial-port based programs need file io >> abilities, that seems true, to me. Particularly for /dev/ttyN type >> native libs or libs that use lock files. >> The question of how to obtain a signed application that is given >> file-io authority may be settled by using a signing technology. >> >> Even applets can be signed, to enable improved access to the file >> system. >> >> What else can we try? Any ideas? > >It might be a good idea to use a more optimized version for youre networked >applications. These native libraries are huge for some reason. >Can you build a "downloader"? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 07:53:54 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 15:53:54 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607231302.59252.pascal@quies.net> Message-ID: <200607231553.55088.pascal@quies.net> Op zondag 23 juli 2006 14:46, schreef Dr. Douglas Lyon: > public static void main(String[] args) { > System.out.println("isJava2="+System.getProperty("java.version")); > > } > Prints out 1.5_06 on my system, but you seem to need the "1.2" to be > present on the system...right? if (System.getProperty("java.version").compareTo("1.2") < 0) throw new Error("RXTX requires a Java 2 platform."); The line requires a version string of "1.2" or higher. Sun decided to name all versions since 1.2 as Java 2. (That is why there is this 2 in J2SE.) The error should never happen anyway if you compile the code with the -target 1.2 flag. From pascal at quies.net Sun Jul 23 07:55:52 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 15:55:52 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607231412.34078.pascal@quies.net> Message-ID: <200607231555.52419.pascal@quies.net> Op zondag 23 juli 2006 14:58, schreef Dr. Douglas Lyon: > Hi All, > Yes, I do have a download, as to the question of "huge": > ls -al native.jar > -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar > 28kbytes is not really huge, right? > In fact, if you uncompress the jar, you get: > -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so > -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so > Which is almost 80kbytes, so the jar is 40% of the native libs size, and > it is signed. > At least on the Linux version, it is smaller. I did not check the > other versions. > > And with java web start, the JNLP only downloads the native jar if it is > new or changed. > And it only downloads the native jar used for the target platform. > > Here is how the jnlp looks, FYI... > codebase="http://show.docjava.com:8086/book/cgij/code/jnlp/"> > > addbk.JAddressBook.Main > DocJava, Inc. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have been playing around with "eager" and "lazy" directives, > but I can't really tell the difference. > > Cheers! > - Doug That is a nice sollution. Is there a tag for the architecture too becouse now you assume i386 and that is of course not necesairy true. From joachim at buechse.de Sun Jul 23 11:17:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 23 Jul 2006 19:17:29 +0200 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <41E45C85-4A22-4C5B-915F-62ED36BACCF2@sympatico.ca> References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> <41E45C85-4A22-4C5B-915F-62ED36BACCF2@sympatico.ca> Message-ID: <0B7FC525-4C71-49E8-B652-CCF6C67B4A58@buechse.de> This happens with the versions in CVS (2.07+ and 2.17+). On 22.07.2006, at 19:58, Andr?-John Mas wrote: > A couple of questions: > - what version are you using? > - does this happen with the version in cvs? > > Andre > > On 22-Jul-06, at 13:37 , Joachim Buechse wrote: > >> I just discovered a strange error in RXTX on OSX. SerialDemo.java >> manages to corrupt the event_info_structure by a simple >> OpenPort,ClosePort - this could be in relation to the deadlock >> problem that was reported recently. >> >> Could anyone try to reproduce this on Solaris or some other system >> which is neither WIN32 nor Linux (ie which uses a drain thread). >> >> In SerialImp.c : RXTXPort(interruptEventLoop) >> >> Apparently the event_info_structure gets corrupted shortly after >> >> pthread_kill(index->drain_tid, SIGABRT); >> >> In particular, the index->closing flag gets overwritten by a pointer >> value. >> >> >> **** Adding the following debugging code: >> >> pthread_kill(index->drain_tid, SIGABRT); >> sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i >> \n", index->fd, index, index->closing ); >> report( message ); >> /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ >> usleep(50 * 1000); >> sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i >> \n", index->fd, index, index->closing ); >> report( message ); >> >> **** gives me: >> >> 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 >> drain_loop: received EINTR------------------ drain_loop exiting >> --------------------- >> entering check_tiocmget_changes >> leaving check_tiocmget_changes >> port_has_changed_fionread: change is 0 >> eventLoop: got interrupt >> 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 >> >> **** Modifying SerialImp.h : event_info_struct by moving the >> prev*, next* pointers >> >> jmethodID checkMonitorThread; >> struct event_info_struct *dummy, *dummy2; >> fd_set rfds; >> struct timeval tv_sleep; >> int closing; >> struct event_info_struct *next, *prev; >> >> *** (ie replacing their original position with dummys and moving them >> *** behind the closing flag) results in this: >> >> 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 >> drain_loop: received EINTR------------------ drain_loop exiting >> --------------------- >> entering check_tiocmget_changes >> leaving check_tiocmget_changes >> port_has_changed_fionread: change is 0 >> eventLoop: got interrupt >> 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 >> >> >> *** I was not able to track down the problem. If anyone could check >> wether this happens on other platforms as well, we may get closer to >> a fix. >> >> Regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Sun Jul 23 11:44:48 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 23 Jul 2006 19:44:48 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607230153.32328.pascal@quies.net> References: <44C252BF.6040404@cox.net> <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> <200607230153.32328.pascal@quies.net> Message-ID: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> Gregg's concern was, that extracting the library from the jar and loading it via System.load needs file access privileges. To solve this concern, all that's required is a static method/flag that triggers loading via System.loadLibrary instead (of course, then he needs to make sure, that the library is on the java.library.path). This could also be handled via a system property of course. Regards, Joachim On 23.07.2006, at 01:53, Pascal S. de Kloe wrote: > Hi Joachim, > > I'm not getting it. > How do you easily get a "stub method / flag"? > > > Op zaterdag 22 juli 2006 19:17, schreef Joachim Buechse: >> We could easily have a stub method / flag that allows you to >> explicitly load the native library (via System.loadLibrary ie from >> the java.library.path). In this case the "auto-extraction" would not >> take place. >> >> On 22.07.2006, at 18:30, Gregg Wonderly wrote: >>> Dr. Douglas Lyon wrote: >>>> Hi All, >>>> I like the idea of the native lib in a jar with other classes. >>>> An alternative I did not know would work. >>> >>> I have several applications that run with a security policy. In >>> these >>> applications, native library loading will require an appropriate >>> FilePermission >>> that should be known about ahead of time. The current native >>> library >>> implementation will require the native library to be extracted from >>> the jar and >>> written to disk, requiring a FilePermission("...","write") for that >>> file, and >>> then will also require read access to load the library. I >>> personally don't want >>> to give write access to a JVM for a shared library which can >>> provide a point of >>> abuse by errant code. >>> >>> Gregg Wonderly >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 13:34:17 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 21:34:17 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> References: <200607230153.32328.pascal@quies.net> <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> Message-ID: <200607232134.17451.pascal@quies.net> Aaah, the penny drops. I was reading it as the stub method _root_ flag like using the root of a jar as a context for java.library.path. Thanks for explaining. :) I'll build it right away. Op zondag 23 juli 2006 19:44, schreef Joachim Buechse: > Gregg's concern was, that extracting the library from the jar and > loading it via System.load needs file access privileges. To solve > this concern, all that's required is a static method/flag that > triggers loading via System.loadLibrary instead (of course, then he > needs to make sure, that the library is on the java.library.path). > This could also be handled via a system property of course. > > Regards, > Joachim > > On 23.07.2006, at 01:53, Pascal S. de Kloe wrote: > > Hi Joachim, > > > > I'm not getting it. > > How do you easily get a "stub method / flag"? > > > > Op zaterdag 22 juli 2006 19:17, schreef Joachim Buechse: > >> We could easily have a stub method / flag that allows you to > >> explicitly load the native library (via System.loadLibrary ie from > >> the java.library.path). In this case the "auto-extraction" would not > >> take place. > >> > >> On 22.07.2006, at 18:30, Gregg Wonderly wrote: > >>> Dr. Douglas Lyon wrote: > >>>> Hi All, > >>>> I like the idea of the native lib in a jar with other classes. > >>>> An alternative I did not know would work. > >>> > >>> I have several applications that run with a security policy. In > >>> these > >>> applications, native library loading will require an appropriate > >>> FilePermission > >>> that should be known about ahead of time. The current native > >>> library > >>> implementation will require the native library to be extracted from > >>> the jar and > >>> written to disk, requiring a FilePermission("...","write") for that > >>> file, and > >>> then will also require read access to load the library. I > >>> personally don't want > >>> to give write access to a JVM for a shared library which can > >>> provide a point of > >>> abuse by errant code. > >>> > >>> Gregg Wonderly > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 18:10:45 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 02:10:45 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607232134.17451.pascal@quies.net> References: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> <200607232134.17451.pascal@quies.net> Message-ID: <200607240210.45992.pascal@quies.net> Hello gentleman, The CommunicationAPI class / utility is almost ready. Could you please have a final look and give your opinion? Does anybody know how the SunOS and the Solaris os.name is used? Sun uses just sparc as the description for os.arch. Is it safe to use the 32-bit binaries? @Gregg You can extract the necessary libraries during the installation with the extractNativeLibraries method to the application directory so they get loaded automatically. Is that good enough? @Trent Would you include this class afther any possible comments in the distribution? -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 10884 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060723/d2e99122/CommunicationAPI-0340.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: PlatformNotSupportedException.java Type: text/x-java Size: 1621 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060723/d2e99122/PlatformNotSupportedException-0340.bin From lyon at docjava.com Sun Jul 23 18:14:08 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 20:14:08 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607231555.52419.pascal@quies.net> References: <200607231412.34078.pascal@quies.net> <200607231555.52419.pascal@quies.net> Message-ID: Hi All, The present JNLP distro that I use: > > >> >> > Works for Macs using G3 and G4's. I have not tested this with an i386 mac, as I do not have one. And it only works with i386 based linux... As far as architecture goes: Allows for a chip arch, and this might address your question. The real bottleneck is that you need one of everything to test a deployment, or you have to know a bunch of people (like on this list!) to do a proper test. Cheers! - Doug >Op zondag 23 juli 2006 14:58, schreef Dr. Douglas Lyon: >> Hi All, >> Yes, I do have a download, as to the question of "huge": >> ls -al native.jar >> -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar >> 28kbytes is not really huge, right? >> In fact, if you uncompress the jar, you get: >> -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so >> -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so >> Which is almost 80kbytes, so the jar is 40% of the native libs size, and >> it is signed. >> At least on the Linux version, it is smaller. I did not check the >> other versions. >> >> And with java web start, the JNLP only downloads the native jar if it is >> new or changed. >> And it only downloads the native jar used for the target platform. >> >> Here is how the jnlp looks, FYI... >> > codebase="http://show.docjava.com:8086/book/cgij/code/jnlp/"> >> >> addbk.JAddressBook.Main >> DocJava, Inc. >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > >> >> > > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> I have been playing around with "eager" and "lazy" directives, >> but I can't really tell the difference. >> >> Cheers! >> - Doug > >That is a nice sollution. > >Is there a tag for the architecture too becouse now you assume i386 and that >is of course not necesairy true. >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Sun Jul 23 10:38:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 23 Jul 2006 11:38:50 -0500 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607221843.27765.pascal@quies.net> References: <44C252BF.6040404@cox.net> <200607221843.27765.pascal@quies.net> Message-ID: <44C3A61A.3060706@cox.net> Pascal S. de Kloe wrote: > Op zaterdag 22 juli 2006 18:30, schreef Gregg Wonderly: >>I have several applications that run with a security policy. In these >>applications, native library loading will require an appropriate >>FilePermission that should be known about ahead of time. The current >>native library implementation will require the native library to be >>extracted from the jar and written to disk, requiring a >>FilePermission("...","write") for that file, and then will also require >>read access to load the library. I personally don't want to give write >>access to a JVM for a shared library which can provide a point of abuse by >>errant code. > That's indeed a pitty limitation. It creates a lot of possible exceptions too. > > On the other hand, any native lib passes the securiy model. Applications who > can access hardware ports can be expected to create files, right? The use of an appropriate security policy is a deployment time configuration. There needs to be appropriate limits that confine the software to its intended tasks. Gregg Wonderly From gergg at cox.net Sun Jul 23 10:56:39 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 23 Jul 2006 11:56:39 -0500 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607221920.20096.pascal@quies.net> <200607222048.16215.pascal@quies.net> Message-ID: <44C3AA47.4060003@cox.net> Dr. Douglas Lyon wrote: > The Class.forName is a static method. Therefore > myClass.forName Should be Class.forName and > myClass becomes an unused parameter. Or better yet, make that parameter a context classloader and call Class.forName( classname, classloader); so that the location of the codebase for loading classes can be separate from the applications classpath. Gregg Wonderly From tjarvi at qbang.org Sun Jul 23 20:26:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 20:26:04 -0600 (MDT) Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: I do not see a point of having CommAPI do much more than basic termios interfaces and possibly parallel ports. The kernels can deliver that interface just fine for USB and other types. One problem with the current implementation for USB and IrDA is hotplug. There is a HAL daemon that can send connect and disconnect events which should probably be added to a new API. Sun is also working on a HAL port for Solaris. It is hackish but I saw at the Linux symposium that it will be getting attention and improving. The point being that these events could be included not that HAL is the end of all problems. It would appear to me that anything further in USB space should be done with the/a USB API to avoid duplication of efforts. USB is only one of many low level options for termios interfaces. On Sat, 22 Jul 2006, Joachim Buechse wrote: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. > > It is clear that javax.comm can never provide a way to talk to all > USB devices, simply because some USB devices have several endpoints. > But it could provide a means of talking to devices that function as a > bidirectional-pipe (ie any USB to serial bridge). > > Regards, > Joachim > > On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > >> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>> Pascal S. de Kloe wrote: >>>>>> I am also not sure if >>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>> single >>>>>> port. >>>>> >>>>> I think the API should hide low-level details like devicefiles. >>>> >>>> Not all ports have device files. It's long been my goal to add >>>> support >>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>> servers, for example integrating RFC2217. This means that the >>>> port name >>>> is some combination of an IP address and TCP port number. >>>> Nothing in >>>> /dev. >>> >>> What I think would make the most sense is a simple "device" >>> enumeration >>> Server Provider Interface that would bring port objects into the >>> JVM based >>> on the platform JVM providers knowledge of how to enumerate those >>> ports. >>> Application writers would provide a plugin using the SPI that >>> would codify >>> those devices into named entities that they are interested in. >>> >>> public interface HardwarePort { >>> public String getName(); >>> public String getHardwareID(); >>> public String getManufacturer(); >>> public List getCapabilities(); >>> public Object getImplementation(); >>> } >>> >>> public interface PortCapability { >>> public String getDescription(); >>> public CapabilityId getIdentifier(); >>> } >>> >>> public enum CapabilityId { >>> INPUT, // Can receive input >>> OUTPUT, // Can send output >>> ASYNCHRONOUS, // Can send and receive at the same time >>> SYNCHRONOUS, // No synchronous I/O >>> ADDRESSABLE // Port has an address associated >>> } >>> >>> Then, you might imagine that the enumerated capabilities had a >>> standardized/specified interface that you'd find implemented on >>> ports that >>> had such capabilities. >>> >>> The getImplementation() method would return the implementation class >>> provided by the JVM provider that had all of the interfaces tied >>> to it. >>> >>> These are just some quick thoughts, pick away at them. >>> >>> I am very interested in getting a new comm api in place which can >>> provide >>> the ability for all USB connected devices to have drivers provided >>> as 100% >>> java for all non-timing critical types of device interfaces. >>> >>> The JVM provider should have an SPI to write to which will enable >>> them to >>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>> something >>> that we can talk 100% java to. >>> >>> That's my big desire. Starting with something simple which gives >>> a good >>> start in that direction would be great! >> >> That was exactly my wish too. >> >> The point people brought up was: >> 1) It's too complex. >> 2) What does it solve? >> >> In both facts they are right. It'll take a *long* time to plan such >> a thing >> right but if it works you have a product. Anyway, I'd like to join. ;) >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jul 23 20:31:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 20:31:45 -0600 (MDT) Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607231412.34078.pascal@quies.net> References: <200607221843.27765.pascal@quies.net> <200607231412.34078.pascal@quies.net> Message-ID: On Sun, 23 Jul 2006, Pascal S. de Kloe wrote: > Op zondag 23 juli 2006 12:54, schreef Dr. Douglas Lyon: >> Hi All, >> Perhaps Java web start can address Gregg's concerns. >> The native libs are placed into a signed jar for distribution. >> As to the assertion that serial-port based programs need file io >> abilities, that seems true, to me. Particularly for /dev/ttyN type >> native libs or libs that use lock files. >> The question of how to obtain a signed application that is given >> file-io authority may be settled by using a signing technology. >> >> Even applets can be signed, to enable improved access to the file >> system. >> >> What else can we try? Any ideas? > > It might be a good idea to use a more optimized version for youre networked > applications. These native libraries are huge for some reason. > Can you build a "downloader"? It may be that the binaries are not stripped. "strip librtxserial.so" for instance. That will remove the symbols which are not usually needed in production. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jul 23 20:49:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 20:49:16 -0600 (MDT) Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607240210.45992.pascal@quies.net> References: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> <200607232134.17451.pascal@quies.net> <200607240210.45992.pascal@quies.net> Message-ID: On Mon, 24 Jul 2006, Pascal S. de Kloe wrote: > Hello gentleman, > > The CommunicationAPI class / utility is almost ready. > Could you please have a final look and give your opinion? > > > Does anybody know how the SunOS and the Solaris os.name is used? > > Sun uses just sparc as the description for os.arch. Is it safe to use the > 32-bit binaries? > > > > @Gregg > You can extract the necessary libraries during the installation with the > extractNativeLibraries method to the application directory so they get loaded > automatically. Is that good enough? > > @Trent > Would you include this class afther any possible comments in the distribution? > Hi Pascal, It would appear to me that this is a tool for using the API, not an API. So perhaps the classname is not the best choice. The class also has a main which would not make a great deal of sense to include in the library to me. It would make a nice example for the contrib directory or a new utility directory though. Documentation of its availability in the main document could make it stand out from the other contrib files. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jul 23 21:27:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 21:27:48 -0600 (MDT) Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> Message-ID: On Sat, 22 Jul 2006, Joachim Buechse wrote: > I just discovered a strange error in RXTX on OSX. SerialDemo.java > manages to corrupt the event_info_structure by a simple > OpenPort,ClosePort - this could be in relation to the deadlock > problem that was reported recently. > > Could anyone try to reproduce this on Solaris or some other system > which is neither WIN32 nor Linux (ie which uses a drain thread). > > In SerialImp.c : RXTXPort(interruptEventLoop) > > Apparently the event_info_structure gets corrupted shortly after > > pthread_kill(index->drain_tid, SIGABRT); > > In particular, the index->closing flag gets overwritten by a pointer > value. > > > **** Adding the following debugging code: > > pthread_kill(index->drain_tid, SIGABRT); > sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ > usleep(50 * 1000); > sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > > **** gives me: > > 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 > > **** Modifying SerialImp.h : event_info_struct by moving the > prev*, next* pointers > > jmethodID checkMonitorThread; > struct event_info_struct *dummy, *dummy2; > fd_set rfds; > struct timeval tv_sleep; > int closing; > struct event_info_struct *next, *prev; > > *** (ie replacing their original position with dummys and moving them > *** behind the closing flag) results in this: > > 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 > > > *** I was not able to track down the problem. If anyone could check > wether this happens on other platforms as well, we may get closer to > a fix. > Hi Joachim Interesting. I did run many tests with that code on may OSs. To be fair, the tests are just starting to get into good shape again. I'm still tagging releases with a bit of feel and not enough process. I'll look at this some more tomorrow night. The SIGABRT was added recently as part of the close speedups. Thats from memory. I can provide the exact patch that introduced that tomorrow. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jul 23 22:22:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 22:22:26 -0600 (MDT) Subject: [Rxtx] clarification Message-ID: It should be clear that doug is the maintainer of rxtx.org now. I'll be running around very fast trying to make that easier for him but if you want something in rxtx, it is doug that does that. There are some things doug isnt very good at. He needs some help there. If he asks others for their opinion, thats his call. If he asks others for help, thats his call. This was setup to help the community. I hope everyone makes good use of it as they are now. I'm very happy with what I see but I want to make it clear that nobody should be asking me to be in rxtx. I have interests but they may not always be yours. -- Trent Jarvi tjarvi at qbang.org From guille at sms.nl Mon Jul 24 00:32:26 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Mon, 24 Jul 2006 08:32:26 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <7.0.1.0.0.20060724082455.038aa518@sms.nl> At 18:31 20/07/2006, Trent Jarvi wrote: > > PROJECT SCOPE: > > ------------- > > > > Also, we should think carefully about what the scope of > > this project would be. Should it be javax."comm" which > > handles both serial and parallel (is parallel going by the > > wayside). Should it be split into two project: > > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > > > > Should we differentiate between single-ended serial > > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > > quasi-multidrop and full multidrop busses such as > > EIA422, EIA432 and EIA485? If we really were to > > add I2C support to the API, we'd have to delve into > > the semantics more, because there could be some > > implicit decoding of the bus the API users would > > want to see. > > > >Hi Paul > >The way RXTX works, which is a fair representation of the people using the >API, is complete support for RIA232, minimal support for IEEE1284. From >what I understand, Sun was going along the same lines. If we combined >both projects, we would have half a parallel port implementation. I see >maybe 4 requests for features not in the parallel support a year. > >The other protocols should not be limited by a JSR which is going to be >focused upon serial port interests. The IEA485 hacks in RXTX along with >I2C and Raw should _not_ be considered a strong basis for extending the >API to cover these protocols. If people want to do real implementations, >they should not face a 'standard' which wasnt really focused upon their >interests. I think we understand the parallel port issues fairly well but >have not implemented many features and I don't know if we would. I agree with all of this. API requirements for I2C, SPI, etc. are very different from those for RS232/485/422. Our embedded Java platform has APIs for all of these and more and they don't share a lot apart from the fact that they all use Input/OutputStreams (and in the case of SPI you still need to cater with the fact that every time you want to read you must also write to the device.) If I was to design javax.comm from scratch, I think I would focus on serial ports exclusively (== whatever the underlying OS represents as serial ports). Even parallel is a bit out of place IMHO, although I understand it needs to stay for backwards compatibility. >So a versatile API is favorable but I do not think we have the proper >community to represent much more than Serial. Yes, I think the same. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From joachim at buechse.de Mon Jul 24 01:33:14 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 24 Jul 2006 09:33:14 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607231412.34078.pascal@quies.net> <200607231555.52419.pascal@quies.net> Message-ID: <106C7BEC-EC26-4A05-8E94-61E2C9F2A54E@buechse.de> Or you put your project on Sourceforge and use this: http://sourceforge.net/docs/compile_farm#hosts On 24.07.2006, at 02:14, Dr. Douglas Lyon wrote: > Hi All, > The present JNLP distro that I use: >>> >>> >> download="eager" /> >>> >> > > Works for Macs using G3 and G4's. I have not tested > this with an i386 mac, as I do not have one. And it only works > with i386 based linux... > > As far as architecture goes: > > > > Allows for a chip arch, and this might address your question. > > The real bottleneck is that you need one of everything to test a > deployment, > or you have to know a bunch of people (like on this list!) to do a > proper test. > > Cheers! > - Doug > > >> Op zondag 23 juli 2006 14:58, schreef Dr. Douglas Lyon: >>> Hi All, >>> Yes, I do have a download, as to the question of "huge": >>> ls -al native.jar >>> -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar >>> 28kbytes is not really huge, right? >>> In fact, if you uncompress the jar, you get: >>> -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so >>> -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so >>> Which is almost 80kbytes, so the jar is 40% of the native libs >>> size, and >>> it is signed. >>> At least on the Linux version, it is smaller. I did not check the >>> other versions. >>> >>> And with java web start, the JNLP only downloads the native jar >>> if it is >>> new or changed. >>> And it only downloads the native jar used for the target platform. >>> >>> Here is how the jnlp looks, FYI... >>> >> codebase="http://show.docjava.com:8086/book/cgij/code/ >>> jnlp/"> >>> >>> addbk.JAddressBook.Main >>> DocJava, Inc. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> download="eager" /> >>> >>> >>> >>> >>> >> download="lazy" /> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I have been playing around with "eager" and "lazy" directives, >>> but I can't really tell the difference. >>> >>> Cheers! >>> - Doug >> >> That is a nice sollution. >> >> Is there a tag for the architecture too becouse now you assume >> i386 and that >> is of course not necesairy true. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jul 24 02:13:15 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 24 Jul 2006 10:13:15 +0200 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> Message-ID: <939306BB-2AEE-4D20-906E-9A9B40C76125@buechse.de> The pthread_kill is followed by a sleep. When the sleep returns the structure is damaged. I did not find the source that overwrites the closing field - it is correctly set by the exiting drain thread. But something overwrites it afterwards. I currently believe that this existed for some time but was never seen because the previous versions did not rely on the structure to be in good shape when tearing down connections. However I may be completely wrong and it is an OSX problem. To help me find the source, it would be nice to get some indications what the 2 debug lines I suggested return on other platforms. Joachim On 24.07.2006, at 05:27, Trent Jarvi wrote: > On Sat, 22 Jul 2006, Joachim Buechse wrote: > >> I just discovered a strange error in RXTX on OSX. SerialDemo.java >> manages to corrupt the event_info_structure by a simple >> OpenPort,ClosePort - this could be in relation to the deadlock >> problem that was reported recently. >> >> Could anyone try to reproduce this on Solaris or some other system >> which is neither WIN32 nor Linux (ie which uses a drain thread). >> >> In SerialImp.c : RXTXPort(interruptEventLoop) >> >> Apparently the event_info_structure gets corrupted shortly after >> >> pthread_kill(index->drain_tid, SIGABRT); >> >> In particular, the index->closing flag gets overwritten by a pointer >> value. > > Hi Joachim > > Interesting. I did run many tests with that code on may OSs. To > be fair, > the tests are just starting to get into good shape again. I'm still > tagging releases with a bit of feel and not enough process. I'll > look at > this some more tomorrow night. > > The SIGABRT was added recently as part of the close speedups. > Thats from > memory. I can provide the exact patch that introduced that tomorrow. > > -- > Trent Jarvi > tjarvi at qbang.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Mon Jul 24 05:58:21 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 13:58:21 +0200 Subject: [Rxtx] =?iso-8859-1?q?NativeLibraryManager_-_A_general_solution_a?= =?iso-8859-1?q?n_to_old=09problem=2E?= In-Reply-To: <44C3AA47.4060003@cox.net> References: <44C3AA47.4060003@cox.net> Message-ID: <200607241358.21366.pascal@quies.net> Op zondag 23 juli 2006 18:56, schreef Gregg Wonderly: > Dr. Douglas Lyon wrote: > > The Class.forName is a static method. Therefore > > myClass.forName Should be Class.forName and > > myClass becomes an unused parameter. > > Or better yet, make that parameter a context classloader and call > > Class.forName( classname, classloader); > > so that the location of the codebase for loading classes can be separate > from the applications classpath. I agree. -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 10719 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060724/693f269d/CommunicationAPI-0340.bin From pascal at quies.net Mon Jul 24 06:05:53 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 14:05:53 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607240210.45992.pascal@quies.net> Message-ID: <200607241405.53456.pascal@quies.net> Op maandag 24 juli 2006 04:49, schreef Trent Jarvi: > > @Trent > > Would you include this class afther any possible comments in the > > distribution? > > Hi Pascal, > > It would appear to me that this is a tool for using the API, not an API. > So perhaps the classname is not the best choice. > > The class also has a main which would not make a great deal of sense to > include in the library to me. It would make a nice example for the > contrib directory or a new utility directory though. Documentation of its > availability in the main document could make it stand out from the other > contrib files. The name-change and the removal of main() would ofcourse be no problem. You really don't want to distribute binaries, huh? How can the developers of RXTX know whether it works on a machine they don't have? Anyway, I don't see anotherway to get a version of the extension "that just works" than to build my own distribution. :@ I also can't believe that nobody on this list has binaries for official supported platforms like Windows IA64 and Windows x86_64 unless the build fails on these platforms (which would be nice to know). http://java.sun.com/j2se/1.4.2/system-configurations.html http://java.sun.com/j2se/1.5.0/system-configurations.html From pascal at quies.net Mon Jul 24 06:08:45 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 14:08:45 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <106C7BEC-EC26-4A05-8E94-61E2C9F2A54E@buechse.de> References: <106C7BEC-EC26-4A05-8E94-61E2C9F2A54E@buechse.de> Message-ID: <200607241408.45956.pascal@quies.net> Op maandag 24 juli 2006 09:33, schreef Joachim Buechse: > Or you put your project on Sourceforge and use this: > > http://sourceforge.net/docs/compile_farm#hosts That's nice. :) I'll host a distribution on Sourceforge real soon. HP also has a such a facility for PA-RISC and IA64 architectures at http://www.testdrive.hp.com/ The other day I was thinking about building a big bittorrent with Qemu images for developers. The number of platforms seems impressive: http://qemu.org/status.html With each image compressed with bzip2 a clean installation of OpenBSD and FreeBSD and a Debian Woody + gmake + gcc for each Qemu platform will take about 1.5GB. From lyon at docjava.com Mon Jul 24 07:07:02 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 24 Jul 2006 09:07:02 -0400 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060724082455.038aa518@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: Hi All, There has been a lot of discussion regarding RS485. Let me see if I can summarize this, please correct me if I am wrong; I am deliberately ignoring connector and electrical issues, focusing, instead, on protocol and software issues. Also, I have never used RS485, and I don't know much about it. 1. Serial ports that claim RS232 are typically used in the data link layer of the OSI model of networking. Basically, this means that they work with a point-to-point protocol and are meant to connect two devices. 2. Within the RS232 standard there are framing bits (start and stop bits) and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. Thats' it. 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) you do it in software, not in the RS232 standard. 4. RS485 is different from RS232 in that it is in the Network Layer of the OSI model of networking. 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in a factory). RS-485 is similar to RS-422, but RS-422 allows just one driver with multiple receivers whereas RS-485 supports multiple drivers and receivers. 6. RS-485 is a serial bus with multiple nodes and thus must handle network link layer protocols. By using high-impedance receivers, you can have as many as 256 nodes. 7. The RS-485 can be implemented with RXTX in the core and a layer of software on top to handle media access control (MAC sublayer). There are also hardware converters. http://www.rs485.com/pconverters.html for example. However, some of these require software control. There is some support in the form of the Rs485.java class, in RXTX. 8. The RS-485 specification will add to the size of the JSR 9. Javax.comm specification, version 2.0 (the Real OLD version) says: This version of the Java communications API contains support for RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not mentioned. 10. DO people want to add RS485 to a new JSR? Would it make sense for the RS-485 people to speak up now? Please let me know if you think my summary is wrong. Thanks! - Doug >At 18:31 20/07/2006, Trent Jarvi wrote: >> > PROJECT SCOPE: >> > ------------- >> > >> > Also, we should think carefully about what the scope of >> > this project would be. Should it be javax."comm" which >> > handles both serial and parallel (is parallel going by the >> > wayside). Should it be split into two project: >> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >> > >> > Should we differentiate between single-ended serial >> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >> > quasi-multidrop and full multidrop busses such as >> > EIA422, EIA432 and EIA485? If we really were to >> > add I2C support to the API, we'd have to delve into >> > the semantics more, because there could be some >> > implicit decoding of the bus the API users would >> > want to see. >> > >> >>Hi Paul >> >>The way RXTX works, which is a fair representation of the people using the >>API, is complete support for RIA232, minimal support for IEEE1284. From >>what I understand, Sun was going along the same lines. If we combined >>both projects, we would have half a parallel port implementation. I see >>maybe 4 requests for features not in the parallel support a year. >> >>The other protocols should not be limited by a JSR which is going to be >>focused upon serial port interests. The IEA485 hacks in RXTX along with >>I2C and Raw should _not_ be considered a strong basis for extending the >>API to cover these protocols. If people want to do real implementations, >>they should not face a 'standard' which wasnt really focused upon their >>interests. I think we understand the parallel port issues fairly well but >>have not implemented many features and I don't know if we would. > >I agree with all of this. API requirements for I2C, SPI, etc. are very >different from those for RS232/485/422. Our embedded Java platform has >APIs for all of these and more and they don't share a lot apart from the >fact that they all use Input/OutputStreams (and in the case of SPI you >still need to cater with the fact that every time you want to read you >must also write to the device.) > >If I was to design javax.comm from scratch, I think I would focus on >serial ports exclusively (== whatever the underlying OS represents as >serial ports). Even parallel is a bit out of place IMHO, although I >understand it needs to stay for backwards compatibility. > > >>So a versatile API is favorable but I do not think we have the proper >>community to represent much more than Serial. > >Yes, I think the same. > >Guillermo >-- >Guillermo Rodriguez Garcia > >Snijder Micro Systems phone +31-493-351020 >G. Rodriguez Garcia fax +31-493-351530 >Visser 25 email guille at sms.nl >NL5751 BL Deurne >The Netherlands http://www.snijder.com > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Mon Jul 24 07:46:55 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Mon, 24 Jul 2006 10:46:55 -0300 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: <44C4CF4F.1080706@gmail.com> Doug: I do not think that RS485 is a must by now. I do think we must make a JSR to standarize a bit Serial Ports accessing. Maybe we can make a JSR just for serial ports, and then start trying with other kind of ports and make others JSR. Or try to expand our first JSR, but I trully do not know if that can be made. About other ports besides RS485, the others I2C, SPI, etc, run at a very low level, maybe too close to the processor for Java. I do not know if Java is fast enough to access this ports, even more as this ports depends directly from the architecture, the write once run every way of Java is somekind useless at this level, so I do not think this is suitable for us. Regards, Manuel > Hi All, > There has been a lot of discussion regarding RS485. > > Let me see if I can summarize this, please correct me if I am wrong; > I am deliberately ignoring connector and electrical issues, focusing, > instead, on protocol and software issues. Also, I have never used > RS485, and I don't know much about it. > > 1. Serial ports that claim RS232 are typically used in > the data link layer of the OSI model of networking. Basically, this means > that they work with a point-to-point protocol and are meant to connect two > devices. > > 2. Within the RS232 standard there are framing bits (start and stop bits) > and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. > Thats' it. > > 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) > you do it in software, not in the RS232 standard. > > 4. RS485 is different from RS232 in that it is in the Network Layer of > the OSI model of networking. > > 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > a factory). > RS-485 is similar to RS-422, but RS-422 allows just one driver with > multiple receivers whereas RS-485 supports multiple drivers and > receivers. > > 6. RS-485 is a serial bus with multiple nodes and thus must handle network > link layer protocols. By using high-impedance receivers, you can have > as many as 256 nodes. > > 7. The RS-485 can be implemented with RXTX in the core and a layer of software > on top to handle media access control (MAC sublayer). There are also > hardware converters. > http://www.rs485.com/pconverters.html for example. However, some of > these require software control. There is some support in the form of > the Rs485.java class, > in RXTX. > > 8. The RS-485 specification will add to the size of the JSR > > 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > This version of the Java communications API contains support for > RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > mentioned. > > 10. DO people want to add RS485 to a new JSR? > > Would it make sense for the RS-485 people to speak up now? > Please let me know if you think my summary is wrong. > > Thanks! > - Doug > > > > > > >> At 18:31 20/07/2006, Trent Jarvi wrote: >> >>> > PROJECT SCOPE: >>> > ------------- >>> > >>> > Also, we should think carefully about what the scope of >>> > this project would be. Should it be javax."comm" which >>> > handles both serial and parallel (is parallel going by the >>> > wayside). Should it be split into two project: >>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>> > >>> > Should we differentiate between single-ended serial >>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>> > quasi-multidrop and full multidrop busses such as >>> > EIA422, EIA432 and EIA485? If we really were to >>> > add I2C support to the API, we'd have to delve into >>> > the semantics more, because there could be some >>> > implicit decoding of the bus the API users would >>> > want to see. >>> > >>> >>> Hi Paul >>> >>> The way RXTX works, which is a fair representation of the people using the >>> API, is complete support for RIA232, minimal support for IEEE1284. From >>> what I understand, Sun was going along the same lines. If we combined >>> both projects, we would have half a parallel port implementation. I see >>> maybe 4 requests for features not in the parallel support a year. >>> >>> The other protocols should not be limited by a JSR which is going to be >>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>> I2C and Raw should _not_ be considered a strong basis for extending the >>> API to cover these protocols. If people want to do real implementations, >>> they should not face a 'standard' which wasnt really focused upon their >>> interests. I think we understand the parallel port issues fairly well but >>> have not implemented many features and I don't know if we would. >>> >> I agree with all of this. API requirements for I2C, SPI, etc. are very >> different from those for RS232/485/422. Our embedded Java platform has >> APIs for all of these and more and they don't share a lot apart from the >> fact that they all use Input/OutputStreams (and in the case of SPI you >> still need to cater with the fact that every time you want to read you >> must also write to the device.) >> >> If I was to design javax.comm from scratch, I think I would focus on >> serial ports exclusively (== whatever the underlying OS represents as >> serial ports). Even parallel is a bit out of place IMHO, although I >> understand it needs to stay for backwards compatibility. >> >> >> >>> So a versatile API is favorable but I do not think we have the proper >>> community to represent much more than Serial. >>> >> Yes, I think the same. >> >> Guillermo >> -- >> Guillermo Rodriguez Garcia >> >> Snijder Micro Systems phone +31-493-351020 >> G. Rodriguez Garcia fax +31-493-351530 >> Visser 25 email guille at sms.nl >> NL5751 BL Deurne >> The Netherlands http://www.snijder.com >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From gergg at cox.net Mon Jul 24 07:51:53 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 08:51:53 -0500 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607240210.45992.pascal@quies.net> References: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> <200607232134.17451.pascal@quies.net> <200607240210.45992.pascal@quies.net> Message-ID: <44C4D079.80609@cox.net> Pascal S. de Kloe wrote: > @Gregg > You can extract the necessary libraries during the installation with the > extractNativeLibraries method to the application directory so they get loaded > automatically. Is that good enough? If you start the JVM with -Djava.security.manager what permissions are required? Can you send me a policy that is applicable so that I can review what permissions are being required? Gregg Wonderly From gergg at cox.net Mon Jul 24 07:54:22 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 08:54:22 -0500 Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: <44C4D10E.50604@cox.net> Joachim Buechse wrote: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. Sorry for the late reply here. My intent was this. That there could be a low level port/device SPI that could be put in place once, and then overtime we could layer other APIs, including an updated javax.comm which would make use of this SPI. Gregg Wonderly From cmalan at lhar.co.za Mon Jul 24 08:04:01 2006 From: cmalan at lhar.co.za (Christo Malan) Date: Mon, 24 Jul 2006 16:04:01 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: <44C4D351.603@lhar.co.za> Hi I don't think RS-485 belong in rxtx, the scope of the spec is not wide enough as it only specify the electrical layer. Their is no data protocol recommended or defined. This mean that we have no idea when to sample for a bit, how long is a bit and how many bits before we can say new data is available. Christo Dr. Douglas Lyon wrote: > Hi All, > There has been a lot of discussion regarding RS485. > > Let me see if I can summarize this, please correct me if I am wrong; > I am deliberately ignoring connector and electrical issues, focusing, > instead, on protocol and software issues. Also, I have never used > RS485, and I don't know much about it. > > 1. Serial ports that claim RS232 are typically used in > the data link layer of the OSI model of networking. Basically, this means > that they work with a point-to-point protocol and are meant to connect two > devices. > > 2. Within the RS232 standard there are framing bits (start and stop bits) > and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. > Thats' it. > > 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) > you do it in software, not in the RS232 standard. > > 4. RS485 is different from RS232 in that it is in the Network Layer of > the OSI model of networking. > > 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > a factory). > RS-485 is similar to RS-422, but RS-422 allows just one driver with > multiple receivers whereas RS-485 supports multiple drivers and > receivers. > > 6. RS-485 is a serial bus with multiple nodes and thus must handle network > link layer protocols. By using high-impedance receivers, you can have > as many as 256 nodes. > > 7. The RS-485 can be implemented with RXTX in the core and a layer of software > on top to handle media access control (MAC sublayer). There are also > hardware converters. > http://www.rs485.com/pconverters.html for example. However, some of > these require software control. There is some support in the form of > the Rs485.java class, > in RXTX. > > 8. The RS-485 specification will add to the size of the JSR > > 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > This version of the Java communications API contains support for > RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > mentioned. > > 10. DO people want to add RS485 to a new JSR? > > Would it make sense for the RS-485 people to speak up now? > Please let me know if you think my summary is wrong. > > Thanks! > - Doug > > > > > > >> At 18:31 20/07/2006, Trent Jarvi wrote: >> >>> > PROJECT SCOPE: >>> > ------------- >>> > >>> > Also, we should think carefully about what the scope of >>> > this project would be. Should it be javax."comm" which >>> > handles both serial and parallel (is parallel going by the >>> > wayside). Should it be split into two project: >>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>> > >>> > Should we differentiate between single-ended serial >>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>> > quasi-multidrop and full multidrop busses such as >>> > EIA422, EIA432 and EIA485? If we really were to >>> > add I2C support to the API, we'd have to delve into >>> > the semantics more, because there could be some >>> > implicit decoding of the bus the API users would >>> > want to see. >>> > >>> >>> Hi Paul >>> >>> The way RXTX works, which is a fair representation of the people using the >>> API, is complete support for RIA232, minimal support for IEEE1284. From >>> what I understand, Sun was going along the same lines. If we combined >>> both projects, we would have half a parallel port implementation. I see >>> maybe 4 requests for features not in the parallel support a year. >>> >>> The other protocols should not be limited by a JSR which is going to be >>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>> I2C and Raw should _not_ be considered a strong basis for extending the >>> API to cover these protocols. If people want to do real implementations, >>> they should not face a 'standard' which wasnt really focused upon their >>> interests. I think we understand the parallel port issues fairly well but >>> have not implemented many features and I don't know if we would. >>> >> I agree with all of this. API requirements for I2C, SPI, etc. are very >> different from those for RS232/485/422. Our embedded Java platform has >> APIs for all of these and more and they don't share a lot apart from the >> fact that they all use Input/OutputStreams (and in the case of SPI you >> still need to cater with the fact that every time you want to read you >> must also write to the device.) >> >> If I was to design javax.comm from scratch, I think I would focus on >> serial ports exclusively (== whatever the underlying OS represents as >> serial ports). Even parallel is a bit out of place IMHO, although I >> understand it needs to stay for backwards compatibility. >> >> >> >>> So a versatile API is favorable but I do not think we have the proper >>> community to represent much more than Serial. >>> >> Yes, I think the same. >> >> Guillermo >> -- >> Guillermo Rodriguez Garcia >> >> Snijder Micro Systems phone +31-493-351020 >> G. Rodriguez Garcia fax +31-493-351530 >> Visser 25 email guille at sms.nl >> NL5751 BL Deurne >> The Netherlands http://www.snijder.com >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > From pascal at quies.net Mon Jul 24 08:19:03 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 16:19:03 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <44C4D079.80609@cox.net> References: <200607240210.45992.pascal@quies.net> <44C4D079.80609@cox.net> Message-ID: <200607241619.04053.pascal@quies.net> Op maandag 24 juli 2006 15:51, schreef Gregg Wonderly: > Pascal S. de Kloe wrote: > > @Gregg > > You can extract the necessary libraries during the installation with the > > extractNativeLibraries method to the application directory so they get > > loaded automatically. Is that good enough? > > If you start the JVM with -Djava.security.manager what permissions are > required? Can you send me a policy that is applicable so that I can review > what permissions are being required? Just look at the javadoc in CommunicationAPI.java for SecurityExceptions. ;) From gergg at cox.net Mon Jul 24 08:21:49 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 09:21:49 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4CF4F.1080706@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> Message-ID: <44C4D77D.5080200@cox.net> Manuel Francisco Naranjo wrote: > Doug: > I do not think that RS485 is a must by now. I do think we must make a > JSR to standarize a bit Serial Ports accessing. Maybe we can make a JSR > just for serial ports, and then start trying with other kind of ports > and make others JSR. Or try to expand our first JSR, but I trully do > not know if that can be made. I think that anyone aimed at the javax.comm space should be interested in creating a hardware access SPI first. This is the predominate stumbling block for java having access to various hardware devices. The more we can promote as a standard, the more we can expect consistency and availability! > About other ports besides RS485, the others I2C, SPI, etc, run at a very > low level, maybe too close to the processor for Java. SPI (not service provider interface) is a great protocol for disparet systems because the clocking is synchronous based on the fastest speed available at each end. This means that you can do SPI, today, in java by connecting serial port signal lines, or parallel port data lines to an SPI device, and bit banging the protocol. It won't be lightening fast, but it will be very much functional. What would make the most since is the ability for applications to designate various signalling line sources such as serial signaling lines and parallel port data lines as SPI data, slave select and clock signals, and plug those into an existing API. public class SPISlaveSelectLine { public SPISlaveSelectLine( int slave, SignalPort sp ) { ... } } public class SPIClockLine { public SPIClockLine( SignalPort sp ) { ... } } public class SPIDataLine { public SPIDataLine( SignalPort sp ) { ... } } I'd really like to see the embedded systems community take up this task and push these kinds of things forward. Having standard APIs would make it possible to run your software on aJile's AJ processors, the Muvium PIC environment, javacard, J2ME, etc. Imagine being able to plug a cellphone into the wall, attach a cable which has signalling lines and presto a remote terminal for monitoring and control. Data collection is a very needed capability as the next wave of technology evolution. The Java platform is not enabled with APIs to do this trivially yet. So, it doesn't look viable to many... Gregg Wonderly From guille at sms.nl Mon Jul 24 08:37:21 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 16:37:21 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: <1153751841.44c4db21de4bb@webmail.eatserver.nl> Hi Doug, Some comments below. Quoting "Dr. Douglas Lyon" : > Hi All, > There has been a lot of discussion regarding RS485. > > Let me see if I can summarize this, please correct me if I am wrong; > I am deliberately ignoring connector and electrical issues, focusing, > instead, on protocol and software issues. Also, I have never used > RS485, and I don't know much about it. > > 1. Serial ports that claim RS232 are typically used in > the data link layer of the OSI model of networking. Basically, this means > that they work with a point-to-point protocol and are meant to connect two > devices. It is actually physical + link (layers 1 and 2 of the OSI model), but yes, this is essentially right. > > 2. Within the RS232 standard there are framing bits (start and stop bits) > and error control bits (parity). The flow control is xon-xoff or DTR, CTS, > RTS. Thats' it. I'm not even sure that the RS232 standard talks about xon-xoff and such, I think it does not do much more than defining the electrical signals. Also note that RS232 was originally defined for the DTE-DCE interface (e.g. a device such as a modem connected to a computer). The current use of RS232 as a "general purpose" point to point link is a generalization of the RS232 standard. > > 3. If you want more than that from RS232 (forward error correction, ARQ, > etc.) > you do it in software, not in the RS232 standard. > > 4. RS485 is different from RS232 in that it is in the Network Layer of > the OSI model of networking. I would not put it that way. RS485 is very similar to RS232 with three main differences: - Only tx/rx, no extra signals such as DTR, RTS, CTS, etc (but then many "RS232" serial ports don't have them either) - Different electrical specs (which do not concern us here) - Multidrop and only one node talks at a given time (half duplex) But it does not define addresses (many RS485-based protocol use addresses for the nodes but that's not part of the RS485 standard), routing, etc. For software developers it still looks like a serial port (which it is!) except for the half-duplex part. More on this below. So RS485 is still about layers 1 and 2, same as RS232. I think all of this could be easier if we talk about UARTs instead of "RS232/RS485/RS422". All of these three are typically UARTs with some sort of buffer to get the electrical levels right: RS232 interface == UART + RS232 buffer/transceiver RS485 interface == UART + RS485 buffer/transceiver RS422 interface == UART + RS422 buffer/transceiver > > 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > a factory). > RS-485 is similar to RS-422, but RS-422 allows just one driver with > multiple receivers whereas RS-485 supports multiple drivers and > receivers. RS422 is exactly the same as RS485 except that it uses 4 wires instead of 2 wires so it can be full duplex again (but again this depends on the protocol you layer on top) > > 6. RS-485 is a serial bus with multiple nodes and thus must handle network > link layer protocols. By using high-impedance receivers, you can have > as many as 256 nodes. > > 7. The RS-485 can be implemented with RXTX in the core and a layer of > software > on top to handle media access control (MAC sublayer). There are also > hardware converters. > http://www.rs485.com/pconverters.html for example. However, some of > these require software control. There is some support in the form of > the Rs485.java class, > in RXTX. > > 8. The RS-485 specification will add to the size of the JSR > > 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > This version of the Java communications API contains support for > RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > mentioned. > > 10. DO people want to add RS485 to a new JSR? > > Would it make sense for the RS-485 people to speak up now? > Please let me know if you think my summary is wrong. Basically, for a software developer the only difference between RS485 and RS232 is the half-duplex nature of RS485, which means that you cannot receive and send at the same time. This has some implications depending on how RS485 is implemented in hardware, and on the (application) protocol defined on top of RS485. As I said, a RS485 interface is normally implemented using a standard UART plus a RS485 buffer/transceiver. RS485 buffers/transceivers can be in transmit mode or in receive mode. In a given RS485 bus, only one node should be in transmit mode at any given time, with the rest of the nodes 'listening' until it is their turn to transmit (and it is the application level protocol the one defines who should transmit next.) The RS485 chips used as buffers/transceivers normally have a control pin that is used to switch them into transmit or receive mode. There are typically three ways to handle this: 1. One of the control signals from the UART, such as RTS, DTR, etc. is connected to this control pin. The software must explicitly toggle this signal in order to switch the RS485 buffer/transceiver into transmit or receive mode. This puts a lot of burden on the software side and is sometimes unreliable because of complex timing issues as well as issues with buffering at the device driver level, but it is still a popular solution. 2. The UART itself knows about RS485 and can be configured to control the RS485 buffer/transceiver automatically, without any sort of software intervention. This is a very good solution since it is transparent to the software. However most UARTs don't know about RS485. 3. Standard UART + some custom hardware to control the direction pin. This is also transparent to the software. RS232/RS485 converters are an example of this approach. Implications for the software: For 3/ the software does not need to do anything special. For 2/ all you need is some sort of mechanism to tell the UART to enter RS485-mode (typically a ioctlex). For 1/ there is no simple solution. The timing issues make it difficult to implement this sort of mechanism in user space so it is often done at the device driver level. If this is the case, then all one needs is a mechanism to tell the driver to enter RS485-mode (again, a ioctlex). If this is NOT the case, then the application will need to take care. To do this more or less reliably, you would probably need a couple of things: - Some way to disable software buffering (and FIFOs if possible) - Some way to poll the UART's serial transmit register so that you can determine exactly when all data has been sent (many UARTs don't even support this) and switch to receive mode. - High resolution timers. - Real-time capabilities. Pretty strict requirements as you can see, which is why this approach never works very well except for very specific applications. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From naranjo.manuel at gmail.com Mon Jul 24 08:39:15 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Mon, 24 Jul 2006 11:39:15 -0300 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D77D.5080200@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> Message-ID: <44C4DB93.8080008@gmail.com> Gregg: Thanks for taking me out of the dark ;). Trully I did not know that SPI was an underlaying level of Serial ports, and Parallel ports. I give back what I said. I also would like to see my cell phone plug to every were, and be able to program it with java, is just that I do not know if we are going to get ourselves in a very almost unfinishable task. Regards, Manuel > Manuel Francisco Naranjo wrote: > >> Doug: >> I do not think that RS485 is a must by now. I do think we must make a >> JSR to standarize a bit Serial Ports accessing. Maybe we can make a JSR >> > > just for serial ports, and then start trying with other kind of ports > > and make others JSR. Or try to expand our first JSR, but I trully do > > not know if that can be made. > > I think that anyone aimed at the javax.comm space should be interested in > creating a hardware access SPI first. This is the predominate stumbling > block for java having access to various hardware devices. The more we can > promote as a standard, the more we can expect consistency and availability! > > >> About other ports besides RS485, the others I2C, SPI, etc, run at a very >> low level, maybe too close to the processor for Java. >> > > SPI (not service provider interface) is a great protocol for disparet systems > because the clocking is synchronous based on the fastest speed available at each > end. This means that you can do SPI, today, in java by connecting serial port > signal lines, or parallel port data lines to an SPI device, and bit banging the > protocol. It won't be lightening fast, but it will be very much functional. > What would make the most since is the ability for applications to designate > various signalling line sources such as serial signaling lines and parallel port > data lines as SPI data, slave select and clock signals, and plug those into an > existing API. > > public class SPISlaveSelectLine { > public SPISlaveSelectLine( int slave, SignalPort sp ) { > ... > } > } > > public class SPIClockLine { > public SPIClockLine( SignalPort sp ) { > ... > } > } > > public class SPIDataLine { > public SPIDataLine( SignalPort sp ) { > ... > } > } > > I'd really like to see the embedded systems community take up this task and push > these kinds of things forward. Having standard APIs would make it possible to > run your software on aJile's AJ processors, the Muvium PIC environment, > javacard, J2ME, etc. Imagine being able to plug a cellphone into the wall, > attach a cable which has signalling lines and presto a remote terminal for > monitoring and control. > > Data collection is a very needed capability as the next wave of technology > evolution. The Java platform is not enabled with APIs to do this trivially yet. > So, it doesn't look viable to many... > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From guille at sms.nl Mon Jul 24 08:41:21 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 16:41:21 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D351.603@lhar.co.za> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: <1153752081.44c4dc11eedf3@webmail.eatserver.nl> Quoting Christo Malan : > Hi > > I don't think RS-485 belong in rxtx, the scope of the spec is not wide > enough as it only specify the electrical layer. Their is no data > protocol recommended or defined. RS485 is exactly at the same level as RS232, no more and no less. > This mean that we have no idea when to > sample for a bit, how long is a bit and how many bits before we can say > new data is available. A "RS485 serial port" is just a UART whose output complies with the RS485 electrical spec, just as a "RS232 serial port" is just a UART whose output complies with the RS232 electrical spec. Bit times, sampling intervals, character structure etc. are the same for both protocols... Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From tjarvi at qbang.org Mon Jul 24 08:44:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 24 Jul 2006 08:44:53 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D351.603@lhar.co.za> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: A JSR/JCP would not just involve RXTX. In fact it would be very nice to have others with expertise in various areas like I2C, IrDA, RS485, RS422, ... involved. Within the RXTX community, I do not think we have enough depth to tackle RS485 alone. I'm aware of some of the low level issues but to be honest, I've never actually used it. The RS485 classes in RXTX are more like notes to myself about the issues involved without hardware solutions. In operating systems like Linux, this may be much less of an issue in the future. Linux is putting realtime patches now in the kernels which could make RS485 over EIA232 possible. This is probably the last chance RS485 has to get into a published spec for a long time though. Right now, I do not think its reasonable to include it in the process. Others could make that less of a problem. On Mon, 24 Jul 2006, Christo Malan wrote: > Hi > > I don't think RS-485 belong in rxtx, the scope of the spec is not wide > enough as it only specify the electrical layer. Their is no data > protocol recommended or defined. This mean that we have no idea when to > sample for a bit, how long is a bit and how many bits before we can say > new data is available. > > Christo > > Dr. Douglas Lyon wrote: >> Hi All, >> There has been a lot of discussion regarding RS485. >> >> Let me see if I can summarize this, please correct me if I am wrong; >> I am deliberately ignoring connector and electrical issues, focusing, >> instead, on protocol and software issues. Also, I have never used >> RS485, and I don't know much about it. >> >> 1. Serial ports that claim RS232 are typically used in >> the data link layer of the OSI model of networking. Basically, this means >> that they work with a point-to-point protocol and are meant to connect two >> devices. >> >> 2. Within the RS232 standard there are framing bits (start and stop bits) >> and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. >> Thats' it. >> >> 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) >> you do it in software, not in the RS232 standard. >> >> 4. RS485 is different from RS232 in that it is in the Network Layer of >> the OSI model of networking. >> >> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in >> a factory). >> RS-485 is similar to RS-422, but RS-422 allows just one driver with >> multiple receivers whereas RS-485 supports multiple drivers and >> receivers. >> >> 6. RS-485 is a serial bus with multiple nodes and thus must handle network >> link layer protocols. By using high-impedance receivers, you can have >> as many as 256 nodes. >> >> 7. The RS-485 can be implemented with RXTX in the core and a layer of software >> on top to handle media access control (MAC sublayer). There are also >> hardware converters. >> http://www.rs485.com/pconverters.html for example. However, some of >> these require software control. There is some support in the form of >> the Rs485.java class, >> in RXTX. >> >> 8. The RS-485 specification will add to the size of the JSR >> >> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: >> This version of the Java communications API contains support for >> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not >> mentioned. >> >> 10. DO people want to add RS485 to a new JSR? >> >> Would it make sense for the RS-485 people to speak up now? >> Please let me know if you think my summary is wrong. >> >> Thanks! >> - Doug >> >> >> >> >> >> >>> At 18:31 20/07/2006, Trent Jarvi wrote: >>> >>>> > PROJECT SCOPE: >>>> > ------------- >>>> > >>>> > Also, we should think carefully about what the scope of >>>> > this project would be. Should it be javax."comm" which >>>> > handles both serial and parallel (is parallel going by the >>>> > wayside). Should it be split into two project: >>>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>>> > >>>> > Should we differentiate between single-ended serial >>>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>>> > quasi-multidrop and full multidrop busses such as >>>> > EIA422, EIA432 and EIA485? If we really were to >>>> > add I2C support to the API, we'd have to delve into >>>> > the semantics more, because there could be some >>>> > implicit decoding of the bus the API users would >>>> > want to see. >>>> > >>>> >>>> Hi Paul >>>> >>>> The way RXTX works, which is a fair representation of the people using the >>>> API, is complete support for RIA232, minimal support for IEEE1284. From >>>> what I understand, Sun was going along the same lines. If we combined >>>> both projects, we would have half a parallel port implementation. I see >>>> maybe 4 requests for features not in the parallel support a year. >>>> >>>> The other protocols should not be limited by a JSR which is going to be >>>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>>> I2C and Raw should _not_ be considered a strong basis for extending the >>>> API to cover these protocols. If people want to do real implementations, >>>> they should not face a 'standard' which wasnt really focused upon their >>>> interests. I think we understand the parallel port issues fairly well but >>>> have not implemented many features and I don't know if we would. >>>> >>> I agree with all of this. API requirements for I2C, SPI, etc. are very >>> different from those for RS232/485/422. Our embedded Java platform has >>> APIs for all of these and more and they don't share a lot apart from the >>> fact that they all use Input/OutputStreams (and in the case of SPI you >>> still need to cater with the fact that every time you want to read you >>> must also write to the device.) >>> >>> If I was to design javax.comm from scratch, I think I would focus on >>> serial ports exclusively (== whatever the underlying OS represents as >>> serial ports). Even parallel is a bit out of place IMHO, although I >>> understand it needs to stay for backwards compatibility. >>> >>> >>> >>>> So a versatile API is favorable but I do not think we have the proper >>>> community to represent much more than Serial. >>>> >>> Yes, I think the same. >>> >>> Guillermo >>> -- >>> Guillermo Rodriguez Garcia >>> >>> Snijder Micro Systems phone +31-493-351020 >>> G. Rodriguez Garcia fax +31-493-351530 >>> Visser 25 email guille at sms.nl >>> NL5751 BL Deurne >>> The Netherlands http://www.snijder.com >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From guille at sms.nl Mon Jul 24 08:47:47 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 16:47:47 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D77D.5080200@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> Message-ID: <1153752467.44c4dd93c08f7@webmail.eatserver.nl> Hi Gregg, Quoting Gregg Wonderly : > SPI (not service provider interface) is a great protocol for disparet systems > > because the clocking is synchronous based on the fastest speed available at > each > end. This means that you can do SPI, today, in java by connecting serial > port > signal lines, or parallel port data lines to an SPI device, and bit banging > the > protocol. It won't be lightening fast, but it will be very much functional. [...] > I'd really like to see the embedded systems community take up this task and > push > these kinds of things forward. Having standard APIs would make it possible > to > run your software on aJile's AJ processors, the Muvium PIC environment, > javacard, J2ME, etc. Imagine being able to plug a cellphone into the wall, > attach a cable which has signalling lines and presto a remote terminal for > monitoring and control. As an embedded Java vendor, SNIJDER Micro Systems certainly sees the value of standardized APIs to talk to different types of communication buses including SPI, I2C, 1-Wire, etc., for embedded applications. However we think this has nothing to do with javax.comm. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From guille at sms.nl Mon Jul 24 09:05:22 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 17:05:22 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4DB93.8080008@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <44C4DB93.8080008@gmail.com> Message-ID: <1153753522.44c4e1b24f2e1@webmail.eatserver.nl> Quoting Manuel Francisco Naranjo : > Gregg: > Thanks for taking me out of the dark ;). Trully I did not know that SPI > was an underlaying level of Serial ports, and Parallel ports. In fact it isn't; it is just another serial protocol, just like I2C. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From jredman at ergotech.com Mon Jul 24 09:29:10 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 09:29:10 -0600 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: <44C4E746.8070808@ergotech.com> Folks, The RS232/485/422/etc. etc. is a complete red herring (http://en.wikipedia.org/wiki/Red_herring in case you don't know the expression). The differences between the two are at the electrical level, not at the RXTX level. I'll provide a concrete example and see if we can get away from this issue. There's an industrial serial communications standard - Modbus. Modbus capable devices are very common and can be purchased, generally, with an RS232 or a 485 or a 422 - you decide when you buy it. Some actually provide both 232 and 485 on the same connector. Now, within our environment you configure a Modbus JavaBean. One of the parameters is the "Station Number". The station number is required for both RS232 and RS485 devices - the protocol doesn't change based on the electrical requirements of the device. Now I can configure an application talking to, say, station 2 and station 7. I can add an RS485 converter to the computer serial port and put two physical devices there, configured as station 2 and station 7 and everything works fine. HOWEVER, over RS232 some devices will respond to both station 2 and station 7. So THE SAME APPLICATION will work with both 232 and 485. The only changes are hardware related. This same behavior is true of a number of 485 "networks" and many industrial devices that have 485 interfaces have 232 as an option using the same protocol. Jim Trent Jarvi wrote: > A JSR/JCP would not just involve RXTX. In fact it would be very nice to > have others with expertise in various areas like I2C, IrDA, RS485, RS422, > ... involved. > > Within the RXTX community, I do not think we have enough depth to tackle > RS485 alone. I'm aware of some of the low level issues but to be honest, > I've never actually used it. The RS485 classes in RXTX are more like > notes to myself about the issues involved without hardware solutions. In > operating systems like Linux, this may be much less of an issue in the > future. Linux is putting realtime patches now in the kernels which could > make RS485 over EIA232 possible. > > This is probably the last chance RS485 has to get into a published spec > for a long time though. Right now, I do not think its reasonable to > include it in the process. Others could make that less of a problem. > > On Mon, 24 Jul 2006, Christo Malan wrote: > >> Hi >> >> I don't think RS-485 belong in rxtx, the scope of the spec is not wide >> enough as it only specify the electrical layer. Their is no data >> protocol recommended or defined. This mean that we have no idea when to >> sample for a bit, how long is a bit and how many bits before we can say >> new data is available. >> >> Christo >> >> Dr. Douglas Lyon wrote: >>> Hi All, >>> There has been a lot of discussion regarding RS485. >>> >>> Let me see if I can summarize this, please correct me if I am wrong; >>> I am deliberately ignoring connector and electrical issues, focusing, >>> instead, on protocol and software issues. Also, I have never used >>> RS485, and I don't know much about it. >>> >>> 1. Serial ports that claim RS232 are typically used in >>> the data link layer of the OSI model of networking. Basically, this means >>> that they work with a point-to-point protocol and are meant to connect two >>> devices. >>> >>> 2. Within the RS232 standard there are framing bits (start and stop bits) >>> and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. >>> Thats' it. >>> >>> 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) >>> you do it in software, not in the RS232 standard. >>> >>> 4. RS485 is different from RS232 in that it is in the Network Layer of >>> the OSI model of networking. >>> >>> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in >>> a factory). >>> RS-485 is similar to RS-422, but RS-422 allows just one driver with >>> multiple receivers whereas RS-485 supports multiple drivers and >>> receivers. >>> >>> 6. RS-485 is a serial bus with multiple nodes and thus must handle network >>> link layer protocols. By using high-impedance receivers, you can have >>> as many as 256 nodes. >>> >>> 7. The RS-485 can be implemented with RXTX in the core and a layer of software >>> on top to handle media access control (MAC sublayer). There are also >>> hardware converters. >>> http://www.rs485.com/pconverters.html for example. However, some of >>> these require software control. There is some support in the form of >>> the Rs485.java class, >>> in RXTX. >>> >>> 8. The RS-485 specification will add to the size of the JSR >>> >>> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: >>> This version of the Java communications API contains support for >>> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not >>> mentioned. >>> >>> 10. DO people want to add RS485 to a new JSR? >>> >>> Would it make sense for the RS-485 people to speak up now? >>> Please let me know if you think my summary is wrong. >>> >>> Thanks! >>> - Doug >>> >>> >>> >>> >>> >>> >>>> At 18:31 20/07/2006, Trent Jarvi wrote: >>>> >>>>>> PROJECT SCOPE: >>>>>> ------------- >>>>>> >>>>>> Also, we should think carefully about what the scope of >>>>>> this project would be. Should it be javax."comm" which >>>>>> handles both serial and parallel (is parallel going by the >>>>>> wayside). Should it be split into two project: >>>>>> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>>>>> >>>>>> Should we differentiate between single-ended serial >>>>>> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>>>>> quasi-multidrop and full multidrop busses such as >>>>>> EIA422, EIA432 and EIA485? If we really were to >>>>>> add I2C support to the API, we'd have to delve into >>>>>> the semantics more, because there could be some >>>>>> implicit decoding of the bus the API users would >>>>>> want to see. >>>>>> >>>>> Hi Paul >>>>> >>>>> The way RXTX works, which is a fair representation of the people using the >>>>> API, is complete support for RIA232, minimal support for IEEE1284. From >>>>> what I understand, Sun was going along the same lines. If we combined >>>>> both projects, we would have half a parallel port implementation. I see >>>>> maybe 4 requests for features not in the parallel support a year. >>>>> >>>>> The other protocols should not be limited by a JSR which is going to be >>>>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>>>> I2C and Raw should _not_ be considered a strong basis for extending the >>>>> API to cover these protocols. If people want to do real implementations, >>>>> they should not face a 'standard' which wasnt really focused upon their >>>>> interests. I think we understand the parallel port issues fairly well but >>>>> have not implemented many features and I don't know if we would. >>>>> >>>> I agree with all of this. API requirements for I2C, SPI, etc. are very >>>> different from those for RS232/485/422. Our embedded Java platform has >>>> APIs for all of these and more and they don't share a lot apart from the >>>> fact that they all use Input/OutputStreams (and in the case of SPI you >>>> still need to cater with the fact that every time you want to read you >>>> must also write to the device.) >>>> >>>> If I was to design javax.comm from scratch, I think I would focus on >>>> serial ports exclusively (== whatever the underlying OS represents as >>>> serial ports). Even parallel is a bit out of place IMHO, although I >>>> understand it needs to stay for backwards compatibility. >>>> >>>> >>>> >>>>> So a versatile API is favorable but I do not think we have the proper >>>>> community to represent much more than Serial. >>>>> >>>> Yes, I think the same. >>>> >>>> Guillermo >>>> -- >>>> Guillermo Rodriguez Garcia >>>> >>>> Snijder Micro Systems phone +31-493-351020 >>>> G. Rodriguez Garcia fax +31-493-351530 >>>> Visser 25 email guille at sms.nl >>>> NL5751 BL Deurne >>>> The Netherlands http://www.snijder.com >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From jredman at ergotech.com Mon Jul 24 09:50:21 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 09:50:21 -0600 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D77D.5080200@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> Message-ID: <44C4EC3D.6010204@ergotech.com> Jim, How about we go back to basics and define a serial port. Under Java, I can open /dev/ttyS0, COM1:, etc and read/write a serial port. So what does RXTX bring to the table? If we can define what we need from the product at a high level (functional spec.) then we can look at what's wrong underneath (design requirements). I can do this fairly easily. Functionally, I want support for SerialPort - a superset of that would be fine. SerialPort provides an abstraction that provides everything I need for accessing serial devices. At the design level, I'd like a "pluggable" architecture. That is, I'd like to able to accommodate anything that it makes sense to implement in terms of the SerialPort interface. An obvious plugin is one that supports the current RXTX serial port access - through device files. But _I'd_ like a plugin for serial ports over Ethernet, serial ports over BlueTooth (including discovery), etc. I'm sure others could think of modules they'd like i2c, SPI, etc. etc. I'm not sure that ANY of these should be part of the spec. although perhaps the device file based version could be part of a reference implementation. I don't know that this is really much different from the existing architecture. I doubt that much code could be shared between, for example, a BlueTooth serial port and a /dev/ttyS0 serial port, but perhaps those more familiar with the code could comment. I suspect some cleanup of registration, etc. would be needed to formalize plugins, but I doubt it's too great. Some time ago I learnt the definition of a "Goal". It should be concrete, winnable and build unity. So, I have laid out a concrete goal, build to a superset of the SerialPort interface, it's winnable because it's not a complete rewrite of RXTX and it builds unity because anyone's pet electrical specification can be added. A simplistic view, tell me where I went wrong. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From lyon at docjava.com Mon Jul 24 10:06:40 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 24 Jul 2006 12:06:40 -0400 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4E746.8070808@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> Message-ID: >Hi All, Wow, what an informed and interesting debate from my most innocent and well-intentioned of e-mails. I must say that I am learning a great deal from this list! When I speak about RS232 I wanted to focus on the protocol, not the connector shape or pin-out or electrical issues. Issues like that are addressed by the rs232c standard. The RS232 is a really loaded term! The C revision of the standard was issued in 1969 in part to accommodate electrical characteristics. Revision D was issued in 1986. The current revision is TIA-232-F Interface Between Data Terminal Equipment and Data Circuit-Terminating Equipment Employing Serial Binary Data Interchange, issued in 1997. None of this is of any particular relevance to the basic underlying question: Should the next JSR attempt to address the multi-drop abilities of RS-485? Thanks! - Doug >Folks, > >The RS232/485/422/etc. etc. is a complete red herring >(http://en.wikipedia.org/wiki/Red_herring in case you don't know the >expression). The differences between the two are at the electrical >level, not at the RXTX level. I'll provide a concrete example and see >if we can get away from this issue. > >There's an industrial serial communications standard - Modbus. Modbus >capable devices are very common and can be purchased, generally, with an >RS232 or a 485 or a 422 - you decide when you buy it. Some actually >provide both 232 and 485 on the same connector. Now, within our >environment you configure a Modbus JavaBean. One of the parameters is >the "Station Number". The station number is required for both RS232 and >RS485 devices - the protocol doesn't change based on the electrical >requirements of the device. Now I can configure an application talking >to, say, station 2 and station 7. I can add an RS485 converter to the >computer serial port and put two physical devices there, configured as >station 2 and station 7 and everything works fine. HOWEVER, over RS232 >some devices will respond to both station 2 and station 7. So THE SAME >APPLICATION will work with both 232 and 485. The only changes are >hardware related. This same behavior is true of a number of 485 >"networks" and many industrial devices that have 485 interfaces have 232 >as an option using the same protocol. > >Jim > > >Trent Jarvi wrote: >> A JSR/JCP would not just involve RXTX. In fact it would be very nice to >> have others with expertise in various areas like I2C, IrDA, RS485, RS422, >> ... involved. >> >> Within the RXTX community, I do not think we have enough depth to tackle >> RS485 alone. I'm aware of some of the low level issues but to be honest, >> I've never actually used it. The RS485 classes in RXTX are more like >> notes to myself about the issues involved without hardware solutions. In >> operating systems like Linux, this may be much less of an issue in the >> future. Linux is putting realtime patches now in the kernels which could >> make RS485 over EIA232 possible. >> >> This is probably the last chance RS485 has to get into a published spec >> for a long time though. Right now, I do not think its reasonable to >> include it in the process. Others could make that less of a problem. >> >> On Mon, 24 Jul 2006, Christo Malan wrote: >> >>> Hi >>> >>> I don't think RS-485 belong in rxtx, the scope of the spec is not wide >>> enough as it only specify the electrical layer. Their is no data >>> protocol recommended or defined. This mean that we have no idea when to >>> sample for a bit, how long is a bit and how many bits before we can say >>> new data is available. >>> >>> Christo >>> >>> Dr. Douglas Lyon wrote: >>>> Hi All, >>>> There has been a lot of discussion regarding RS485. >>>> >>>> Let me see if I can summarize this, please correct me if I am wrong; >>>> I am deliberately ignoring connector and electrical issues, focusing, >>>> instead, on protocol and software issues. Also, I have never used >>>> RS485, and I don't know much about it. > >>> >>>> 1. Serial ports that claim RS232 are typically used in >>>> the data link layer of the OSI model of networking. Basically, this means >>>> that they work with a point-to-point protocol and are meant to connect two > >>> devices. >>>> >>>> 2. Within the RS232 standard there are framing bits (start and stop bits) >>>> and error control bits (parity). The flow control is xon-xoff or >>>>DTR, CTS, RTS. >>>> Thats' it. >>>> >>>> 3. If you want more than that from RS232 (forward error >>>>correction, ARQ, etc.) >>>> you do it in software, not in the RS232 standard. >>>> >>>> 4. RS485 is different from RS232 in that it is in the Network Layer of >>>> the OSI model of networking. >>>> >>>> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in >>>> a factory). >>>> RS-485 is similar to RS-422, but RS-422 allows just one driver with >>>> multiple receivers whereas RS-485 supports multiple drivers and >>>> receivers. >>>> >>>> 6. RS-485 is a serial bus with multiple nodes and thus must handle network >>>> link layer protocols. By using high-impedance receivers, you can have >>>> as many as 256 nodes. >>>> >>>> 7. The RS-485 can be implemented with RXTX in the core and a >>>>layer of software >>>> on top to handle media access control (MAC sublayer). There are also >>>> hardware converters. >>>> http://www.rs485.com/pconverters.html for example. However, some of >>>> these require software control. There is some support in the form of >>>> the Rs485.java class, >>>> in RXTX. >>>> >>>> 8. The RS-485 specification will add to the size of the JSR >>>> >>>> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: >>>> This version of the Java communications API contains support for >>>> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not >>>> mentioned. >>>> >>>> 10. DO people want to add RS485 to a new JSR? >>>> >>>> Would it make sense for the RS-485 people to speak up now? >>>> Please let me know if you think my summary is wrong. >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>> >>>> >>>> >>>> >>>>> At 18:31 20/07/2006, Trent Jarvi wrote: >>>>> >>>>>>> PROJECT SCOPE: >>>>>>> ------------- >>>>>>> >>>>>>> Also, we should think carefully about what the scope of >>>>>>> this project would be. Should it be javax."comm" which >>>>>>> handles both serial and parallel (is parallel going by the >>>>>>> wayside). Should it be split into two project: >>>>>>> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>>>>>> >>>>>>> Should we differentiate between single-ended serial >>>>>>> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>>>>>> quasi-multidrop and full multidrop busses such as >>>>>>> EIA422, EIA432 and EIA485? If we really were to >>>>>>> add I2C support to the API, we'd have to delve into >>>>>>> the semantics more, because there could be some >>>>>>> implicit decoding of the bus the API users would >>>>>>> want to see. >>>>>>> >>>>>> Hi Paul >>>>>> >>>>>> The way RXTX works, which is a fair representation of the >>>>>>people using the >>>>>> API, is complete support for RIA232, minimal support for IEEE1284. From >>>>>> what I understand, Sun was going along the same lines. If we combined >>>>>> both projects, we would have half a parallel port implementation. I see >>>>>> maybe 4 requests for features not in the parallel support a year. >>>>>> >>>>>> The other protocols should not be limited by a JSR which is going to be >>>>>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>>>>> I2C and Raw should _not_ be considered a strong basis for extending the >>>>>> API to cover these protocols. If people want to do real >>>>>>implementations, >>>>>> they should not face a 'standard' which wasnt really focused upon their >>>>>> interests. I think we understand the parallel port issues >>>>>>fairly well but >>>>>> have not implemented many features and I don't know if we would. >>>>>> >>>>> I agree with all of this. API requirements for I2C, SPI, etc. are very >>>>> different from those for RS232/485/422. Our embedded Java platform has >>>>> APIs for all of these and more and they don't share a lot apart from the >>>>> fact that they all use Input/OutputStreams (and in the case of SPI you > >>>> still need to cater with the fact that every time you want to read you >>>>> must also write to the device.) >>>>> >>>>> If I was to design javax.comm from scratch, I think I would focus on >>>>> serial ports exclusively (== whatever the underlying OS represents as > >>>> serial ports). Even parallel is a bit out of place IMHO, although I >>>>> understand it needs to stay for backwards compatibility. >>>>> >>>>> >>>>> >>>>>> So a versatile API is favorable but I do not think we have the proper >>>>>> community to represent much more than Serial. >>>>>> >>>>> Yes, I think the same. >>>>> >>>>> Guillermo >>>>> -- >>>>> Guillermo Rodriguez Garcia >>>>> >>>>> Snijder Micro Systems phone +31-493-351020 >>>>> G. Rodriguez Garcia fax +31-493-351530 >>>>> Visser 25 email guille at sms.nl >>>>> NL5751 BL Deurne >>>>> The Netherlands http://www.snijder.com >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >-- >Jim Redman >(505) 662 5156 x85 >http://www.ergotech.com >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Mon Jul 24 10:16:44 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 18:16:44 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> Message-ID: <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> Hi Doug, Quoting "Dr. Douglas Lyon" : > >Hi All, > > > Wow, what an informed and interesting debate from my most > innocent and well-intentioned of e-mails. > > I must say that I am learning a great deal from this list! > > When I speak about > RS232 I wanted to focus on the protocol, not the connector shape or > pin-out or electrical issues. Issues like that are addressed by the > rs232c standard. > The RS232 is a really loaded term! Right. Maybe we should be talking about "serial ports" instead. At the functional level it does not make any difference whether it is RS232, RS485, or RS422... except maybe for the direction control in the case of RS485 ports. [...] > > None of this is of any particular relevance to the basic underlying > question: > > Should the next JSR attempt to address the multi-drop abilities of RS-485? What I would suggest is to just add a new 'ioctlex'-like method to the SerialPort API: A method that you'd use to pass platform- or implementation-specific info to the underlying driver or OS to do things such as "enabling RS485 mode" or "disable FIFOs" or "poll the TSR register". No need to define any function codes. This is for stuff that is platform- or implementation-specific and as such cannot be easily abstracted anyway. The goal is to accomodate hat those systems that have serial ports with special, non-standard capabilities without forcing developers to leave javax.comm. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From Paul.Klissner at Sun.COM Mon Jul 24 10:45:33 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Mon, 24 Jul 2006 09:45:33 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> Message-ID: <44C4F92D.6090807@sun.com> >> None of this is of any particular relevance to the basic underlying >> question: >> >> Should the next JSR attempt to address the multi-drop abilities of RS-485? > > What I would suggest is to just add a new 'ioctlex'-like method > to the SerialPort API: A method that you'd use to pass platform- > or implementation-specific info to the underlying driver or OS > to do things such as "enabling RS485 mode" or "disable FIFOs" or > "poll the TSR register". > > No need to define any function codes. This is for stuff that is > platform- or implementation-specific and as such cannot be easily > abstracted anyway. Detrimental to platform independence. Paul From berkland at spamcop.net Mon Jul 24 11:07:58 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 24 Jul 2006 13:07:58 -0400 Subject: [Rxtx] jcp and jsr In-Reply-To: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> Message-ID: <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> Gregg Wonderly wrote: > That there could be a low level port/device SPI > that could be put in place once, and then overtime > we could layer other APIs, including an updated > javax.comm which would make use of this SPI. I think there is great merit in this suggestion. I would like to see the ability to register a new "port" along with a custom handler in the Java client code before attempting to access the port. e.g . CommManager.getInstance().registerPortImpl("USB1:", new HidPortAdapter(/*vendorId=*/ "1234", /*deviceId=*/ "4321"); CommManager.getInstance().registerPortImpl("Ether1:", new InetPortAdapter(/*ipAndPort=*/ "192.168.1.101:8088"); It would allow other protocols that this group doesn't have depth in to be developed by someone who does on an "as needed" basis. Additionally, the value of this would be with some devices that implement basically the same protocol that was initially used over RS232 for a USB (via an HID) or Ethernet interface. There are a number of these in POS hardware. The existing JavaPOS driver written against JavaCOMM 2.0 could be reused by plugging in an HID or IP adapter before attempting to access the device. It might also be valuable to use something like an extended version of the portmapping file found in JavaCOMM 3.0. A configuration file could allow this definition to take place outside of any Java client code. Such a mapping file wouldn't even need to be part of the JSR API or reference implementation. It could be handled in a specific implementation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060724/7f51342e/attachment-0339.html From guille at sms.nl Mon Jul 24 11:14:54 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 19:14:54 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4F92D.6090807@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> Message-ID: <1153761294.44c5000ec1360@webmail.eatserver.nl> Quoting Paul Klissner : > >> None of this is of any particular relevance to the basic underlying > >> question: > >> > >> Should the next JSR attempt to address the multi-drop abilities of > RS-485? > > > > What I would suggest is to just add a new 'ioctlex'-like method > > to the SerialPort API: A method that you'd use to pass platform- > > or implementation-specific info to the underlying driver or OS > > to do things such as "enabling RS485 mode" or "disable FIFOs" or > > "poll the TSR register". > > > > No need to define any function codes. This is for stuff that is > > platform- or implementation-specific and as such cannot be easily > > abstracted anyway. > > Detrimental to platform independence. Yes, it is. But as you go closer and closer to the hardware level some things are by nature platform-dependent, and sometimes just cannot be solved in a platform-independent way. In these cases, is it better to have no solution at all than having one that is less than perfect? Put it another way, would you prefer having people say "I just cannot do this in Java; I'll go somewhere else" rather than "I can do this in Java -- only not in a platform-independent way" ? Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From gergg at cox.net Mon Jul 24 11:34:00 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 12:34:00 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153752467.44c4dd93c08f7@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> Message-ID: <44C50488.1040508@cox.net> Guillermo Rodriguez wrote: > As an embedded Java vendor, SNIJDER Micro Systems certainly sees the > value of standardized APIs to talk to different types of communication > buses including SPI, I2C, 1-Wire, etc., for embedded applications. > However we think this has nothing to do with javax.comm. I don't think this is only about javax.comm. Certainly that's important. I'm just wading into this conversation mainstream and trying to say: If you are going to do anything about "fixing" javax.comm to work on all platforms, please, please, please start with a hardware port SPI definition that lets you get to serial ports, and then provide the existing javax.com API and whatever new API you think is necessary (I don't have any really issues with the existing API directly). Then, there will be a place for others interesting in SPI, i2C, USB and other things to get started with providing access to devices that are also interesting in Java applications, and directly, in embedded Java applications. Gregg Wonderly From Paul.Klissner at Sun.COM Mon Jul 24 11:41:51 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Mon, 24 Jul 2006 10:41:51 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153761294.44c5000ec1360@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> Message-ID: <44C5065F.3060802@sun.com> Guillermo Rodriguez wrote: > Quoting Paul Klissner : > >>>> None of this is of any particular relevance to the basic underlying >>>> question: >>>> >>>> Should the next JSR attempt to address the multi-drop abilities of >> RS-485? >>> What I would suggest is to just add a new 'ioctlex'-like method >>> to the SerialPort API: A method that you'd use to pass platform- >>> or implementation-specific info to the underlying driver or OS >>> to do things such as "enabling RS485 mode" or "disable FIFOs" or >>> "poll the TSR register". >>> >>> No need to define any function codes. This is for stuff that is >>> platform- or implementation-specific and as such cannot be easily >>> abstracted anyway. >> Detrimental to platform independence. > > Yes, it is. But as you go closer and closer to the hardware level some > things are by nature platform-dependent, and sometimes just cannot be > solved in a platform-independent way. In these cases, is it better to > have no solution at all than having one that is less than perfect? > > Put it another way, would you prefer having people say "I just cannot > do this in Java; I'll go somewhere else" rather than "I can do this > in Java -- only not in a platform-independent way" ? If there isn't a reasonable way to abstract it out, then why use Java? The whole idea is platform neutrality, otherwise, what is the huge advantage of adopting a standardized Java API? I think it is wrong to subvert the API. I think we have to arrive at some sort of consensus about the scope of the API and do our best to engineer a robust API in terms of that scope using abstraction. There may be outliers, but the outliers probably aren't portable, and probably would do just as well to not use java for that particular application. If this was a JSR, if we found some compelling problem that kept cropping up the API could be reved so as not to just orphan cases with legitimate requests. If someone really needs to do funky things with the hardware, why wouldn't that be put in the native back end? Couldn't some of this be addressed by the multiple SPI layer that I recommended as one of the two changes I'd like to see made to javax.comm (the other being a port mapping plugin layer)? Paul From jredman at ergotech.com Mon Jul 24 11:49:46 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 11:49:46 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> Message-ID: <44C5083A.6090902@ergotech.com> A thought for later since we haven't really reached this level of detail, but since this type of approach seems likely... If a configuration file is mandatory, can we specify what the file is called and what the format of the options are (mandatory?, and optional) without limiting extensions. This just adds consistency across platforms/implementations. Jim Doug Berkland wrote: > Gregg Wonderly wrote: > > That there could be a low level port/device SPI > > that could be put in place once, and then overtime > > we could layer other APIs, including an updated > > javax.comm which would make use of this SPI. > > I think there is great merit in this suggestion. I would like to see > the ability to register a new "port" along with a custom handler in the > Java client code before attempting to access the port. > e.g . > CommManager.getInstance().registerPortImpl("USB1:", new > HidPortAdapter(/*vendorId=*/ "1234", /*deviceId=*/ "4321"); > CommManager.getInstance().registerPortImpl("Ether1:", new > InetPortAdapter(/*ipAndPort=*/ " 192.168.1.101:8088 > "); > > It would allow other protocols that this group doesn't have depth in to > be developed by someone who does on an "as needed" basis. > > Additionally, the value of this would be with some devices that > implement basically the same protocol that was initially used over RS232 > for a USB (via an HID) or Ethernet interface. There are a number of > these in POS hardware. The existing JavaPOS driver written against > JavaCOMM 2.0 could be reused by plugging in an HID or IP adapter before > attempting to access the device. > > It might also be valuable to use something like an extended version of > the portmapping file found in JavaCOMM 3.0. A configuration file could > allow this definition to take place outside of any Java client code. > Such a mapping file wouldn't even need to be part of the JSR API or > reference implementation. It could be handled in a specific > implementation. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From mtnvega at yahoo.com.br Mon Jul 24 11:51:40 2006 From: mtnvega at yahoo.com.br (mtnvega) Date: Mon, 24 Jul 2006 14:51:40 -0300 Subject: [Rxtx] Serial Read/Write Details Message-ID: <44C508AC.7060103@yahoo.com.br> Hello, I'm have being flirting with RXTX for a while since I'm working on a college project where I will need to communicate with a microcontroller using USART. Now is the time to start using it! But I have some doubts and I hope you can help-me. I will need to both send and receive data from the serial port. First I will need to send some command bytes then wait for some data that will be returned from the microcontroller. And I would like to know which is the best way to do that. I'm mean, of course send and receive data is the purpose of the serial port and RXTX but I'm looking for some details since there will be no package control but just a fixed command format and confirmation messages from the microcontroller side. I would like to know if I should open and close the port or if I can just open it once. I read that upon writing to output the input buffer are filled with the same data, is it right? If yes, isn't it a problem since I'm waiting for data back in a very small time? Thank you, Luiz _______________________________________________________ Voc? quer respostas para suas perguntas? Ou voc? sabe muito e quer compartilhar seu conhecimento? Experimente o Yahoo! Respostas ! http://br.answers.yahoo.com/ From jredman at ergotech.com Mon Jul 24 12:45:50 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 12:45:50 -0600 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C50488.1040508@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> Message-ID: <44C5155E.7080105@ergotech.com> Gregg, Is SPI applicable to a SerialPort interface over Ethernet (or Bluetooth)? I've assumed that it's specific to directly-connected-UART-based serial ports - something similar to I2C. I'm starting to think that I'm opposed to having hardware definitions (transport layer?) in the JavaComm spec., but then what's left? Jim Gregg Wonderly wrote: > Guillermo Rodriguez wrote: >> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the >> value of standardized APIs to talk to different types of communication >> buses including SPI, I2C, 1-Wire, etc., for embedded applications. >> However we think this has nothing to do with javax.comm. > > I don't think this is only about javax.comm. Certainly that's important. I'm > just wading into this conversation mainstream and trying to say: > > If you are going to do anything about "fixing" javax.comm to work on all > platforms, please, please, please start with a hardware port SPI definition that > lets you get to serial ports, and then provide the existing javax.com API and > whatever new API you think is necessary (I don't have any really issues with the > existing API directly). > > Then, there will be a place for others interesting in SPI, i2C, USB and other > things to get started with providing access to devices that are also interesting > in Java applications, and directly, in embedded Java applications. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Mon Jul 24 13:15:19 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 14:15:19 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C5155E.7080105@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <44C5155E.7080105@ergotech.com> Message-ID: <44C51C47.90409@cox.net> Jim Redman wrote: > Is SPI applicable to a SerialPort interface over Ethernet (or > Bluetooth)? I've assumed that it's specific to > directly-connected-UART-based serial ports - something similar to I2C. SPI is a simple 2 line (clock and data) plus slave select bi-directional, full duplex data transfer mechanism. It has nothing to do, directly with serial ports, but could be implemented using serial port signalling lines. > I'm starting to think that I'm opposed to having hardware definitions > (transport layer?) in the JavaComm spec., but then what's left? Jim, there are multiple conversations going on, on the list. There is a group of people that just want a standard serial port mechanism in Java, apparently NOW! They are going back and forth about that. There is another conversation about doing a JSR to make the serial port interfaces a standard, since Sun's original implementation was never a Java standard. There is a small group saying if you're going to do a JSR for serial ports, why not provide a nice foundation for serial ports which might also support other kinds of "ports" and associated protocols. And there are a couple of other conversations about Pascal's stuff. It's this last group that I am the most interested in. I think that it is possible to create a simple Service Provider Interface for 'hardware interfacing' that covers serial ports and also includes expandability to cover other types of hardware. We want to find the level of abstraction that the most number of OSes provide in their user level APIs, and create a matching SPI at that level which will allow a JVM vendor to provide access to the types of hardware that is common on their OSes/hardware. Then, third parties might add some value by providing some good abstrations for particular types of protocols or particular vendors' hardware (ports which can be switched between RS232 and RS485 for example). Finally, we can create an implementation of the javax.comm API which uses this SPI to provide exactly the same API as today, but with an approved foundation for hardware access from java using 100% java code. Gregg Wonderly From mark at mdsh.com Mon Jul 24 16:03:38 2006 From: mark at mdsh.com (Mark Himsley) Date: Mon, 24 Jul 2006 23:03:38 +0100 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: I don't see how any Java app is going to know the difference between an RS232, RS422, or RS485 port. I regularly use RXTX controlling RS422 devices (controlling VTRs) and I can use an RS232 port with bodged wiring (for short distances) or RS232 port with a media converted - either of which may be built into the PC or may be a USB device - or an RS422 USB device. They are just 'serial port' devices. Please don't get hung up on higher layer stuff - that's for application developers to add on top of a rock-solid multi platform 'serial port' driver implementations. On 24 July 2006 08:44 -0600 Trent Jarvi wrote: > > A JSR/JCP would not just involve RXTX. In fact it would be very nice to > have others with expertise in various areas like I2C, IrDA, RS485, RS422, > ... involved. > > Within the RXTX community, I do not think we have enough depth to tackle > RS485 alone. I'm aware of some of the low level issues but to be honest, > I've never actually used it. The RS485 classes in RXTX are more like > notes to myself about the issues involved without hardware solutions. In > operating systems like Linux, this may be much less of an issue in the > future. Linux is putting realtime patches now in the kernels which could > make RS485 over EIA232 possible. > > This is probably the last chance RS485 has to get into a published spec > for a long time though. Right now, I do not think its reasonable to > include it in the process. Others could make that less of a problem. > > On Mon, 24 Jul 2006, Christo Malan wrote: > > > Hi > > > > I don't think RS-485 belong in rxtx, the scope of the spec is not wide > > enough as it only specify the electrical layer. Their is no data > > protocol recommended or defined. This mean that we have no idea when to > > sample for a bit, how long is a bit and how many bits before we can say > > new data is available. > > > > Christo > > > > Dr. Douglas Lyon wrote: > >> Hi All, > >> There has been a lot of discussion regarding RS485. > >> > >> Let me see if I can summarize this, please correct me if I am wrong; > >> I am deliberately ignoring connector and electrical issues, focusing, > >> instead, on protocol and software issues. Also, I have never used > >> RS485, and I don't know much about it. > >> > >> 1. Serial ports that claim RS232 are typically used in > >> the data link layer of the OSI model of networking. Basically, this > >> means that they work with a point-to-point protocol and are meant to > >> connect two devices. > >> > >> 2. Within the RS232 standard there are framing bits (start and stop > >> bits) and error control bits (parity). The flow control is xon-xoff or > >> DTR, CTS, RTS. Thats' it. > >> > >> 3. If you want more than that from RS232 (forward error correction, > >> ARQ, etc.) you do it in software, not in the RS232 standard. > >> > >> 4. RS485 is different from RS232 in that it is in the Network Layer of > >> the OSI model of networking. > >> > >> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > >> a factory). > >> RS-485 is similar to RS-422, but RS-422 allows just one driver with > >> multiple receivers whereas RS-485 supports multiple drivers and > >> receivers. > >> > >> 6. RS-485 is a serial bus with multiple nodes and thus must handle > >> network link layer protocols. By using high-impedance receivers, you > >> can have as many as 256 nodes. > >> > >> 7. The RS-485 can be implemented with RXTX in the core and a layer of > >> software on top to handle media access control (MAC sublayer). There > >> are also hardware converters. > >> http://www.rs485.com/pconverters.html for example. However, some of > >> these require software control. There is some support in the form of > >> the Rs485.java class, > >> in RXTX. > >> > >> 8. The RS-485 specification will add to the size of the JSR > >> > >> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > >> This version of the Java communications API contains support for > >> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > >> mentioned. > >> > >> 10. DO people want to add RS485 to a new JSR? > >> > >> Would it make sense for the RS-485 people to speak up now? > >> Please let me know if you think my summary is wrong. > >> > >> Thanks! > >> - Doug > >> > >> > >> > >> > >> > >> > >>> At 18:31 20/07/2006, Trent Jarvi wrote: > >>> > >>>> > PROJECT SCOPE: > >>>> > ------------- > >>>> > > >>>> > Also, we should think carefully about what the scope of > >>>> > this project would be. Should it be javax."comm" which > >>>> > handles both serial and parallel (is parallel going by the > >>>> > wayside). Should it be split into two project: > >>>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > >>>> > > >>>> > Should we differentiate between single-ended serial > >>>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > >>>> > quasi-multidrop and full multidrop busses such as > >>>> > EIA422, EIA432 and EIA485? If we really were to > >>>> > add I2C support to the API, we'd have to delve into > >>>> > the semantics more, because there could be some > >>>> > implicit decoding of the bus the API users would > >>>> > want to see. > >>>> > > >>>> > >>>> Hi Paul > >>>> > >>>> The way RXTX works, which is a fair representation of the people > >>>> using the API, is complete support for RIA232, minimal support for > >>>> IEEE1284. From what I understand, Sun was going along the same > >>>> lines. If we combined both projects, we would have half a parallel > >>>> port implementation. I see maybe 4 requests for features not in the > >>>> parallel support a year. > >>>> > >>>> The other protocols should not be limited by a JSR which is going to > >>>> be focused upon serial port interests. The IEA485 hacks in RXTX > >>>> along with I2C and Raw should _not_ be considered a strong basis for > >>>> extending the API to cover these protocols. If people want to do > >>>> real implementations, they should not face a 'standard' which wasnt > >>>> really focused upon their interests. I think we understand the > >>>> parallel port issues fairly well but have not implemented many > >>>> features and I don't know if we would. > >>>> > >>> I agree with all of this. API requirements for I2C, SPI, etc. are very > >>> different from those for RS232/485/422. Our embedded Java platform has > >>> APIs for all of these and more and they don't share a lot apart from > >>> the fact that they all use Input/OutputStreams (and in the case of > >>> SPI you still need to cater with the fact that every time you want to > >>> read you must also write to the device.) > >>> > >>> If I was to design javax.comm from scratch, I think I would focus on > >>> serial ports exclusively (== whatever the underlying OS represents as > >>> serial ports). Even parallel is a bit out of place IMHO, although I > >>> understand it needs to stay for backwards compatibility. > >>> > >>> > >>> > >>>> So a versatile API is favorable but I do not think we have the proper > >>>> community to represent much more than Serial. > >>>> > >>> Yes, I think the same. > >>> > >>> Guillermo > >>> -- > >>> Guillermo Rodriguez Garcia > >>> > >>> Snijder Micro Systems phone +31-493-351020 > >>> G. Rodriguez Garcia fax +31-493-351530 > >>> Visser 25 email guille at sms.nl > >>> NL5751 BL Deurne > >>> The Netherlands http://www.snijder.com > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> > >> > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Mark Himsley From berkland at spamcop.net Mon Jul 24 16:55:18 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 24 Jul 2006 18:55:18 -0400 Subject: [Rxtx] jcp and jsr In-Reply-To: <44C5083A.6090902@ergotech.com> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> <44C5083A.6090902@ergotech.com> Message-ID: <269e40090607241555g281c7f24s5577b86e35d27eab@mail.gmail.com> I'm sorry, I keep reading SPI as "Service Provider Interface" instead of "Serial Peripheral Interface". (See http://en.wikipedia.org/wiki/Serial_Peripheral_Interface.) What I thought was being suggested was a pluggable implementation like that found in javax.security. (The SPI there actually stands for "Security Provider Interface" not "Service Provider Interface" like I had thought.) I guess that might be a CPI (Comm Provider Interface) or PPI (Port Provider Interface.) At any rate what I would like to see is a JSR with (in order of priority) - compatible API for code written against current javax.comm 2.0 classes - ability to register or "force" a port by providing a name and implementation (not have to rely completely on the "auto-discovery") - nothing precluding the use of a portmapping in a given implementation - ability to register port implementations On 7/24/06, Jim Redman wrote: > > A thought for later since we haven't really reached this level of > detail, but since this type of approach seems likely... > > If a configuration file is mandatory, can we specify what the file is > called and what the format of the options are (mandatory?, and optional) > without limiting extensions. > > This just adds consistency across platforms/implementations. > > Jim > > Doug Berkland wrote: > > Gregg Wonderly wrote: > > > That there could be a low level port/device SPI > > > that could be put in place once, and then overtime > > > we could layer other APIs, including an updated > > > javax.comm which would make use of this SPI. > > > > I think there is great merit in this suggestion. I would like to see > > the ability to register a new "port" along with a custom handler in the > > Java client code before attempting to access the port. > > e.g . > > CommManager.getInstance().registerPortImpl("USB1:", new > > HidPortAdapter(/*vendorId=*/ "1234", /*deviceId=*/ "4321"); > > CommManager.getInstance().registerPortImpl("Ether1:", new > > InetPortAdapter(/*ipAndPort=*/ " 192.168.1.101:8088 > > "); > > > > It would allow other protocols that this group doesn't have depth in to > > be developed by someone who does on an "as needed" basis. > > > > Additionally, the value of this would be with some devices that > > implement basically the same protocol that was initially used over RS232 > > for a USB (via an HID) or Ethernet interface. There are a number of > > these in POS hardware. The existing JavaPOS driver written against > > JavaCOMM 2.0 could be reused by plugging in an HID or IP adapter before > > attempting to access the device. > > > > It might also be valuable to use something like an extended version of > > the portmapping file found in JavaCOMM 3.0. A configuration file could > > allow this definition to take place outside of any Java client code. > > Such a mapping file wouldn't even need to be part of the JSR API or > > reference implementation. It could be handled in a specific > > implementation. > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060724/02c50e6a/attachment-0339.html From tjarvi at qbang.org Mon Jul 24 18:44:54 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 24 Jul 2006 18:44:54 -0600 (MDT) Subject: [Rxtx] Serial Read/Write Details In-Reply-To: <44C508AC.7060103@yahoo.com.br> References: <44C508AC.7060103@yahoo.com.br> Message-ID: On Mon, 24 Jul 2006, mtnvega wrote: > Hello, > > I'm have being flirting with RXTX for a while since I'm working on a > college project where I will > need to communicate with a microcontroller using USART. > > Now is the time to start using it! But I have some doubts and I hope you > can help-me. > > I will need to both send and receive data from the serial port. First I > will need to send some command > bytes then wait for some data that will be returned from the > microcontroller. And I would like > to know which is the best way to do that. I'm mean, of course send and > receive data is the purpose > of the serial port and RXTX but I'm looking for some details since there > will be no package control > but just a fixed command format and confirmation messages from the > microcontroller side. > > I would like to know if I should open and close the port or if I can > just open it once. > I read that upon writing to output the input buffer are filled with the > same data, is it right? > If yes, isn't it a problem since I'm waiting for data back in a very > small time? > Hi Luiz Unless you want to use the port with a second application, just open the port once and close it when you exit the application. The input will not be filled with the data you write. The API has events to let you know when data is available and when your data has gone out the port. You can look in the contrib directory that comes with the source for crude examples of event notification. I think there is an example on the wiki too. I don't think you will have any problems. -- Trent Jarvi tjarvi at qbang.org From guille at sms.nl Tue Jul 25 00:26:12 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 08:26:12 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C50488.1040508@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> Message-ID: <7.0.1.0.0.20060725082124.036309e0@sms.nl> At 19:34 24/07/2006, Gregg Wonderly wrote: >Guillermo Rodriguez wrote: > > As an embedded Java vendor, SNIJDER Micro Systems certainly sees the > > value of standardized APIs to talk to different types of communication > > buses including SPI, I2C, 1-Wire, etc., for embedded applications. > > However we think this has nothing to do with javax.comm. > >I don't think this is only about javax.comm. Certainly that's >important. I'm >just wading into this conversation mainstream and trying to say: > >If you are going to do anything about "fixing" javax.comm to work on all >platforms, please, please, please start with a hardware port SPI >definition that >lets you get to serial ports, and then provide the existing javax.com API and >whatever new API you think is necessary (I don't have any really >issues with the >existing API directly). > >Then, there will be a place for others interesting in SPI, i2C, USB and other >things to get started with providing access to devices that are also >interesting >in Java applications, and directly, in embedded Java applications. I do agree that the best a hardware port SPI definition (where SPI = Service Provider Interface, not the SPI protocol) is a good thing to have to support serial ports layered over other transports. However these are still serial ports at the end. I still don't think the javax.comm API is well suited to "any" serial bus such as I2C, SPI, etc. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 00:41:46 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 08:41:46 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C5065F.3060802@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> Message-ID: <7.0.1.0.0.20060725082630.036d2d10@sms.nl> At 19:41 24/07/2006, Paul Klissner wrote: >Guillermo Rodriguez wrote: >>Quoting Paul Klissner : >> >>>>>None of this is of any particular relevance to the basic underlying >>>>>question: >>>>> >>>>>Should the next JSR attempt to address the multi-drop abilities of >>>RS-485? >>>>What I would suggest is to just add a new 'ioctlex'-like method >>>>to the SerialPort API: A method that you'd use to pass platform- >>>>or implementation-specific info to the underlying driver or OS >>>>to do things such as "enabling RS485 mode" or "disable FIFOs" or >>>>"poll the TSR register". >>>> >>>>No need to define any function codes. This is for stuff that is >>>>platform- or implementation-specific and as such cannot be easily >>>>abstracted anyway. >>>Detrimental to platform independence. >>Yes, it is. But as you go closer and closer to the hardware level some >>things are by nature platform-dependent, and sometimes just cannot be >>solved in a platform-independent way. In these cases, is it better to >>have no solution at all than having one that is less than perfect? >>Put it another way, would you prefer having people say "I just cannot >>do this in Java; I'll go somewhere else" rather than "I can do this >>in Java -- only not in a platform-independent way" ? > >If there isn't a reasonable way to abstract it out, then >why use Java? If an application can be 99% platform independent with small bits being not portable, why *not* use Java? I'd prefer to see people using Java to write non-portable applications than having them use C instead. I believe that Java should promote platform neutrality, but that does not necessarily mean precluding the use of anything that is NOT platform independent. And let's face it, if you are using javax.comm to talk to some serial device directly, then chances are you are already tied to some specific hardware anyway. Also, some people (myself included) think that Java can also be used as a systems programming language, not only for applications. For many embedded platforms this is certainly the case. In our platform we even write device drivers directly in Java. I would imagine the Sun SPOT team (www.sunspotworld.com) supports a similar view. If people needs to do non-portable stuff and wants to do it in Java I'd rather have them do it in Java than tell them to do it in C instead. >The whole idea is platform neutrality, otherwise, what is the >huge advantage of adopting a standardized Java API? I think >it is wrong to subvert the API. I think we have to arrive at >some sort of consensus about the scope of the API and do our >best to engineer a robust API in terms of that scope using >abstraction. > >There may be outliers, but the outliers probably aren't portable, >and probably would do just as well to not use java for that >particular application. The cases I have in mind is more like portable applications with very small bits of non portable code. I can imagine lots of portable applications that need access to RS485, specially in the industrial process control and factory automation fields. As I said in an earlier mail RS485 is half- duplex, but there is standard way to do RS485 direction control from software. Does it mean that the whole application should not be written in Java, only because some small bits of code related to RS485 direction control are not completely portable? > If this was a JSR, if we found some >compelling problem that kept cropping up the API could be >reved so as not to just orphan cases with legitimate requests. > >If someone really needs to do funky things with the hardware, >why wouldn't that be put in the native back end? But nobody said the functionality can't be implemented in the native back end. However you still need an application level API to enable/disable it. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 00:44:43 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 08:44:43 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <269e40090607241555g281c7f24s5577b86e35d27eab@mail.gmail.co m> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> <44C5083A.6090902@ergotech.com> <269e40090607241555g281c7f24s5577b86e35d27eab@mail.gmail.com> Message-ID: <7.0.1.0.0.20060725084431.036d0700@sms.nl> At 00:55 25/07/2006, Doug Berkland wrote: >I'm sorry, I keep reading SPI as "Service Provider Interface" >instead of "Serial Peripheral Interface". (See >http://en.wikipedia.org/wiki/Serial_Peripheral_Interface. >) > >What I thought was being suggested was a pluggable implementation >like that found in javax.security. (The SPI there actually stands >for "Security Provider Interface" not "Service Provider Interface" >like I had thought.) I guess that might be a CPI (Comm Provider >Interface) or PPI (Port Provider Interface.) > >At any rate what I would like to see is a JSR with (in order of priority) >- compatible API for code written against current javax.comm 2.0 classes >- ability to register or "force" a port by providing a name and >implementation (not have to rely completely on the "auto-discovery") >- nothing precluding the use of a portmapping in a given implementation >- ability to register port implementations That sounds very good to me. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From tjarvi at qbang.org Tue Jul 25 01:21:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 01:21:53 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725082124.036309e0@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> Message-ID: On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: > At 19:34 24/07/2006, Gregg Wonderly wrote: >> Guillermo Rodriguez wrote: >>> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the >>> value of standardized APIs to talk to different types of communication >>> buses including SPI, I2C, 1-Wire, etc., for embedded applications. >>> However we think this has nothing to do with javax.comm. >> >> I don't think this is only about javax.comm. Certainly that's >> important. I'm >> just wading into this conversation mainstream and trying to say: >> >> If you are going to do anything about "fixing" javax.comm to work on all >> platforms, please, please, please start with a hardware port SPI >> definition that >> lets you get to serial ports, and then provide the existing javax.com API and >> whatever new API you think is necessary (I don't have any really >> issues with the >> existing API directly). >> >> Then, there will be a place for others interesting in SPI, i2C, USB and other >> things to get started with providing access to devices that are also >> interesting >> in Java applications, and directly, in embedded Java applications. > > I do agree that the best a hardware port SPI definition (where SPI = Service > Provider Interface, not the SPI protocol) is a good thing to have to support > serial ports layered over other transports. However these are still serial > ports at the end. I still don't think the javax.comm API is well suited to > "any" serial bus such as I2C, SPI, etc. > Perhaps the javax.com namespace is just wrong. I think thats a larger issue we are not well prepared to answer. We do have a larger group participating so there is interest beyond our current solution. My concern is getting into blue sky efforts that never materialize. We have a very concrete solution that just needs a few modifications to make current java users happy. This solution is more or less supporting POSIX termios on all platforms including windows. This solution does not ask deep questions like is it USB or RS485 or IrDA. Smart kernel people worry about that. Thats what works. When the fun goes away and I'm fixing spam on slow mail-lists, thats what will continue to work. Thats what will be tested on hundreds of machines every six months. I don't want to remind people of JSR80 windows support but you should keep that in mind while getting too far from the crusty roman roads. I'd love to move off to the side in the namespace and leave javax.com for a great effort unifying the time space continuum to be announced at a later date. Beyond that, we would need serious commitment from people in the community to get more working. Both rxtx.org and Sun are about maxed out right now. -- Trent Jarvi tjarvi at qbang.org From martin at jopdesign.com Tue Jul 25 01:32:22 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 09:32:22 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> Message-ID: <005b01c6afbc$794fc060$0202a8c0@luna> >>> None of this is of any particular relevance to the basic underlying >>> question: >>> >>> Should the next JSR attempt to address the multi-drop abilities of RS-485? I would vote for a strong yes. >> >> What I would suggest is to just add a new 'ioctlex'-like method >> to the SerialPort API: A method that you'd use to pass platform- >> or implementation-specific info to the underlying driver or OS >> to do things such as "enabling RS485 mode" or "disable FIFOs" or >> "poll the TSR register". >> >> No need to define any function codes. This is for stuff that is >> platform- or implementation-specific and as such cannot be easily >> abstracted anyway. > > Detrimental to platform independence. We can model it platform independent with two methods: enterTransmit() and extiTransmit() to do whatever is necessary on the underlying platform to switch to RS485 transmit mode and back. Martin From guille at sms.nl Tue Jul 25 01:45:53 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 09:45:53 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <005b01c6afbc$794fc060$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> Message-ID: <7.0.1.0.0.20060725094317.0363b390@sms.nl> Hi Martin, At 09:32 25/07/2006, Martin Schoeberl wrote: > >>> None of this is of any particular relevance to the basic underlying > >>> question: > >>> > >>> Should the next JSR attempt to address the multi-drop abilities > of RS-485? > >I would vote for a strong yes. > > >> > >> What I would suggest is to just add a new 'ioctlex'-like method > >> to the SerialPort API: A method that you'd use to pass platform- > >> or implementation-specific info to the underlying driver or OS > >> to do things such as "enabling RS485 mode" or "disable FIFOs" or > >> "poll the TSR register". > >> > >> No need to define any function codes. This is for stuff that is > >> platform- or implementation-specific and as such cannot be easily > >> abstracted anyway. > > > > Detrimental to platform independence. > >We can model it platform independent with two methods: > >enterTransmit() and extiTransmit() to do whatever is necessary >on the underlying platform to switch to RS485 transmit mode and >back. Tempting as it is, I don't think this covers all cases. For example, in those cases where RS485 direction control must be done 100% in software, the software needs to have a way to flush (sync) software buffers, poll the hardware FIFOs and TSR (not THR), etc. Or, for example, for those UARTs that do automatic RS485 direction control with a configurable turnaround delay, how would you configure this turnaround delay from the application? Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 01:48:10 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 09:48:10 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> Message-ID: <7.0.1.0.0.20060725094602.036cec00@sms.nl> Hi Trent, At 09:21 25/07/2006, Trent Jarvi wrote: >On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: > > > At 19:34 24/07/2006, Gregg Wonderly wrote: > >> Guillermo Rodriguez wrote: > >>> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the > >>> value of standardized APIs to talk to different types of communication > >>> buses including SPI, I2C, 1-Wire, etc., for embedded applications. > >>> However we think this has nothing to do with javax.comm. > >> > >> I don't think this is only about javax.comm. Certainly that's > >> important. I'm > >> just wading into this conversation mainstream and trying to say: > >> > >> If you are going to do anything about "fixing" javax.comm to work on all > >> platforms, please, please, please start with a hardware port SPI > >> definition that > >> lets you get to serial ports, and then provide the existing > javax.com API and > >> whatever new API you think is necessary (I don't have any really > >> issues with the > >> existing API directly). > >> > >> Then, there will be a place for others interesting in SPI, i2C, > USB and other > >> things to get started with providing access to devices that are also > >> interesting > >> in Java applications, and directly, in embedded Java applications. > > > > I do agree that the best a hardware port SPI definition (where > SPI = Service > > Provider Interface, not the SPI protocol) is a good thing to have > to support > > serial ports layered over other transports. However these are still serial > > ports at the end. I still don't think the javax.comm API is well suited to > > "any" serial bus such as I2C, SPI, etc. > > > >Perhaps the javax.com namespace is just wrong. I think thats a larger >issue we are not well prepared to answer. We do have a larger group >participating so there is interest beyond our current solution. My concern was not about the name specifically, but about the idea that a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, IrDA, etc. Looking from a distance all of these may look similar but the fact is, they have little to do with each other (apart from being 'communication protocols' or 'buses') Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From Paul.Klissner at Sun.COM Tue Jul 25 01:51:26 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Tue, 25 Jul 2006 00:51:26 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725082630.036d2d10@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> Message-ID: <44C5CD7E.9030903@sun.com> Guillermo Rodriguez Garcia wrote: > At 19:41 24/07/2006, Paul Klissner wrote: >> Guillermo Rodriguez wrote: >>> Quoting Paul Klissner : >>> >>>>>> None of this is of any particular relevance to the basic underlying >>>>>> question: >>>>>> >>>>>> Should the next JSR attempt to address the multi-drop abilities of >>>> RS-485? >>>>> What I would suggest is to just add a new 'ioctlex'-like method >>>>> to the SerialPort API: A method that you'd use to pass platform- >>>>> or implementation-specific info to the underlying driver or OS >>>>> to do things such as "enabling RS485 mode" or "disable FIFOs" or >>>>> "poll the TSR register". >>>>> >>>>> No need to define any function codes. This is for stuff that is >>>>> platform- or implementation-specific and as such cannot be easily >>>>> abstracted anyway. >>>> Detrimental to platform independence. >>> Yes, it is. But as you go closer and closer to the hardware level some >>> things are by nature platform-dependent, and sometimes just cannot be >>> solved in a platform-independent way. In these cases, is it better to >>> have no solution at all than having one that is less than perfect? >>> Put it another way, would you prefer having people say "I just cannot >>> do this in Java; I'll go somewhere else" rather than "I can do this >>> in Java -- only not in a platform-independent way" ? >> If there isn't a reasonable way to abstract it out, then >> why use Java? > > If an application can be 99% platform independent with small bits > being not portable, why *not* use Java? I'd prefer to see people > using Java to write non-portable applications than having them > use C instead. > > I believe that Java should promote platform neutrality, but that > does not necessarily mean precluding the use of anything that is > NOT platform independent. And let's face it, if you are using > javax.comm to talk to some serial device directly, then chances > are you are already tied to some specific hardware anyway. > > Also, some people (myself included) think that Java can also be > used as a systems programming language, not only for applications. > For many embedded platforms this is certainly the case. In our > platform we even write device drivers directly in Java. I would > imagine the Sun SPOT team (www.sunspotworld.com) supports a > similar view. > > If people needs to do non-portable stuff and wants to do it in > Java I'd rather have them do it in Java than tell them to do it > in C instead. That sounds a bit evangelizing. I think C is perfectly viable for some jobs, and might even be preferable in some cases, for example in some cases where performance or space is a factor. I feel it isn't right to corrupt an API with hacks for the goal of enticing users to Java, even for all the 'right' reasons. >> If someone really needs to do funky things with the hardware, >> why wouldn't that be put in the native back end? > > But nobody said the functionality can't be implemented in the > native back end. However you still need an application level API > to enable/disable it. Sure, but the functions, if really along the lines of the defined standard, can be abstracted, rather than cheat with a general purpose hack-all ioctl-like interface that just begs to be abused, lending itself to a litany of non-portable applications. I maintain we should scope the project appropriately, then take our best shot at a reasonably complete set of abstract functions, and improve it if necessary over time (alpha and beta, release candidates? And then update the API in a backward-compatible way based on feedback after FCS if necessary), rather than add an everything-but-the-kitchen-sink escape clause method. A determined programmer facing a corner case can figure out a way to accomplish the goal in most cases. Even if the API doesn't provide an ioctl call, it is possible to create implementation classes that mak methods visible outsidethe scope of the API-defined methods. For example, if I am implementing class Foo in FooImpl.java, And Foo.java defines interface methods a(), b() and c(), FooImpl.java can also have public methods d(), e() and f(), which can be accessed from the application by casting a Foo object into a FooImpl object. This is one way to provide a back door without compromising the core API itself to do it. This puts the responsibility of breaking platform independence on the developers and not on the designers. Paul From tjarvi at qbang.org Tue Jul 25 02:57:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 02:57:28 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725094602.036cec00@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> Message-ID: On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: > Hi Trent, > > At 09:21 25/07/2006, Trent Jarvi wrote: >> On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: >> >>> At 19:34 24/07/2006, Gregg Wonderly wrote: >>>> Guillermo Rodriguez wrote: >>>>> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the >>>>> value of standardized APIs to talk to different types of communication >>>>> buses including SPI, I2C, 1-Wire, etc., for embedded applications. >>>>> However we think this has nothing to do with javax.comm. >>>> >>>> I don't think this is only about javax.comm. Certainly that's >>>> important. I'm >>>> just wading into this conversation mainstream and trying to say: >>>> >>>> If you are going to do anything about "fixing" javax.comm to work on all >>>> platforms, please, please, please start with a hardware port SPI >>>> definition that >>>> lets you get to serial ports, and then provide the existing >> javax.com API and >>>> whatever new API you think is necessary (I don't have any really >>>> issues with the >>>> existing API directly). >>>> >>>> Then, there will be a place for others interesting in SPI, i2C, >> USB and other >>>> things to get started with providing access to devices that are also >>>> interesting >>>> in Java applications, and directly, in embedded Java applications. >>> >>> I do agree that the best a hardware port SPI definition (where >> SPI = Service >>> Provider Interface, not the SPI protocol) is a good thing to have >> to support >>> serial ports layered over other transports. However these are still serial >>> ports at the end. I still don't think the javax.comm API is well suited to >>> "any" serial bus such as I2C, SPI, etc. >>> >> >> Perhaps the javax.com namespace is just wrong. I think thats a larger >> issue we are not well prepared to answer. We do have a larger group >> participating so there is interest beyond our current solution. > > My concern was not about the name specifically, but about the idea that > a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, > IrDA, etc. Looking from a distance all of these may look similar but > the fact is, they have little to do with each other (apart from being > 'communication protocols' or 'buses') > Hi Guillermo Interesting name. Fair enough. My thoughts are that if it can't be unified in the kernel we are out of our skulls trying to do it in user space. Hacks trying to do such will sure to be in open solaris or linux symposiums about why user space sucks. But there is a minimal bit that overlapps that is what most users want. If we limit the scope, it isnt that hard of a problem. By limiting the scope we also limit our deliverables. If you have an interest in a specific area it will probably not be enough. -- Trent Jarvi tjarvi at qbang.org From martin at jopdesign.com Tue Jul 25 03:25:38 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 11:25:38 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> Message-ID: <001901c6afcc$4bcf64f0$0c28a8c0@luna> >> >> >> >> What I would suggest is to just add a new 'ioctlex'-like method >> >> to the SerialPort API: A method that you'd use to pass platform- >> >> or implementation-specific info to the underlying driver or OS >> >> to do things such as "enabling RS485 mode" or "disable FIFOs" or >> >> "poll the TSR register". >> >> >> >> No need to define any function codes. This is for stuff that is >> >> platform- or implementation-specific and as such cannot be easily >> >> abstracted anyway. >> > >> > Detrimental to platform independence. >> >>We can model it platform independent with two methods: >> >>enterTransmit() and extiTransmit() to do whatever is necessary >>on the underlying platform to switch to RS485 transmit mode and >>back. > > Tempting as it is, I don't think this covers all cases. For example, > in those cases where RS485 direction control must be done 100% in > software, the software needs to have a way to flush (sync) software > buffers, poll the hardware FIFOs and TSR (not THR), etc. I just meant to hide those low-level issues you mention in the enter/exitTransmit modes. > > Or, for example, for those UARTs that do automatic RS485 direction > control with a configurable turnaround delay, how would you configure > this turnaround delay from the application? Mmh, perhaps in a similar way as you configure timeouts? Isn't this 'just' a timeout value? Martin From guille at sms.nl Tue Jul 25 04:05:29 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 12:05:29 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <001901c6afcc$4bcf64f0$0c28a8c0@luna> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> Message-ID: <7.0.1.0.0.20060725115736.03706a38@sms.nl> At 11:25 25/07/2006, Martin Schoeberl wrote: > >> >> > >> >> What I would suggest is to just add a new 'ioctlex'-like method > >> >> to the SerialPort API: A method that you'd use to pass platform- > >> >> or implementation-specific info to the underlying driver or OS > >> >> to do things such as "enabling RS485 mode" or "disable FIFOs" or > >> >> "poll the TSR register". > >> >> > >> >> No need to define any function codes. This is for stuff that is > >> >> platform- or implementation-specific and as such cannot be easily > >> >> abstracted anyway. > >> > > >> > Detrimental to platform independence. > >> > >>We can model it platform independent with two methods: > >> > >>enterTransmit() and extiTransmit() to do whatever is necessary > >>on the underlying platform to switch to RS485 transmit mode and > >>back. > > > > Tempting as it is, I don't think this covers all cases. For example, > > in those cases where RS485 direction control must be done 100% in > > software, the software needs to have a way to flush (sync) software > > buffers, poll the hardware FIFOs and TSR (not THR), etc. > >I just meant to hide those low-level issues you mention in the >enter/exitTransmit modes. If the system has dedicated RS485 hardware then the underlying kernel or device driver may know about it and all of the hassle can be conveniently encapsulated in some enter/exitTransmit methods -- but in this case you can also skip these and just have the driver enable transmit mode as long as it has data to transmit, and stay in receive mode otherwise. If the system has a UART that can be configured as RS232 or RS485 then you may need to tell the kernel or device driver to enter RS485 mode explicitly. Your approach may work there as well. If the system does not have dedicated RS485 hardware and you are using an external RS232-RS485 protocol converter (a very common case) then the driver and kernel probably don't know about that and you have to take care at the application level (javax.comm doesn't even need to know this converter exists), and in order to that you may need to do different things depending on the specific converter you're using. > > > > Or, for example, for those UARTs that do automatic RS485 direction > > control with a configurable turnaround delay, how would you configure > > this turnaround delay from the application? > >Mmh, perhaps in a similar way as you configure timeouts? >Isn't this 'just' a timeout value? Yes, but this is just a specific parameter that you can configure in a specific type of UART (an EXAR UART). Other UARTs might be different. The point I'm trying to make is that there are just too many parameters to have an API for each specific case. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 04:12:31 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 12:12:31 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C5CD7E.9030903@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> <44C5CD7E.9030903@sun.com> Message-ID: <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> At 09:51 25/07/2006, Paul Klissner wrote: >Guillermo Rodriguez Garcia wrote: > > At 19:41 24/07/2006, Paul Klissner wrote: > >> Guillermo Rodriguez wrote: > >>> Quoting Paul Klissner : > >>> > >>>>>> None of this is of any particular relevance to the basic underlying > >>>>>> question: > >>>>>> > >>>>>> Should the next JSR attempt to address the multi-drop abilities of > >>>> RS-485? > >>>>> What I would suggest is to just add a new 'ioctlex'-like method > >>>>> to the SerialPort API: A method that you'd use to pass platform- > >>>>> or implementation-specific info to the underlying driver or OS > >>>>> to do things such as "enabling RS485 mode" or "disable FIFOs" or > >>>>> "poll the TSR register". > >>>>> > >>>>> No need to define any function codes. This is for stuff that is > >>>>> platform- or implementation-specific and as such cannot be easily > >>>>> abstracted anyway. > >>>> Detrimental to platform independence. > >>> Yes, it is. But as you go closer and closer to the hardware level some > >>> things are by nature platform-dependent, and sometimes just cannot be > >>> solved in a platform-independent way. In these cases, is it better to > >>> have no solution at all than having one that is less than perfect? > >>> Put it another way, would you prefer having people say "I just cannot > >>> do this in Java; I'll go somewhere else" rather than "I can do this > >>> in Java -- only not in a platform-independent way" ? > >> If there isn't a reasonable way to abstract it out, then > >> why use Java? > > > > If an application can be 99% platform independent with small bits > > being not portable, why *not* use Java? I'd prefer to see people > > using Java to write non-portable applications than having them > > use C instead. > > > > I believe that Java should promote platform neutrality, but that > > does not necessarily mean precluding the use of anything that is > > NOT platform independent. And let's face it, if you are using > > javax.comm to talk to some serial device directly, then chances > > are you are already tied to some specific hardware anyway. > > > > Also, some people (myself included) think that Java can also be > > used as a systems programming language, not only for applications. > > For many embedded platforms this is certainly the case. In our > > platform we even write device drivers directly in Java. I would > > imagine the Sun SPOT team (www.sunspotworld.com) supports a > > similar view. > > > > If people needs to do non-portable stuff and wants to do it in > > Java I'd rather have them do it in Java than tell them to do it > > in C instead. > >That sounds a bit evangelizing. Could be, but then what's wrong with that? As I said there is people that thinks that Java can be perfectly adequate for system level programming -- especially for embedded platforms. I guess the whole issue is whether it is better to have no solution at all for a specific problem than a solution that is not perfect (in this context a "perfect" solution is one that is portable and platform-independent). I think a solution that is not perfect is better than no solution. If I understand correctly you say that you prefer to have no Java solution (and have people use C) rather than one that is not portable. >I think C is perfectly viable >for some jobs, and might even be preferable in some cases, for example >in some cases where performance or space is a factor. I feel it isn't >right to corrupt an API with hacks for the goal of enticing users >to Java, even for all the 'right' reasons. > > >> If someone really needs to do funky things with the hardware, > >> why wouldn't that be put in the native back end? > > > > But nobody said the functionality can't be implemented in the > > native back end. However you still need an application level API > > to enable/disable it. > >Sure, but the functions, if really along the lines of the defined >standard, can be abstracted, rather than cheat with a general >purpose hack-all ioctl-like interface that just begs to be abused, >lending itself to a litany of non-portable applications. Well, I didn't specifically say there's no way to abstract these functions. I only said that it is not easy, and that I don't know of any reasonable way to do it. But if others can find a way, that is fine of course. >I maintain we should scope the project appropriately, then take >our best shot at a reasonably complete set of abstract functions, >and improve it if necessary over time (alpha and beta, release >candidates? And then update the API in a backward-compatible way >based on feedback after FCS if necessary), rather than add an >everything-but-the-kitchen-sink escape clause method. > >A determined programmer facing a corner case can figure out a way >to accomplish the goal in most cases. Even if the API doesn't provide >an ioctl call, it is possible to create implementation classes that >mak methods visible outsidethe scope of the API-defined methods. > >For example, if I am implementing class Foo in FooImpl.java, >And Foo.java defines interface methods a(), b() and c(), >FooImpl.java can also have public methods d(), e() and f(), which can >be accessed from the application by casting a Foo object into >a FooImpl object. This is one way to provide a back door without >compromising the core API itself to do it. This puts the >responsibility of breaking platform independence on the developers >and not on the designers. Yes, that may be a good way to do it. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 04:21:31 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 12:21:31 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> Message-ID: <7.0.1.0.0.20060725121958.03714668@sms.nl> Hi Trent, At 10:57 25/07/2006, Trent Jarvi wrote: > >> Perhaps the javax.com namespace is just wrong. I think thats a larger > >> issue we are not well prepared to answer. We do have a larger group > >> participating so there is interest beyond our current solution. > > > > My concern was not about the name specifically, but about the idea that > > a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, > > IrDA, etc. Looking from a distance all of these may look similar but > > the fact is, they have little to do with each other (apart from being > > 'communication protocols' or 'buses') > > > >Hi Guillermo > >Interesting name. > >Fair enough. My thoughts are that if it can't be unified in the kernel we >are out of our skulls trying to do it in user space. Hacks trying to do >such will sure to be in open solaris or linux symposiums about why user >space sucks. > >But there is a minimal bit that overlapps that is what most users want. >If we limit the scope, it isnt that hard of a problem. By limiting the >scope we also limit our deliverables. If you have an interest in a >specific area it will probably not be enough. Yes, you are right. But isn't this 'minimal bit that overlaps' what we have already? (basically support for UART-based serial ports plus minimal support for parallel ports) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From lyon at docjava.com Tue Jul 25 05:44:43 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 25 Jul 2006 07:44:43 -0400 Subject: [Rxtx] 7 RS485 questions... In-Reply-To: <7.0.1.0.0.20060725115736.03706a38@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: Hi All, 1. Does anyone have a sense for how much larger the JSR would be if it embraced a multi-drop protocol, like RS485? 2. Do we address collision detection and addressing in RS485? 3. How would collision detection and addressing impact the size of the specification? 4. Would JSR80 (and, perhaps a RS485-USB converter) be the more appropriate place for RS485 support? 5. Is RS485 Transmission controlled by RTS, and the TxD line? 6. How tight is the windows timing on control of the RTS line? 7. Does an RTS controlled RS485 converter work well at high baud rates under windows? Thanks! - Doug From naranjo.manuel at gmail.com Tue Jul 25 06:29:45 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Tue, 25 Jul 2006 09:29:45 -0300 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725094602.036cec00@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> Message-ID: <44C60EB9.5000803@gmail.com> Guillermo Rodriguez Garcia escribi?: > My concern was not about the name specifically, but about the idea that > a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, > IrDA, etc. Looking from a distance all of these may look similar but > the fact is, they have little to do with each other (apart from being > 'communication protocols' or 'buses') > I think Guillermo is right, all ports has in common that they are buses. A stupid idea but why don't declarate the package javax.bus and make javax.comm a dedicated namespace to rs232 and parallell to mantain backward compatibility, obviously the classes at javax.comm should extend classes from javax.bus. Regards, Manuel From j.a.horsmeier at wanadoo.nl Tue Jul 25 07:00:17 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Tue, 25 Jul 2006 15:00:17 +0200 Subject: [Rxtx] 7 RS485 questions... In-Reply-To: Message-ID: <05a701c6afea$47002e00$0a01a8c0@CALVIN> Douglas Lyon wrote: > 1. Does anyone have a sense for how much larger the JSR would > be if it embraced a multi-drop protocol, like RS485? The RS485 multidrop capability all resides on top of the communication layer, i.e. all transmitters but one are disabled (all devices are just listening). When the message has been sent at most one device answers (see 2) > 2. Do we address collision detection and addressing in RS485? Addressing a device is also implemented on top of the communication layer. If/when two devices happen to have the same address it would be disastrous. An address is defined by the protocol, e.g. modbus allows for 250 or so different addresses but another protocol might allow for 2^32 different devices hooked up on one two wire cable. > 3. How would collision detection and addressing impact the size of > the specification? IMHO it's none of rxtx's business, it's a configuration error on the devices if that happens. > 4. Would JSR80 (and, perhaps a RS485-USB converter) be the > more appropriate place for RS485 support? Don't know. > 5. Is RS485 Transmission controlled by RTS, and the TxD line? Two wire RS485 doesn't have a RTS line. It's all in the timing. The half duplex protocol is extremely simple: one master sends, all devices listen, after that at most one device enables its transmitter and sends something back. > 6. How tight is the windows timing on control of the RTS line? Before a device enables its transmitter it should wait a bit because of cable lengths and the other device that must *disable* its transmitter. It's all up to the devices and rxtx can do nothing about it. > 7. Does an RTS controlled RS485 converter work well at high baud > rates under windows? Baud rates aren't the problem; cable lengths are the problem, sensitivity for distortion are the problem. The wait time between en/disabling transmitters can be configured in the devices and can be software controlled on the pc. kind regards, Jos From tjarvi at qbang.org Tue Jul 25 07:08:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 07:08:53 -0600 (MDT) Subject: [Rxtx] 7 RS485 questions... In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: > 5. Is RS485 Transmission controlled by RTS, and the TxD line? This is done when using EIA232 to drive RS485 with no adaptor. This is the RS485 hack that is in RXTX 2.1 that never went anyplace. I discovered no typical kernel will openly support this line of thought. It is not maintainable. There are hardware solutions. Off the top of my head it required < 10 ms responses and typical kernels + java do 10 ms responses. Realtime kernels or special kernel drivers are required. It is possible but not supportable. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Tue Jul 25 07:46:52 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 08:46:52 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <005b01c6afbc$794fc060$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> Message-ID: <44C620CC.6090901@cox.net> Martin Schoeberl wrote: > We can model it platform independent with two methods: > > enterTransmit() and extiTransmit() to do whatever is necessary > on the underlying platform to switch to RS485 transmit mode and > back. Or, do what is typically done, and use a single write operation as the indication of a 'packet' that will let the underlying RS-485/422 driver assert the appropriate signalling. Gregg Wonderly From guille at sms.nl Tue Jul 25 07:48:04 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 15:48:04 +0200 Subject: [Rxtx] 7 RS485 questions... In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: <7.0.1.0.0.20060725154329.036deb18@sms.nl> Hi Doug, Some answers below. At 13:44 25/07/2006, Dr. Douglas Lyon wrote: >Hi All, > >1. Does anyone have a sense for how much larger the JSR would be >if it embraced a multi-drop protocol, like RS485? As I've said in other mails RS485 is in essence just a UART-based serial port interface just like RS232. The only functional difference is that it is multi-drop and half-duplex so there must be a way for nodes to switch between transmit and receive modes but then the RS485 standard does not tell you when or how you should do that -- this depends on the upper layer protocols (for example Modbus) >2. Do we address collision detection and addressing in RS485? Collision detection and addressing are not defined by the RS485 standard. Upper layer protocols such as Modbus take care of that. >3. How would collision detection and addressing impact the size of >the specification? See above. >4. Would JSR80 (and, perhaps a RS485-USB converter) be the more appropriate >place for RS485 support? I don't think so. As I said RS485 is just a serial port like RS232 is. >5. Is RS485 Transmission controlled by RTS, and the TxD line? Some RS232-RS485 protocol converters use the RTS line as a control signal to switch between transmit and receive modes. Others use DTR. Others do not use any of them. >6. How tight is the windows timing on control of the RTS line? Depends on the upper layer protocols, e.g. Modbus. Not defined by RS485. >7. Does an RTS controlled RS485 converter work well at high baud >rates under windows? Depends on how tight the timing is. For some applications it may work well but for many probably won't. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 09:22:09 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Tue, 25 Jul 2006 17:22:09 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C620CC.6090901@cox.net> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> Message-ID: <1153840929.44c6372186f67@webmail.eatserver.nl> Hi Gregg, Quoting Gregg Wonderly : > Martin Schoeberl wrote: > > We can model it platform independent with two methods: > > > > enterTransmit() and extiTransmit() to do whatever is necessary > > on the underlying platform to switch to RS485 transmit mode and > > back. > > Or, do what is typically done, and use a single write operation as the > indication of a 'packet' that will let the underlying RS-485/422 driver > assert > the appropriate signalling. The problem with this is that there is no guarantee that a single call to the write method of the OutputStream associated with a javax.comm SerialPort will translate to a single write to the underlying device driver -- this depends on the javax.comm implementation. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From Paul.Klissner at Sun.COM Tue Jul 25 09:35:19 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Tue, 25 Jul 2006 08:35:19 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C60EB9.5000803@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> <44C60EB9.5000803@gmail.com> Message-ID: <44C63A37.8080406@sun.com> Manuel Francisco Naranjo wrote: > Guillermo Rodriguez Garcia escribi?: >> My concern was not about the name specifically, but about the idea that >> a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, >> IrDA, etc. Looking from a distance all of these may look similar but >> the fact is, they have little to do with each other (apart from being >> 'communication protocols' or 'buses') >> > I think Guillermo is right, all ports has in common that they are buses. > A stupid idea but why don't declarate the package javax.bus and make > javax.comm a dedicated namespace to rs232 and parallell to mantain > backward compatibility, obviously the classes at javax.comm should > extend classes from javax.bus. I like the initial sound of that idea too and was starting to think along those lines myself. But what would be the points of commonality to extend? Device mapping, ownership? Read, write, type, status? Too late for javax.usb (JSR80) very complex Bus and for the most part cast in stone. And 'bus' has such a wide scope. Also that would imply two downloads to install any given bus support, which might not be the end of the world. And maybe two JSRs? Paul From martin at jopdesign.com Tue Jul 25 09:37:12 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 17:37:12 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> Message-ID: <00c801c6b000$33a68f00$0c28a8c0@luna> >> Martin Schoeberl wrote: >> > We can model it platform independent with two methods: >> > >> > enterTransmit() and extiTransmit() to do whatever is necessary >> > on the underlying platform to switch to RS485 transmit mode and >> > back. >> >> Or, do what is typically done, and use a single write operation as the >> indication of a 'packet' that will let the underlying RS-485/422 driver >> assert >> the appropriate signalling. > > The problem with this is that there is no guarantee that a single call > to the write method of the OutputStream associated with a javax.comm > SerialPort will translate to a single write to the underlying device > driver -- this depends on the javax.comm implementation. > I completely agree - it's still a stream and not a packet. This is similar to a single write to a TCP/IP socket. There is no guarantee that you get this data as a single packet/single read on the other side. However, I've seen a lot of programs assuming that this happens ;-) Martin From gergg at cox.net Tue Jul 25 10:15:41 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 11:15:41 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725082124.036309e0@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> Message-ID: <44C643AD.6020604@cox.net> Guillermo Rodriguez Garcia wrote: > At 19:34 24/07/2006, Gregg Wonderly wrote: >>Then, there will be a place for others interesting in SPI, i2C, USB and other >>things to get started with providing access to devices that are also >>interesting >>in Java applications, and directly, in embedded Java applications. > > I do agree that the best a hardware port SPI definition (where SPI = Service > Provider Interface, not the SPI protocol) is a good thing to have to support > serial ports layered over other transports. However these are still serial > ports at the end. I still don't think the javax.comm API is well suited to > "any" serial bus such as I2C, SPI, etc. Yes, absolutely these other wire protocols are different. As I tried to say before, I think that the javax.comm API works fine for my needs. I think that we need to keep it around, no matter what else happens. So, for me, there are a few choices. 1. Create a new JSR to formalize the existing API and include some hardwired JNI code to provide port enumeration and access. 2. Create a new JSR to create a port abstraction SPI to allow JVM providers to enumerate all kinds of port/circuit based hardware to the JVM. Create an implementation of the existing javax.comm API that uses this SPI. 3. Just implement some JNI and Java libraries post them on sourceforge/java.net and let people have at them. For 1 and 2, you'll have to get the JCP to approve that the JSR is worth making a standard. Option 3 doesn't really solve a problem as much as it creates a new way to deal with an existing problem. I think 2 is the most desireable way to go. It really will open the door for more access to hardware from Java! Gregg Wonderly From joachim at buechse.de Tue Jul 25 10:17:07 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 25 Jul 2006 18:17:07 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <00c801c6b000$33a68f00$0c28a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: Just trigger writing on flush(). It is perfectly legal for an Outputstream implementation to do do nothing until flush is called and the documentation of OutputStream.flush reads: "Flushes this output stream and forces any buffered output bytes to be written out. The general contract of flush is that calling it is an indication that, if any bytes previously written have been buffered by the implementation of the output stream, such bytes should immediately be written to their intended destination." As RS485 is a "dont speak up unless requested" protocol, a mandatory flush after write seems like the way to go to me No client can prevent another client from writing, so there is no point in keeping the output-drivers enabled after all data currently buffered has been written. So flush() should trigger "enterTransmit, writePacket[s], exitTransmit". If the service provider (ie concrete implementation of the flush method) decides that the write is inapropriate at the moment (ie because of a higher level arbitration protocol that might be implemented by the service provider) it will simply block the flush or throw an IOException (preferably after some sort of timeout). Regards, Joachim PS: It is great to see all the motivation that is brought forward on this list regarding the future. It would be great if only 10% of that motivation could be transformed into a cleanup and extension of the existing code. The current code access model seems rather inappropriate for the prototyping of the ideas beeing presented. Trent can we get a "contributions" branch with "free" access. On 25.07.2006, at 17:37, Martin Schoeberl wrote: >>> Martin Schoeberl wrote: >>>> We can model it platform independent with two methods: >>>> >>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>> on the underlying platform to switch to RS485 transmit mode and >>>> back. >>> >>> Or, do what is typically done, and use a single write operation >>> as the >>> indication of a 'packet' that will let the underlying RS-485/422 >>> driver >>> assert >>> the appropriate signalling. >> >> The problem with this is that there is no guarantee that a single >> call >> to the write method of the OutputStream associated with a javax.comm >> SerialPort will translate to a single write to the underlying device >> driver -- this depends on the javax.comm implementation. >> > I completely agree - it's still a stream and not a packet. > > This is similar to a single write to a TCP/IP socket. There > is no guarantee that you get this data as a single packet/single > read on the other side. However, I've seen a lot of programs > assuming that this happens ;-) > > Martin > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Tue Jul 25 10:34:59 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Tue, 25 Jul 2006 18:34:59 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <1153845299.44c64833920bd@webmail.eatserver.nl> Hi Joachim, That is a very nice approach which I think would work well as far as the underlying device driver knows about RS485. However it still does not solve the problem with external protocol converters where the device driver only knows about regular UARTs and RTS or DTR must be used to toggle direction of the converter. Guillermo Quoting Joachim Buechse : > Just trigger writing on flush(). It is perfectly legal for an > Outputstream implementation to do do nothing until flush is called > and the documentation of OutputStream.flush reads: > > "Flushes this output stream and forces any buffered output bytes to > be written out. The general contract of flush is that calling it is > an indication that, if any bytes previously written have been > buffered by the implementation of the output stream, such bytes > should immediately be written to their intended destination." > > As RS485 is a "dont speak up unless requested" protocol, a mandatory > flush after write seems like the way to go to me > > No client can prevent another client from writing, so there is no > point in keeping the output-drivers enabled after all data currently > buffered has been written. So flush() should trigger "enterTransmit, > writePacket[s], exitTransmit". If the service provider (ie concrete > implementation of the flush method) decides that the write is > inapropriate at the moment (ie because of a higher level arbitration > protocol that might be implemented by the service provider) it will > simply block the flush or throw an IOException (preferably after some > sort of timeout). > > Regards, > Joachim > > PS: It is great to see all the motivation that is brought forward on > this list regarding the future. It would be great if only 10% of that > motivation could be transformed into a cleanup and extension of the > existing code. The current code access model seems rather > inappropriate for the prototyping of the ideas beeing presented. > Trent can we get a "contributions" branch with "free" access. > > > On 25.07.2006, at 17:37, Martin Schoeberl wrote: > > >>> Martin Schoeberl wrote: > >>>> We can model it platform independent with two methods: > >>>> > >>>> enterTransmit() and extiTransmit() to do whatever is necessary > >>>> on the underlying platform to switch to RS485 transmit mode and > >>>> back. > >>> > >>> Or, do what is typically done, and use a single write operation > >>> as the > >>> indication of a 'packet' that will let the underlying RS-485/422 > >>> driver > >>> assert > >>> the appropriate signalling. > >> > >> The problem with this is that there is no guarantee that a single > >> call > >> to the write method of the OutputStream associated with a javax.comm > >> SerialPort will translate to a single write to the underlying device > >> driver -- this depends on the javax.comm implementation. > >> > > I completely agree - it's still a stream and not a packet. > > > > This is similar to a single write to a TCP/IP socket. There > > is no guarantee that you get this data as a single packet/single > > read on the other side. However, I've seen a lot of programs > > assuming that this happens ;-) > > > > Martin > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- http://www.snijder.com/ SNIJDER Micro Systems From guille at sms.nl Tue Jul 25 10:44:56 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Tue, 25 Jul 2006 18:44:56 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C643AD.6020604@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <44C643AD.6020604@cox.net> Message-ID: <1153845896.44c64a8890968@webmail.eatserver.nl> Hi Gregg, Quoting Gregg Wonderly : > Guillermo Rodriguez Garcia wrote: > > At 19:34 24/07/2006, Gregg Wonderly wrote: > >>Then, there will be a place for others interesting in SPI, i2C, USB and > other > >>things to get started with providing access to devices that are also > >>interesting > >>in Java applications, and directly, in embedded Java applications. > > > > I do agree that the best a hardware port SPI definition (where SPI = > Service > > Provider Interface, not the SPI protocol) is a good thing to have to > support > > serial ports layered over other transports. However these are still serial > > ports at the end. I still don't think the javax.comm API is well suited to > > "any" serial bus such as I2C, SPI, etc. > > Yes, absolutely these other wire protocols are different. As I tried to say > > before, I think that the javax.comm API works fine for my needs. I think > that > we need to keep it around, no matter what else happens. So, for me, there > are a > few choices. > > 1. Create a new JSR to formalize the existing API and include some hardwired > JNI > code to provide port enumeration and access. > > 2. Create a new JSR to create a port abstraction SPI to allow JVM providers > to > enumerate all kinds of port/circuit based hardware to the JVM. Create an > implementation of the existing javax.comm API that uses this SPI. As an embedded Java vendor we work very close to the hardware level and have to deal daily with dozens of different types of ports and communication buses and protocols. Based on our experience I think that a SPI for "all kinds of port/circuit based hardware" is just too generic and not really practical. I think having a Service Provider Interface within javax.comm so that custom serial port implementations can be plugged in is a very good idea. However I don't think it is convenient to have it as a separate JSR and then with such a broad scope. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From joachim at buechse.de Tue Jul 25 10:56:12 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 25 Jul 2006 18:56:12 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <1153845299.44c64833920bd@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> <1153845299.44c64833920bd@webmail.eatserver.nl> Message-ID: In this case you need to configure your port with a different device driver. You may optionally take an existing port, wrap it up in a "wrapping device driver" implemented in Java and add it to the list of ports as a new port... In any case the core application should not care. On 25.07.2006, at 18:34, Guillermo Rodriguez wrote: > Hi Joachim, > > That is a very nice approach which I think would work well as far > as the underlying device driver knows about RS485. > > However it still does not solve the problem with external protocol > converters where the device driver only knows about regular UARTs > and RTS or DTR must be used to toggle direction of the converter. > > Guillermo > > Quoting Joachim Buechse : > >> Just trigger writing on flush(). It is perfectly legal for an >> Outputstream implementation to do do nothing until flush is called >> and the documentation of OutputStream.flush reads: >> >> "Flushes this output stream and forces any buffered output bytes to >> be written out. The general contract of flush is that calling it is >> an indication that, if any bytes previously written have been >> buffered by the implementation of the output stream, such bytes >> should immediately be written to their intended destination." >> >> As RS485 is a "dont speak up unless requested" protocol, a mandatory >> flush after write seems like the way to go to me >> >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). >> >> Regards, >> Joachim >> >> PS: It is great to see all the motivation that is brought forward on >> this list regarding the future. It would be great if only 10% of that >> motivation could be transformed into a cleanup and extension of the >> existing code. The current code access model seems rather >> inappropriate for the prototyping of the ideas beeing presented. >> Trent can we get a "contributions" branch with "free" access. >> >> >> On 25.07.2006, at 17:37, Martin Schoeberl wrote: >> >>>>> Martin Schoeberl wrote: >>>>>> We can model it platform independent with two methods: >>>>>> >>>>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>>>> on the underlying platform to switch to RS485 transmit mode and >>>>>> back. >>>>> >>>>> Or, do what is typically done, and use a single write operation >>>>> as the >>>>> indication of a 'packet' that will let the underlying RS-485/422 >>>>> driver >>>>> assert >>>>> the appropriate signalling. >>>> >>>> The problem with this is that there is no guarantee that a single >>>> call >>>> to the write method of the OutputStream associated with a >>>> javax.comm >>>> SerialPort will translate to a single write to the underlying >>>> device >>>> driver -- this depends on the javax.comm implementation. >>>> >>> I completely agree - it's still a stream and not a packet. >>> >>> This is similar to a single write to a TCP/IP socket. There >>> is no guarantee that you get this data as a single packet/single >>> read on the other side. However, I've seen a lot of programs >>> assuming that this happens ;-) >>> >>> Martin >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > > -- > http://www.snijder.com/ > SNIJDER Micro Systems > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From martin at jopdesign.com Tue Jul 25 11:13:10 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 19:13:10 +0200 Subject: [Rxtx] JSR Direction; packetizing writes References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com><005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net><1153840929.44c6372186f67@webmail.eatserver.nl><00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <000f01c6b00d$9bcc51c0$0202a8c0@luna> > No client can prevent another client from writing, so there is no > point in keeping the output-drivers enabled after all data currently > buffered has been written. So flush() should trigger "enterTransmit, > writePacket[s], exitTransmit". If the service provider (ie concrete > implementation of the flush method) decides that the write is > inapropriate at the moment (ie because of a higher level arbitration > protocol that might be implemented by the service provider) it will > simply block the flush or throw an IOException (preferably after some > sort of timeout). Not only flush() would mean enterTransmit(). With your idea each write should enable the driver, but only flush() can disable the driver after the last byte is written. RS485 is a beast. E.g. some driver chips need a few us (100us for a Maxim 1480B!) from output enable till output low/high. On a different application we had to wait a little bit before disabling the output driver to have a clear '1' on the bus as it took too long for the termination resistors to force the bus to 1. I can imagine that this is not really funny with general RS232/RS485 converters. Martin From joachim at buechse.de Tue Jul 25 11:42:18 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 25 Jul 2006 19:42:18 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <000f01c6b00d$9bcc51c0$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com><005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net><1153840929.44c6372186f67@webmail.eatserver.nl><00c801c6b000$33a68f00$0c28a8c0@luna> <000f01c6b00d$9bcc51c0$0202a8c0@luna> Message-ID: Simple answer: NO. You can not control the timing of the Java VM (especially not on ME) and hence you do not want to enable the outputs before you have all data collected. The timings you mention are all in the implementation space of the device driver. The core application should not care, neither should the javax.comm api in my opinion. Should I happen to be the pour soul that tries to implement an RS485 device driver reference implementation I will try to remember your email and add appropriate properties. Regards, Joachim On 25.07.2006, at 19:13, Martin Schoeberl wrote: >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). > > Not only flush() would mean enterTransmit(). With your idea each > write should enable the driver, but only flush() can disable > the driver after the last byte is written. > > RS485 is a beast. E.g. some driver chips need a few us (100us > for a Maxim 1480B!) from output enable till output low/high. > > On a different application we had to wait a little bit before > disabling the output driver to have a clear '1' on the bus as it took > too long for the termination resistors to force the bus to 1. > > I can imagine that this is not really funny with general > RS232/RS485 converters. > > Martin > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Tue Jul 25 12:50:20 2006 From: jredman at ergotech.com (Jim Redman) Date: Tue, 25 Jul 2006 12:50:20 -0600 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <44C667EC.2070602@ergotech.com> The horror! This would be terribly inefficient. Especially in serial protocols you need to start getting bits on the wire as soon as possible. It could also have some timeout implications. Jim Joachim Buechse wrote: > Just trigger writing on flush(). It is perfectly legal for an > Outputstream implementation to do do nothing until flush is called > and the documentation of OutputStream.flush reads: > > "Flushes this output stream and forces any buffered output bytes to > be written out. The general contract of flush is that calling it is > an indication that, if any bytes previously written have been > buffered by the implementation of the output stream, such bytes > should immediately be written to their intended destination." > > As RS485 is a "dont speak up unless requested" protocol, a mandatory > flush after write seems like the way to go to me > > No client can prevent another client from writing, so there is no > point in keeping the output-drivers enabled after all data currently > buffered has been written. So flush() should trigger "enterTransmit, > writePacket[s], exitTransmit". If the service provider (ie concrete > implementation of the flush method) decides that the write is > inapropriate at the moment (ie because of a higher level arbitration > protocol that might be implemented by the service provider) it will > simply block the flush or throw an IOException (preferably after some > sort of timeout). > > Regards, > Joachim > > PS: It is great to see all the motivation that is brought forward on > this list regarding the future. It would be great if only 10% of that > motivation could be transformed into a cleanup and extension of the > existing code. The current code access model seems rather > inappropriate for the prototyping of the ideas beeing presented. > Trent can we get a "contributions" branch with "free" access. > > > On 25.07.2006, at 17:37, Martin Schoeberl wrote: > >>>> Martin Schoeberl wrote: >>>>> We can model it platform independent with two methods: >>>>> >>>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>>> on the underlying platform to switch to RS485 transmit mode and >>>>> back. >>>> Or, do what is typically done, and use a single write operation >>>> as the >>>> indication of a 'packet' that will let the underlying RS-485/422 >>>> driver >>>> assert >>>> the appropriate signalling. >>> The problem with this is that there is no guarantee that a single >>> call >>> to the write method of the OutputStream associated with a javax.comm >>> SerialPort will translate to a single write to the underlying device >>> driver -- this depends on the javax.comm implementation. >>> >> I completely agree - it's still a stream and not a packet. >> >> This is similar to a single write to a TCP/IP socket. There >> is no guarantee that you get this data as a single packet/single >> read on the other side. However, I've seen a lot of programs >> assuming that this happens ;-) >> >> Martin >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From jredman at ergotech.com Tue Jul 25 12:53:02 2006 From: jredman at ergotech.com (Jim Redman) Date: Tue, 25 Jul 2006 12:53:02 -0600 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <000f01c6b00d$9bcc51c0$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com><005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net><1153840929.44c6372186f67@webmail.eatserver.nl><00c801c6b000$33a68f00$0c28a8c0@luna> <000f01c6b00d$9bcc51c0$0202a8c0@luna> Message-ID: <44C6688E.8040202@ergotech.com> Since we now seem to have entered a discussion of how to switch receive/transmit on 485 lines, I can tell you from experience that you cannot reliably do this from Java. Java just is not fast enough. I spend some time trying to get this to work with RXTX and it would work _most_ of the time, but you need to be able to guarantee ms level response which you can't do in any system that doesn't have real-time capabilities. Jim Martin Schoeberl wrote: >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). > > Not only flush() would mean enterTransmit(). With your idea each > write should enable the driver, but only flush() can disable > the driver after the last byte is written. > > RS485 is a beast. E.g. some driver chips need a few us (100us > for a Maxim 1480B!) from output enable till output low/high. > > On a different application we had to wait a little bit before > disabling the output driver to have a clear '1' on the bus as it took > too long for the termination resistors to force the bus to 1. > > I can imagine that this is not really funny with general > RS232/RS485 converters. > > Martin > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Tue Jul 25 13:37:14 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 14:37:14 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725115736.03706a38@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: <44C672EA.1080604@cox.net> Guillermo Rodriguez Garcia wrote: > At 11:25 25/07/2006, Martin Schoeberl wrote: >>Mmh, perhaps in a similar way as you configure timeouts? >>Isn't this 'just' a timeout value? > > Yes, but this is just a specific parameter that you can configure in a > specific type of UART (an EXAR UART). Other UARTs might be different. The > point I'm trying to make is that there are just too many parameters to > have an API for each specific case. In my earlier example/proposal, I included the ability for attributes of a port to be expressed as a collection of enumeration values for standard things. That would be fine for simple things like Input, Output, Sync, Async etc. When there are specific attributes of specific hardware, the vendor is going to have to provide a way to configure those attributes. One of the primary mechanisms in Java to do this is the JavaBean pattern that can be manifested in a Map type object when an API needs to preexist. So, we can provide an mechanism for propagating random attributes using a Map argument to a method such as public void setConfig( Map params ) throws IOException; public Map getConfig() throws IOException; Then, there is a conduit in and out of the driver that the user can use without needing more standards/spec'd code/API. This isn't much different than an ioctl(2) like mechanism, but it feels more Java like. A URL like mechanism, such as that which JDBC drivers use, could also be attractive. I've also wanted to replace java.net with the J2ME connection based mechanism as well. We might consider looking at the J2ME connector architecture to see if there is any gain in using some of that experience. Gregg Wonderly From gergg at cox.net Tue Jul 25 13:38:42 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 14:38:42 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> <44C5CD7E.9030903@sun.com> <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> Message-ID: <44C67342.9020402@cox.net> Guillermo Rodriguez Garcia wrote: > At 09:51 25/07/2006, Paul Klissner wrote: >>For example, if I am implementing class Foo in FooImpl.java, >>And Foo.java defines interface methods a(), b() and c(), >>FooImpl.java can also have public methods d(), e() and f(), which can >>be accessed from the application by casting a Foo object into >>a FooImpl object. This is one way to provide a back door without >>compromising the core API itself to do it. This puts the >>responsibility of breaking platform independence on the developers >>and not on the designers. > > Yes, that may be a good way to do it. The J2ME connector architecture is an example of a place where this is done. Gregg Wonderly From Paul.Klissner at Sun.COM Tue Jul 25 14:02:40 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Tue, 25 Jul 2006 13:02:40 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C67342.9020402@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> <44C5CD7E.9030903@sun.com> <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> <44C67342.9020402@cox.net> Message-ID: <44C678E0.90209@sun.com> Gregg Wonderly wrote: > Guillermo Rodriguez Garcia wrote: >> At 09:51 25/07/2006, Paul Klissner wrote: >>> For example, if I am implementing class Foo in FooImpl.java, >>> And Foo.java defines interface methods a(), b() and c(), >>> FooImpl.java can also have public methods d(), e() and f(), which can >>> be accessed from the application by casting a Foo object into >>> a FooImpl object. This is one way to provide a back door without >>> compromising the core API itself to do it. This puts the >>> responsibility of breaking platform independence on the developers >>> and not on the designers. >> Yes, that may be a good way to do it. > > The J2ME connector architecture is an example of a place where this is done. It's how I debugged my javax.usb implementations. Paul From Pawan.Kharbanda at dot.state.co.us Tue Jul 25 14:02:53 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 25 Jul 2006 14:02:53 -0600 Subject: [Rxtx] Strange error (show stopper) Message-ID: <939A619A756047469C41EE9BA51890FB0429DFA4@hqexchange3.dot.state.co.us> Joachim, I believe it's the same problem that I reported earlier (Thread deadlocks/Locked Ports), I am not a C person so don't know exactly whatz going in the native code but was able to find a workaround for right now by synchronizing the "interruptEventLoop" and "eventLoop" methods in the RXTXPort class. It helped but is not the right solution, I still find the deadlocks but not as often as I used too. A fix for this will be highly appreciated. I have some Test Classes that I have posted earlier to simulate the problem. ~pk -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Joachim Buechse Sent: Monday, July 24, 2006 2:13 AM To: RXTX Developers and Users Subject: Re: [Rxtx] Strange error (show stopper) The pthread_kill is followed by a sleep. When the sleep returns the structure is damaged. I did not find the source that overwrites the closing field - it is correctly set by the exiting drain thread. But something overwrites it afterwards. I currently believe that this existed for some time but was never seen because the previous versions did not rely on the structure to be in good shape when tearing down connections. However I may be completely wrong and it is an OSX problem. To help me find the source, it would be nice to get some indications what the 2 debug lines I suggested return on other platforms. Joachim On 24.07.2006, at 05:27, Trent Jarvi wrote: > On Sat, 22 Jul 2006, Joachim Buechse wrote: > >> I just discovered a strange error in RXTX on OSX. SerialDemo.java >> manages to corrupt the event_info_structure by a simple >> OpenPort,ClosePort - this could be in relation to the deadlock >> problem that was reported recently. >> >> Could anyone try to reproduce this on Solaris or some other system >> which is neither WIN32 nor Linux (ie which uses a drain thread). >> >> In SerialImp.c : RXTXPort(interruptEventLoop) >> >> Apparently the event_info_structure gets corrupted shortly after >> >> pthread_kill(index->drain_tid, SIGABRT); >> >> In particular, the index->closing flag gets overwritten by a pointer >> value. > > Hi Joachim > > Interesting. I did run many tests with that code on may OSs. To be > fair, the tests are just starting to get into good shape again. I'm > still tagging releases with a bit of feel and not enough process. > I'll look at this some more tomorrow night. > > The SIGABRT was added recently as part of the close speedups. > Thats from > memory. I can provide the exact patch that introduced that tomorrow. > > -- > Trent Jarvi > tjarvi at qbang.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Jul 25 17:42:23 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 18:42:23 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153840929.44c6372186f67@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> Message-ID: <44C6AC5F.3060107@cox.net> Guillermo Rodriguez wrote: > The problem with this is that there is no guarantee that a single call > to the write method of the OutputStream associated with a javax.comm > SerialPort will translate to a single write to the underlying device > driver -- this depends on the javax.comm implementation. More specifically, it depends on a software layer that would targeted specifically at solving this problem for RS-485 and other transports which have blocking or packetizing issues. There are many. In amatuer radio, we have TNCs (radio modems) which will block things using newline separators in some modes, and 0xc0 in others. Gregg Wonderly From gergg at cox.net Tue Jul 25 17:46:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 18:46:11 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C63A37.8080406@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> <44C60EB9.5000803@gmail.com> <44C63A37.8080406@sun.com> Message-ID: <44C6AD43.1090302@cox.net> Paul Klissner wrote: > Also that would imply two downloads to install any given > bus support, which might not be the end of the world. > And maybe two JSRs? Why are we hovering around this "downloads" issue? If we create a JSR that covers everything needed for javax.comm compatibility, does that still imply that it would be an unincluded, optional part of the JVM? If that is still something that people will tolerate, I'm a little lost for words. Still today, I can use the old javax.comm support. If we're just going to recreate the same concerns, issues and limitations, then what's the point? Gregg Wonderly From gergg at cox.net Tue Jul 25 17:48:42 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 18:48:42 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <00c801c6b000$33a68f00$0c28a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <44C6ADDA.5040208@cox.net> Martin Schoeberl wrote: > I completely agree - it's still a stream and not a packet. > > This is similar to a single write to a TCP/IP socket. There > is no guarantee that you get this data as a single packet/single > read on the other side. However, I've seen a lot of programs > assuming that this happens ;-) For nearly forever, serialport drivers have operated in the mode that they send either everything up to the divider char, or a single char. This was specifically done for protocols such as modbus which have 1 1/2 bit time delays indicating end of packet. This kind of thing is something that needs to be maintained for serial protocols to work. A user has to have a way to send a single "packet" of data and make sure that it flows out of the uart uninterrupted. Gregg Wonderly From gergg at cox.net Tue Jul 25 18:03:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 19:03:11 -0500 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <939A619A756047469C41EE9BA51890FB0429DFA4@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB0429DFA4@hqexchange3.dot.state.co.us> Message-ID: <44C6B13F.1000306@cox.net> Kharbanda, Pawan wrote: > Joachim, > I believe it's the same problem that I reported earlier (Thread > deadlocks/Locked Ports), I am not a C person so don't know exactly whatz > going in the native code but was able to find a workaround for right now > by synchronizing the "interruptEventLoop" and "eventLoop" methods in the > RXTXPort class. It helped but is not the right solution, I still find > the deadlocks but not as often as I used too. > > A fix for this will be highly appreciated. I have some Test Classes that > I have posted earlier to simulate the problem. You can send SIGQUIT (signal #3) to unix JVMs to get a stacktrace of where all the threads are at and who owns what locks. Also, on windows, you can run the JVM in a DOS window and use CTRL-BREAK to get the stack trace. This won't go beyond the native level, but it might expose what you need to know. Gregg Wonderly From tjarvi at qbang.org Tue Jul 25 22:21:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 22:21:22 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6AC5F.3060107@cox.net> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: On Tue, 25 Jul 2006, Gregg Wonderly wrote: > Guillermo Rodriguez wrote: >> The problem with this is that there is no guarantee that a single call >> to the write method of the OutputStream associated with a javax.comm >> SerialPort will translate to a single write to the underlying device >> driver -- this depends on the javax.comm implementation. > > More specifically, it depends on a software layer that would targeted > specifically at solving this problem for RS-485 and other transports which have > blocking or packetizing issues. There are many. In amatuer radio, we have TNCs > (radio modems) which will block things using newline separators in some modes, > and 0xc0 in others. > I had looked into RS-485 some. It is daunting without proper hardware. One option is to do a native local tcpip/udp server to remove most of the the 'java issues.' Realtime patches comming down the pipe make it tempting to jump into the tarpit of failures. Beyond that, we should be very explicit about what type of RS-485 hardware we do support and it should not involve things that we have to control DTR/RTS in almost realtime (<20 ms). There are going to be people wanting < $5/EURO winmodem type solutions that will be nothing but problems. Thats doable by hacking kernel drivers but it will never get into mainstream kernels. I do not think thats reasonable from java and is even questionable in typical C. It will work fine until you start oracle... It would be nice to get RS-485 support in. Things like controlling low cost devices in houses, ... But cutting out the hardware isn't a viable solution in java. -- Trent Jarvi tjarvi From tjarvi at qbang.org Tue Jul 25 22:40:36 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 22:40:36 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6AD43.1090302@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> <44C60EB9.5000803@gmail.com> <44C63A37.8080406@sun.com> <44C6AD43.1090302@cox.net> Message-ID: On Tue, 25 Jul 2006, Gregg Wonderly wrote: > Paul Klissner wrote: >> Also that would imply two downloads to install any given >> bus support, which might not be the end of the world. >> And maybe two JSRs? > > Why are we hovering around this "downloads" issue? If we create a JSR that > covers everything needed for javax.comm compatibility, does that still imply > that it would be an unincluded, optional part of the JVM? If that is still > something that people will tolerate, I'm a little lost for words. Still today, > I can use the old javax.comm support. If we're just going to recreate the same > concerns, issues and limitations, then what's the point? > I don't have a problem with Sun shipping rxtx or whatever it becomes. They may have some legacy issues :) Just poking fun. The current state does not work for java users. Not having w32 support means about 80+% of the users do not have support. The rxtx w32 support is heavily influenced by cygwin so it wont change license out of respect for that project. If you really hate life and the LGPL, you can do a w32 port and the rest will just fall into place while you chase windows bugs for 5 years. Anything that dances around w32 support is just an academic waste of time. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Tue Jul 25 22:41:21 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 23:41:21 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: <44C6F271.2020604@cox.net> Trent Jarvi wrote: > I had looked into RS-485 some. It is daunting without proper hardware. > One option is to do a native local tcpip/udp server to remove most of the > the 'java issues.' Realtime patches comming down the pipe make it tempting > to jump into the tarpit of failures. Trent, there is not a way for a non-realtime OS to drive 485 hardware without the hardware taking care of the timing issues. But, a non-realtime OS can support software APIs which let the developer express in an API the types of things that a piece of hardware is capable of. Then we can have an API, and the hardware people and the OS people will provide the solutions where possible. > It would be nice to get RS-485 support in. Things like controlling > low cost devices in houses, ... But cutting out the hardware isn't a > viable solution in java. The 485 hardware devices will have to have non-realtime requirements associated with the controlling mechanisms. There are some of those. I'm mostly interested in having a 485 API for realtime java and/or the aJile and other uC environments which can provide realtime environments. Gregg Wonderly From tjarvi at qbang.org Tue Jul 25 22:54:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 22:54:44 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6F271.2020604@cox.net> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <44C6F271.2020604@cox.net> Message-ID: On Tue, 25 Jul 2006, Gregg Wonderly wrote: > Trent Jarvi wrote: >> I had looked into RS-485 some. It is daunting without proper hardware. >> One option is to do a native local tcpip/udp server to remove most of the >> the 'java issues.' Realtime patches comming down the pipe make it tempting >> to jump into the tarpit of failures. > > Trent, there is not a way for a non-realtime OS to drive 485 hardware without > the hardware taking care of the timing issues. But, a non-realtime OS can > support software APIs which let the developer express in an API the types of > things that a piece of hardware is capable of. Then we can have an API, and the > hardware people and the OS people will provide the solutions where possible. > >> It would be nice to get RS-485 support in. Things like controlling >> low cost devices in houses, ... But cutting out the hardware isn't a >> viable solution in java. > > The 485 hardware devices will have to have non-realtime requirements associated > with the controlling mechanisms. There are some of those. I'm mostly > interested in having a 485 API for realtime java and/or the aJile and other uC > environments which can provide realtime environments. > Hi Gregg I do not disagree with you but I have a problem with this (realtime java and/or the aJile and other Uc environements) being something I may be hearing bugs about 5 years from now. Is this really something that should be in the API or is it something that would make a nice niche market for support and services? Do the two really go together? If you like that market and I think there is a niche market there, great. This is a good area for SPI type interfaces where you could support it but it was not provided by default. -- Trent Jarvi tjarvi at qbang.org From guille at sms.nl Wed Jul 26 00:39:47 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 08:39:47 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C672EA.1080604@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> Message-ID: <7.0.1.0.0.20060726083751.03633188@sms.nl> At 21:37 25/07/2006, Gregg Wonderly wrote: >Guillermo Rodriguez Garcia wrote: > > At 11:25 25/07/2006, Martin Schoeberl wrote: > >>Mmh, perhaps in a similar way as you configure timeouts? > >>Isn't this 'just' a timeout value? > > > > Yes, but this is just a specific parameter that you can configure in a > > specific type of UART (an EXAR UART). Other UARTs might be different. The > > point I'm trying to make is that there are just too many parameters to > > have an API for each specific case. > >In my earlier example/proposal, I included the ability for >attributes of a port >to be expressed as a collection of enumeration values for standard >things. That >would be fine for simple things like Input, Output, Sync, Async >etc. When there >are specific attributes of specific hardware, the vendor is going to have to >provide a way to configure those attributes. One of the primary >mechanisms in >Java to do this is the JavaBean pattern that can be manifested in a Map type >object when an API needs to preexist. So, we can provide an mechanism for >propagating random attributes using a Map argument to a method such as > >public void setConfig( Map params ) throws IOException; >public Map getConfig() throws IOException; > >Then, there is a conduit in and out of the driver that the user can >use without >needing more standards/spec'd code/API. > >This isn't much different than an ioctl(2) like mechanism, This is exactly what I was thinking while reading your mail :) >but it feels more Java like. It would do the job as well and I would be happy with that. However Paul's proposal where implementation classes extend the core API as necessary might be more elegant (for the same reason that it is more elegant than ioctl) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Wed Jul 26 00:41:40 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 08:41:40 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6AC5F.3060107@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: <7.0.1.0.0.20060726084016.03633040@sms.nl> At 01:42 26/07/2006, Gregg Wonderly wrote: >Guillermo Rodriguez wrote: > > The problem with this is that there is no guarantee that a single call > > to the write method of the OutputStream associated with a javax.comm > > SerialPort will translate to a single write to the underlying device > > driver -- this depends on the javax.comm implementation. > >More specifically, it depends on a software layer that would targeted >specifically at solving this problem for RS-485 and other transports >which have >blocking or packetizing issues. There are many. In amatuer radio, >we have TNCs >(radio modems) which will block things using newline separators in >some modes, >and 0xc0 in others. Right. I meant that in general one cannot assume that writes to a stream will translate 1:1 to writes in every layer of the protocol stack (this is most often not the case.) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Wed Jul 26 00:44:57 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 08:44:57 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6ADDA.5040208@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> <44C6ADDA.5040208@cox.net> Message-ID: <7.0.1.0.0.20060726084203.036cd2b8@sms.nl> At 01:48 26/07/2006, Gregg Wonderly wrote: >Martin Schoeberl wrote: > > I completely agree - it's still a stream and not a packet. > > > > This is similar to a single write to a TCP/IP socket. There > > is no guarantee that you get this data as a single packet/single > > read on the other side. However, I've seen a lot of programs > > assuming that this happens ;-) > >For nearly forever, serialport drivers have operated in the mode >that they send >either everything up to the divider char, or a single char. This was >specifically done for protocols such as modbus which have 1 1/2 bit >time delays >indicating end of packet. This kind of thing is something that needs to be >maintained for serial protocols to work. A user has to have a way to send a >single "packet" of data and make sure that it flows out of the uart >uninterrupted. Even that is sometimes difficult to achieve. If the whole packet does not fit in the UART FIFOs, then the driver may have a hard time making sure that all of the data flows out uninterrupted, unless 1/ you have a RTOS with a response time that is fast enough to refill the FIFO before it empties, and/or 2/ you can tolerate a 'stop the world' approach where ints are globally disabled while the packet is being sent (not nice) (just a side comment) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From tjarvi at qbang.org Wed Jul 26 00:48:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 26 Jul 2006 00:48:29 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060726084016.03633040@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <7.0.1.0.0.20060726084016.03633040@sms.nl> Message-ID: On Wed, 26 Jul 2006, Guillermo Rodriguez Garcia wrote: > At 01:42 26/07/2006, Gregg Wonderly wrote: >> Guillermo Rodriguez wrote: >>> The problem with this is that there is no guarantee that a single call >>> to the write method of the OutputStream associated with a javax.comm >>> SerialPort will translate to a single write to the underlying device >>> driver -- this depends on the javax.comm implementation. >> >> More specifically, it depends on a software layer that would targeted >> specifically at solving this problem for RS-485 and other transports >> which have >> blocking or packetizing issues. There are many. In amatuer radio, >> we have TNCs >> (radio modems) which will block things using newline separators in >> some modes, >> and 0xc0 in others. > > Right. I meant that in general one cannot assume that writes to a stream > will translate 1:1 to writes in every layer of the protocol stack (this is > most often not the case.) > Hi Guillermo This sounds like a dead end to me. People using commapi want a a write, an interrupt and data. The kernel being a big problem these days. There are _much_ better ways to do things like protocol stacks. This is not how EIA232 works in the real world. -- Trent Jarvi tjarvi From guille at sms.nl Wed Jul 26 01:02:09 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 09:02:09 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <7.0.1.0.0.20060726084016.03633040@sms.nl> Message-ID: <7.0.1.0.0.20060726090154.036dd708@sms.nl> At 08:48 26/07/2006, Trent Jarvi wrote: >On Wed, 26 Jul 2006, Guillermo Rodriguez Garcia wrote: > > > At 01:42 26/07/2006, Gregg Wonderly wrote: > >> Guillermo Rodriguez wrote: > >>> The problem with this is that there is no guarantee that a single call > >>> to the write method of the OutputStream associated with a javax.comm > >>> SerialPort will translate to a single write to the underlying device > >>> driver -- this depends on the javax.comm implementation. > >> > >> More specifically, it depends on a software layer that would targeted > >> specifically at solving this problem for RS-485 and other transports > >> which have > >> blocking or packetizing issues. There are many. In amatuer radio, > >> we have TNCs > >> (radio modems) which will block things using newline separators in > >> some modes, > >> and 0xc0 in others. > > > > Right. I meant that in general one cannot assume that writes to a stream > > will translate 1:1 to writes in every layer of the protocol stack (this is > > most often not the case.) > > > >Hi Guillermo > >This sounds like a dead end to me. People using commapi want a a write, >an interrupt and data. The kernel being a big problem these days. > >There are _much_ better ways to do things like protocol stacks. This is >not how EIA232 works in the real world. Yes, this is exactly what I'm saying. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From Luis.Moreira at jet.uk Wed Jul 26 01:34:42 2006 From: Luis.Moreira at jet.uk (Luis Moreira) Date: Wed, 26 Jul 2006 08:34:42 +0100 Subject: [Rxtx] Portability Message-ID: Hi Guys, I managed to get the RXTX package to work on my PC, but the question is, if I need to distribute my program to someone that does not know much about java how do I get the program to work on their System? Best regards Luis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/3e3c2058/attachment-0338.html From joachim at buechse.de Wed Jul 26 02:18:19 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 26 Jul 2006 10:18:19 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <44C667EC.2070602@ergotech.com> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> <44C667EC.2070602@ergotech.com> Message-ID: I may not have been very clear with my suggestion: The "mandatory" flush after write was only regarding RS485. If an application does not use flush after write (today), it is damned to fail anyway. The Outputstream interface makes no guarentee what so ever, that any data will be writen before you call flush. So in fact flush is already mandatory unless you dont care if your data is ever transmitted. I don't see how sending on flush for RS485 would be less efficient. If you are concerned about the additional function call you may want to specify on which platform/VM you are working. A function call in java even on slow PCs is in the microsecond range. So if your concern is, that writes should be forwarded as soon as possible, well then follow any write by a flush. I haven't done any JavaME serial programming, but from my experience with implementing Ymodem over RS232+USB, all I can say is this: Either you have your data ready when it is demanded and you can write it with a single write(+flush) or your application will be slow. So yes, you need to get data on the wire as quick as possible, the solutions are manyfold but an additional (flush) function call will hardly make your application slower. Regards, Joachim On 25.07.2006, at 20:50, Jim Redman wrote: > The horror! This would be terribly inefficient. Especially in serial > protocols you need to start getting bits on the wire as soon as > possible. It could also have some timeout implications. > > Jim > > Joachim Buechse wrote: >> Just trigger writing on flush(). It is perfectly legal for an >> Outputstream implementation to do do nothing until flush is called >> and the documentation of OutputStream.flush reads: >> >> "Flushes this output stream and forces any buffered output bytes to >> be written out. The general contract of flush is that calling it is >> an indication that, if any bytes previously written have been >> buffered by the implementation of the output stream, such bytes >> should immediately be written to their intended destination." >> >> As RS485 is a "dont speak up unless requested" protocol, a mandatory >> flush after write seems like the way to go to me >> >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). >> >> Regards, >> Joachim >> >> PS: It is great to see all the motivation that is brought forward on >> this list regarding the future. It would be great if only 10% of that >> motivation could be transformed into a cleanup and extension of the >> existing code. The current code access model seems rather >> inappropriate for the prototyping of the ideas beeing presented. >> Trent can we get a "contributions" branch with "free" access. >> >> >> On 25.07.2006, at 17:37, Martin Schoeberl wrote: >> >>>>> Martin Schoeberl wrote: >>>>>> We can model it platform independent with two methods: >>>>>> >>>>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>>>> on the underlying platform to switch to RS485 transmit mode and >>>>>> back. >>>>> Or, do what is typically done, and use a single write operation >>>>> as the >>>>> indication of a 'packet' that will let the underlying RS-485/422 >>>>> driver >>>>> assert >>>>> the appropriate signalling. >>>> The problem with this is that there is no guarantee that a single >>>> call >>>> to the write method of the OutputStream associated with a >>>> javax.comm >>>> SerialPort will translate to a single write to the underlying >>>> device >>>> driver -- this depends on the javax.comm implementation. >>>> >>> I completely agree - it's still a stream and not a packet. >>> >>> This is similar to a single write to a TCP/IP socket. There >>> is no guarantee that you get this data as a single packet/single >>> read on the other side. However, I've seen a lot of programs >>> assuming that this happens ;-) >>> >>> Martin >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Jul 26 04:28:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 26 Jul 2006 06:28:33 -0400 Subject: [Rxtx] Should we defer JSR support of RS485? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: Hi All, Would it make sense to focus the JSR on rock solid serial and parallel port support? Can the RS485 people live with unofficial support, at least until we get the JSR accepted and the implementation rock solid? Thanks! - Doug From gergg at cox.net Wed Jul 26 08:49:21 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 26 Jul 2006 09:49:21 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <44C6F271.2020604@cox.net> Message-ID: <44C780F1.8020506@cox.net> Trent Jarvi wrote: > I do not disagree with you but I have a problem with this (realtime java > and/or the aJile and other Uc environements) being something I may be > hearing bugs about 5 years from now. Is this really something that should > be in the API or is it something that would make a nice niche market for > support and services? Do the two really go together? The question is whether there needs to be two, three or five ways to do the same thing, or can we distill it down to one so that software working in one environment can work in all. > If you like that market and I think there is a niche market there, great. > This is a good area for SPI type interfaces where you could support it but > it was not provided by default. SPI is supported natively on the aJile processors. Systronix provides an API for using the SPI lines defined for that use. Adding extra slave selects is not part of their API. There are plenty of places where this stuff is getting used. In the C world of uC, there are 500 ways to do the same thing because everyone wants to be as close to the hardware as possible. The trumpet of the Java platform proclaims write once, run anywhere. Thats been a powerful impetus to me and others to use the language. I really do appreciate that I don't have to think about non-application related programming tasks as much as I did in C and C++. It's possible to pick a reasonable level of abstraction that provide opportunity to expand in the future while accounting for the small in the present. But, we have to all get together with a desire to accomplish this, have good constructive conversation and feedback, and get it done. Gregg Wonderly From gergg at cox.net Wed Jul 26 08:56:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 26 Jul 2006 09:56:11 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060726083751.03633188@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> Message-ID: <44C7828B.7040904@cox.net> Guillermo Rodriguez Garcia wrote: > It would do the job as well and I would be happy with that. However > Paul's proposal where implementation classes extend the core API as > necessary might be more elegant (for the same reason that it is more > elegant than ioctl) Right, but my argument was that this demanded that the classes preexist at the time I am writing the software. I have to be able to compile against them. The Map mechanism would allow me to write software that worked with any hardware. The person deploying my software into their environment with their hardware would then just provide a set of configuration values that my software would pass into the API. That's the point I'm trying to make. I'm on the fence about a Map vs a subclass with methods. I can see it both ways. But, as a JDBC user, I've learned to appreciate a single API with Properties passed in. As a Jini user I've learned to appreciate the Configuration mechanisms that Jini 2.x has. I can write code in my configuration file to instantiate and configure the system at deployment time! Gregg Wonderly From joachim at buechse.de Wed Jul 26 09:37:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 26 Jul 2006 17:37:27 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C7828B.7040904@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> <44C7828B.7040904@cox.net> Message-ID: <08E356DB-AC3F-46FC-952B-82D5ABB15926@buechse.de> Unless you are working with J2ME, you can just as well do what you describe using reflection (ie a JavaBean strategy). A Map can change at runtime, an interface can not. Regards, Joachim On 26.07.2006, at 16:56, Gregg Wonderly wrote: > Guillermo Rodriguez Garcia wrote: >> It would do the job as well and I would be happy with that. However >> Paul's proposal where implementation classes extend the core API as >> necessary might be more elegant (for the same reason that it is more >> elegant than ioctl) > > Right, but my argument was that this demanded that the classes > preexist at the > time I am writing the software. I have to be able to compile > against them. > > The Map mechanism would allow me to write software that worked with > any > hardware. The person deploying my software into their environment > with their > hardware would then just provide a set of configuration values that > my software > would pass into the API. > > That's the point I'm trying to make. I'm on the fence about a Map > vs a subclass > with methods. I can see it both ways. But, as a JDBC user, I've > learned to > appreciate a single API with Properties passed in. As a Jini user > I've learned > to appreciate the Configuration mechanisms that Jini 2.x has. I > can write code > in my configuration file to instantiate and configure the system at > deployment > time! > > config/ConfigurationFile.html> > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Paul.Klissner at Sun.COM Wed Jul 26 12:11:37 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 26 Jul 2006 11:11:37 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C780F1.8020506@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <44C6F271.2020604@cox.net> <44C780F1.8020506@cox.net> Message-ID: <44C7B059.1060302@sun.com> Gregg Wonderly wrote: > Trent Jarvi wrote: >> I do not disagree with you but I have a problem with this (realtime java >> and/or the aJile and other Uc environements) being something I may be >> hearing bugs about 5 years from now. Is this really something that should >> be in the API or is it something that would make a nice niche market for >> support and services? Do the two really go together? > > The question is whether there needs to be two, three or five ways to do the same > thing, or can we distill it down to one so that software working in one > environment can work in all. > >> If you like that market and I think there is a niche market there, great. >> This is a good area for SPI type interfaces where you could support it but >> it was not provided by default. > > SPI is supported natively on the aJile processors. Systronix provides an API > for using the SPI lines defined for that use. Adding extra slave selects is not > part of their API. > > There are plenty of places where this stuff is getting used. In the C world of > uC, there are 500 ways to do the same thing because everyone wants to be as > close to the hardware as possible. > > The trumpet of the Java platform proclaims write once, run anywhere. Thats been > a powerful impetus to me and others to use the language. I really do appreciate > that I don't have to think about non-application related programming tasks as > much as I did in C and C++. > > It's possible to pick a reasonable level of abstraction that provide opportunity > to expand in the future while accounting for the small in the present. > > But, we have to all get together with a desire to accomplish this, have good > constructive conversation and feedback, and get it done. I agree that whatever approach we take should involve settling on the scope and then seeking to create a reasonably complete set of abstractions to generalize and make platform independent, and then refine that list as corner cases appear. For whichever bus(ses) we support, it will be standards-based functionality we're trying to support, with device-specific functionality hidden in the driver and not passed through as direct driver-oriented commands via the API. Paul > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Paul.Klissner at Sun.COM Wed Jul 26 12:23:56 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 26 Jul 2006 11:23:56 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C7828B.7040904@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> <44C7828B.7040904@cox.net> Message-ID: <44C7B33C.8090005@sun.com> Gregg Wonderly wrote: > Guillermo Rodriguez Garcia wrote: >> It would do the job as well and I would be happy with that. However >> Paul's proposal where implementation classes extend the core API as >> necessary might be more elegant (for the same reason that it is more >> elegant than ioctl) > > Right, but my argument was that this demanded that the classes preexist at the > time I am writing the software. I have to be able to compile against them. > > The Map mechanism would allow me to write software that worked with any > hardware. The person deploying my software into their environment with their > hardware would then just provide a set of configuration values that my software > would pass into the API. > > That's the point I'm trying to make. I'm on the fence about a Map vs a subclass > with methods. I can see it both ways. But, as a JDBC user, I've learned to > appreciate a single API with Properties passed in. As a Jini user I've learned > to appreciate the Configuration mechanisms that Jini 2.x has. I can write code > in my configuration file to instantiate and configure the system at deployment > time! I don't think this is a problem as long as the implementation specific stuff is handled by controlling through vehicles outside the API. The application code layered over the API should be written such that it can run on any platform and with any generic device of the class the API claims to support. The problem with the ioctl is it's proneness for abuse and invitation to proliferate the space with non-portable applications. If the implementation requires a configuration file to be passed through the API then the application can run on platform A, B and C, which all have the same type of device, fine, and then with a different configuration file, could run on D, E and F with other hardware, that seems reasonable. What if there are multiple devices on a system of different types? There needs to be a way to get the right configuration file to associate with the right device, and the application should seamlessly work with either. The application code layered over the API should not have to be aware of the configuration file or the programmatic peculiarities of the underlying hardware. Paul From joachim at buechse.de Wed Jul 26 12:59:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 26 Jul 2006 20:59:06 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C7B33C.8090005@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> <44C7828B.7040904@cox.net> <44C7B33C.8090005@sun.com> Message-ID: <1A34B6D0-43B2-4F73-A39F-004B3D100CE9@buechse.de> Paul honestly I think you are to extreme - Often enough a USER is very well capable of indentifying which "config file" needs to be choosen to set up the device he owns. This file can be accepted from the application as a "configuration parameter" and passed on to the driver. One very typical example are AT-command sequences. Terminal programs know nothing about their meaning - still they happily pass them on to do their magic. Best regards, Joachim On 26.07.2006, at 20:23, Paul Klissner wrote: > Gregg Wonderly wrote: >> Guillermo Rodriguez Garcia wrote: >>> It would do the job as well and I would be happy with that. However >>> Paul's proposal where implementation classes extend the core API as >>> necessary might be more elegant (for the same reason that it is more >>> elegant than ioctl) >> >> Right, but my argument was that this demanded that the classes >> preexist at the >> time I am writing the software. I have to be able to compile >> against them. >> >> The Map mechanism would allow me to write software that worked >> with any >> hardware. The person deploying my software into their environment >> with their >> hardware would then just provide a set of configuration values >> that my software >> would pass into the API. >> >> That's the point I'm trying to make. I'm on the fence about a Map >> vs a subclass >> with methods. I can see it both ways. But, as a JDBC user, I've >> learned to >> appreciate a single API with Properties passed in. As a Jini user >> I've learned >> to appreciate the Configuration mechanisms that Jini 2.x has. I >> can write code >> in my configuration file to instantiate and configure the system >> at deployment >> time! > > I don't think this is a problem as long as the implementation specific > stuff is handled by controlling through vehicles outside the API. > The application code layered over the API should be written such that > it can run on any platform and with any generic device of the class > the API claims to support. > > The problem with the ioctl is it's proneness for abuse and invitation > to proliferate the space with non-portable applications. > > If the implementation requires a configuration file to be passed > through > the API then the application can run on platform A, B and C, which all > have the same type of device, fine, and then with a different > configuration > file, could run on D, E and F with other hardware, that seems > reasonable. > > What if there are multiple devices on a system of different types? > There needs to be a way to get the right configuration file to > associate > with the right device, and the application should seamlessly work > with either. > The application code layered over the API should not have to be aware > of the configuration file or the programmatic peculiarities of the > underlying hardware. > > Paul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From savagobr at yahoo.com Wed Jul 26 13:15:13 2006 From: savagobr at yahoo.com (Adenilson Cavalcanti) Date: Wed, 26 Jul 2006 12:15:13 -0700 (PDT) Subject: [Rxtx] Strange error (show stopper) - Fedora Core 5 is ok! Message-ID: <20060726191513.28407.qmail@web53802.mail.yahoo.com> Dear Joachim Buechse I'm pretty new to this list (actually, first post) but got curious about the issue that you reported. If a undertood the code correctly, SerialImp.c -> interruptEventLoop only calls pthread_kill when compiled for MacOSX. Anyway, I changed the code to print field values of structure object 'index' and got this results: 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 CLOSING=0 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 CLOSING=1 Which I think seems to be o.k. (I must also comment that I'm running FC5, kernel 2.6.15, gcc 4.1.1, jdk 1.5.0_06). Bellow you will find where in source code I printed the debug information. I was wondering why in Linux is not necessary to call pthread_kill (of course I did read the comments about "output buffer empty" but don't get it...). Any comments? Best regards Savago //---------------------------------------------------------------------------------------------- Changed code. //---------------------------------------------------------------------------------------------- /** XXX: DEBUG INFO*/ snprintf(message, sizeof(message), "1 interrupted thread for FD=%i PTR=%i CLOSING=%i\n", index->fd, index, index->closing ); report(message); #ifdef TIOCSERGETLSR index->closing=1; #endif /* TIOCSERGETLSR */ #ifdef WIN32 termios_interrupt_event_loop( index->fd, 1 ); #endif /* WIN32 */ #if !defined(TIOCSERGETLSR) && !defined(WIN32) . . . #endif /** XXX: DEBUG INFO*/ snprintf(message, sizeof(message), "2 interrupted thread for FD=%i PTR=%i CLOSING=%i\n", index->fd, index, index->closing ); report(message); report("interruptEventLoop: interrupted\n"); //---------------------------------------------------------------------------------------------- OUTPUT: 15:00:24:******* report_serial_events: sending DATA_AVAILABLE 15:00:24:******* reporting data available 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 CLOSING=0 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 CLOSING=1 15:00:24:******* interruptEventLoop: interrupted 15:00:24:******* eventLoop: got interrupt 15:00:24:******* setDTR( 0 ) 15:00:24:******* setDSR( 0 ) 15:00:24:******* >nativeClose pid 15:00:24:******* nativeClose: pid 15:00:24:******* nativeClose: discarding remaining datai (tcflush) 15:00:24:******* nativeClose: calling close 15:00:24:******* fhs_unlock: Removing LockFile 15:00:24:******* nativeClose: Delete jclazz 15:00:24:******* nativeClose: release filename 15:00:24:******* fhs_unlock: Removing LockFile //---------------------------------------------------------------------------------------------- --------------------------------- How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone call rates. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/ad116f14/attachment-0337.html From savagobr at yahoo.com Wed Jul 26 13:23:05 2006 From: savagobr at yahoo.com (Adenilson Cavalcanti) Date: Wed, 26 Jul 2006 12:23:05 -0700 (PDT) Subject: [Rxtx] Locked ports - to Kharbanda Message-ID: <20060726192305.23957.qmail@web53807.mail.yahoo.com> Dear Kharbanda I'm trying to reproduce the bug that you reported (the deadlock one) but dont get it. What I did was write a java app that continuously open/close a port (/dev/ttyS0) within 1 second for this operation. The program keeps running fine, no lock until now. I'm wondering if you could send me a sample app that could help me to reproduce this bug? Best regards Savago --------------------------------- Yahoo! Music Unlimited - Access over 1 million songs.Try it free. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/c56bc64a/attachment-0337.html From Pawan.Kharbanda at dot.state.co.us Wed Jul 26 13:41:13 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Wed, 26 Jul 2006 13:41:13 -0600 Subject: [Rxtx] Locked ports - to Kharbanda Message-ID: <939A619A756047469C41EE9BA51890FB0429E08B@hqexchange3.dot.state.co.us> Savago, I have attached the Test class that i wrote to replicate the locking/threading problem with RXTX in Redhat Linux. Please follow the following instructions to replicate the problem. I don't know if you will be able to replicate using one Serial port or not, i was able to reproduced it using 3 or 4 ports constantly. Instructions: In the TestOpenClosePort.java please change the Serial Ports names(Add the ports installed on your machine). Then compile your java file and run as "java TestOpenClosePort 100" (100 is the no of times you want to open and close the port in one single thread). I have tested this with the Digi Boxes and able to replicate this over and over in Single JVM. Thanks ~pk ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Adenilson Cavalcanti Sent: Wednesday, July 26, 2006 1:23 PM To: rxtx at qbang.org Subject: [Rxtx] Locked ports - to Kharbanda Dear Kharbanda I'm trying to reproduce the bug that you reported (the deadlock one) but dont get it. What I did was write a java app that continuously open/close a port (/dev/ttyS0) within 1 second for this operation. The program keeps running fine, no lock until now. I'm wondering if you could send me a sample app that could help me to reproduce this bug? Best regards Savago ________________________________ Yahoo! Music Unlimited - Access over 1 million songs. Try it free. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/c581de54/attachment-0337.html -------------- next part -------------- A non-text attachment was scrubbed... Name: TestOpenClosePort.java Type: application/octet-stream Size: 6038 bytes Desc: TestOpenClosePort.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/c581de54/TestOpenClosePort-0337.obj From joachim at buechse.de Wed Jul 26 16:01:31 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 27 Jul 2006 00:01:31 +0200 Subject: [Rxtx] Strange error (show stopper) - Fedora Core 5 is ok! In-Reply-To: <20060726191513.28407.qmail@web53802.mail.yahoo.com> References: <20060726191513.28407.qmail@web53802.mail.yahoo.com> Message-ID: Linux offers a feature (TIOCSERGETLSR) that allows to check if all data has been sent. This feature does not exist on OSX, BSD, Solaris and probably some other systems. For these systems RXTX uses a separate thread that calls tc_drain() - on return of this call all data has been written. The pthread_kill is used to guarantee that the drain thread has been canceled. On Linux there is no forced "wait" between the setting of the "closing" flag and the end of the procedure. The test should to be done on a BSD or Solaris system. But maybe you could add a usleep (50000) just before the second sprintf. This might in fact be helpful to see if the problem exists on Linux as well. Thanks, Joachim On 26.07.2006, at 21:15, Adenilson Cavalcanti wrote: > Dear Joachim Buechse > > I'm pretty new to this list (actually, first post) but got curious > about the issue that you reported. > > If a undertood the code correctly, SerialImp.c -> > interruptEventLoop only calls pthread_kill when compiled for MacOSX. > > Anyway, I changed the code to print field values of structure > object 'index' and got this results: > > 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 > CLOSING=0 > 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 > CLOSING=1 > > Which I think seems to be o.k. (I must also comment that I'm > running FC5, kernel 2.6.15, gcc 4.1.1, jdk 1.5.0_06). > > Bellow you will find where in source code I printed the debug > information. > > I was wondering why in Linux is not necessary to call pthread_kill > (of course I did read the comments about "output buffer empty" but > don't get it...). Any comments? > > Best regards > > Savago > > //-------------------------------------------------------------------- > -------------------------- > Changed code. > //-------------------------------------------------------------------- > -------------------------- > /** XXX: DEBUG INFO*/ > snprintf(message, sizeof(message), "1 interrupted thread for FD= > %i PTR=%i CLOSING=%i\n", > index->fd, index, index->closing ); > report(message); > > #ifdef TIOCSERGETLSR > index->closing=1; > #endif /* TIOCSERGETLSR */ > #ifdef WIN32 > termios_interrupt_event_loop( index->fd, 1 ); > #endif /* WIN32 */ > #if !defined(TIOCSERGETLSR) && !defined(WIN32) > . > . > . > #endif > /** XXX: DEBUG INFO*/ > snprintf(message, sizeof(message), "2 interrupted thread for FD= > %i PTR=%i CLOSING=%i\n", > index->fd, index, index->closing ); > report(message); > > report("interruptEventLoop: interrupted\n"); > > //-------------------------------------------------------------------- > -------------------------- > OUTPUT: > > 15:00:24:******* report_serial_events: sending DATA_AVAILABLE > 15:00:24:******* reporting data available > 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 > CLOSING=0 > 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 > CLOSING=1 > 15:00:24:******* interruptEventLoop: interrupted > 15:00:24:******* eventLoop: got interrupt > 15:00:24:******* setDTR( 0 ) > 15:00:24:******* setDSR( 0 ) > 15:00:24:******* >nativeClose pid > 15:00:24:******* nativeClose: pid > 15:00:24:******* nativeClose: discarding remaining datai (tcflush) > 15:00:24:******* nativeClose: calling close > 15:00:24:******* fhs_unlock: Removing LockFile > 15:00:24:******* nativeClose: Delete jclazz > 15:00:24:******* nativeClose: release filename > 15:00:24:******* fhs_unlock: Removing LockFile > //-------------------------------------------------------------------- > -------------------------- > > How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone > call rates. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jul 26 19:34:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 26 Jul 2006 19:34:11 -0600 (MDT) Subject: [Rxtx] Strange error (show stopper) - Fedora Core 5 is ok! In-Reply-To: References: <20060726191513.28407.qmail@web53802.mail.yahoo.com> Message-ID: It is also possible to undefine TIOCSERGETLSR on Linux. It would be nice if BSD and Solaris made the line status register available but it isn't really a standard. On Thu, 27 Jul 2006, Joachim Buechse wrote: > Linux offers a feature (TIOCSERGETLSR) that allows to check if all > data has been sent. This feature does not exist on OSX, BSD, Solaris > and probably some other systems. For these systems RXTX uses a > separate thread that calls tc_drain() - on return of this call all > data has been written. The pthread_kill is used to guarantee that the > drain thread has been canceled. > > On Linux there is no forced "wait" between the setting of the > "closing" flag and the end of the procedure. The test should to be > done on a BSD or Solaris system. But maybe you could add a usleep > (50000) just before the second sprintf. This might in fact be helpful > to see if the problem exists on Linux as well. > > Thanks, > Joachim > > > On 26.07.2006, at 21:15, Adenilson Cavalcanti wrote: > >> Dear Joachim Buechse >> >> I'm pretty new to this list (actually, first post) but got curious >> about the issue that you reported. >> >> If a undertood the code correctly, SerialImp.c -> >> interruptEventLoop only calls pthread_kill when compiled for MacOSX. >> >> Anyway, I changed the code to print field values of structure >> object 'index' and got this results: >> >> 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 >> CLOSING=0 >> 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 >> CLOSING=1 >> >> Which I think seems to be o.k. (I must also comment that I'm >> running FC5, kernel 2.6.15, gcc 4.1.1, jdk 1.5.0_06). >> >> Bellow you will find where in source code I printed the debug >> information. >> >> I was wondering why in Linux is not necessary to call pthread_kill >> (of course I did read the comments about "output buffer empty" but >> don't get it...). Any comments? >> >> Best regards >> >> Savago >> >> //-------------------------------------------------------------------- >> -------------------------- >> Changed code. >> //-------------------------------------------------------------------- >> -------------------------- >> /** XXX: DEBUG INFO*/ >> snprintf(message, sizeof(message), "1 interrupted thread for FD= >> %i PTR=%i CLOSING=%i\n", >> index->fd, index, index->closing ); >> report(message); >> >> #ifdef TIOCSERGETLSR >> index->closing=1; >> #endif /* TIOCSERGETLSR */ >> #ifdef WIN32 >> termios_interrupt_event_loop( index->fd, 1 ); >> #endif /* WIN32 */ >> #if !defined(TIOCSERGETLSR) && !defined(WIN32) >> . >> . >> . >> #endif >> /** XXX: DEBUG INFO*/ >> snprintf(message, sizeof(message), "2 interrupted thread for FD= >> %i PTR=%i CLOSING=%i\n", >> index->fd, index, index->closing ); >> report(message); >> >> report("interruptEventLoop: interrupted\n"); >> >> //-------------------------------------------------------------------- >> -------------------------- >> OUTPUT: >> >> 15:00:24:******* report_serial_events: sending DATA_AVAILABLE >> 15:00:24:******* reporting data available >> 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 >> CLOSING=0 >> 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 >> CLOSING=1 >> 15:00:24:******* interruptEventLoop: interrupted >> 15:00:24:******* eventLoop: got interrupt >> 15:00:24:******* setDTR( 0 ) >> 15:00:24:******* setDSR( 0 ) >> 15:00:24:******* >nativeClose pid >> 15:00:24:******* nativeClose: pid >> 15:00:24:******* nativeClose: discarding remaining datai (tcflush) >> 15:00:24:******* nativeClose: calling close >> 15:00:24:******* fhs_unlock: Removing LockFile >> 15:00:24:******* nativeClose: Delete jclazz >> 15:00:24:******* nativeClose: release filename >> 15:00:24:******* fhs_unlock: Removing LockFile >> //-------------------------------------------------------------------- >> -------------------------- >> >> How low will we go? Check out Yahoo! Messengers low PC-to-Phone >> call rates. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From guille at sms.nl Thu Jul 27 00:30:47 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 27 Jul 2006 08:30:47 +0200 Subject: [Rxtx] more RS485 (was: Strange error (show stopper) - Fedora Core 5 is ok!) In-Reply-To: References: <20060726191513.28407.qmail@web53802.mail.yahoo.com> Message-ID: <7.0.1.0.0.20060727082321.036f10d0@sms.nl> At 00:01 27/07/2006, Joachim Buechse wrote: >Linux offers a feature (TIOCSERGETLSR) that allows to check if all >data has been sent. Just a side note: This is one of the things that is useful when one needs to control external RS232 to RS485 converters with the RTS or DTR lines. The above lets you look at the transmit shift register to know if/when the last character has been completely shifted out ('transmit shift register empty' is a different thing than 'output FIFO empty' and than 'software output buffer empty'). This is something you currently cannot do from your application using rxtx. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From gergg at cox.net Thu Jul 27 11:08:32 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 27 Jul 2006 12:08:32 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C7B33C.8090005@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> <44C7828B.7040904@cox.net> <44C7B33C.8090005@sun.com> Message-ID: <44C8F310.2040107@cox.net> Paul Klissner wrote: > What if there are multiple devices on a system of different types? > There needs to be a way to get the right configuration file to associate > with the right device, and the application should seamlessly work with either. > The application code layered over the API should not have to be aware > of the configuration file or the programmatic peculiarities of the > underlying hardware. If the configuration mechanism is the standard and must be supported, then every device will have to have such a configuration object. The configuration object would be the per device mechanism with a real API on that object. I'll use the Jini ConfigurationFile syntax here as an example: com2 { driver = "name.of.device.driver.class"; config = new com.deviceco.rs485.Parameters( ... arguments to parameter construction ... ); } then the API would ask for the driver and configuration for device com2, and have all the things needed to make the correct device used with the correct configuration. Gregg Wonderly From fredm at alum.mit.edu Fri Jul 28 04:32:56 2006 From: fredm at alum.mit.edu (Fred G. Martin) Date: Fri, 28 Jul 2006 06:32:56 -0400 Subject: [Rxtx] precompiled for Intel Mac? Message-ID: Dear RXTX'ers, Would there be a precompiled binary of the older 2.0-7pre1 version (javax.comm namespace) rxtx for the Intel Mac platform? Would I just need the libSerial.jnilib file? Thank you, Fred From savagobr at yahoo.com Fri Jul 28 09:34:35 2006 From: savagobr at yahoo.com (Adenilson Cavalcanti) Date: Fri, 28 Jul 2006 08:34:35 -0700 (PDT) Subject: [Rxtx] Strange error (show stopper) - FC5 still ok! Message-ID: <20060728153435.41645.qmail@web53815.mail.yahoo.com> Friends I repeated the test, both undefining TIOCSERGETLSR in SerialImp.h as also adding a sleep in function 'interruptEventLoop' and it still is working fine. Later I can test it in pcbsd (based on FreeBSD 6) on my notebook. So far, I think that we can say that in Linux this error doesn't happen. Best regards Savago //------------------------------------------------------------------------ Result with #undef TIOCSERGETLSR 11:08:11:******* 1 interrupted thread for FD=51 PTR=-1321354040 CLOSING=0 11:08:11:******* 2 interrupted thread for FD=51 PTR=-1321354040 CLOSING=1 Result with usleep(50000) 11:14:57:******* 1 interrupted thread for FD=51 PTR=-1322914604 CLOSING=0 11:14:57:******* 2 interrupted thread for FD=51 PTR=-1322914604 CLOSING=1 --------------------------------- How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone call rates. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060728/acd6aec1/attachment-0335.html From joachim at buechse.de Fri Jul 28 12:48:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 28 Jul 2006 20:48:33 +0200 Subject: [Rxtx] precompiled for Intel Mac? In-Reply-To: References: Message-ID: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> There will be. However not before we have figured out some remaining issues. Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 28.07.2006, at 12:32, Fred G. Martin wrote: > Dear RXTX'ers, > > Would there be a precompiled binary of the older 2.0-7pre1 version > (javax.comm namespace) rxtx for the Intel Mac platform? > > Would I just need the libSerial.jnilib file? > > Thank you, > Fred > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From fredm at alum.mit.edu Fri Jul 28 15:30:38 2006 From: fredm at alum.mit.edu (Fred G. Martin) Date: Fri, 28 Jul 2006 17:30:38 -0400 Subject: [Rxtx] precompiled for Intel Mac? In-Reply-To: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> References: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> Message-ID: <4616ED35-24BC-4FD3-90FB-81CAA851FB08@alum.mit.edu> May I ask another way--- can it [easily] be built from the 2.0-7pre1 sources? Fred On Jul 28, 2006, at 2:48 PM, Joachim Buechse wrote: > There will be. However not before we have figured out some remaining > issues. > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 28.07.2006, at 12:32, Fred G. Martin wrote: > >> Dear RXTX'ers, >> >> Would there be a precompiled binary of the older 2.0-7pre1 version >> (javax.comm namespace) rxtx for the Intel Mac platform? >> >> Would I just need the libSerial.jnilib file? >> >> Thank you, >> Fred >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Fri Jul 28 21:04:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 28 Jul 2006 21:04:45 -0600 (MDT) Subject: [Rxtx] precompiled for Intel Mac? In-Reply-To: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> References: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> Message-ID: On Fri, 28 Jul 2006, Joachim Buechse wrote: > There will be. However not before we have figured out some remaining > issues. > Joachim > Joachim and I are trying to get together to work out the remaining issues. I'll be looking at some w32 issues this weekend - a lovely job everyone should do exactly once. There are a few details that need attention. The summer vacation schedual is keeping things at a slow pace. This will be the first free weekend I've had in a while. I'm also gathering a list of things to do on Linux and Solaris which so far isn't too big but there are some that can be problems depending upon your use. Bugzilla is also your friend for bugs that are not getting attention right away. All bugs are interesting but sometimes forgotten on the mail list. I do go through all the bugs in bugzilla one by one now and then. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jul 29 05:18:25 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 29 Jul 2006 07:18:25 -0400 Subject: [Rxtx] The new JSR and RS485 - Moderator Ruling In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: Hi All, It has been several days since I asked the below question. There has not been much in the way of response. Therefore, I am using my new-age radioactive mutant moderator super-powers to make a (non-final) decision that: 1. We can live with unofficial RS485 support for a while, 2. The JSR specification that we embark upon will focus on serial and parallel ports and 3. We may revisit the RS485 question, in the future. Thanks! - Doug Date: Wed, 26 Jul 2006 06:28:33 -0400 From: "Dr. Douglas Lyon" Subject: Should we defer JSR support of RS485? To: RXTX Developers and Users , lyon at docjava.com Original-recipient: rfc822;dlyon at optonline.net Hi All, Would it make sense to focus the JSR on rock solid serial and parallel port support? Can the RS485 people live with unofficial support, at least until we get the JSR accepted and the implementation rock solid? Thanks! - Doug From naranjo.manuel at gmail.com Sat Jul 29 07:59:10 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Sat, 29 Jul 2006 10:59:10 -0300 Subject: [Rxtx] The new JSR and RS485 - Moderator Ruling In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: <44CB69AE.8030104@gmail.com> +1 Totally agree, Manuel > Hi All, > > It has been several days since I asked the below question. > There has not been much in the way of response. > Therefore, I am using my new-age radioactive > mutant moderator super-powers to > make a (non-final) decision that: > 1. We can live with unofficial RS485 support for a while, > 2. The JSR specification that we embark upon will focus on > serial and parallel ports and > 3. We may revisit the RS485 question, in the future. > > Thanks! > - Doug > > > Date: Wed, 26 Jul 2006 06:28:33 -0400 > From: "Dr. Douglas Lyon" > Subject: Should we defer JSR support of RS485? > To: RXTX Developers and Users , lyon at docjava.com > Original-recipient: rfc822;dlyon at optonline.net > > Hi All, > > Would it make sense to focus the JSR on rock solid > serial and parallel port support? > > Can the RS485 people live with unofficial support, at least until > we get the JSR accepted and the implementation rock solid? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Sat Jul 29 14:21:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 29 Jul 2006 14:21:32 -0600 (MDT) Subject: [Rxtx] The new JSR and RS485 - Moderator Ruling In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: Hi Doug At this time, I agree. RS485 is interesting and I would be intested in participating in future discussions/plans with RS485. On Sat, 29 Jul 2006, Dr. Douglas Lyon wrote: > Hi All, > > It has been several days since I asked the below question. > There has not been much in the way of response. > Therefore, I am using my new-age radioactive > mutant moderator super-powers to > make a (non-final) decision that: > 1. We can live with unofficial RS485 support for a while, > 2. The JSR specification that we embark upon will focus on > serial and parallel ports and > 3. We may revisit the RS485 question, in the future. > > Thanks! > - Doug > > > Date: Wed, 26 Jul 2006 06:28:33 -0400 > From: "Dr. Douglas Lyon" > Subject: Should we defer JSR support of RS485? > To: RXTX Developers and Users , lyon at docjava.com > Original-recipient: rfc822;dlyon at optonline.net > > Hi All, > > Would it make sense to focus the JSR on rock solid > serial and parallel port support? > > Can the RS485 people live with unofficial support, at least until > we get the JSR accepted and the implementation rock solid? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Sun Jul 30 04:28:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 30 Jul 2006 06:28:49 -0400 Subject: [Rxtx] interfaces vs. abstract classes Message-ID: Hi All, I was thinking that the new JSR might be more interface oriented and less abstract class oriented. For example, instead of subclassing CommPort, perhaps we should implement a CommPortInterface. How would this look? I don't know. But, perhaps, it would look something like this: package gnu.io; import java.io.InputStream; import java.io.IOException; import java.io.OutputStream; /** * User: lyon * Date: Jul 30, 2006 * Time: 5:19:55 AM * Copyright DocJava, Inc. 2005. */ public interface CommPortInterface { void enableReceiveFraming(int f) throws UnsupportedCommOperationException; void disableReceiveFraming(); boolean isReceiveFramingEnabled(); int getReceiveFramingByte(); void disableReceiveTimeout(); void enableReceiveTimeout(int time) throws UnsupportedCommOperationException; boolean isReceiveTimeoutEnabled(); int getReceiveTimeout(); void enableReceiveThreshold(int thresh) throws UnsupportedCommOperationException; void disableReceiveThreshold(); int getReceiveThreshold(); boolean isReceiveThresholdEnabled(); void setInputBufferSize(int size); int getInputBufferSize(); void setOutputBufferSize(int size); int getOutputBufferSize(); void close(); InputStream getInputStream() throws IOException; OutputStream getOutputStream() throws IOException; String getName(); } Then, we can use: /** * CommPort */ public abstract class CommPort implements CommPortInterface And replace uses of CommPort with uses of CommPortInterface.... package gnu.io; import java.io.FileDescriptor; /** * User: lyon * Date: Jul 30, 2006 * Time: 5:40:20 AM * Copyright DocJava, Inc. 2005. */ public interface CommPortIdentifierInterface { int PORT_SERIAL = 1; int PORT_PARALLEL = 2; int PORT_I2C = 3; int PORT_RS485 = 4; int PORT_RAW = 5; void addPortOwnershipListener(CommPortOwnershipListener c); String getCurrentOwner(); String getName(); int getPortType(); boolean isCurrentlyOwned(); CommPortInterface open(FileDescriptor f) throws UnsupportedCommOperationExce ption; CommPortInterface open(String TheOwner, int i) throws PortInUseException; void removePortOwnershipListener(CommPortOwnershipListener c); } If we continue in this vain, the SerialPort should have an interface that it implements, called (due to my lack of imagination) the SerialPortInterface package gnu.io; import java.util.TooManyListenersException; /** * User: lyon * Date: Jul 30, 2006 * Time: 5:56:35 AM * Copyright DocJava, Inc. 2005. */ public interface SerialPortInterface extends CommPortInterface { int DATABITS_5 = 5; int DATABITS_6 = 6; int DATABITS_7 = 7; int DATABITS_8 = 8; int PARITY_NONE = 0; int PARITY_ODD = 1; int PARITY_EVEN = 2; int PARITY_MARK = 3; int PARITY_SPACE = 4; int STOPBITS_1 = 1; int STOPBITS_2 = 2; int STOPBITS_1_5 = 3; int FLOWCONTROL_NONE = 0; int FLOWCONTROL_RTSCTS_IN = 1; int FLOWCONTROL_RTSCTS_OUT = 2; int FLOWCONTROL_XONXOFF_IN = 4; int FLOWCONTROL_XONXOFF_OUT = 8; void setSerialPortParams(int b, int d, int s, int p) throws UnsupportedCommOperationException; int getBaudRate(); int getDataBits(); int getStopBits(); int getParity(); void setFlowControlMode(int flowcontrol) throws UnsupportedCommOperationException; int getFlowControlMode(); boolean isDTR(); void setDTR(boolean state); void setRTS(boolean state); boolean isCTS(); boolean isDSR(); boolean isCD(); boolean isRI(); boolean isRTS(); void sendBreak(int duration); void addEventListener(SerialPortEventListener lsnr) throws TooManyListenersException; void removeEventListener(); void notifyOnDataAvailable(boolean enable); void notifyOnOutputEmpty(boolean enable); void notifyOnCTS(boolean enable); void notifyOnDSR(boolean enable); void notifyOnRingIndicator(boolean enable); void notifyOnCarrierDetect(boolean enable); void notifyOnOverrunError(boolean enable); void notifyOnParityError(boolean enable); void notifyOnFramingError(boolean enable); void notifyOnBreakInterrupt(boolean enable); byte getParityErrorChar() throws UnsupportedCommOperationException; boolean setParityErrorChar(byte b) throws UnsupportedCommOperationException; byte getEndOfInputChar() throws UnsupportedCommOperationException; boolean setEndOfInputChar(byte b) throws UnsupportedCommOperationException; boolean setUARTType(String type, boolean test) throws UnsupportedCommOperationException; String getUARTType() throws UnsupportedCommOperationException; boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException; int getBaudBase() throws UnsupportedCommOperationException; boolean setDivisor(int Divisor) throws UnsupportedCommOperationException; int getDivisor() throws UnsupportedCommOperationException; boolean setLowLatency() throws UnsupportedCommOperationException; boolean getLowLatency() throws UnsupportedCommOperationException; boolean setCallOutHangup(boolean NoHup) throws UnsupportedCommOperationException; boolean getCallOutHangup() throws UnsupportedCommOperationException; } And, of course, you need a parallel port: package gnu.io; import java.util.TooManyListenersException; /** * User: lyon * Date: Jul 30, 2006 * Time: 6:14:02 AM * Copyright DocJava, Inc. 2005. */ public interface ParallelPortInterface extends CommPortInterface { int LPT_MODE_ANY = 0; int LPT_MODE_SPP = 1; int LPT_MODE_PS2 = 2; int LPT_MODE_EPP = 3; int LPT_MODE_ECP = 4; int LPT_MODE_NIBBLE = 5; int getMode(); int setMode(int mode) throws UnsupportedCommOperationException; void restart(); void suspend(); boolean isPaperOut(); boolean isPrinterBusy(); boolean isPrinterError(); boolean isPrinterSelected(); boolean isPrinterTimedOut(); int getOutputBufferFree(); void addEventListener(ParallelPortEventListener lsnr) throws TooManyListenersException; void removeEventListener(); void notifyOnError(boolean enable); void notifyOnBuffer(boolean enable); } Now, I have refactored my code to take advantage of these interfaces. And have done very limited testing. The problem is that we have some static methods in classes like CommPortIdentifier that don't refactor into interfaces cleanly. I don't know what to do about that... What do people think about the idea of using interfaces rather than abstract classes for making the system a little more component oriented? Thanks! - Doug From tjarvi at qbang.org Sun Jul 30 10:13:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 30 Jul 2006 10:13:06 -0600 (MDT) Subject: [Rxtx] interfaces vs. abstract classes In-Reply-To: References: Message-ID: Hi Doug, I don't see a big advantage one way or another for the interfaces. One thing that should be added but not supported initially on all platforms is event notification of devices becomming physically available and vanishing. This is not the same as digging into USB. If the OS can provide a clean event driven method and provides a proper interface, it is of great use to people dealing with USB and Serial and Parallel Dongles. On Sun, 30 Jul 2006, Dr. Douglas Lyon wrote: > Hi All, > I was thinking that the new JSR might be more > interface oriented and less abstract class oriented. > > For example, instead of subclassing CommPort, perhaps > we should implement a CommPortInterface. > > How would this look? > > I don't know. But, perhaps, it would look something like this: > package gnu.io; > > import java.io.InputStream; > import java.io.IOException; > import java.io.OutputStream; > > /** > * User: lyon > * Date: Jul 30, 2006 > * Time: 5:19:55 AM > * Copyright DocJava, Inc. 2005. > */ > public interface CommPortInterface { > void enableReceiveFraming(int f) > throws UnsupportedCommOperationException; > > void disableReceiveFraming(); > > boolean isReceiveFramingEnabled(); > > int getReceiveFramingByte(); > > void disableReceiveTimeout(); > > void enableReceiveTimeout(int time) > throws UnsupportedCommOperationException; > > boolean isReceiveTimeoutEnabled(); > > int getReceiveTimeout(); > > void enableReceiveThreshold(int thresh) > throws UnsupportedCommOperationException; > > void disableReceiveThreshold(); > > int getReceiveThreshold(); > > boolean isReceiveThresholdEnabled(); > > void setInputBufferSize(int size); > > int getInputBufferSize(); > > void setOutputBufferSize(int size); > > int getOutputBufferSize(); > > void close(); > > InputStream getInputStream() throws IOException; > > OutputStream getOutputStream() throws IOException; > > String getName(); > } > > Then, we can use: > /** > * CommPort > */ > public abstract class CommPort implements CommPortInterface > > And replace uses of CommPort with uses of CommPortInterface.... > package gnu.io; > > import java.io.FileDescriptor; > > /** > * User: lyon > * Date: Jul 30, 2006 > * Time: 5:40:20 AM > * Copyright DocJava, Inc. 2005. > */ > public interface CommPortIdentifierInterface { > int PORT_SERIAL = 1; > int PORT_PARALLEL = 2; > int PORT_I2C = 3; > int PORT_RS485 = 4; > int PORT_RAW = 5; > > void addPortOwnershipListener(CommPortOwnershipListener c); > > String getCurrentOwner(); > > String getName(); > > int getPortType(); > > boolean isCurrentlyOwned(); > > CommPortInterface open(FileDescriptor f) throws > UnsupportedCommOperationExce > ption; > > CommPortInterface open(String TheOwner, int i) > throws PortInUseException; > > void removePortOwnershipListener(CommPortOwnershipListener c); > } > > If we continue in this vain, the SerialPort should have an interface that > it implements, called (due to my lack of imagination) the SerialPortInterface > > package gnu.io; > > import java.util.TooManyListenersException; > > /** > * User: lyon > * Date: Jul 30, 2006 > * Time: 5:56:35 AM > * Copyright DocJava, Inc. 2005. > */ > public interface SerialPortInterface extends CommPortInterface { > int DATABITS_5 = 5; > int DATABITS_6 = 6; > int DATABITS_7 = 7; > int DATABITS_8 = 8; > int PARITY_NONE = 0; > int PARITY_ODD = 1; > int PARITY_EVEN = 2; > int PARITY_MARK = 3; > int PARITY_SPACE = 4; > int STOPBITS_1 = 1; > int STOPBITS_2 = 2; > int STOPBITS_1_5 = 3; > int FLOWCONTROL_NONE = 0; > int FLOWCONTROL_RTSCTS_IN = 1; > int FLOWCONTROL_RTSCTS_OUT = 2; > int FLOWCONTROL_XONXOFF_IN = 4; > int FLOWCONTROL_XONXOFF_OUT = 8; > > void setSerialPortParams(int b, int d, int s, int p) > throws UnsupportedCommOperationException; > > int getBaudRate(); > > int getDataBits(); > > int getStopBits(); > > int getParity(); > > void setFlowControlMode(int flowcontrol) > throws UnsupportedCommOperationException; > > int getFlowControlMode(); > > boolean isDTR(); > > void setDTR(boolean state); > > void setRTS(boolean state); > > boolean isCTS(); > > boolean isDSR(); > > boolean isCD(); > > boolean isRI(); > > boolean isRTS(); > > void sendBreak(int duration); > > void addEventListener(SerialPortEventListener lsnr) > throws TooManyListenersException; > > void removeEventListener(); > > void notifyOnDataAvailable(boolean enable); > > void notifyOnOutputEmpty(boolean enable); > > void notifyOnCTS(boolean enable); > > void notifyOnDSR(boolean enable); > > void notifyOnRingIndicator(boolean enable); > > void notifyOnCarrierDetect(boolean enable); > > void notifyOnOverrunError(boolean enable); > > void notifyOnParityError(boolean enable); > > void notifyOnFramingError(boolean enable); > > void notifyOnBreakInterrupt(boolean enable); > > byte getParityErrorChar() > throws UnsupportedCommOperationException; > > boolean setParityErrorChar(byte b) > throws UnsupportedCommOperationException; > > byte getEndOfInputChar() > throws UnsupportedCommOperationException; > > boolean setEndOfInputChar(byte b) > throws UnsupportedCommOperationException; > > boolean setUARTType(String type, boolean test) > throws UnsupportedCommOperationException; > > String getUARTType() > throws UnsupportedCommOperationException; > > boolean setBaudBase(int BaudBase) > throws UnsupportedCommOperationException; > > int getBaudBase() > throws UnsupportedCommOperationException; > > boolean setDivisor(int Divisor) > throws UnsupportedCommOperationException; > > int getDivisor() > throws UnsupportedCommOperationException; > > boolean setLowLatency() > throws UnsupportedCommOperationException; > > boolean getLowLatency() > throws UnsupportedCommOperationException; > > boolean setCallOutHangup(boolean NoHup) > throws UnsupportedCommOperationException; > > boolean getCallOutHangup() > throws UnsupportedCommOperationException; > } > > And, of course, you need a parallel port: > package gnu.io; > > import java.util.TooManyListenersException; > > /** > * User: lyon > * Date: Jul 30, 2006 > * Time: 6:14:02 AM > * Copyright DocJava, Inc. 2005. > */ > public interface ParallelPortInterface extends CommPortInterface { > int LPT_MODE_ANY = 0; > int LPT_MODE_SPP = 1; > int LPT_MODE_PS2 = 2; > int LPT_MODE_EPP = 3; > int LPT_MODE_ECP = 4; > int LPT_MODE_NIBBLE = 5; > > int getMode(); > > int setMode(int mode) > throws UnsupportedCommOperationException; > > void restart(); > > void suspend(); > > boolean isPaperOut(); > > boolean isPrinterBusy(); > > boolean isPrinterError(); > > boolean isPrinterSelected(); > > boolean isPrinterTimedOut(); > > int getOutputBufferFree(); > > void addEventListener(ParallelPortEventListener lsnr) > throws TooManyListenersException; > > void removeEventListener(); > > void notifyOnError(boolean enable); > > void notifyOnBuffer(boolean enable); > } > > Now, I have refactored my code to take advantage of these interfaces. > And have done very limited testing. The problem is that we have some > static methods in > classes like CommPortIdentifier that don't refactor into interfaces cleanly. > > I don't know what to do about that... > > What do people think about the idea of using interfaces rather than > abstract classes for making the system a little more component oriented? > > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From berkland at spamcop.net Sun Jul 30 15:15:59 2006 From: berkland at spamcop.net (Doug Berkland) Date: Sun, 30 Jul 2006 17:15:59 -0400 Subject: [Rxtx] interfaces vs. abstract classes In-Reply-To: <269e40090607301408q41759906k6e45f0dd33618655@mail.gmail.com> References: <269e40090607301408q41759906k6e45f0dd33618655@mail.gmail.com> Message-ID: <269e40090607301415p3238e51eyce4b124f385c1918@mail.gmail.com> I think the interfaces are a good idea. They will allow more flexibility if someone needs to create a modified implementation. I just hope that all of this will end up in the javax.comm package instead of gnu.io. From gergg at cox.net Sun Jul 30 16:30:37 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 30 Jul 2006 17:30:37 -0500 Subject: [Rxtx] interfaces vs. abstract classes In-Reply-To: <269e40090607301415p3238e51eyce4b124f385c1918@mail.gmail.com> References: <269e40090607301408q41759906k6e45f0dd33618655@mail.gmail.com> <269e40090607301415p3238e51eyce4b124f385c1918@mail.gmail.com> Message-ID: <44CD330D.20608@cox.net> Doug Berkland wrote: > I think the interfaces are a good idea. They will allow more > flexibility if someone needs to create a modified implementation. I > just hope that all of this will end up in the javax.comm package > instead of gnu.io. You can provide an abstract class that implements the interface, but defers on the implementation details to allow porting parties the ability to reuse common code with less variations on the behavior that users experience. Please don't include anything in the interface that can't be described in 100% accuracy and perform identically on all possible ports, or throw a well described compatibility exception. Gregg Wonderly From lyon at docjava.com Sun Jul 30 17:27:13 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 30 Jul 2006 19:27:13 -0400 Subject: [Rxtx] interfaces vs abstract classes Message-ID: Hi All, If you ever want to use serial ports with RMI, a nice set of interfaces will be required. On the other hand, perhaps nobody wants that. On the other, other hand, there are some areas where we could really use some API clean-up. This could be a chance to shape the JSR with really clean interfaces with well defined semantics and some good Javadoc. For example: I2CPort, RS485Port and SerialPort all begin with duplicate code. We can put all the constants in a nice interface, as appears below. I have added a little Javadoc. Would someone like to finish it up? So far, I have not added any new features, other than documentation and refactoring. >More importantly is the philosophical start point for a >specification in a JSR; >that is speaking to the future: >Interfaces describe capabilities; >Classes implement capabilities; Methods execute capabilities. >In the long run, a plug-in based system can be used to substitute >implementation >but retain the use of the interface. > >So, use inheritance for internal code reuse and interfaces for >contract definition. > >As the famous GoF book says: > >Prefer interfaces over inheritance. > >Use interfaces as a design-time resource when you are planning your system. >It is almost always useful to define a contract of functionality for >a given set of features. Clients of such a contract should never >have to bother with details of actual implementations. - DL public interface SerialPortInterface extends CommPortInterface { int DATABITS_5 = 5; int DATABITS_6 = 6; int DATABITS_7 = 7; int DATABITS_8 = 8; int PARITY_NONE = 0; int PARITY_ODD = 1; int PARITY_EVEN = 2; int PARITY_MARK = 3; int PARITY_SPACE = 4; int STOPBITS_1 = 1; int STOPBITS_2 = 2; int STOPBITS_1_5 = 3; int FLOWCONTROL_NONE = 0; int FLOWCONTROL_RTSCTS_IN = 1; int FLOWCONTROL_RTSCTS_OUT = 2; int FLOWCONTROL_XONXOFF_IN = 4; int FLOWCONTROL_XONXOFF_OUT = 8; /** * @return true if the DTR bit is set. * * @see #setDTR */ boolean isCTS(); /** * @return true if the DTR bit is set. * */ boolean isDSR(); /** * @return true if the CD bit is set. * */ boolean isCD(); /** * @return true if the RI bit is set. * */ boolean isRI(); /** * @return true if the RTS bit is set. * * @see #setRTS */ boolean isRTS(); /** would someone like to write some nice javadoc for the following? */ void addEventListener(SerialPortEventListener lsnr) throws TooManyListenersException; void removeEventListener(); void notifyOnDataAvailable(boolean enable); void notifyOnOutputEmpty(boolean enable); void notifyOnCTS(boolean enable); void notifyOnDSR(boolean enable); void notifyOnRingIndicator(boolean enable); void notifyOnCarrierDetect(boolean enable); void notifyOnOverrunError(boolean enable); void notifyOnParityError(boolean enable); void notifyOnFramingError(boolean enable); void notifyOnBreakInterrupt(boolean enable); byte getParityErrorChar() throws UnsupportedCommOperationException; boolean setParityErrorChar(byte b) throws UnsupportedCommOperationException; byte getEndOfInputChar() throws UnsupportedCommOperationException; boolean setEndOfInputChar(byte b) throws UnsupportedCommOperationException; boolean setUARTType(String type, boolean test) throws UnsupportedCommOperationException; String getUARTType() throws UnsupportedCommOperationException; boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException; int getBaudBase() throws UnsupportedCommOperationException; boolean setDivisor(int Divisor) throws UnsupportedCommOperationException; int getDivisor() throws UnsupportedCommOperationException; boolean setLowLatency() throws UnsupportedCommOperationException; boolean getLowLatency() throws UnsupportedCommOperationException; boolean setCallOutHangup(boolean NoHup) throws UnsupportedCommOperationException; boolean getCallOutHangup() throws UnsupportedCommOperationException; /** * @return the current baud rate */ int getBaudRate(); /** * @return the current number of data bits: DATABITS_5, DATABITS_6, * DATABITS_7, or DATABITS_8. */ int getDataBits(); /** * @return the current number of stop bits: STOPBITS_1, STOPBITS_2, or * STOPBITS_1_5. */ int getStopBits(); /** * @return the current parity scheme: PARITY_NONE, PARITY_ODD, * PARITY_EVEN, PARITY_MARK or PARITY_SPACE. */ int getParity(); /** * Sends a break of the specified duration. * * @param millis the duration in milliseconds */ void sendBreak(int millis); /** * Sets the flow control mode. * * @param flowcontrol a bitmask combination of FLOWCONTROL_NONE, * FLOWCONTROL_RTSCTS_IN, FLOWCONTROL_RTSCTS_OUT, * FLOWCONTROL_XONXOFF_IN, and/or FLOWCONTROL_XONXOFF_OUT. */ void setFlowControlMode(int flowcontrol); /** * @return the current flow control mode as a bitmask of * FLOWCONTROL_NONE, FLOWCONTROL_RTSCTS_IN, FLOWCONTROL_RTSCTS_OUT, * FLOWCONTROL_XONXOFF_IN, and/or FLOWCONTROL_XONXOFF_OUT. */ int getFlowControlMode(); /** * Set the Receive Fifo trigger level. * If the UART has a FIFO and if it can have programmable trigger * levels, then this method will cause the UART to raise an interrupt * after trigger bytes have been received. * * @param trigger the trigger level * @deprecated */ void setRcvFifoTrigger(int trigger); /** * Sets the serial port parameters. * * @param baudRate the baud rate * @param dataBits the number of data bits: DATABITS_5, * DATABITS_6, DATABITS_7, or DATABITS_8 * @param stopBits the number of stop bits: STOPBITS_1, * STOPBITS_2, or STOPBITS_1_5 * @param parity the parity schema: PARITY_NONE, PARITY_ODD, * PARITY_EVEN, PARITY_MARK or PARITY_SPACE * @throws UnsupportedCommOperationException */ void setSerialPortParams(int baudRate, int dataBits, int stopBits, int parity) throws UnsupportedCommOperationException; /** * Sets or clears the DTR bit in the UART. * * @param dtr the Data Terminal Ready bit value * @see #isDTR */ void setDTR(boolean dtr); /** * @return true if the DTR bit is set. * * @see #setDTR */ boolean isDTR(); /** * Sets or clears the RTS bit in the UART. * * @param rts the Request To Send bit value */ void setRTS(boolean rts); } Here is the CommPortInterface: public interface CommPortInterface { /** * @return the name of this port. * */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is disabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } From tjarvi at qbang.org Sun Jul 30 17:43:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 30 Jul 2006 17:43:13 -0600 (MDT) Subject: [Rxtx] RMI In-Reply-To: References: Message-ID: On Sun, 30 Jul 2006, Dr. Douglas Lyon wrote: > Hi All, > > If you ever want to use serial ports with RMI, > a nice set of interfaces will be required. > So this would eventually lead to j2ee beans and such. The security model would have to be examined for this. Often there are tens of thousands of dollars in instrumentation or even cash drawers/POS sitting on the other end of the cable. A serial port should be no less secure than a hard drive. I think security is going to be OK but then we are opening up for a bunch of questions about how to get it working. That puts us in a position of answering how to bypass security with RMI to access hard drives [or serial ports]. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Jul 30 21:48:01 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 30 Jul 2006 22:48:01 -0500 Subject: [Rxtx] RMI In-Reply-To: References: Message-ID: <44CD7D71.2080306@cox.net> Trent Jarvi wrote: > On Sun, 30 Jul 2006, Dr. Douglas Lyon wrote: >>If you ever want to use serial ports with RMI, >>a nice set of interfaces will be required. > > So this would eventually lead to j2ee beans and such. > > The security model would have to be examined for this. Often there are > tens of thousands of dollars in instrumentation or even cash drawers/POS > sitting on the other end of the cable. > > A serial port should be no less secure than a hard drive. I think > security is going to be OK but then we are opening up for a bunch of > questions about how to get it working. > > That puts us in a position of answering how to bypass security with RMI to > access hard drives [or serial ports]. This really depends on whether you want those streams to be visible remotely, directly or not. I think that it is poor engineering practice for any Remote access to directly expose the raw hardware/stream/data. You need to have choices on how to transport and encapsulate data streams. This is the power of the RMI programming model. Mobile code can put computational activities on the client instead of the server. The next generation of RMI, with all of the security features you need was developed by the original RMI team and some others, and is the Jini Extensible Remote Invocation (JERI) stack that is available in Jini 2.0 and later versions (http://www.jini.org and http://starterkit.dev.java.net). One of the primary things that JERI provides is an authentication and authorization mechanism that is activated at deployment time, instead of being coded into the libraries. Gregg Wonderly From guille at sms.nl Mon Jul 31 03:17:29 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Mon, 31 Jul 2006 11:17:29 +0200 Subject: [Rxtx] interfaces vs. abstract classes In-Reply-To: References: Message-ID: <7.0.1.0.0.20060731111659.0363b620@sms.nl> At 12:28 30/07/2006, Dr. Douglas Lyon wrote: >Hi All, >I was thinking that the new JSR might be more >interface oriented and less abstract class oriented. > >For example, instead of subclassing CommPort, perhaps >we should implement a CommPortInterface. > >How would this look? Will it break backwards compatibility? Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From lyon at docjava.com Mon Jul 31 04:57:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 31 Jul 2006 06:57:39 -0400 Subject: [Rxtx] Rxtx RMI/SSL In-Reply-To: <44CD7D71.2080306@cox.net> References: <44CD7D71.2080306@cox.net> Message-ID: Hi All, Networked based serial ports are a nice option for java clients that do not need (or want) native method drivers installed. Applications include web-controlled robotics, network-based modems, auto-dialing addressbooks (remote dialers), remote sensing, etc. If you are behind a firewall, you may not feel the need for RMI/SSL security. After all, hacking into a serial port behind a firewall does seem a bit over-the-top. On the other hand, for those who feel they want to go over the Internet; I have been playing around with RMI over SSL. Here is a paper on the topic: http://show.docjava.com:8086/pub/document/jot/rjs.pdf Remote Job Submission Security by Pawel Krepstzul and Douglas A. Lyon, in Journal of Object Technology, vol. 5, no. 1, Janurary-February 2006, pp. 13-29. From the programmer point-of-view the SSL part is not quite transparent, but, given proper diligence, can be made somewhat secure. Naturally, you can put the exchange in a high-level of abstraction. I guess it really depends on the application. The question of how level-of-abstraction impacts security, remains open. You may observe a trend toward RMI based API's by looking at JAI (Java Advanced Imaging). Cheers! - Doug >Trent Jarvi wrote: >> On Sun, 30 Jul 2006, Dr. Douglas Lyon wrote: >>>If you ever want to use serial ports with RMI, >>>a nice set of interfaces will be required. >> >> So this would eventually lead to j2ee beans and such. >> >> The security model would have to be examined for this. Often there are >> tens of thousands of dollars in instrumentation or even cash drawers/POS >> sitting on the other end of the cable. >> >> A serial port should be no less secure than a hard drive. I think >> security is going to be OK but then we are opening up for a bunch of >> questions about how to get it working. >> >> That puts us in a position of answering how to bypass security with RMI to >> access hard drives [or serial ports]. > >This really depends on whether you want those streams to be visible remotely, >directly or not. I think that it is poor engineering practice for any Remote >access to directly expose the raw hardware/stream/data. You need to have >choices on how to transport and encapsulate data streams. This is >the power of >the RMI programming model. Mobile code can put computational >activities on the >client instead of the server. > >The next generation of RMI, with all of the security features you need was >developed by the original RMI team and some others, and is the Jini Extensible >Remote Invocation (JERI) stack that is available in Jini 2.0 and >later versions >(http://www.jini.org and http://starterkit.dev.java.net). > >One of the primary things that JERI provides is an authentication and >authorization mechanism that is activated at deployment time, instead of being >coded into the libraries. > >Gregg Wonderly >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Mon Jul 31 07:16:51 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 31 Jul 2006 15:16:51 +0200 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> Message-ID: <1154351811.44ce02c3a5539@webmail.eatserver.nl> Hi Doug, I understand. Note that we are not only concerned about source compatibility, but also about binary compatibility (which would be preserved as well with this approach if I understood correctly) Best regards, Guillermo Quoting "Dr. Douglas Lyon" : > Hi All, > At present I have a prototype version of the libraries that I am > testing that contains the Interfaces, with growing Javadoc. > I have been refactoring my code to take advantage of these > interfaces, but, in the interest of backward compatibility, > have left the abstract classes, for those who want to continue > to use and test them. So there is 100% backward compatibility. > > My goal is to identify the features of the class specification and > provide good documentation for them. I think this is seen most clearly in > the below code. This has ZERO impact on existing code that > seeks to make use of the CommPort class. > > I am adding interfaces and documentation to arrive at a specification. > Abstract methods and constants move from the abstract class into the > interface, but then the abstract class implements the interface. > > To the API user, it should have no effect. > > Cheers! > - Doug > > > public interface CommPortIdentifierInterface { > > int PORT_I2C = 3; > int PORT_RS485 = 4; > int PORT_RAW = 5; > /** > * RS-232 serial port. > */ > int PORT_SERIAL = 1; > /** > * IEEE 1284 parallel port. > */ > int PORT_PARALLEL = 2; > > > > /** > * @return the port name, typically an OS-dependent hardware label. > * > */ > String getName(); > > /** > * @return the port type, PORT_SERIAL or PORT_PARALLEL. > */ > int getPortType() > ; > > /** > * @return the current owner of this port. > */ > String getCurrentOwner() > ; > > /** > * @return true if this port is currently owned. > */ > boolean isCurrentlyOwned() ; > > /** > * @return communications port. > * If the port is in use by another application, it will be notified > * with a PORT_OWNERSHIP_REQUESTED event. If the current owner closes > * the port, then this method will succeed. Otherwise a > * PortInUseException will be thrown. > * @param appName the name of the application requesting the port > * @param timeout number of miliseconds to wait for the port to open > * @throws PortInUseException > */ > CommPortInterface open(String appName, int timeout) > throws PortInUseException; > > /** > * @return a port using a file descriptor. > * @param fd the file descriptor > * @exception UnsupportedCommOperationException if the platform does > not > * support this functionality > */ > CommPortInterface open(FileDescriptor fd) > throws UnsupportedCommOperationException; > > /** > * Adds the specified listener to the list of ownership listeners for > * this port. > * @param listener the ownership listener to add > */ > void addPortOwnershipListener(CommPortOwnershipListener listener); > > /** > * Removes the specified listener from the list of ownership listeners > for > * this port. > * @param listener the ownership listener to remove > */ > void removePortOwnershipListener(CommPortOwnershipListener listener); > } > public abstract class CommPort implements CommPortInterface { > protected String name; > private final static boolean debug = false; > > public void close() { > if (debug) System.out.println("CommPort:close()"); > > try { > CommPortIdentifierInterface cp = > CommPortIdentifier.getPortIdentifier(this); > if (cp != null) > > CommPortIdentifier.getPortIdentifier(this).internalClosePort(); > } > catch (NoSuchPortException e) { > e.printStackTrace(); > } > } > > public String getName() { > if (debug) System.out.println("CommPort:getName()"); > return (name); > } > > public String toString() { > if (debug) System.out.println("CommPort:toString()"); > return (name); > } > } > >At 12:28 30/07/2006, Dr. Douglas Lyon wrote: > >>Hi All, > >>I was thinking that the new JSR might be more > >>interface oriented and less abstract class oriented. > >> > >>For example, instead of subclassing CommPort, perhaps > >>we should implement a CommPortInterface. > >> > >>How would this look? > > > >Will it break backwards compatibility? > > > >Guillermo > >-- > >Guillermo Rodriguez Garcia > > > >Snijder Micro Systems phone +31-493-351020 > >G. Rodriguez Garcia fax +31-493-351530 > >Visser 25 email guille at sms.nl > >NL5751 BL Deurne > >The Netherlands http://www.snijder.com > > -- http://www.snijder.com/ SNIJDER Micro Systems From lyon at docjava.com Mon Jul 31 07:44:29 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 31 Jul 2006 09:44:29 -0400 Subject: [Rxtx] Do interfaces break backwards BINARY compatibility? Welcome to the serial ports of tomorrow! In-Reply-To: <1154351811.44ce02c3a5539@webmail.eatserver.nl> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> Message-ID: Hi All, The jar file, comm.jar, will change in the sense that there will be new byte codes for Interfaces and the abstract classes byte codes will change. However, the native methods are left unchanged. The goal is to specify "what is" via interfaces, minimizing the impact on the API. This enables RXTX to be a reference implementation of the interface specification. If the JSR is accepted and the interfaces become a part of the javax.comm package, then rxtx could implement the javax.comm specification. Thus, my VISION of the FUTURE (ta da): javax.comm programmers code to the javax.comm interfaces and use a factory method to get an RXTX-based driver. Does that sort of make sense? Thanks! - Doug >Hi Doug, > >I understand. Note that we are not only concerned about source >compatibility, but also about binary compatibility (which would be >preserved as well with this approach if I understood correctly) > >Best regards, >Guillermo > >Quoting "Dr. Douglas Lyon" : > >> Hi All, >> At present I have a prototype version of the libraries that I am >> testing that contains the Interfaces, with growing Javadoc. >> I have been refactoring my code to take advantage of these >> interfaces, but, in the interest of backward compatibility, >> have left the abstract classes, for those who want to continue >> to use and test them. So there is 100% backward compatibility. >> >> My goal is to identify the features of the class specification and >> provide good documentation for them. I think this is seen most clearly in >> the below code. This has ZERO impact on existing code that >> seeks to make use of the CommPort class. >> >> I am adding interfaces and documentation to arrive at a specification. >> Abstract methods and constants move from the abstract class into the >> interface, but then the abstract class implements the interface. >> >> To the API user, it should have no effect. >> >> Cheers! >> - Doug >> >> >> public interface CommPortIdentifierInterface { >> >> int PORT_I2C = 3; >> int PORT_RS485 = 4; >> int PORT_RAW = 5; >> /** >> * RS-232 serial port. >> */ >> int PORT_SERIAL = 1; >> /** >> * IEEE 1284 parallel port. >> */ >> int PORT_PARALLEL = 2; >> >> >> >> /** >> * @return the port name, typically an OS-dependent hardware label. >> * >> */ >> String getName(); >> >> /** >> * @return the port type, PORT_SERIAL or PORT_PARALLEL. >> */ >> int getPortType() >> ; >> >> /** >> * @return the current owner of this port. >> */ >> String getCurrentOwner() >> ; >> >> /** >> * @return true if this port is currently owned. >> */ >> boolean isCurrentlyOwned() ; >> >> /** >> * @return communications port. >> * If the port is in use by another application, it will be notified >> * with a PORT_OWNERSHIP_REQUESTED event. If the current owner closes >> * the port, then this method will succeed. Otherwise a >> * PortInUseException will be thrown. >> * @param appName the name of the application requesting the port >> * @param timeout number of miliseconds to wait for the port to open >> * @throws PortInUseException >> */ >> CommPortInterface open(String appName, int timeout) >> throws PortInUseException; >> >> /** >> * @return a port using a file descriptor. >> * @param fd the file descriptor >> * @exception UnsupportedCommOperationException if the platform does >> not >> * support this functionality >> */ >> CommPortInterface open(FileDescriptor fd) >> throws UnsupportedCommOperationException; >> >> /** >> * Adds the specified listener to the list of ownership listeners for >> * this port. >> * @param listener the ownership listener to add >> */ >> void addPortOwnershipListener(CommPortOwnershipListener listener); > > >> /** >> * Removes the specified listener from the list of ownership listeners >> for >> * this port. >> * @param listener the ownership listener to remove >> */ >> void removePortOwnershipListener(CommPortOwnershipListener listener); >> } >> public abstract class CommPort implements CommPortInterface { >> protected String name; >> private final static boolean debug = false; >> >> public void close() { >> if (debug) System.out.println("CommPort:close()"); >> >> try { >> CommPortIdentifierInterface cp = >> CommPortIdentifier.getPortIdentifier(this); >> if (cp != null) >>???????????????? >> CommPortIdentifier.getPortIdentifier(this).internalClosePort(); >> } >> catch (NoSuchPortException e) { >> e.printStackTrace(); >> } >> } >> >> public String getName() { >> if (debug) System.out.println("CommPort:getName()"); >> return (name); >> } >> >> public String toString() { >> if (debug) System.out.println("CommPort:toString()"); >> return (name); >> } >> } >> >At 12:28 30/07/2006, Dr. Douglas Lyon wrote: >> >>Hi All, >> >>I was thinking that the new JSR might be more >> >>interface oriented and less abstract class oriented. >> >> >> >>For example, instead of subclassing CommPort, perhaps >> >>we should implement a CommPortInterface. >> >> >> >>How would this look? >> > >> >Will it break backwards compatibility? >> > >> >Guillermo >> >-- >> >Guillermo Rodriguez Garcia >> > >> >Snijder Micro Systems phone +31-493-351020 >> >G. Rodriguez Garcia fax +31-493-351530 >> >Visser 25 email guille at sms.nl >> >NL5751 BL Deurne >> >The Netherlands http://www.snijder.com >> >> > > >-- >http://www.snijder.com/ >SNIJDER Micro Systems From berkland at spamcop.net Mon Jul 31 07:57:50 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 31 Jul 2006 09:57:50 -0400 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <1154351811.44ce02c3a5539@webmail.eatserver.nl> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> Message-ID: <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> Adding interfaces does not break any kind of compatibility. Java is more forgiving when it comes to this kind of change than languages that are compiled into native code. As long as the implementing class has the same name, same package, and all of the same methods (with the same signatures) you can add on anything you wish, including implementing additional interfaces. On 7/31/06, Guillermo Rodriguez wrote: > Hi Doug, > > I understand. Note that we are not only concerned about source > compatibility, but also about binary compatibility (which would be > preserved as well with this approach if I understood correctly) > > Best regards, > Guillermo From gergg at cox.net Mon Jul 31 08:12:20 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 31 Jul 2006 09:12:20 -0500 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> Message-ID: <44CE0FC4.9010307@cox.net> Doug Berkland wrote: > Adding interfaces does not break any kind of compatibility. Java is > more forgiving when it comes to this kind of change than languages > that are compiled into native code. As long as the implementing class > has the same name, same package, and all of the same methods (with the > same signatures) you can add on anything you wish, including > implementing additional interfaces. Check the Serialization compatibility guidelines for more information on exactly what binary compatibility requires, and what things can change in an interface and/or class which won't break things. Gregg Wonderly From berkland at spamcop.net Mon Jul 31 09:13:00 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 31 Jul 2006 11:13:00 -0400 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <44CE0FC4.9010307@cox.net> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> <44CE0FC4.9010307@cox.net> Message-ID: <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> As far as I can tell, nothing in either RXTX or Sun's JavaCOMM implements Serializable. Therefore, there are no worries from that either. (I can't think of a reason anything in JavaCOMM should implement Serializable either.) On 7/31/06, Gregg Wonderly wrote: > Doug Berkland wrote: > > Adding interfaces does not break any kind of compatibility. Java is > > more forgiving when it comes to this kind of change than languages > > that are compiled into native code. As long as the implementing class > > has the same name, same package, and all of the same methods (with the > > same signatures) you can add on anything you wish, including > > implementing additional interfaces. > > Check the Serialization compatibility guidelines for more information on exactly > what binary compatibility requires, and what things can change in an interface > and/or class which won't break things. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From berkland at spamcop.net Mon Jul 31 09:20:48 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 31 Jul 2006 11:20:48 -0400 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> <44CE0FC4.9010307@cox.net> <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> Message-ID: <269e40090607310820s15f2eee8j903e077917d7fc72@mail.gmail.com> Correction: Nothing except the classes extending Exception and Event implement Serializable. On 7/31/06, Doug Berkland wrote: > As far as I can tell, nothing in either RXTX or Sun's JavaCOMM > implements Serializable. Therefore, there are no worries from that > either. (I can't think of a reason anything in JavaCOMM should > implement Serializable either.) > > On 7/31/06, Gregg Wonderly wrote: > > Doug Berkland wrote: > > > Adding interfaces does not break any kind of compatibility. Java is > > > more forgiving when it comes to this kind of change than languages > > > that are compiled into native code. As long as the implementing class > > > has the same name, same package, and all of the same methods (with the > > > same signatures) you can add on anything you wish, including > > > implementing additional interfaces. > > > > Check the Serialization compatibility guidelines for more information on exactly > > what binary compatibility requires, and what things can change in an interface > > and/or class which won't break things. > > > > Gregg Wonderly > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > From gergg at cox.net Mon Jul 31 11:21:19 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 31 Jul 2006 12:21:19 -0500 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> <44CE0FC4.9010307@cox.net> <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> Message-ID: <44CE3C0F.3080408@cox.net> Doug Berkland wrote: > As far as I can tell, nothing in either RXTX or Sun's JavaCOMM > implements Serializable. Therefore, there are no worries from that > either. (I can't think of a reason anything in JavaCOMM should > implement Serializable either.) Any interface in javax.comm can become implemented by a serializable object. Thus, if someone wants to provide remote access to a serial port, then they might (and I think this is not wise) choose to subclass and add Serializable to the interface list. It's that kind of Serialization compatibility that I'm talking about. Gregg Wonderly From rwelty at suespammers.org Mon Jul 31 19:53:12 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 31 Jul 2006 21:53:12 -0400 Subject: [Rxtx] Application Name? Message-ID: <44CEB408.7040407@suespammers.org> trying to get my app running on a Mac OS X powerbook, when the following is executed as the first thing inside the run method of a Thread: try { port = (SerialPort) selectedPort.open( this.getClass().getName(), 2000); } catch ( PortInUseException ex){ ex.printStackTrace(); return; } i get the following: gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at com.krusty_motorsports.scale.monitor.ScaleWatcher.run(ScaleWatcher.java:143) i've not seen any documentation suggesting that rxtx would be finicky about application names... thanks for any suggestions, richard From stevebeemonkey at monkey-media.co.uk Wed Jul 5 05:59:02 2006 From: stevebeemonkey at monkey-media.co.uk (steve@monkey-media.co.uk) Date: Wed, 5 Jul 2006 04:59:02 -0700 Subject: [Rxtx] No output on WinXP Message-ID: <1152100742.44aba986565e7@www.webmail.ezpublishing.com> Hi there, I've installed RXTX 2.1.7 under Win XP, copying the .jar and .dll files according to the instructions given. I've changed the javax.comm import to gnu.io, but when I run the following code the only output I get is: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Then the program ends, without listing any of the ports. What am I doing wrong? Cheers, Steve Here's my code: ---------------------------------------- import gnu.io.*; import java.util.*; public class PortList { public static void main(String [] args) { Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while(portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); if( portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("Serial port: " + portId.getName()); } else if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { System.out.println("Parallel port: " + portId.getName()); } else System.out.println("Other port: " + portId.getName()); } } } ------------------------------- From tjarvi at qbang.org Wed Jul 5 07:57:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 5 Jul 2006 07:57:22 -0600 (MDT) Subject: [Rxtx] No output on WinXP In-Reply-To: <1152100742.44aba986565e7@www.webmail.ezpublishing.com> References: <1152100742.44aba986565e7@www.webmail.ezpublishing.com> Message-ID: On Wed, 5 Jul 2006, steve at monkey-media.co.uk wrote: > > > Hi there, > > I've installed RXTX 2.1.7 under Win XP, copying the .jar and .dll files > according to the instructions given. > > I've changed the javax.comm import to gnu.io, but when I run the following code > the only output I get is: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Then the program ends, without listing any of the ports. > > What am I doing wrong? > > Cheers, > > Steve > > Here's my code: > > ---------------------------------------- > > import gnu.io.*; > import java.util.*; > > public class PortList > { > public static void main(String [] args) > { > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > while(portList.hasMoreElements()) { > CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); > if( portId.getPortType() == > CommPortIdentifier.PORT_SERIAL) > { > System.out.println("Serial port: " + > portId.getName()); > } else if (portId.getPortType() == > CommPortIdentifier.PORT_PARALLEL) > { > System.out.println("Parallel port: " + > portId.getName()); > } else > System.out.println("Other port: " + > portId.getName()); > } > } > } > > ------------------------------- > If you have a port open with another terminal such as hyperterminal or even another copy of your application using rxtx, the port will not be enumerated. rxtx enumerates ports by opening prospective ports and doing a timed out read. If the port is open by another application, the open will fail. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Wed Jul 5 15:44:05 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Wed, 5 Jul 2006 15:44:05 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EA89@hqexchange3.dot.state.co.us> Trent, I did put some debug statements and the "index" returned to me in the while loop is "0" (see the code below) and it gets into the infinite loop, I can put a break statement but don't know the ramifications of it. Can you explain in what scenarios the index can be "0" or are we somehow in the native code loosing refrences to the indexes? Thanks Again Pawan Kharbanda while( searching ) { index = master_index; if( index ) { while( index->fd != fd && index->next ) index = index->next; if ( index->fd == fd ) searching = 0; } else report("Index"+index"x"); <<<<<< The code gets to this statement and index is returned as "0" and I don't see anyway to break out of this looop after. if( searching ) { report("@"); usleep(1000); } } -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, June 29, 2006 6:21 AM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports > Here is how you can test if you have resources/ test environment. > Write a program and try to open/close different ports(I will say have > a minimum of four) randomly and very frequently(may be 30 seconds), I > am pretty sure you will see the deadlocks and it happens in the native > call to interrptEventLoop in RXTXPort.java in removeEventListener() > method call. Hi Pawan I'll try to find a way to reproduce this. One thing to note is that you are using different kernel drivers (digi) to perform this task. So I probably will not be able to reproduce the exact same environment. In general, multiport kernel drivers have been tested far less than typical serial drivers. This may or may not be an issue. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Wed Jul 5 18:50:01 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Wed, 5 Jul 2006 18:50:01 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EA96@hqexchange3.dot.state.co.us> Trent, Sorry for so many emails, but as I mentioned earlier I will write a test to replicate the Locking problem. I am attaching a Java file to replicate the problem. You need atleast 4-5 ports to simulate the problem. Here is how to run the program. In the TestOpenClosePort.java please change the Serial Ports names(Add the ports installed on your machine). Then compile your java file and run as "java TestOpenClosePort 100" (100 is the no of times you want to open and close the port in one single thread). I have tested this with the Digi Boxes and able to replicate this over and over in Single JVM. Hope this test helps track down the problem. Thanks Pawan Kharbanda -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, June 29, 2006 6:21 AM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports > Here is how you can test if you have resources/ test environment. > Write a program and try to open/close different ports(I will say have > a minimum of four) randomly and very frequently(may be 30 seconds), I > am pretty sure you will see the deadlocks and it happens in the native > call to interrptEventLoop in RXTXPort.java in removeEventListener() > method call. Hi Pawan I'll try to find a way to reproduce this. One thing to note is that you are using different kernel drivers (digi) to perform this task. So I probably will not be able to reproduce the exact same environment. In general, multiport kernel drivers have been tested far less than typical serial drivers. This may or may not be an issue. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: TestOpenClosePort.java Type: application/octet-stream Size: 6038 bytes Desc: TestOpenClosePort.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060705/82f8488f/TestOpenClosePort-0359.obj From tjarvi at qbang.org Wed Jul 5 22:48:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 5 Jul 2006 22:48:52 -0600 (MDT) Subject: [Rxtx] Locked Ports In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3EA89@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03F3EA89@hqexchange3.dot.state.co.us> Message-ID: On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did put some debug statements and the "index" returned to me in > the while loop is "0" (see the code below) and it gets into the infinite > loop, I can put a break statement but don't know the ramifications of > it. Can you explain in what scenarios the index can be "0" or are we > somehow in the native code loosing refrences to the indexes? > > Thanks Again > Pawan Kharbanda > > while( searching ) > { > index = master_index; > > if( index ) > { > while( index->fd != fd && > index->next ) index = index->next; > if ( index->fd == fd ) searching = 0; > } > else > report("Index"+index"x"); <<<<<< The code gets > to this statement and index is returned as "0" and I don't see anyway to > break out of this looop after. > if( searching ) > { > report("@"); > usleep(1000); > } > } > Hi Pawan I am reading with interest :) So it sounds like this is a thread safe problem. The thing I don't understand here is open and close are synchronized in RXTXPort.java. I thought that would prevent any thread problems with the linked list. Looking closer, the linked list is actually populated in eventLoop/MonitorThread which is not synchronized. So you may be able to synchronize on an object in RXTXPort.java. A seperate native call would probably be required for the initalization to prevent a deadlock. A solution might involve making finalize_event_info_struct() and initialise_event_info_struct() [uk spelling?] thread safe with glib. http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads.html#id2786034 glib also has more robust linked lists which could be used. Thats the indirectly the problem found in termios.c for windows. The disadvantage is we would require linking to glib which is another step for systems that don't come with it. The advantage would be reduced code size we have to maintain. We could borrow bits of glib as the licenses are the same. Another solution might be to just use pthread_mutex_lock and unlock. http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html I don't think that would work on windows though. It would require linking cygwin.dll which would not work with nonGPL projects in practice. -- Trent Jarvi tjarvi From neville_seed at yahoo.com Thu Jul 6 06:42:29 2006 From: neville_seed at yahoo.com (neville seed) Date: Thu, 6 Jul 2006 05:42:29 -0700 (PDT) Subject: [Rxtx] port to palm OS? Message-ID: <20060706124230.55790.qmail@web51015.mail.yahoo.com> hello. Has rxtx been ported to PalmOS? regards neville __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From neville_seed at yahoo.com Thu Jul 6 06:43:44 2006 From: neville_seed at yahoo.com (neville seed) Date: Thu, 6 Jul 2006 05:43:44 -0700 (PDT) Subject: [Rxtx] example code Message-ID: <20060706124344.5063.qmail@web51013.mail.yahoo.com> hello. Could anyone provide me with example code of how to read from the serial port. regards neville __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From naranjo.manuel at gmail.com Thu Jul 6 06:48:20 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Thu, 06 Jul 2006 09:48:20 -0300 Subject: [Rxtx] port to palm OS? In-Reply-To: <20060706124230.55790.qmail@web51015.mail.yahoo.com> References: <20060706124230.55790.qmail@web51015.mail.yahoo.com> Message-ID: <44AD0694.1090703@gmail.com> neville seed wrote: > hello. > > Has rxtx been ported to PalmOS? > > regards > neville > I'm interested on this. Do you need rxtx ported to J2ME or to Superwaba?. Superwaba has it owns implementation of a serial port, but it is not rxtx. Regards, Manuel From joachim at buechse.de Thu Jul 6 07:20:57 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 6 Jul 2006 15:20:57 +0200 Subject: [Rxtx] port to palm OS? In-Reply-To: <20060706124230.55790.qmail@web51015.mail.yahoo.com> References: <20060706124230.55790.qmail@web51015.mail.yahoo.com> Message-ID: Which version of PalmOS are you targeting? I have been doing some Java on PalmOS programming for the Palm Vx using the JVM from Esmertec. The problem there was, that PalmOS can only process one kernel call at a time (it is (was?) not a multithreading OS). Threads were implemented by the VM. In a situation like this, any kind of "abort" mechanism is very difficult to handle - from what I know about the RXTX code and the way close() would have to be implemented it's the same as rewriting RXTX. Newer versions of PalmOS might have improved in this respect... Best regards, Joachim On 06.07.2006, at 14:42, neville seed wrote: > hello. > > Has rxtx been ported to PalmOS? > > regards > neville > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From neville_seed at yahoo.com Thu Jul 6 08:23:29 2006 From: neville_seed at yahoo.com (neville seed) Date: Thu, 6 Jul 2006 07:23:29 -0700 (PDT) Subject: [Rxtx] port to palm OS? In-Reply-To: Message-ID: <20060706142329.91625.qmail@web51005.mail.yahoo.com> The palmOS would be version 5.x however i am new to both palm and java. As such I would have to find out any questions. --- Joachim Buechse wrote: > Which version of PalmOS are you targeting? > > I have been doing some Java on PalmOS programming > for the Palm Vx > using the JVM from Esmertec. The problem there was, > that PalmOS can > only process one kernel call at a time (it is (was?) > not a > multithreading OS). Threads were implemented by the > VM. In a > situation like this, any kind of "abort" mechanism > is very difficult > to handle - from what I know about the RXTX code and > the way close() > would have to be implemented it's the same as > rewriting RXTX. Newer > versions of PalmOS might have improved in this > respect... > > Best regards, > Joachim > > On 06.07.2006, at 14:42, neville seed wrote: > > > hello. > > > > Has rxtx been ported to PalmOS? > > > > regards > > neville > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From jhaysonn at gmail.com Thu Jul 6 08:58:07 2006 From: jhaysonn at gmail.com (jhaysonn pathak) Date: Thu, 6 Jul 2006 10:58:07 -0400 Subject: [Rxtx] RXTX install (jhaysonn pathak) Message-ID: Thanks for the install tip. I figured out how to do the cvs update, but in my MACOSX_IDE dir I didn't have any Xcode folders and searching my computer, I only have 3 Xcode folders (one for application support, one for Max/MSP and one in developer tools). I have tried building each of the different *.xcodeproj files and in eachone they have little toolbox looking items that are in red (i assume that means it can't find them). Some of them I manage to locate but some of them just aren't on my computer. In any event, I still can't find the libserial.jnilib. After the update I read the README.OSX and it did make it seem a lot easier, but for the future, if I finally create a libserial.jnilib I don't know what the 'JavaVM' is in reference to this line "Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required)." PS - How do I uninstall everything RXTX so that I can try and re-download and re-install everything? From joachim at buechse.de Thu Jul 6 09:12:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 6 Jul 2006 17:12:24 +0200 Subject: [Rxtx] RXTX install (jhaysonn pathak) In-Reply-To: References: Message-ID: <98F15662-544D-41B5-8229-BB1DB6B6FD43@buechse.de> The Java VM ist the Java Virtual Machine. It runs your application. For the rest of your message ... your description is much to unprecise to help. To start, you could describe what IS in the MACOSX_IDE folder and its subfolders. On 06.07.2006, at 16:58, jhaysonn pathak wrote: > Thanks for the install tip. I figured out how to do the cvs update, > but in my MACOSX_IDE dir I didn't have any Xcode folders and searching > my computer, I only have 3 Xcode folders (one for application support, > one for Max/MSP and one in developer tools). I have tried building > each of the different *.xcodeproj files and in eachone they have > little toolbox looking items that are in red (i assume that means it > can't find them). Some of them I manage to locate but some of them > just aren't on my computer. In any event, I still can't find the > libserial.jnilib. > > After the update I read the README.OSX and it did make it seem a lot > easier, but for the future, if I finally create a libserial.jnilib I > don't know what the 'JavaVM' is in reference to this line > > "Put > libSerial.jnilib > in the directory of the application (the JavaVM will find it > there). Add > RXTXComm.jar > to the application classpath or include the classes in the > application jar. > (Some applications already include the RXTX classes in their > application jar, > in which case only the file libSerial.jnilib is required)." > > PS - How do I uninstall everything RXTX so that I can try and > re-download and re-install everything? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jul 6 09:20:16 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 6 Jul 2006 17:20:16 +0200 Subject: [Rxtx] RXTX install (jhaysonn pathak) In-Reply-To: References: Message-ID: <8F03CA0E-44F4-434F-AA7E-3A8B5054AA6F@buechse.de> Rethinking about your problem... I think you should try a cvs up -d Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 06.07.2006, at 16:58, jhaysonn pathak wrote: > Thanks for the install tip. I figured out how to do the cvs update, > but in my MACOSX_IDE dir I didn't have any Xcode folders and searching > my computer, I only have 3 Xcode folders (one for application support, > one for Max/MSP and one in developer tools). I have tried building > each of the different *.xcodeproj files and in eachone they have > little toolbox looking items that are in red (i assume that means it > can't find them). Some of them I manage to locate but some of them > just aren't on my computer. In any event, I still can't find the > libserial.jnilib. > > After the update I read the README.OSX and it did make it seem a lot > easier, but for the future, if I finally create a libserial.jnilib I > don't know what the 'JavaVM' is in reference to this line > > "Put > libSerial.jnilib > in the directory of the application (the JavaVM will find it > there). Add > RXTXComm.jar > to the application classpath or include the classes in the > application jar. > (Some applications already include the RXTX classes in their > application jar, > in which case only the file libSerial.jnilib is required)." > > PS - How do I uninstall everything RXTX so that I can try and > re-download and re-install everything? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Thu Jul 6 10:19:17 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Thu, 06 Jul 2006 13:19:17 -0300 Subject: [Rxtx] port to palm OS? In-Reply-To: <20060706142329.91625.qmail@web51005.mail.yahoo.com> References: <20060706142329.91625.qmail@web51005.mail.yahoo.com> Message-ID: <44AD3805.3010609@gmail.com> neville seed wrote: > The palmOS would be version 5.x however i am new to > both palm and java. As such I would have to find out > any questions. > Hello if you are new you could use Superwaba, url: www.superwaba.com, which is not exactly Java but works great, and has a serial port. If you need any more info please let me know. Manuel From Pawan.Kharbanda at dot.state.co.us Thu Jul 6 12:49:50 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 6 Jul 2006 12:49:50 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EB11@hqexchange3.dot.state.co.us> Trent, I did made the eventLoop() call in the Monitor Thread synchronized, it improved but still see the same problem. Your comment > A solution might involve making finalize_event_info_struct() and > initialise_event_info_struct() [uk spelling?] thread safe with glib. I didn't follow this how I can implement this. I am not a C guy, can you help me understand how I can implement this? Thanks Pawan Kharbanda -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, July 05, 2006 10:49 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did put some debug statements and the "index" returned to me in > the while loop is "0" (see the code below) and it gets into the > infinite loop, I can put a break statement but don't know the > ramifications of it. Can you explain in what scenarios the index can > be "0" or are we somehow in the native code loosing refrences to the indexes? > > Thanks Again > Pawan Kharbanda > > while( searching ) > { > index = master_index; > > if( index ) > { > while( index->fd != fd && > index->next ) index = index->next; > if ( index->fd == fd ) searching = 0; > } > else > report("Index"+index"x"); <<<<<< The code gets to this statement > and index is returned as "0" and I don't see anyway to break out of > this looop after. > if( searching ) > { > report("@"); > usleep(1000); > } > } > Hi Pawan I am reading with interest :) So it sounds like this is a thread safe problem. The thing I don't understand here is open and close are synchronized in RXTXPort.java. I thought that would prevent any thread problems with the linked list. Looking closer, the linked list is actually populated in eventLoop/MonitorThread which is not synchronized. So you may be able to synchronize on an object in RXTXPort.java. A seperate native call would probably be required for the initalization to prevent a deadlock. A solution might involve making finalize_event_info_struct() and initialise_event_info_struct() [uk spelling?] thread safe with glib. http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. html#id2786034 glib also has more robust linked lists which could be used. Thats the indirectly the problem found in termios.c for windows. The disadvantage is we would require linking to glib which is another step for systems that don't come with it. The advantage would be reduced code size we have to maintain. We could borrow bits of glib as the licenses are the same. Another solution might be to just use pthread_mutex_lock and unlock. http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html I don't think that would work on windows though. It would require linking cygwin.dll which would not work with nonGPL projects in practice. -- Trent Jarvi tjarvi _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From zhanglong at adventnet.com Wed Jul 5 20:44:18 2006 From: zhanglong at adventnet.com (zhanglong) Date: Thu, 06 Jul 2006 10:44:18 +0800 Subject: [Rxtx] rxtx can not read data from serialport Message-ID: <44AC7902.8070407@adventnet.com> Dear sir, When I use rxrx2.1-7-bin-r2?I can write data into serialport,But can not read data from serialport on windowsXP. I can not write and read data from serialport on Redhat Linux9.0. I can get serialport list on my machine.And no error with open serialport. I can get and read data from serialport on windowsXP with SUN's javacomm20-win32.zip. How can I read data on windows and write,read data on Linux with rxtx? Best Regards, Zhanglong From tjarvi at qbang.org Thu Jul 6 19:07:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 19:07:13 -0600 (MDT) Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: <44AC7902.8070407@adventnet.com> References: <44AC7902.8070407@adventnet.com> Message-ID: On Thu, 6 Jul 2006, zhanglong wrote: > Dear sir, > > When I use rxrx2.1-7-bin-r2??I can write data into serialport,But can > not read data from serialport on windowsXP. > I can not write and read data from serialport on Redhat Linux9.0. > I can get serialport list on my machine.And no error with open serialport. > > I can get and read data from serialport on windowsXP with SUN's > javacomm20-win32.zip. > > How can I read data on windows and write,read data on Linux with rxtx? > > Hi Zhanglong Make sure that you specify the flow control, timeout and threshold that you want. The defaults may vary between rxtx and Sun. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jul 6 19:10:25 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 19:10:25 -0600 (MDT) Subject: [Rxtx] Controlling Individual Signals DTR and RTS In-Reply-To: References: Message-ID: On Thu, 29 Jun 2006, Chris Pine wrote: > Dear Moussa Ba, > I hope I am not being too forward, but we are having the exact same > issue with needing to control DTR from RXTX in Linux. Did you ever have any > luck figuring it out? > > Thank you very much for your time, > Hi Chris Are you using an unusual serial port? It could be that the port does not support DTR/RTS. Especially if its an inexpensive USB->Serial dongle. I'll double check Linux tomorrow but I'm fairly sure it works. I have verified windows after a questions like yours. Some multiport cards and usb dongles do not support everything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jul 6 19:17:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 19:17:09 -0600 (MDT) Subject: [Rxtx] Locked Ports In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3EB11@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03F3EB11@hqexchange3.dot.state.co.us> Message-ID: Hi Pawan There is an example of doing this in the link I provided below. They make a pointer to the function they want to be thread safe and then use that with the glib functions. I'm not ready to just toss out a quick hack because I'd like to think through this a bit to make sure I understand what types of problems we may run into. The code still hung in the same place after synchronizing the eventLoop? I think that eventLoop needs to be refactored to pull out the initialization code so people do not need to run the monitor. On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did made the eventLoop() call in the Monitor Thread synchronized, it > improved but still see the same problem. > > Your comment >> A solution might involve making finalize_event_info_struct() and >> initialise_event_info_struct() [uk spelling?] thread safe with glib. > > I didn't follow this how I can implement this. I am not a C guy, can you > help me understand how I can implement this? > > Thanks > Pawan Kharbanda > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Wednesday, July 05, 2006 10:49 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] Locked Ports > > On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > >> Trent, >> I did put some debug statements and the "index" returned to me in >> the while loop is "0" (see the code below) and it gets into the >> infinite loop, I can put a break statement but don't know the >> ramifications of it. Can you explain in what scenarios the index can >> be "0" or are we somehow in the native code loosing refrences to the > indexes? >> >> Thanks Again >> Pawan Kharbanda >> >> while( searching ) >> { >> index = master_index; >> >> if( index ) >> { >> while( index->fd != fd && >> index->next ) index = index->next; >> if ( index->fd == fd ) searching = 0; >> } >> else >> report("Index"+index"x"); <<<<<< The code gets > to this statement >> and index is returned as "0" and I don't see anyway to break out of >> this looop after. >> if( searching ) >> { >> report("@"); >> usleep(1000); >> } >> } >> > > Hi Pawan > > I am reading with interest :) > > So it sounds like this is a thread safe problem. > > The thing I don't understand here is open and close are synchronized in > RXTXPort.java. I thought that would prevent any thread problems with > the linked list. Looking closer, the linked list is actually populated > in eventLoop/MonitorThread which is not synchronized. > > So you may be able to synchronize on an object in RXTXPort.java. A > seperate native call would probably be required for the initalization to > prevent a deadlock. > > A solution might involve making finalize_event_info_struct() and > initialise_event_info_struct() [uk spelling?] thread safe with glib. > > http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. > html#id2786034 > > glib also has more robust linked lists which could be used. Thats the > indirectly the problem found in termios.c for windows. The disadvantage > is we would require linking to glib which is another step for systems > that don't come with it. The advantage would be reduced code size we > have to maintain. We could borrow bits of glib as the licenses are the > same. > > Another solution might be to just use pthread_mutex_lock and unlock. > > http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html > > I don't think that would work on windows though. It would require > linking cygwin.dll which would not work with nonGPL projects in > practice. > > -- > Trent Jarvi > tjarvi > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Pawan.Kharbanda at dot.state.co.us Thu Jul 6 21:46:08 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 6 Jul 2006 21:46:08 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EB35@hqexchange3.dot.state.co.us> Trent, Just curious to know if you were able to replicate the problem with my example? Pawan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, July 06, 2006 7:17 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports Hi Pawan There is an example of doing this in the link I provided below. They make a pointer to the function they want to be thread safe and then use that with the glib functions. I'm not ready to just toss out a quick hack because I'd like to think through this a bit to make sure I understand what types of problems we may run into. The code still hung in the same place after synchronizing the eventLoop? I think that eventLoop needs to be refactored to pull out the initialization code so people do not need to run the monitor. On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did made the eventLoop() call in the Monitor Thread synchronized, > it improved but still see the same problem. > > Your comment >> A solution might involve making finalize_event_info_struct() and >> initialise_event_info_struct() [uk spelling?] thread safe with glib. > > I didn't follow this how I can implement this. I am not a C guy, can > you help me understand how I can implement this? > > Thanks > Pawan Kharbanda > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Wednesday, July 05, 2006 10:49 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] Locked Ports > > On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > >> Trent, >> I did put some debug statements and the "index" returned to me in >> the while loop is "0" (see the code below) and it gets into the >> infinite loop, I can put a break statement but don't know the >> ramifications of it. Can you explain in what scenarios the index can >> be "0" or are we somehow in the native code loosing refrences to the > indexes? >> >> Thanks Again >> Pawan Kharbanda >> >> while( searching ) >> { >> index = master_index; >> >> if( index ) >> { >> while( index->fd != fd && >> index->next ) index = index->next; >> if ( index->fd == fd ) searching = 0; >> } >> else >> report("Index"+index"x"); <<<<<< The code gets > to this statement >> and index is returned as "0" and I don't see anyway to break out of >> this looop after. >> if( searching ) >> { >> report("@"); >> usleep(1000); >> } >> } >> > > Hi Pawan > > I am reading with interest :) > > So it sounds like this is a thread safe problem. > > The thing I don't understand here is open and close are synchronized > in RXTXPort.java. I thought that would prevent any thread problems > with the linked list. Looking closer, the linked list is actually > populated in eventLoop/MonitorThread which is not synchronized. > > So you may be able to synchronize on an object in RXTXPort.java. A > seperate native call would probably be required for the initalization > to prevent a deadlock. > > A solution might involve making finalize_event_info_struct() and > initialise_event_info_struct() [uk spelling?] thread safe with glib. > > http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. > html#id2786034 > > glib also has more robust linked lists which could be used. Thats the > indirectly the problem found in termios.c for windows. The > disadvantage is we would require linking to glib which is another step > for systems that don't come with it. The advantage would be reduced > code size we have to maintain. We could borrow bits of glib as the > licenses are the same. > > Another solution might be to just use pthread_mutex_lock and unlock. > > http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html > > I don't think that would work on windows though. It would require > linking cygwin.dll which would not work with nonGPL projects in > practice. > > -- > Trent Jarvi > tjarvi > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jul 6 21:53:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 21:53:49 -0600 (MDT) Subject: [Rxtx] Locked Ports In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3EB35@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03F3EB35@hqexchange3.dot.state.co.us> Message-ID: Pawan: I'm sure I can reproduce the problem. What you have described makes very good sense and has changed how I think about rxtx. 64 ports. Take your design specs and write 'open source' on them. On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > Trent, > Just curious to know if you were able to replicate the problem > with my example? > > Pawan > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Thursday, July 06, 2006 7:17 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] Locked Ports > > > Hi Pawan > > There is an example of doing this in the link I provided below. They > make a pointer to the function they want to be thread safe and then use > that with the glib functions. > > I'm not ready to just toss out a quick hack because I'd like to think > through this a bit to make sure I understand what types of problems we > may run into. > > The code still hung in the same place after synchronizing the eventLoop? > > > > > I think that eventLoop needs to be refactored to pull out the > initialization code so people do not need to run the monitor. > > On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > >> Trent, >> I did made the eventLoop() call in the Monitor Thread synchronized, >> it improved but still see the same problem. >> >> Your comment >>> A solution might involve making finalize_event_info_struct() and >>> initialise_event_info_struct() [uk spelling?] thread safe with glib. >> >> I didn't follow this how I can implement this. I am not a C guy, can >> you help me understand how I can implement this? >> >> Thanks >> Pawan Kharbanda >> >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > >> Of Trent Jarvi >> Sent: Wednesday, July 05, 2006 10:49 PM >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] Locked Ports >> >> On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: >> >>> Trent, >>> I did put some debug statements and the "index" returned to me in >>> the while loop is "0" (see the code below) and it gets into the >>> infinite loop, I can put a break statement but don't know the >>> ramifications of it. Can you explain in what scenarios the index can >>> be "0" or are we somehow in the native code loosing refrences to the >> indexes? >>> >>> Thanks Again >>> Pawan Kharbanda >>> >>> while( searching ) >>> { >>> index = master_index; >>> >>> if( index ) >>> { >>> while( index->fd != fd && >>> index->next ) index = index->next; >>> if ( index->fd == fd ) searching = 0; >>> } >>> else >>> report("Index"+index"x"); <<<<<< The code gets >> to this statement >>> and index is returned as "0" and I don't see anyway to break out of >>> this looop after. >>> if( searching ) >>> { >>> report("@"); >>> usleep(1000); >>> } >>> } >>> >> >> Hi Pawan >> >> I am reading with interest :) >> >> So it sounds like this is a thread safe problem. >> >> The thing I don't understand here is open and close are synchronized >> in RXTXPort.java. I thought that would prevent any thread problems >> with the linked list. Looking closer, the linked list is actually >> populated in eventLoop/MonitorThread which is not synchronized. >> >> So you may be able to synchronize on an object in RXTXPort.java. A >> seperate native call would probably be required for the initalization >> to prevent a deadlock. >> >> A solution might involve making finalize_event_info_struct() and >> initialise_event_info_struct() [uk spelling?] thread safe with glib. >> >> > http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. >> html#id2786034 >> >> glib also has more robust linked lists which could be used. Thats the > >> indirectly the problem found in termios.c for windows. The >> disadvantage is we would require linking to glib which is another step > >> for systems that don't come with it. The advantage would be reduced >> code size we have to maintain. We could borrow bits of glib as the >> licenses are the same. >> >> Another solution might be to just use pthread_mutex_lock and unlock. >> >> http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html >> >> I don't think that would work on windows though. It would require >> linking cygwin.dll which would not work with nonGPL projects in >> practice. >> >> -- >> Trent Jarvi >> tjarvi >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pascal at quies.net Fri Jul 7 08:45:59 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Fri, 7 Jul 2006 16:45:59 +0200 Subject: [Rxtx] Java installer Message-ID: <200607071645.59765.pascal@quies.net> Hello everybody, We need a *simple* installer for the RXTX extension. I'm working on a pure Java installer right now. Let's get this thing working over the weekend. The license of choise is the modified BSD license. My plan is to make a JAR with: * the RXTX binaries * a simple API to detect any installed version * a simple Swing installer * a executeable detector: java -jar communicationapi.jar detect javax.comm * a executable installer: java -jar communicationapi.jar install gnu.io * Java 1.2 compatible Comments? _The Java API_: class CommunicationAPI { CommunicationAPI() CommunicationAPI(String path) boolean available() boolean supportsRS232() boolean supportsRS485() boolean supportsI2C() boolean supportsIEEE1280() static void main(String[] args) static boolean installRXTX(boolean headless) } Comments? To get this working we need binaries. Who is having what? The package from the official site has the following: * Linux: i686, x86_64, ia64 * Solaris: sparc32, sparc64 * Windows: i386 Now that's a start. I had to modify the code (what a mess!) to get it working on OpenBSD but I don't have the time to get it working for every platform. Any help here? From j.a.horsmeier at wanadoo.nl Fri Jul 7 09:11:24 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Fri, 7 Jul 2006 17:11:24 +0200 Subject: [Rxtx] Java installer In-Reply-To: <200607071645.59765.pascal@quies.net> Message-ID: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> > Pascal S. de Kloe wrote: > We need a *simple* installer for the RXTX extension. > I'm working on a pure Java installer right now. Let's get > this thing working > over the weekend. The license of choise is the modified BSD license. > > My plan is to make a JAR with: > * the RXTX binaries > * a simple API to detect any installed version > * a simple Swing installer > * a executeable detector: java -jar communicationapi.jar > detect javax.comm > * a executable installer: java -jar communicationapi.jar > install gnu.io > * Java 1.2 compatible > > Comments? Have a look at IzPack: http://www.izforge.com/izpack/ I use it all the time to install rxtx as part of our application. kind regards, Jos From brian at mbari.org Fri Jul 7 10:01:27 2006 From: brian at mbari.org (Brian Schlining) Date: Fri, 7 Jul 2006 09:01:27 -0700 Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: <44AC7902.8070407@adventnet.com> References: <44AC7902.8070407@adventnet.com> Message-ID: On Jul 5, 2006, at 7:44 PM, zhanglong wrote: > Dear sir, > > When I use rxrx2.1-7-bin-r2?I can write data into serialport,But can > not read data from serialport on windowsXP. > I can not write and read data from serialport on Redhat Linux9.0. > I can get serialport list on my machine.And no error with open > serialport. > > I can get and read data from serialport on windowsXP with SUN's > javacomm20-win32.zip. > > How can I read data on windows and write,read data on Linux with rxtx? On windows, if all else fails you may need to use this flow control: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_IN); Also, for some command/response applications that I've tried with RXTX, I find that if I write to the serialport and then immediately try to read from it I get byte arrays filled with zeros, no matter what I set the recieveTimeout to (this has occurred on both Mac OS X and Windows). The workaround that I found was to very briefly put the I/O thread to sleep, like so: // DO set up and get I/O streams //in = serialPort.getInputStream(); //out = serialPort.getOutputStream(); out.write(someByteArray); try { Thread.sleep(10); catch (InterruptedException e) { // handle exception } in.read(anotherByteArray); Note: I've never had to put the thread to sleep using Java comm, only with RXTX. Anyone know why this might be? Cheers B Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060707/f0799573/attachment-0357.html From pascal at quies.net Fri Jul 7 16:55:03 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 00:55:03 +0200 Subject: [Rxtx] Java installer In-Reply-To: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> Message-ID: <200607080055.04501.pascal@quies.net> Op vrijdag 7 juli 2006 17:11, schreef Jos A. Horsmeier: > > Pascal S. de Kloe wrote: > > > > We need a *simple* installer for the RXTX extension. > > I'm working on a pure Java installer right now. Let's get > > this thing working > > over the weekend. The license of choise is the modified BSD license. > > > > My plan is to make a JAR with: > > * the RXTX binaries > > * a simple API to detect any installed version > > * a simple Swing installer > > * a executeable detector: java -jar communicationapi.jar > > detect javax.comm > > * a executable installer: java -jar communicationapi.jar > > install gnu.io > > * Java 1.2 compatible > > > > Comments? > > Have a look at IzPack: http://www.izforge.com/izpack/ > I use it all the time to install rxtx as part of our application. Hello Jos, Thanks for the idea. Could you publish the IzPack configuration and the binaries? That would be very helpful since the current installation procedure is somewhat "unprofessional". ;) IzPack is great but this API is a little more than that. It allows java applications who require the extension to detect available versions and install RXTX on the fly if needed. Is Izpack: * able to install binaries for the right platform (os + hardware architecture)? * Java 1.2 compatible * able to run from the command line? I need as many pre-compiled binaries as possible. Could you help me with that? The detection system already works. Thanks again, Pascal PS Is the gnu.io namespace still necessary? I couldn't find the problem. From naranjo.manuel at gmail.com Fri Jul 7 17:04:31 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 07 Jul 2006 20:04:31 -0300 Subject: [Rxtx] Java installer In-Reply-To: <200607080055.04501.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: <44AEE87F.60202@gmail.com> Pascal: I will be a little short with my answer but very informative :) > Could you publish the IzPack configuration and the binaries? That would be > very helpful since the current installation procedure is > somewhat "unprofessional". ;) > > IzPack is great but this API is a little more than that. It allows java > applications who require the extension to detect available versions and > install RXTX on the fly if needed. > > Is Izpack: > * able to install binaries for the right platform (os + hardware > architecture)? Yes. > * Java 1.2 compatible Yes of course > * able to run from the command line? Yes, and can run from command line detecting which is the underlaying os. I have attached an old version of one of my installer, I can't find the last one, but it is like this one. In this you will see how to detect the OS and architecture and install binaries for that plataform. Regards, Manuel -------------- next part -------------- A non-text attachment was scrubbed... Name: installer.xml Type: text/xml Size: 4683 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060707/fbc3be3c/installer-0357.xml From pascal at quies.net Fri Jul 7 18:35:29 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 02:35:29 +0200 Subject: [Rxtx] Java installer In-Reply-To: <44AEE87F.60202@gmail.com> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <44AEE87F.60202@gmail.com> Message-ID: <200607080235.29486.pascal@quies.net> Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: > > Is Izpack: > > * able to install binaries for the right platform (os + hardware > > architecture)? > > Yes. > > > * Java 1.2 compatible > > Yes of course > > > * able to run from the command line? > > Yes, and can run from command line detecting which is the underlaying os. > I have attached an old version of one of my installer, I can't find the > last one, but it is like this one. In this you will see how to detect > the OS and architecture and install binaries for that plataform. > Regards, > Manuel You are right. IzPack looks like the right tool for this job. As far as I can see there is no commandline support but I'll get over it. ;) I'll link my detection system to the IzPack installation procedure and publish the results. From tjarvi at qbang.org Fri Jul 7 19:00:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 7 Jul 2006 19:00:56 -0600 (MDT) Subject: [Rxtx] Controlling Individual Signals DTR and RTS In-Reply-To: References: Message-ID: On Thu, 6 Jul 2006, Trent Jarvi wrote: > On Thu, 29 Jun 2006, Chris Pine wrote: > >> Dear Moussa Ba, >> I hope I am not being too forward, but we are having the exact same >> issue with needing to control DTR from RXTX in Linux. Did you ever have any >> luck figuring it out? >> >> Thank you very much for your time, >> > > Hi Chris > > Are you using an unusual serial port? It could be that the port does not > support DTR/RTS. Especially if its an inexpensive USB->Serial dongle. > > I'll double check Linux tomorrow but I'm fairly sure it works. I have > verified windows after a questions like yours. Some multiport cards and > usb dongles do not support everything. > I double checked that DTR and RTS are working. The system was a 64 bit opteron with an inexexpensive dual port serial card. Suse 9.3 rxtx 2.1-7 (final). I just used the demo SerialBlackBox that used to come with commapi modified to use rxtx 2.1. The serial card was a NetMos PCI NM9835CV with a 16C550 high speed UART dual port. These are not expensive cards. Everything worked fine. I could see the voltage flipping back and forth on the scope for both DTR(pin 4) and CTS(pin 7). You are not the first to report problems. But everytime I try to reproduce the problem, it appears to work. I suspect it is either hardware or kernel driver related and not specific to RXTX. Note that playing with RTS and DTR with hardware flow control enabled does not make sense as those pins are used for the flow control. I've not looked at many USB serial dongles but I have noticed that some are not as good as others. I think one lacked DTR/CTS support. Another one appeared to be fully functional. The one I noticed no issues with was the Hawking Tech HUC232S on windows. I did not test it on Mac OS X or Linux. The same variability can be observed with multiport serial cards. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jul 7 19:15:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 7 Jul 2006 19:15:06 -0600 (MDT) Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: References: <44AC7902.8070407@adventnet.com> Message-ID: On Fri, 7 Jul 2006, Brian Schlining wrote: > Also, for some command/response applications that I've tried with RXTX, I > find that if I write to the serialport and then immediately try to read from > it I get byte arrays filled with zeros, no matter what I set the > recieveTimeout to (this has occurred on both Mac OS X and Windows). The > workaround that I found was to very briefly put the I/O thread to sleep, like > so: > > // DO set up and get I/O streams > //in = serialPort.getInputStream(); > //out = serialPort.getOutputStream(); > > out.write(someByteArray); > try { > Thread.sleep(10); > catch (InterruptedException e) { > // handle exception > } > in.read(anotherByteArray); > > Note: I've never had to put the thread to sleep using Java comm, only with > RXTX. Anyone know why this might be? Hi Brian Interesting. Is this something that can be reproduced with a loopback connection or something commonly available? I was unaware of this behavior. Is it restricted to something that quickly opens, writes, reads and closes the port by chance? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jul 7 19:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 7 Jul 2006 19:39:37 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607080055.04501.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > Is the gnu.io namespace still necessary? I couldn't find the problem. Hi Pascal CommAPI is a little different in that it was grandfathered into the javax namespace with its own license at the time. It is my understanding that if CommAPI went through the JSR process, anyone would _clearly_ be able to implement a javax.comm package and RXTX would then be one of the first to do so. I believe Doug has expressed some interest in RXTX trying to work with the JSR process. Besides the license questions, there is the fact that RXTX has extensions to CommAPI which could cause confusion in the namespace. Not being a lawyer and *really* not liking to talk to lawyers in my free time, it is better to be safe than sorry. The lawyers tend to come in wolf packs when they do come. There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay there as long as we are just geeks trying to figure out if a license does or does not allow us to implement in the javax.comm namespace. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Sat Jul 8 05:30:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 13:30:24 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: <200607081330.24381.pascal@quies.net> Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > > Is the gnu.io namespace still necessary? I couldn't find the problem. > > Hi Pascal > > CommAPI is a little different in that it was grandfathered into the javax > namespace with its own license at the time. > > It is my understanding that if CommAPI went through the JSR process, > anyone would _clearly_ be able to implement a javax.comm package and RXTX > would then be one of the first to do so. I believe Doug has expressed > some interest in RXTX trying to work with the JSR process. > > Besides the license questions, there is the fact that RXTX has extensions > to CommAPI which could cause confusion in the namespace. Not being a > lawyer and *really* not liking to talk to lawyers in my free time, it is > better to be safe than sorry. The lawyers tend to come in wolf packs > when they do come. > > There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay > there as long as we are just geeks trying to figure out if a license does > or does not allow us to implement in the javax.comm namespace. Nicely said. :) The whole point of namespaces is to create a universal registry of, in this case, classes. This gnu.io namespace is very inconvenient. We feel the same way about lawyers. However I'd like to go into the details of the license (see attachment) if you don't mind? The first license does not apply since RXTX does not use the software. The second one at point 3 specifies our options. > 3. You may not modify the Java Platform Interface ("JPI", identified as > classes contained within the "java" package or any subpackages of the > "java" package), by creating additional classes within the JPI or otherwise > causing the addition to or modification of the classes in the JPI. RXTX is a extension. > In the event that you create an additional class and associated API(s) > which (i) extends the functionality of the Java platform, and (ii) is > exposed to third party software developers for the purpose of developing > additional software which invokes such additional API, you must promptly > publish broadly an accurate specification for such API for free use by all > developers. That's the way we operate. :) > You may not create, or authorize your licensees to create additional > classes, interfaces, or subpackages that are in any way identified as > "java", "javax", "sun" or similar convention as specified by Sun in any > naming convention designation. They don't want additional components in the Communication API since they don't want a mess in theire namespace. So we *can* use javax.comm for the core: javax.comm.CommDriver javax.comm.CommPort javax.comm.CommPortIdentifier javax.comm.CommPortOwnershipListener javax.comm.NoSuchPortException javax.comm.PortInUseException javax.comm.UnsupportedCommOperationException ...and for the default hardware support: javax.comm.SerialPort javax.comm.SerialPortEvent javax.comm.SerialPortEventListener javax.comm.ParralelPort javax.comm.ParralelPortEvent javax.comm.ParralelPortEventListener ...but RXTX aditional hardware support has to go somewhere else like: org.rxtx.RS485Port org.rxtx.RS485PortEvent org.rxtx.RS485PortEventListener org.rxtx.I2CPort org.rxtx.I2CPortEvent org.rxtx.I2CPortEventListener Right? -------------- next part -------------- Sun Microsystems, Inc. Binary Code License Agreement READ THE TERMS OF THIS AGREEMENT AND ANY PROVIDED SUPPLEMENTAL LICENSE TERMS (COLLECTIVELY "AGREEMENT") CAREFULLY BEFORE OPENING THE SOFTWARE MEDIA PACKAGE. BY OPENING THE SOFTWARE MEDIA PACKAGE, YOU AGREE TO THE TERMS OF THIS AGREEMENT. IF YOU ARE ACCESSING THE SOFTWARE ELECTRONICALLY, INDICATE YOUR ACCEPTANCE OF THESE TERMS BY SELECTING THE "ACCEPT" BUTTON AT THE END OF THIS AGREEMENT. IF YOU DO NOT AGREE TO ALL THESE TERMS, PROMPTLY RETURN THE UNUSED SOFTWARE TO YOUR PLACE OF PURCHASE FOR A REFUND OR, IF THE SOFTWARE IS ACCESSED ELECTRONICALLY, SELECT THE "DECLINE" BUTTON AT THE END OF THIS AGREEMENT. 1. LICENSE TO USE. Sun grants you a non-exclusive and non-transferable license for the internal use only of the accompanying software and documentation and any error corrections provided by Sun (collectively "Software"), by the number of users and the class of computer hardware for which the corresponding fee has been paid. 2. RESTRICTIONS. Software is confidential and copyrighted. Title to Software and all associated intellectual property rights is retained by Sun and/or its licensors. Except as specifically authorized in any Supplemental License Terms, you may not make copies of Software, other than a single copy of Software for archival purposes. Unless enforcement is prohibited by applicable law, you may not modify, decompile, or reverse engineer Software. Licensee acknowledges that Licensed Software is not designed or intended for use in the design, construction, operation or maintenance of any nuclear facility. Sun Microsystems, Inc. disclaims any express or implied warranty of fitness for such uses. No right, title or interest in or to any trademark, service mark, logo or trade name of Sun or its licensors is granted under this Agreement. 3. LIMITED WARRANTY. Sun warrants to you that for a period of ninety (90) days from the date of purchase, as evidenced by a copy of the receipt, the media on which Software is furnished (if any) will be free of defects in materials and workmanship under normal use. Except for the foregoing, Software is provided "AS IS". Your exclusive remedy and Sun's entire liability under this limited warranty will be at Sun's option to replace Software media or refund the fee paid for Software. 4. DISCLAIMER OF WARRANTY. UNLESS SPECIFIED IN THIS AGREEMENT, ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT THESE DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. 5.LIMITATION OF LIABILITY. TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF OR RELATED TO THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. In no event will Sun's liability to you, whether in contract, tort (including negligence), or otherwise, exceed the amount paid by you for Software under this Agreement. The foregoing limitations will apply even if the above stated warranty fails of its essential purpose. 6. TERMINATION. This Agreement is effective until terminated. You may terminate this Agreement at any time by destroying all copies of Software. This Agreement will terminate immediately without notice from Sun if you fail to comply with any provision of this Agreement. Upon Termination, you must destroy all copies of Software. 7. EXPORT REGULATIONS. All Software and technical data delivered under this Agreement are subject to US export control laws and may be subject to export or import regulations in other countries. You agree to comply strictly with all such laws and regulations and acknowledge that you have the responsibility to obtain such licenses to export, re-export, or import as may be required after delivery to you. 8. U.S. GOVERNMENT RESTRICTED RIGHTS. If Software is being acquired by or on behalf of the U.S. Government or by a U.S. Government prime contractor or subcontractor (at any tier), then the Government's rights in Software and accompanying documentation will be only as set forth in this Agreement; this is in accordance with 48 CFR 227.7201 through 227.7202-4 (for Department of Defense (DOD) acquisitions) and with 48 CFR 2.101 and 12.212 (for non-DOD acquisitions). 9. GOVERNING LAW. Any action related to this Agreement will be governed by California law and controlling U.S. federal law. No choice of law rules of any jurisdiction will apply. 10, SEVERABILITY. If any provision of this Agreement is held to be unenforceable, this Agreement will remain in effect with the provision omitted, unless omission would frustrate the intent of the parties, in which case this Agreement will immediately terminate. 11. INTEGRATION This Agreement is the entire agreement between you and Sun relating to its subject matter. It supersedes all prior or contemporaneous oral or written communications, proposals, representations and warranties and prevails over any conflicting or additional terms of any quote, order, acknowledgment, or other communication between the parties relating to its subject matter during the term of this Agreement. No modification of this Agreement will be binding, unless in writing and signed by an authorized representative of each party. JAVA OPTIONAL PACKAGE JAVAX.COMM 3.0 SUPPLEMENTAL LICENSE TERMS These supplemental license terms ("Supplemental Terms") add to or modify the terms of the Binary Code License Agreement (collectively, the "Agreement"). Capitalized terms not defined in these Supplemental Terms shall have the same meanings ascribed to them in the Agreement. These Supplemental Terms shall supersede any inconsistent or conflicting terms in the Agreement, or in any license contained within the Software. 1. Software Internal Use and Development License Grant. Subject to the terms and conditions of this Agreement, including, but not limited to Section 3 (Java(TM) Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce internally and use internally the binary form of the Software, complete and unmodified, for the sole purpose of designing, developing and testing your Java applets and applications ("Programs"). 2. License to Distribute Software. In addition to the license granted in Section 1 (Software Internal Use and Development License Grant) of these Supplemental Terms, subject to the terms and conditions of this Agreement, including but not limited to, Section 3 (Java Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce and distribute the Software in binary code form only, provided that you (i) distribute the Software complete and unmodified and only bundled as part of your Programs, (ii) do not distribute additional software intended to replace any component(s) of the Software, (iii) do not remove or alter any proprietary legends or notices contained in the Software, (iv) only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (v) agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software. 3. Java Technology Restrictions. You may not modify the Java Platform Interface ("JPI", identified as classes contained within the "java" package or any subpackages of the "java" package), by creating additional classes within the JPI or otherwise causing the addition to or modification of the classes in the JPI. In the event that you create an additional class and associated API(s) which (i) extends the functionality of the Java platform, and (ii) is exposed to third party software developers for the purpose of developing additional software which invokes such additional API, you must promptly publish broadly an accurate specification for such API for free use by all developers. You may not create, or authorize your licensees to create additional classes, interfaces, or subpackages that are in any way identified as "java", "javax", "sun" or similar convention as specified by Sun in any naming convention designation. 4. Trademarks and Logos. You acknowledge and agree as between you and Sun that Sun owns the SUN, SOLARIS, JAVA, JINI, FORTE, and iPLANET trademarks and all SUN, SOLARIS, JAVA, JINI, FORTE, and iPLANET-related trademarks, service marks, logos and other brand designations ("Sun Marks"), and you agree to comply with the Sun Trademark and Logo Usage Requirements currently located at http://www.sun.com/policies/trademarks. Any use you make of the Sun Marks inures to Sun's benefit. 5. Source Code. Software may contain source code that is provided solely for reference purposes pursuant to the terms of this Agreement. Source code may not be redistributed unless expressly provided for in this Agreement. 6. Termination for Infringement. Either party may terminate this Agreement immediately should any Software become, or in either party's opinion be likely to become, the subject of a claim of infringement of any intellectual property right. For inquiries please contact: Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, California 95054. (LFI#143217/Form ID#011801) From tjarvi at qbang.org Sat Jul 8 10:12:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 10:12:55 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607081330.24381.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <200607081330.24381.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> Is the gnu.io namespace still necessary? I couldn't find the problem. >> >> Hi Pascal >> >> CommAPI is a little different in that it was grandfathered into the javax >> namespace with its own license at the time. >> >> It is my understanding that if CommAPI went through the JSR process, >> anyone would _clearly_ be able to implement a javax.comm package and RXTX >> would then be one of the first to do so. I believe Doug has expressed >> some interest in RXTX trying to work with the JSR process. >> >> Besides the license questions, there is the fact that RXTX has extensions >> to CommAPI which could cause confusion in the namespace. Not being a >> lawyer and *really* not liking to talk to lawyers in my free time, it is >> better to be safe than sorry. The lawyers tend to come in wolf packs >> when they do come. >> >> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay >> there as long as we are just geeks trying to figure out if a license does >> or does not allow us to implement in the javax.comm namespace. > > Nicely said. :) > > The whole point of namespaces is to create a universal registry of, in this > case, classes. This gnu.io namespace is very inconvenient. > > We feel the same way about lawyers. However I'd like to go into the details of > the license (see attachment) if you don't mind? > > The first license does not apply since RXTX does not use the software. The > second one at point 3 specifies our options. > >> 3. You may not modify the Java Platform Interface ("JPI", identified as >> classes contained within the "java" package or any subpackages of the >> "java" package), by creating additional classes within the JPI or otherwise >> causing the addition to or modification of the classes in the JPI. > > RXTX is a extension. > >> In the event that you create an additional class and associated API(s) >> which (i) extends the functionality of the Java platform, and (ii) is >> exposed to third party software developers for the purpose of developing >> additional software which invokes such additional API, you must promptly >> publish broadly an accurate specification for such API for free use by all >> developers. > > That's the way we operate. :) > >> You may not create, or authorize your licensees to create additional >> classes, interfaces, or subpackages that are in any way identified as >> "java", "javax", "sun" or similar convention as specified by Sun in any >> naming convention designation. > > They don't want additional components in the Communication API since they > don't want a mess in theire namespace. > > So we *can* use javax.comm for the core: > javax.comm.CommDriver > javax.comm.CommPort > javax.comm.CommPortIdentifier > javax.comm.CommPortOwnershipListener > javax.comm.NoSuchPortException > javax.comm.PortInUseException > javax.comm.UnsupportedCommOperationException > > ...and for the default hardware support: > javax.comm.SerialPort > javax.comm.SerialPortEvent > javax.comm.SerialPortEventListener > javax.comm.ParralelPort > javax.comm.ParralelPortEvent > javax.comm.ParralelPortEventListener > > ...but RXTX aditional hardware support has to go somewhere else like: > org.rxtx.RS485Port > org.rxtx.RS485PortEvent > org.rxtx.RS485PortEventListener > org.rxtx.I2CPort > org.rxtx.I2CPortEvent > org.rxtx.I2CPortEventListener > > Right? > I do not disagree with anything you said :) RXTX and Sun agree with each other almost completely but not exactly. I think there are three uses of CommAPI and Sun is mainly interested in one. 1) Point of sale. This is the direction Sun is going with limited resources thats causing some problems. They would obviously cause fewer problems with more resources just like rxtx would work with them better with more resources. I'm sure if you talk to people in this area they are very optimitsic about what CommAPI could be. 2) Instrument Control. This is my area of interest as its my job too. I'm still formulating opinions here and it is far to early to say much but I'm very optimistic about what CommAPI could be. 3) Hobby and other hardware control. Circuts, road signs, rxtx in cell phones controlling TVs, you name it. People asking about palm, wince, embeded hardware. This is why I thought it was important to open source rxtx in the beginning and still find it my primary motive to read rxtx email every morning and evening. The optimism here is abundant and self explained. Nothing would make me happier than having someone get a working demo of controlling LEDs with parallel ports that could be used by people learning. So everyone agrees with almost everything. Nobody is looking for conflicts. But these various interests have not been _clearly_ formalized. Licenses are tools for manipulating behavior. Until the above is clearly in line with each other, the license will be a tool for lawyers to cause problems for people working for free. This is why I support a move to go through the JSR process and formalize the relationship. My concern is not really Sun comming after RXTX with Lawyers. I have a great deal of respect for Sun going back to their sunsite project. My concern is how lawyers think. They look at the intent which is not all in line. Then I get what feels like insane conference calls that cost companies over $2000 an hour which pisses me off to no end. Companies paying lawyers to take time from developers for free. This really does happen when a fortune 50 company developer asks their legal department if they can use rxtx. I don't have enough bullets for that. The way you avoid this is formalize everones intent so lawyers don't make conference call meetings in outlook. I want to put those lawyers out of work and if it takes a little discomfort, thats perfectly fine. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Sat Jul 8 11:44:40 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 19:44:40 +0200 Subject: [Rxtx] Fwd: Re: Java installer Message-ID: <200607081944.41123.pascal@quies.net> For some reason the first mail failed... ---------- Doorgestuurd bericht ---------- Subject: Re: [Rxtx] Java installer Date: zaterdag 8 juli 2006 17:18 From: "Pascal S. de Kloe" To: RXTX Developers and Users Hello Manuel, In case of a JDK the installation goes into the "jre" directory. I can't find a simple way to get this information into a variable of IzPack. (see attachment) Do you have a idea? Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: > Pascal: > I will be a little short with my answer but very informative :) > > > Could you publish the IzPack configuration and the binaries? That would > > be very helpful since the current installation procedure is > > somewhat "unprofessional". ;) > > > > IzPack is great but this API is a little more than that. It allows java > > applications who require the extension to detect available versions and > > install RXTX on the fly if needed. > > > > Is Izpack: > > * able to install binaries for the right platform (os + hardware > > architecture)? > > Yes. > > > * Java 1.2 compatible > > Yes of course > > > * able to run from the command line? > > Yes, and can run from command line detecting which is the underlaying os. > I have attached an old version of one of my installer, I can't find the > last one, but it is like this one. In this you will see how to detect > the OS and architecture and install binaries for that plataform. > Regards, > Manuel ------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: izpack.xml Type: text/xml Size: 1401 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060708/413315d2/izpack-0356.xml From joachim at buechse.de Sat Jul 8 10:02:18 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 8 Jul 2006 18:02:18 +0200 Subject: [Rxtx] Java installer In-Reply-To: <200607080055.04501.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: <7D4FA261-44FA-4A6E-8EB9-7A7B0116BB2C@buechse.de> Hello Pascal, as soon as the 2.1.8 version is "released" I'll happily provide you with a precompiled library for Mac OSX. The currently tagged version is 2.17 which has a non standard implementation for OSX. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 08.07.2006, at 00:55, Pascal S. de Kloe wrote: > > I need as many pre-compiled binaries as possible. > Could you help me with that? > > The detection system already works. > > Thanks again, > > Pascal > > > PS > Is the gnu.io namespace still necessary? I couldn't find the problem. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 8 09:18:09 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 17:18:09 +0200 Subject: [Rxtx] Java installer In-Reply-To: <44AEE87F.60202@gmail.com> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <44AEE87F.60202@gmail.com> Message-ID: <200607081718.09605.pascal@quies.net> Hello Manuel, In case of a JDK the installation goes into the "jre" directory. I can't find a simple way to get this information into a variable of IzPack. (see attachment) Do you have a idea? Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: > Pascal: > I will be a little short with my answer but very informative :) > > > Could you publish the IzPack configuration and the binaries? That would > > be very helpful since the current installation procedure is > > somewhat "unprofessional". ;) > > > > IzPack is great but this API is a little more than that. It allows java > > applications who require the extension to detect available versions and > > install RXTX on the fly if needed. > > > > Is Izpack: > > * able to install binaries for the right platform (os + hardware > > architecture)? > > Yes. > > > * Java 1.2 compatible > > Yes of course > > > * able to run from the command line? > > Yes, and can run from command line detecting which is the underlaying os. > I have attached an old version of one of my installer, I can't find the > last one, but it is like this one. In this you will see how to detect > the OS and architecture and install binaries for that plataform. > Regards, > Manuel -------------- next part -------------- A non-text attachment was scrubbed... Name: izpack.xml Type: text/xml Size: 1401 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060708/fa6f5a81/izpack-0356.xml From naranjo.manuel at gmail.com Sat Jul 8 12:52:23 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 15:52:23 -0300 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607081944.41123.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> Message-ID: <44AFFEE7.3090306@gmail.com> Pascal: I can't get exactly your point, but my installer was to avoid modifying the users JDK or JRE. Download this app made by me, and you will get my point: http://www.aircable.net/downloads/AIRcable_Configuration_Utility_v0.2_ALPHA_1.zip, this app bundles RXTX library inside the zip file, and does not need RXTX installed on the Users system. Manuel > For some reason the first mail failed... > > > ---------- Doorgestuurd bericht ---------- > > Subject: Re: [Rxtx] Java installer > Date: zaterdag 8 juli 2006 17:18 > From: "Pascal S. de Kloe" > To: RXTX Developers and Users > > Hello Manuel, > > In case of a JDK the installation goes into the "jre" directory. > I can't find a simple way to get this information into a variable of IzPack. > (see attachment) > > Do you have a idea? > > Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: >> Pascal: >> I will be a little short with my answer but very informative :) >> >>> Could you publish the IzPack configuration and the binaries? That would >>> be very helpful since the current installation procedure is >>> somewhat "unprofessional". ;) >>> >>> IzPack is great but this API is a little more than that. It allows java >>> applications who require the extension to detect available versions and >>> install RXTX on the fly if needed. >>> >>> Is Izpack: >>> * able to install binaries for the right platform (os + hardware >>> architecture)? >> Yes. >> >>> * Java 1.2 compatible >> Yes of course >> >>> * able to run from the command line? >> Yes, and can run from command line detecting which is the underlaying os. >> I have attached an old version of one of my installer, I can't find the >> last one, but it is like this one. In this you will see how to detect >> the OS and architecture and install binaries for that plataform. >> Regards, >> Manuel > > ------------------------------------------------------- > > > ------------------------------------------------------------------------ > > > > > RXTX > 2... > http://www.rxtx.org/ > 1.2 > uninstallRXTX > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Jul 8 12:53:32 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 15:53:32 -0300 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607081944.41123.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> Message-ID: <44AFFF2C.8090005@gmail.com> Even more, the variable ${CURRENT_JRE} referees to the actuall JVM as far as I know, so you will have no difference in installing towards a JDK. > For some reason the first mail failed... > > > ---------- Doorgestuurd bericht ---------- > > Subject: Re: [Rxtx] Java installer > Date: zaterdag 8 juli 2006 17:18 > From: "Pascal S. de Kloe" > To: RXTX Developers and Users > > Hello Manuel, > > In case of a JDK the installation goes into the "jre" directory. > I can't find a simple way to get this information into a variable of IzPack. > (see attachment) > > Do you have a idea? > > Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: >> Pascal: >> I will be a little short with my answer but very informative :) >> >>> Could you publish the IzPack configuration and the binaries? That would >>> be very helpful since the current installation procedure is >>> somewhat "unprofessional". ;) >>> >>> IzPack is great but this API is a little more than that. It allows java >>> applications who require the extension to detect available versions and >>> install RXTX on the fly if needed. >>> >>> Is Izpack: >>> * able to install binaries for the right platform (os + hardware >>> architecture)? >> Yes. >> >>> * Java 1.2 compatible >> Yes of course >> >>> * able to run from the command line? >> Yes, and can run from command line detecting which is the underlaying os. >> I have attached an old version of one of my installer, I can't find the >> last one, but it is like this one. In this you will see how to detect >> the OS and architecture and install binaries for that plataform. >> Regards, >> Manuel > > ------------------------------------------------------- > > > ------------------------------------------------------------------------ > > > > > RXTX > 2... > http://www.rxtx.org/ > 1.2 > uninstallRXTX > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Jul 8 12:54:22 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 15:54:22 -0300 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <200607081330.24381.pascal@quies.net> Message-ID: <44AFFF5E.50603@gmail.com> > > I do not disagree with anything you said :) > > RXTX and Sun agree with each other almost completely but not exactly. I > think there are three uses of CommAPI and Sun is mainly interested in one. > > 1) Point of sale. This is the direction Sun is going with limited > resources thats causing some problems. They would obviously cause fewer > problems with more resources just like rxtx would work with them better > with more resources. I'm sure if you talk to people in this area they are > very optimitsic about what CommAPI could be. > > 2) Instrument Control. This is my area of interest as its my job too. I'm > still formulating opinions here and it is far to early to say much but I'm > very optimistic about what CommAPI could be. > > 3) Hobby and other hardware control. Circuts, road signs, rxtx in cell > phones controlling TVs, you name it. People asking about palm, wince, > embeded hardware. This is why I thought it was important to open source > rxtx in the beginning and still find it my primary motive to read rxtx > email every morning and evening. The optimism here is abundant and self > explained. Nothing would make me happier than having someone get a > working demo of controlling LEDs with parallel ports that could be used by > people learning. > > So everyone agrees with almost everything. Nobody is looking for > conflicts. But these various interests have not been _clearly_ > formalized. Licenses are tools for manipulating behavior. Until the > above is clearly in line with each other, the license will be a tool for > lawyers to cause problems for people working for free. This is why I > support a move to go through the JSR process and formalize the > relationship. > > My concern is not really Sun comming after RXTX with Lawyers. I have a > great deal of respect for Sun going back to their sunsite project. My > concern is how lawyers think. They look at the intent which is not all in > line. Then I get what feels like insane conference calls that cost > companies over $2000 an hour which pisses me off to no end. Companies > paying lawyers to take time from developers for free. This really does > happen when a fortune 50 company developer asks their legal department if > they can use rxtx. I don't have enough bullets for that. > > The way you avoid this is formalize everones intent so lawyers don't > make conference call meetings in outlook. I want to put those lawyers out > of work and if it takes a little discomfort, thats perfectly fine. > > -- > Trent Jarvi > tjarvi at qbang.org > > Trent: GREAT MAIL, I hate lawyers too. From naranjo.manuel at gmail.com Sat Jul 8 07:52:47 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 10:52:47 -0300 Subject: [Rxtx] Java installer In-Reply-To: <200607080235.29486.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <44AEE87F.60202@gmail.com> <200607080235.29486.pascal@quies.net> Message-ID: <44AFB8AF.50403@gmail.com> > > You are right. IzPack looks like the right tool for this job. > > As far as I can see there is no commandline support but I'll get over it. ;) Actually there is a way to execute native app in the Underlaying OS. Check out the JavaDOC and all the documentation given by them. If you need to also generate warper around the jar files, check this projects out: http://launch4j.sourceforge.net and http://jsmooth.sourceforge.net/ I have been able to make and exe with jsmooth that does not need to have RXTX installed if you want I can send the source of it. But it is simple. Do not put the jar inside the exe file, and add to the classpath relative paths to rxtx jar and then your jar file, and then add to the JVM command line (I can't remeber the actual name of it :P) -Djava.library.path=bin\ (Or were ever you installed the binary package). I have tryied doing the same with Java Comm from Sun but it actually is imposible, the main difference to me that make me move to RXTX, was that there is no need to have the javax.comm.properties file, which gave me lot of headaches. Regards, Manuel. From naranjo.manuel at gmail.com Sat Jul 8 08:03:58 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 11:03:58 -0300 Subject: [Rxtx] License question. Message-ID: <44AFBB4E.70808@gmail.com> Hi: I have a question, haven't you ever thought about changing RXTX license from GNU/GPL to a more open license like Apache v2 or BSD like?. As far as I understand if I make an application that uses RXTX libraries, I must release my app under the GNU/GPL. I have no problem with that in fact I'm an Open Source user and defender. The fact is that in same cases the applications made by one, could get into hands of a company that needs to release a Closed Source app. I understand that using GNU/GPL do not give you the power to do this, but a more "open" license like Apache does. By "open" I mean that the license respects the Open Source license, but also lives the user the opportunity to use the library in closed source programs. I have seen that there is an exception to the license that applies to RXTX v2.0-5 and above, the only problem with it is that Java Comm Api (the jar file) needs the file javax.comm.properties installed correctly, which in lot of cases is a headache. RXTX jar does not need this, actually I think that RXTX is more user friendly than Java Comm. Maybe there has been a discussion like this before, but I just wanted to ask, and to get an answer that is adequate to our time. Regards, Manuel From pascal at quies.net Sat Jul 8 14:03:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:03:13 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <44AFFF2C.8090005@gmail.com> References: <200607081944.41123.pascal@quies.net> <44AFFF2C.8090005@gmail.com> Message-ID: <200607082203.13696.pascal@quies.net> Op zaterdag 8 juli 2006 20:53, schreef Manuel Naranjo: > Even more, the variable ${CURRENT_JRE} referees to the actuall JVM as > far as I know, so you will have no difference in installing towards a JDK. As far as the installation instructions go the location of the libraries is the following. Windows * JRE: $JAVA_HOME/bin/ * JDK: $JAVA_HOME/jre/bin/ UNIX * JRE: $JAVA_HOME/lib/ * JRE: $JAVA_HOME/jre/lib/ From pascal at quies.net Sat Jul 8 14:04:50 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:04:50 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <44AFFEE7.3090306@gmail.com> References: <200607081944.41123.pascal@quies.net> <44AFFEE7.3090306@gmail.com> Message-ID: <200607082204.50712.pascal@quies.net> Op zaterdag 8 juli 2006 20:52, schreef Manuel Naranjo: > Pascal: > I can't get exactly your point, but my installer was to avoid modifying > the users JDK or JRE. Download this app made by me, and you will get my > point: > http://www.aircable.net/downloads/AIRcable_Configuration_Utility_v0.2_ALPHA >_1.zip, this app bundles RXTX library inside the zip file, and does not need > RXTX installed on the Users system. > Manuel I didn't get the point indeed and I still don't get it. :$ The installation instructions state that RXTX.jar must be in the classpath and the libraries should go as my previous mail stated. Do you have another way? I don't have Windows so i can't run that EXE. From pascal at quies.net Sat Jul 8 14:05:40 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:05:40 +0200 Subject: [Rxtx] Java installer In-Reply-To: <7D4FA261-44FA-4A6E-8EB9-7A7B0116BB2C@buechse.de> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <7D4FA261-44FA-4A6E-8EB9-7A7B0116BB2C@buechse.de> Message-ID: <200607082205.40527.pascal@quies.net> Op zaterdag 8 juli 2006 18:02, schreef Joachim Buechse: > as soon as the 2.1.8 version is "released" I'll happily provide you ? > with a precompiled library for Mac OSX. The currently tagged version ? > is 2.17 which has a non standard implementation for OSX. Perfect! :) Do you have a idea when that will be? Like this month? From pascal at quies.net Sat Jul 8 14:14:44 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:14:44 +0200 Subject: [Rxtx] Java installer In-Reply-To: <44AFB8AF.50403@gmail.com> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080235.29486.pascal@quies.net> <44AFB8AF.50403@gmail.com> Message-ID: <200607082214.45115.pascal@quies.net> Op zaterdag 8 juli 2006 15:52, schreef Manuel Naranjo: > > You are right. IzPack looks like the right tool for this job. > > > > As far as I can see there is no commandline support but I'll get over it. > > ;) > > Actually there is a way to execute native app in the Underlaying OS. > Check out the JavaDOC and all the documentation given by them. > If you need to also generate warper around the jar files, check this > projects out: > http://launch4j.sourceforge.net and http://jsmooth.sourceforge.net/ > I have been able to make and exe with jsmooth that does not need to > have RXTX installed if you want I can send the source of it. But it is > simple. > Do not put the jar inside the exe file, and add to the classpath > relative paths to rxtx jar and then your jar file, and then add to the > JVM command line (I can't remeber the actual name of it :P) > -Djava.library.path=bin\ (Or were ever you installed the binary package). > I have tryied doing the same with Java Comm from Sun but it actually is > imposible, the main difference to me that make me move to RXTX, was that > there is no need to have the javax.comm.properties file, which gave me > lot of headaches. > Regards, > Manuel. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Those are verry interresting and impressive tools for Windows. However, I wanted (and still do) a universal installer for all supported platforms as a single JAR. IzPack seemed quite suitable but it is limited and not well written so I'me still searching... Thanks for the help though. :) From pascal at quies.net Sat Jul 8 14:19:59 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:19:59 +0200 Subject: [Rxtx] License question. In-Reply-To: <44AFBB4E.70808@gmail.com> References: <44AFBB4E.70808@gmail.com> Message-ID: <200607082219.59514.pascal@quies.net> I thought of the same thing. The modified BSD license would certainly make it more eazy and acceptable for Sun to include RXTX in theire products. Unfortunately in general people who chose GPL don't like other licenses. ;) Op zaterdag 8 juli 2006 16:03, schreef Manuel Naranjo: > Hi: > I have a question, haven't you ever thought about changing RXTX license > from GNU/GPL to a more open license like Apache v2 or BSD like?. > As far as I understand if I make an application that uses RXTX > libraries, I must release my app under the GNU/GPL. I have no problem > with that in fact I'm an Open Source user and defender. > The fact is that in same cases the applications made by one, could get > into hands of a company that needs to release a Closed Source app. I > understand that using GNU/GPL do not give you the power to do this, but > a more "open" license like Apache does. By "open" I mean that the > license respects the Open Source license, but also lives the user the > opportunity to use the library in closed source programs. > I have seen that there is an exception to the license that applies to > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > (the jar file) needs the file javax.comm.properties installed correctly, > which in lot of cases is a headache. RXTX jar does not need this, > actually I think that RXTX is more user friendly than Java Comm. > Maybe there has been a discussion like this before, but I just wanted to > ask, and to get an answer that is adequate to our time. > Regards, > Manuel > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jul 8 15:30:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 15:30:31 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <44AFBB4E.70808@gmail.com> References: <44AFBB4E.70808@gmail.com> Message-ID: On Sat, 8 Jul 2006, Manuel Naranjo wrote: > Hi: > I have a question, haven't you ever thought about changing RXTX license > from GNU/GPL to a more open license like Apache v2 or BSD like?. > As far as I understand if I make an application that uses RXTX > libraries, I must release my app under the GNU/GPL. I have no problem > with that in fact I'm an Open Source user and defender. > The fact is that in same cases the applications made by one, could get > into hands of a company that needs to release a Closed Source app. I > understand that using GNU/GPL do not give you the power to do this, but > a more "open" license like Apache does. By "open" I mean that the > license respects the Open Source license, but also lives the user the > opportunity to use the library in closed source programs. > I have seen that there is an exception to the license that applies to > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > (the jar file) needs the file javax.comm.properties installed correctly, > which in lot of cases is a headache. RXTX jar does not need this, > actually I think that RXTX is more user friendly than Java Comm. > Maybe there has been a discussion like this before, but I just wanted to > ask, and to get an answer that is adequate to our time. > Regards, > Manuel Hi Manuel As one of the primary copyright 'owners' and a representative of all the people who have worked on RXTX I feel very compelled to comment on this. I often observe this misconception and just ignore it. RXTX is very commercial friendly both in open and closed source. The license is LGPL not GPL. This allows for linking to any application you like without sharing yoru application code. It is not unlike Apache or BSD in that sense. I like the BSD license but not in this case. The difference is you can not keep your changes to rxtx itself if your product is distributed in practice. To me this makes no sense and is a basic flaw in BSD licensing for libraries. I have _no_ intentions of "competing" with various incarnations of RXTX. If you use RXTX in your commercial application, I hope for two things. First I want you to do well for using rxtx even if you somehow compete with me in the commercial world. Second I want to see changes to RXTX come back to RXTX so we all do well for choosing RXTX. This is not possible with the BSD, MIT ... licenses. They result in multiple forks from the code and this is used to disrupt 'standards' by companies you would recognize (I no longer mention any company when saying bad things without fair notice). Your code is your code. Thats how the LGPL works. But don't take RXTX and fork it where I or anyone else that has worked on RXTX can see it. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Sat Jul 8 16:06:17 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 00:06:17 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> Message-ID: <200607090006.18197.pascal@quies.net> Op zaterdag 8 juli 2006 23:30, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Manuel Naranjo wrote: > > Hi: > > I have a question, haven't you ever thought about changing RXTX license > > from GNU/GPL to a more open license like Apache v2 or BSD like?. > > As far as I understand if I make an application that uses RXTX > > libraries, I must release my app under the GNU/GPL. I have no problem > > with that in fact I'm an Open Source user and defender. > > The fact is that in same cases the applications made by one, could get > > into hands of a company that needs to release a Closed Source app. I > > understand that using GNU/GPL do not give you the power to do this, but > > a more "open" license like Apache does. By "open" I mean that the > > license respects the Open Source license, but also lives the user the > > opportunity to use the library in closed source programs. > > I have seen that there is an exception to the license that applies to > > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > > (the jar file) needs the file javax.comm.properties installed correctly, > > which in lot of cases is a headache. RXTX jar does not need this, > > actually I think that RXTX is more user friendly than Java Comm. > > Maybe there has been a discussion like this before, but I just wanted to > > ask, and to get an answer that is adequate to our time. > > Regards, > > Manuel > > Hi Manuel > > As one of the primary copyright 'owners' and a representative of all the > people who have worked on RXTX I feel very compelled to comment on this. > I often observe this misconception and just ignore it. > > RXTX is very commercial friendly both in open and closed source. The > license is LGPL not GPL. This allows for linking to any application you > like without sharing yoru application code. It is not unlike Apache or > BSD in that sense. I like the BSD license but not in this case. > > The difference is you can not keep your changes to rxtx itself if your > product is distributed in practice. To me this makes no sense and is a > basic flaw in BSD licensing for libraries. I have _no_ intentions of > "competing" with various incarnations of RXTX. If you use RXTX in your > commercial application, I hope for two things. First I want you to do > well for using rxtx even if you somehow compete with me in the commercial > world. Second I want to see changes to RXTX come back to RXTX so we all > do well for choosing RXTX. > > This is not possible with the BSD, MIT ... licenses. They result in > multiple forks from the code and this is used to disrupt 'standards' by > companies you would recognize (I no longer mention any company when > saying bad things without fair notice). > > Your code is your code. Thats how the LGPL works. But don't take RXTX > and fork it where I or anyone else that has worked on RXTX can see it. > > -- > Trent Jarvi Hallo Trent, The BSD license wants to give and GPL wants to improve the public available content. What do you prefer? If you build the code to provide everyone a better experience then the BSD license would be suitable since the business acceptance is much higher. If you see this as a crucial component to build a complete free Java infrastructure that has no place for commerce then the GPL would be better In both situations RXTX will be free. I say that the chance a company would not contribute does not outweight the chance that the API is less available to the users. The entire API is a dead end. Mustang has USB support. Please let's make this as good as it gets. From tjarvi at qbang.org Sat Jul 8 16:09:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 16:09:31 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <200607082219.59514.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > I thought of the same thing. The modified BSD license would certainly make it > more eazy and acceptable for Sun to include RXTX in theire products. > > Unfortunately in general people who chose GPL don't like other licenses. ;) > If Sun can not accept the license, thats their problem. I have no problem with Sun distributing RXTX and working with the community. I've even stepped down as then primary and given that power to Doug to facilitate different opinions. For licensing changes, I am the primary copyright owner and have very strong opinions though I have a great deal of respect for everyone that has contributed to RXTX. Sun has their process and we have our process - screwy but a process and real. RXTX is not going to rubber stamp into any company without process that gives major power to the contributors to RXTX. There is a community here and it is not Sun's. (It isn't "gnu" either; the license is closest) This isn't about Trent. He is a wierd guy you should fear. That said, I'm not fundamentally against Sun distributing RXTX and changing package names. What I am fundametally against is multiple RXTXs. There isnt enough space for that game. -- Trent Jarvi tarvi at qbang.org From pascal at quies.net Sat Jul 8 16:25:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 00:25:24 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> Message-ID: <200607090025.24884.pascal@quies.net> Op zondag 9 juli 2006 00:09, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > > I thought of the same thing. The modified BSD license would certainly > > make it more eazy and acceptable for Sun to include RXTX in theire > > products. > > > > Unfortunately in general people who chose GPL don't like other licenses. > > ;) > > If Sun can not accept the license, thats their problem. > > I have no problem with Sun distributing RXTX and working with the > community. I've even stepped down as then primary and given that power to > Doug to facilitate different opinions. For licensing changes, I am the > primary copyright owner and have very strong opinions though I have a > great deal of respect for everyone that has contributed to RXTX. > > Sun has their process and we have our process - screwy but a process and > real. RXTX is not going to rubber stamp into any company without process > that gives major power to the contributors to RXTX. There is a community > here and it is not Sun's. (It isn't "gnu" either; the license is closest) > This isn't about Trent. He is a wierd guy you should fear. Hahaha, I found him very reasonable. The LGPL is not going to prevent forks. Any company which would take the code and keep little improvements to theirselves is stupid since they throw away a great deal of support and they know it. RXTX works. It needs a huge cleanup and more strict platform definitions but that's just a matter of time. What do you have to loose? From tjarvi at qbang.org Sat Jul 8 16:33:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 16:33:32 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <200607090025.24884.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> <200607090025.24884.pascal@quies.net> Message-ID: On Sun, 9 Jul 2006, Pascal S. de Kloe wrote: > Op zondag 9 juli 2006 00:09, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> I thought of the same thing. The modified BSD license would certainly >>> make it more eazy and acceptable for Sun to include RXTX in theire >>> products. >>> >>> Unfortunately in general people who chose GPL don't like other licenses. >>> ;) >> >> If Sun can not accept the license, thats their problem. >> >> I have no problem with Sun distributing RXTX and working with the >> community. I've even stepped down as then primary and given that power to >> Doug to facilitate different opinions. For licensing changes, I am the >> primary copyright owner and have very strong opinions though I have a >> great deal of respect for everyone that has contributed to RXTX. >> >> Sun has their process and we have our process - screwy but a process and >> real. RXTX is not going to rubber stamp into any company without process >> that gives major power to the contributors to RXTX. There is a community >> here and it is not Sun's. (It isn't "gnu" either; the license is closest) >> This isn't about Trent. He is a wierd guy you should fear. > > Hahaha, I found him very reasonable. > > The LGPL is not going to prevent forks. No it will not, but it will allow for you or me to view forks and absorb them. It renders forks of RXTX useless at the price of whatever product is shipped. I would ask that you consider the larger picture here. Termios and DCB are almost dead but almost being used like a VISA interface. Everyone just wants it to work but it does not always. So your proposal is to make mulitiple deal protocols? -- Trent Jarvi tjarvi at qbang.org From naranjo.manuel at gmail.com Sat Jul 8 17:20:44 2006 From: naranjo.manuel at gmail.com (Naranjo Manuel Francisco) Date: Sat, 8 Jul 2006 20:20:44 -0300 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> Message-ID: <360bc8300607081620x4e5d0f23h88fef8d81e6b6a0b@mail.gmail.com> Sorry, my mistake then, I thought the license was GPL not LGPL, I guess I readed some thing badly. I have readed all the emails, and you are right, there is no need for a Fork of RXTX, I think it works right as it is. So I can make my app Apache v2 with out any worry, because RXTX is LGPL :), great then. From tjarvi at qbang.org Sat Jul 8 17:57:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 17:57:05 -0600 (MDT) Subject: [Rxtx] License question ver2. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> <200607090025.24884.pascal@quies.net> Message-ID: Are there any more questions relating to this subject? From tjarvi at qbang.org Sat Jul 8 21:14:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 21:14:09 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <200607090006.18197.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607090006.18197.pascal@quies.net> Message-ID: On Sun, 9 Jul 2006, Pascal S. de Kloe wrote: > Op zaterdag 8 juli 2006 23:30, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Manuel Naranjo wrote: >>> Hi: >>> I have a question, haven't you ever thought about changing RXTX license >>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>> As far as I understand if I make an application that uses RXTX >>> libraries, I must release my app under the GNU/GPL. I have no problem >>> with that in fact I'm an Open Source user and defender. >>> The fact is that in same cases the applications made by one, could get >>> into hands of a company that needs to release a Closed Source app. I >>> understand that using GNU/GPL do not give you the power to do this, but >>> a more "open" license like Apache does. By "open" I mean that the >>> license respects the Open Source license, but also lives the user the >>> opportunity to use the library in closed source programs. >>> I have seen that there is an exception to the license that applies to >>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>> (the jar file) needs the file javax.comm.properties installed correctly, >>> which in lot of cases is a headache. RXTX jar does not need this, >>> actually I think that RXTX is more user friendly than Java Comm. >>> Maybe there has been a discussion like this before, but I just wanted to >>> ask, and to get an answer that is adequate to our time. >>> Regards, >>> Manuel >> >> Hi Manuel >> >> As one of the primary copyright 'owners' and a representative of all the >> people who have worked on RXTX I feel very compelled to comment on this. >> I often observe this misconception and just ignore it. >> >> RXTX is very commercial friendly both in open and closed source. The >> license is LGPL not GPL. This allows for linking to any application you >> like without sharing yoru application code. It is not unlike Apache or >> BSD in that sense. I like the BSD license but not in this case. >> >> The difference is you can not keep your changes to rxtx itself if your >> product is distributed in practice. To me this makes no sense and is a >> basic flaw in BSD licensing for libraries. I have _no_ intentions of >> "competing" with various incarnations of RXTX. If you use RXTX in your >> commercial application, I hope for two things. First I want you to do >> well for using rxtx even if you somehow compete with me in the commercial >> world. Second I want to see changes to RXTX come back to RXTX so we all >> do well for choosing RXTX. >> >> This is not possible with the BSD, MIT ... licenses. They result in >> multiple forks from the code and this is used to disrupt 'standards' by >> companies you would recognize (I no longer mention any company when >> saying bad things without fair notice). >> >> Your code is your code. Thats how the LGPL works. But don't take RXTX >> and fork it where I or anyone else that has worked on RXTX can see it. >> >> -- >> Trent Jarvi > > Hallo Trent, > > The BSD license wants to give and GPL wants to improve the public available > content. What do you prefer? > > If you build the code to provide everyone a better experience then the BSD > license would be suitable since the business acceptance is much higher. > If you see this as a crucial component to build a complete free Java > infrastructure that has no place for commerce then the GPL would be better > In both situations RXTX will be free. > > I say that the chance a company would not contribute does not outweight the > chance that the API is less available to the users. > The entire API is a dead end. Mustang has USB support. Please let's make this > as good as it gets. Hi Pascal I can not speak for any company here. I just happen to have become interesting to companies. With RXTX, the intent has always been to improve functionality. I don't play between the two worlds except for borrowing a scope at late in the evening. Thats rxtx and there is nothing else going on. Note that the RXTX library is LGPL. I would be interested in knowing where the GPL confusion comes from. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Jul 9 04:46:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 09 Jul 2006 06:46:49 -0400 Subject: [Rxtx] Java installer In-Reply-To: <200607082214.45115.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080235.29486.pascal@quies.net> <44AFB8AF.50403@gmail.com> <200607082214.45115.pascal@quies.net> Message-ID: Hi All, The problem of improving Java's ability to install and configure applications is a topic of current research. Configuration is a loaded word. When I think of configuration, I think, discover the properties of the operating environment and configure the software to work within that environment. Properties may include, but are not limited to, number and kind of monitors, serial ports, JVM versions, native method libs, graphics cards, graphics libs, write access to directories, changing the default screen saver (a new research topic) etc. There are two deployment solutions I can think of, please correct me, if I have left something out: 1. A source code distro with build tools (i.e., make and or ant) that enable the user to do a build for the target platform. 2. A binary distro built for each platform. Now, Java (in theory), is compile once, run anywhere. This assumes you don't use native methods. Once you start using native methods, you end up with many builds of the libs (one for each supported platform). Assuming you want binary distros for each platform, then you are faced with how to deploy them. Here are two basic approaches I know: 1. Build an application installer 2. Build a web-start distribution Some would argue for the application installer, as this is what many people are used to. Others will argue for a web-start distro. For a JNI-based application, like one that makes use of RXTX, I don't know which approach is "better". To know, one must first establish what "better" means. I think there must be (at least) two properties here: 1. Minimal installation effort 2. Trust. For minimal installation effort, I think that I should be able to download software, on demand, and just run it. Updates are obtained with minimal effort. Everything just works. And on all platforms that I use. For trust, I want to make sure I know the author and am able to hold someone accountable for application creation. I need to be able to thwart man-in-the-middle attacks and assure my user-base that I have signed off on my software. I have been making use of web-start, as a multi-year experiment. I have had mixed results. Particularly with more complex installs that make use of Java3d. In my view, several open problems remain. And cross-platform testing is needed for each major new application, platform, or major native method revision. On the other hand, I have had some good results with Java web start and RXTX. I can cite: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Which is an address book program that should identify your serial port and enable dialing via the modem. The web start system seems to be able to adapt to multiple operating environments. The question of how well this deploys remains open. It should work on mac, windows and linux. If people want to try it and give me feedback, I would appreciate it. Deployment is semi-automatic using Project Initium. This is described in: http://show.docjava.com:8086/pub/document/jot/web.pdf and http://show.docjava.com:8086/pub/document/jot/initium.pdf Thanks! - Doug >Op zaterdag 8 juli 2006 15:52, schreef Manuel Naranjo: >> > You are right. IzPack looks like the right tool for this job. >> > >> > As far as I can see there is no commandline support but I'll get over it. >> > ;) >> >> Actually there is a way to execute native app in the Underlaying OS. >> Check out the JavaDOC and all the documentation given by them. >> If you need to also generate warper around the jar files, check this > > projects out: > > http://launch4j.sourceforge.net and http://jsmooth.sourceforge.net/ > > I have been able to make and exe with jsmooth that does not need to >> have RXTX installed if you want I can send the source of it. But it is >> simple. >> Do not put the jar inside the exe file, and add to the classpath >> relative paths to rxtx jar and then your jar file, and then add to the >> JVM command line (I can't remeber the actual name of it :P) > > -Djava.library.path=bin\ (Or were ever you installed the binary package). >> I have tryied doing the same with Java Comm from Sun but it actually is >> imposible, the main difference to me that make me move to RXTX, was that >> there is no need to have the javax.comm.properties file, which gave me >> lot of headaches. >> Regards, >> Manuel. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >Those are verry interresting and impressive tools for Windows. >However, I wanted (and still do) a universal installer for all supported >platforms as a single JAR. IzPack seemed quite suitable but it is limited and >not well written so I'me still searching... > >Thanks for the help though. :) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 9 05:15:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 13:15:13 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607090006.18197.pascal@quies.net> Message-ID: <200607091315.14053.pascal@quies.net> Op zondag 9 juli 2006 05:14, schreef Trent Jarvi: > Hi Pascal > > I can not speak for any company here. I just happen to have become > interesting to companies. > > With RXTX, the intent has always been to improve functionality. > > I don't play between the two worlds except for borrowing a scope at late > in the evening. Thats rxtx and there is nothing else going on. > > Note that the RXTX library is LGPL. I would be interested in knowing > where the GPL confusion comes from. Hi Trent, The license is stated clearly everywhere so don't worry. You are right that the LGPL should not be a problem for companies. The problem is, especially in larger companies, that the people who take the decissions think differend. When they hear about the demands of the license they rather spend "some" money on a commercial solution just to be sure because the trouble it might cause is not worth it. From pascal at quies.net Sun Jul 9 05:15:41 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 13:15:41 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607090025.24884.pascal@quies.net> Message-ID: <200607091315.41848.pascal@quies.net> Op zondag 9 juli 2006 00:33, schreef Trent Jarvi: > I would ask that you consider the larger picture here. Termios and DCB > are almost dead but almost being used like a VISA interface. Everyone > just wants it to work but it does not always. > > So your proposal is to make mulitiple deal protocols? No, nothing like that. Just use native calls where possible. I'll send you some things this week anyway. From pascal at quies.net Sun Jul 9 05:52:11 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 13:52:11 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607082214.45115.pascal@quies.net> Message-ID: <200607091352.11696.pascal@quies.net> Op zondag 9 juli 2006 12:46, schreef Dr. Douglas Lyon: > Hi All, > The problem of improving Java's ability to > install and configure applications is a topic of current research. > > Configuration is a loaded word. When I think of configuration, > I think, discover the properties of the operating environment and > configure the software to work within that environment. > > Properties may include, but are not limited to, number and > kind of monitors, serial ports, JVM versions, native method libs, > graphics cards, graphics libs, write access to directories, > changing the default screen saver (a new research topic) etc. > > There are two deployment solutions I can think of, > please correct me, if I have left something out: > 1. A source code distro with build tools (i.e., make and or ant) that > enable the user to do a build for the target platform. > 2. A binary distro built for each platform. > > Now, Java (in theory), is compile once, run anywhere. This assumes you > don't use native methods. Once you start using native methods, > you end up with many builds of the libs (one for each supported platform). > > Assuming you want binary distros for each platform, then you are faced with > how to deploy them. Here are two basic approaches I know: > 1. Build an application installer > 2. Build a web-start distribution > > Some would argue for the application installer, as this is what > many people are used to. Others will argue for a web-start distro. > > For a JNI-based application, like one that makes use of RXTX, > I don't know which approach is "better". To know, one must > first establish what "better" means. I think there must be (at least) two > properties here: > 1. Minimal installation effort > 2. Trust. > > For minimal installation effort, I think that I should be able to download > software, on demand, and just run it. Updates are obtained with minimal > effort. Everything just works. And on all platforms that I use. > > For trust, I want to make sure I know the author and am able to hold > someone accountable for application creation. I need to be able to thwart > man-in-the-middle > attacks and assure my user-base that I have signed off on my software. > > I have been making > use of web-start, as a multi-year experiment. > > I have had mixed results. Particularly with more complex installs > that make use of Java3d. In my view, several open problems remain. > And cross-platform testing is needed for each major new application, > platform, or major native method revision. > > On the other hand, I have had some good results with Java web start > and RXTX. I can cite: > http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jn >lp Which is an address book program that should identify your > serial port and enable dialing via the modem. > > The web start system seems to be able to adapt to multiple operating > environments. The question of how well this deploys remains open. > > It should work on mac, windows and linux. If people want to try it > and give me feedback, I would appreciate it. > > Deployment is semi-automatic using Project Initium. This is described in: > http://show.docjava.com:8086/pub/document/jot/web.pdf > and > http://show.docjava.com:8086/pub/document/jot/initium.pdf > > Thanks! > - Doug Hello Dough, We are bumping into the same problems. Youre web-based plan is definitely the way to go. I still didn't find a way to get around two IzPack problems without hacking into the code and it's taking too long so I started again on the inital plan. The CommunicationAPI class does leave the trust thing up to the implementation. This means that users can download and run the JAR and other applications can include the jar to install things if needed. If you could "Initum" this process then RXTX has no installating limits anymore. From joachim at buechse.de Sun Jul 9 07:13:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 9 Jul 2006 15:13:34 +0200 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44AFBB4E.70808@gmail.com> References: <44AFBB4E.70808@gmail.com> Message-ID: <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> Manuel, a simple way to avoid the javax.comm.properties file is to include a class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } into your application jar file and make sure, that you include the javax.comm jar after it. That's all you need. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 08.07.2006, at 16:03, Manuel Naranjo wrote: > Hi: > I have a question, haven't you ever thought about changing RXTX > license > from GNU/GPL to a more open license like Apache v2 or BSD like?. > As far as I understand if I make an application that uses RXTX > libraries, I must release my app under the GNU/GPL. I have no problem > with that in fact I'm an Open Source user and defender. > The fact is that in same cases the applications made by one, could get > into hands of a company that needs to release a Closed Source app. I > understand that using GNU/GPL do not give you the power to do this, > but > a more "open" license like Apache does. By "open" I mean that the > license respects the Open Source license, but also lives the user the > opportunity to use the library in closed source programs. > I have seen that there is an exception to the license that applies to > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > (the jar file) needs the file javax.comm.properties installed > correctly, > which in lot of cases is a headache. RXTX jar does not need this, > actually I think that RXTX is more user friendly than Java Comm. > Maybe there has been a discussion like this before, but I just > wanted to > ask, and to get an answer that is adequate to our time. > Regards, > Manuel > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Sun Jul 9 07:19:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 9 Jul 2006 15:19:43 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607082203.13696.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> <44AFFF2C.8090005@gmail.com> <200607082203.13696.pascal@quies.net> Message-ID: <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> Pascal, I would strongly suggest NOT to follow these installation instructions for OSX. It "poisons" the global Java VM with a specific implementation of RXTX. Plus: there is not one, but several Java VMs installed on every version of OSX. An application specific file and global preference pane defines which VM launches which application. There is really no good reason to install RXTX globally. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 08.07.2006, at 22:03, Pascal S. de Kloe wrote: > > As far as the installation instructions go the location of the > libraries is > the following. > > Windows > * JRE: $JAVA_HOME/bin/ > * JDK: $JAVA_HOME/jre/bin/ > > UNIX > * JRE: $JAVA_HOME/lib/ > * JRE: $JAVA_HOME/jre/lib/ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 9 09:01:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 17:01:24 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> References: <200607081944.41123.pascal@quies.net> <200607082203.13696.pascal@quies.net> <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> Message-ID: <200607091701.24661.pascal@quies.net> Op zondag 9 juli 2006 15:19, schreef Joachim Buechse: > Pascal, > > I would strongly suggest NOT to follow these installation > instructions for OSX. It "poisons" the global Java VM with a specific > implementation of RXTX. Plus: there is not one, but several Java VMs > installed on every version of OSX. An application specific file and > global preference pane defines which VM launches which application. > There is really no good reason to install RXTX globally. I see your points. How can you use the extension non-globally? I asked the same thing for Windows to Manuel. The system will allow you to detect any implementation. So the "poison" becomes a alternative. Applications can install the extension if needed to the current runtime with something like: CommunicationAPI comm = new CommunicationAPI(); if (! comm.available()) { if (comm.installRXTX()) restart(); else handleError("I need the extension!"); } From naranjo.manuel at gmail.com Sun Jul 9 10:36:21 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 09 Jul 2006 13:36:21 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> Message-ID: <44B13085.2000805@gmail.com> Joachim, Does that really work???? I will try it later, thanks :) Manuel > Manuel, > > a simple way to avoid the javax.comm.properties file is to include a > class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > into your application jar file and make sure, that you include the > javax.comm jar after it. That's all you need. > > Regards, > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 08.07.2006, at 16:03, Manuel Naranjo wrote: > >> Hi: >> I have a question, haven't you ever thought about changing RXTX >> license >> from GNU/GPL to a more open license like Apache v2 or BSD like?. >> As far as I understand if I make an application that uses RXTX >> libraries, I must release my app under the GNU/GPL. I have no problem >> with that in fact I'm an Open Source user and defender. >> The fact is that in same cases the applications made by one, could get >> into hands of a company that needs to release a Closed Source app. I >> understand that using GNU/GPL do not give you the power to do this, >> but >> a more "open" license like Apache does. By "open" I mean that the >> license respects the Open Source license, but also lives the user the >> opportunity to use the library in closed source programs. >> I have seen that there is an exception to the license that applies to >> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >> (the jar file) needs the file javax.comm.properties installed >> correctly, >> which in lot of cases is a headache. RXTX jar does not need this, >> actually I think that RXTX is more user friendly than Java Comm. >> Maybe there has been a discussion like this before, but I just >> wanted to >> ask, and to get an answer that is adequate to our time. >> Regards, >> Manuel >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jul 9 10:50:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Jul 2006 10:50:11 -0600 (MDT) Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44B13085.2000805@gmail.com> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> Message-ID: I won't prevent people from discussing this hack. You can discuss anything on the list including things I do not agree with. But I do not agree with that hack. That is not in line with the history of RXTX respecting all that contribute including Sun. If you do this, it is your own thing. Agreeing to disagree is fine and usually the default here :). I just want to make it clear I do disagree. On Sun, 9 Jul 2006, Manuel Naranjo wrote: > Joachim, > Does that really work???? I will try it later, thanks :) > Manuel > >> Manuel, >> >> a simple way to avoid the javax.comm.properties file is to include a >> class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> into your application jar file and make sure, that you include the >> javax.comm jar after it. That's all you need. >> >> Regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 08.07.2006, at 16:03, Manuel Naranjo wrote: >> >>> Hi: >>> I have a question, haven't you ever thought about changing RXTX >>> license >>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>> As far as I understand if I make an application that uses RXTX >>> libraries, I must release my app under the GNU/GPL. I have no problem >>> with that in fact I'm an Open Source user and defender. >>> The fact is that in same cases the applications made by one, could get >>> into hands of a company that needs to release a Closed Source app. I >>> understand that using GNU/GPL do not give you the power to do this, >>> but >>> a more "open" license like Apache does. By "open" I mean that the >>> license respects the Open Source license, but also lives the user the >>> opportunity to use the library in closed source programs. >>> I have seen that there is an exception to the license that applies to >>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>> (the jar file) needs the file javax.comm.properties installed >>> correctly, >>> which in lot of cases is a headache. RXTX jar does not need this, >>> actually I think that RXTX is more user friendly than Java Comm. >>> Maybe there has been a discussion like this before, but I just >>> wanted to >>> ask, and to get an answer that is adequate to our time. >>> Regards, >>> Manuel >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From naranjo.manuel at gmail.com Sun Jul 9 11:43:33 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 09 Jul 2006 14:43:33 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> Message-ID: <44B14045.9030601@gmail.com> Trent: Do you know any other way, to use Java Comm API with RXTX with out the javax.comm.properties?. Have any information about how is the JSR going? Regards, Manuel > > I won't prevent people from discussing this hack. You can discuss > anything on the list including things I do not agree with. > > But I do not agree with that hack. That is not in line with the history > of RXTX respecting all that contribute including Sun. If you do this, > it is your own thing. > > Agreeing to disagree is fine and usually the default here :). I just > want to make it clear I do disagree. > > On Sun, 9 Jul 2006, Manuel Naranjo wrote: > >> Joachim, >> Does that really work???? I will try it later, thanks :) >> Manuel >> >>> Manuel, >>> >>> a simple way to avoid the javax.comm.properties file is to include a >>> class >>> >>> package com.sun.comm; >>> public class SolarisDriver extends gnu.io.RXTXCommDriver { >>> } >>> >>> into your application jar file and make sure, that you include the >>> javax.comm jar after it. That's all you need. >>> >>> Regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich >>> >>> >>> On 08.07.2006, at 16:03, Manuel Naranjo wrote: >>> >>>> Hi: >>>> I have a question, haven't you ever thought about changing RXTX >>>> license >>>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>>> As far as I understand if I make an application that uses RXTX >>>> libraries, I must release my app under the GNU/GPL. I have no problem >>>> with that in fact I'm an Open Source user and defender. >>>> The fact is that in same cases the applications made by one, could get >>>> into hands of a company that needs to release a Closed Source app. I >>>> understand that using GNU/GPL do not give you the power to do this, >>>> but >>>> a more "open" license like Apache does. By "open" I mean that the >>>> license respects the Open Source license, but also lives the user the >>>> opportunity to use the library in closed source programs. >>>> I have seen that there is an exception to the license that applies to >>>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>>> (the jar file) needs the file javax.comm.properties installed >>>> correctly, >>>> which in lot of cases is a headache. RXTX jar does not need this, >>>> actually I think that RXTX is more user friendly than Java Comm. >>>> Maybe there has been a discussion like this before, but I just >>>> wanted to >>>> ask, and to get an answer that is adequate to our time. >>>> Regards, >>>> Manuel >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Jul 9 11:53:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Jul 2006 11:53:19 -0600 (MDT) Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44B14045.9030601@gmail.com> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> Message-ID: Hi Manuel I do not know of another way. If you look at rxtx.org, even the compiled version is hard to find, always late and not what you want. At rxtx.org we just worry about the source and do a minimal effort to provide binaries. I'd love nothing more than someone to start selling RXTX binaries or working with us like Doug is to deliver the problems solved to users. The Free here is Freedom. Not price. There is a need for services rxtx.org is not able to provide well. That said I do not ever expect to recieve anything. It just makes sense for everyone to work together and compete outside of the source. On Sun, 9 Jul 2006, Manuel Naranjo wrote: > Trent: > Do you know any other way, to use Java Comm API with RXTX with out the > javax.comm.properties?. > Have any information about how is the JSR going? > Regards, > Manuel >> >> I won't prevent people from discussing this hack. You can discuss >> anything on the list including things I do not agree with. >> >> But I do not agree with that hack. That is not in line with the history >> of RXTX respecting all that contribute including Sun. If you do this, >> it is your own thing. >> >> Agreeing to disagree is fine and usually the default here :). I just >> want to make it clear I do disagree. >> >> On Sun, 9 Jul 2006, Manuel Naranjo wrote: >> >>> Joachim, >>> Does that really work???? I will try it later, thanks :) >>> Manuel >>> >>>> Manuel, >>>> >>>> a simple way to avoid the javax.comm.properties file is to include a >>>> class >>>> >>>> package com.sun.comm; >>>> public class SolarisDriver extends gnu.io.RXTXCommDriver { >>>> } >>>> >>>> into your application jar file and make sure, that you include the >>>> javax.comm jar after it. That's all you need. >>>> >>>> Regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >>>> >>>> >>>> On 08.07.2006, at 16:03, Manuel Naranjo wrote: >>>> >>>>> Hi: >>>>> I have a question, haven't you ever thought about changing RXTX >>>>> license >>>>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>>>> As far as I understand if I make an application that uses RXTX >>>>> libraries, I must release my app under the GNU/GPL. I have no problem >>>>> with that in fact I'm an Open Source user and defender. >>>>> The fact is that in same cases the applications made by one, could get >>>>> into hands of a company that needs to release a Closed Source app. I >>>>> understand that using GNU/GPL do not give you the power to do this, >>>>> but >>>>> a more "open" license like Apache does. By "open" I mean that the >>>>> license respects the Open Source license, but also lives the user the >>>>> opportunity to use the library in closed source programs. >>>>> I have seen that there is an exception to the license that applies to >>>>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>>>> (the jar file) needs the file javax.comm.properties installed >>>>> correctly, >>>>> which in lot of cases is a headache. RXTX jar does not need this, >>>>> actually I think that RXTX is more user friendly than Java Comm. >>>>> Maybe there has been a discussion like this before, but I just >>>>> wanted to >>>>> ask, and to get an answer that is adequate to our time. >>>>> Regards, >>>>> Manuel >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From naranjo.manuel at gmail.com Sun Jul 9 12:04:28 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 09 Jul 2006 15:04:28 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> Message-ID: <44B1452C.60208@gmail.com> Trent Jarvi wrote: > > Hi Manuel > > I do not know of another way. If you look at rxtx.org, even the > compiled version is hard to find, always late and not what you want. At > rxtx.org we just worry about the source and do a minimal effort to > provide binaries. Then that probes my theory, RXTX is much better than Java comm :) > I'd love nothing more than someone to start selling RXTX binaries or > working with us like Doug is to deliver the problems solved to users. > The Free here is Freedom. Not price. There is a need for services > rxtx.org is not able to provide well. That said I do not ever expect to > recieve anything. It just makes sense for everyone to work together and > compete outside of the source. I would like to contribute with the project giving support, I have worked using JSmooth and IzPack, and been able to make things that make RXTX easier to use and install. I will try to debug them, and send them to the mailing list, so you can do what ever you want with this :). Regards, Manuel From tjarvi at qbang.org Sun Jul 9 22:15:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Jul 2006 22:15:28 -0600 (MDT) Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44B1452C.60208@gmail.com> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> <44B1452C.60208@gmail.com> Message-ID: On Sun, 9 Jul 2006, Manuel Naranjo wrote: > Trent Jarvi wrote: >> >> Hi Manuel >> >> I do not know of another way. If you look at rxtx.org, even the >> compiled version is hard to find, always late and not what you want. At >> rxtx.org we just worry about the source and do a minimal effort to >> provide binaries. > Then that probes my theory, RXTX is much better than Java comm :) > >> I'd love nothing more than someone to start selling RXTX binaries or >> working with us like Doug is to deliver the problems solved to users. >> The Free here is Freedom. Not price. There is a need for services >> rxtx.org is not able to provide well. That said I do not ever expect to >> recieve anything. It just makes sense for everyone to work together and >> compete outside of the source. > I would like to contribute with the project giving support, I have > worked using JSmooth and IzPack, and been able to make things that make > RXTX easier to use and install. I will try to debug them, and send them > to the mailing list, so you can do what ever you want with this :). > Regards, Hi Manuel This is interesting. There are some checks and balances that we do at rxtx.org to make sure random material does not get in. It isn't personal just a low bar that must be crossed. After you get your changes in, you will know that others must cross the same bar. The basic question asked is "Does this change reflect the intent and work of those that have contributed to RXTX." Perhaps Doug is the best person to be the bar here. I'm more than willing to admit my limitations and obviously this is a limitation I face. If Doug is willing to take this task, I'd be glad to give him CVS write access which is more than overdue as he is the official maintainer now :) He then could optionally give you write access if your changes are fine and you represent a bar for new changes. I trust Doug. We do take the bar seriously as you can see. But it is not intended to prevent fair use of RXTX or prevent facilitating new uses. If we don't manage expectations here, there will be all sorts of problems and issues. -- Trent Jarvi tjarvi at qbang.org From zhanglong at adventnet.com Mon Jul 10 02:02:20 2006 From: zhanglong at adventnet.com (zhanglong) Date: Mon, 10 Jul 2006 16:02:20 +0800 Subject: [Rxtx] rxtx can not read data from serialport Message-ID: <44B2098C.6050407@adventnet.com> Dear brian and tjarvi, Thank you! After I set flowcontrol as FLOWCONTROL_RTSCTS_IN serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_IN); Then I can read and write data from serial port on Windows. But On linux9.0,No response,no data. I can get serialport list on my machine.And no error when I open serialport. I use Wevecom GSM modem device.I install Linux in VWware Workstation. And VWware Workstation install on windowsXP,So windowsXP and redhat Linux9.0 are on the same PC. On windows,I use COM1 serialport. On Linux,I use /dev/ttyS0 serialport. I hava test with SerialPort.FLOWCONTROL_XONXOFF_IN flow control,But still no data. How to set flow control,timeout and threshold on linux9.0? Thanks & Regards, Zhanglong -------------- next part -------------- A non-text attachment was scrubbed... Name: ListPort.java Type: text/x-java Size: 1659 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060710/334802b0/ListPort-0355.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: listport return on Windows and Linux.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060710/334802b0/listportreturnonWindowsandLinux-0355.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: TwoWaySerialComm.java Type: text/x-java Size: 3516 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060710/334802b0/TwoWaySerialComm-0355.bin From joachim at buechse.de Mon Jul 10 02:53:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 10 Jul 2006 10:53:09 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607091701.24661.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> <200607082203.13696.pascal@quies.net> <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> <200607091701.24661.pascal@quies.net> Message-ID: <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> The problem is, that once the libraries are installed in JAVA_HOME/ lib they will be loaded in preference to classes in your application classpath. If all you want is to use RXTX, then: - put the native lib in your application directory - include the javax.comm classes and RXTX classes in your application classpath - add the little stub class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } before the javax.comm classes in your application classpath. Alternatively you could also include the native lib in your application jar, extract it at runtime to a temp file, load it with System.load(). This will work on Windows and OSX. I didn't test it on Linux, but it should work. Regards, Joachim On 09.07.2006, at 17:01, Pascal S. de Kloe wrote: > Op zondag 9 juli 2006 15:19, schreef Joachim Buechse: >> Pascal, >> >> I would strongly suggest NOT to follow these installation >> instructions for OSX. It "poisons" the global Java VM with a specific >> implementation of RXTX. Plus: there is not one, but several Java VMs >> installed on every version of OSX. An application specific file and >> global preference pane defines which VM launches which application. >> There is really no good reason to install RXTX globally. > > I see your points. > How can you use the extension non-globally? I asked the same thing > for Windows > to Manuel. > > The system will allow you to detect any implementation. So the > "poison" > becomes a alternative. Applications can install the extension if > needed to > the current runtime with something like: > > CommunicationAPI comm = new CommunicationAPI(); > if (! comm.available()) { > if (comm.installRXTX()) > restart(); > else > handleError("I need the extension!"); > } > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jul 10 06:07:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 10 Jul 2006 06:07:23 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607081330.24381.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <200607081330.24381.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> Is the gnu.io namespace still necessary? I couldn't find the problem. >> >> Hi Pascal >> >> CommAPI is a little different in that it was grandfathered into the javax >> namespace with its own license at the time. >> >> It is my understanding that if CommAPI went through the JSR process, >> anyone would _clearly_ be able to implement a javax.comm package and RXTX >> would then be one of the first to do so. I believe Doug has expressed >> some interest in RXTX trying to work with the JSR process. >> >> Besides the license questions, there is the fact that RXTX has extensions >> to CommAPI which could cause confusion in the namespace. Not being a >> lawyer and *really* not liking to talk to lawyers in my free time, it is >> better to be safe than sorry. The lawyers tend to come in wolf packs >> when they do come. >> >> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay >> there as long as we are just geeks trying to figure out if a license does >> or does not allow us to implement in the javax.comm namespace. > > Nicely said. :) > > The whole point of namespaces is to create a universal registry of, in this > case, classes. This gnu.io namespace is very inconvenient. > > We feel the same way about lawyers. However I'd like to go into the details of > the license (see attachment) if you don't mind? > > The first license does not apply since RXTX does not use the software. The > second one at point 3 specifies our options. > >> 3. You may not modify the Java Platform Interface ("JPI", identified as >> classes contained within the "java" package or any subpackages of the >> "java" package), by creating additional classes within the JPI or otherwise >> causing the addition to or modification of the classes in the JPI. > > RXTX is a extension. > >> In the event that you create an additional class and associated API(s) >> which (i) extends the functionality of the Java platform, and (ii) is >> exposed to third party software developers for the purpose of developing >> additional software which invokes such additional API, you must promptly >> publish broadly an accurate specification for such API for free use by all >> developers. > > That's the way we operate. :) > >> You may not create, or authorize your licensees to create additional >> classes, interfaces, or subpackages that are in any way identified as >> "java", "javax", "sun" or similar convention as specified by Sun in any >> naming convention designation. > > They don't want additional components in the Communication API since they > don't want a mess in theire namespace. > > So we *can* use javax.comm for the core: > javax.comm.CommDriver > javax.comm.CommPort > javax.comm.CommPortIdentifier > javax.comm.CommPortOwnershipListener > javax.comm.NoSuchPortException > javax.comm.PortInUseException > javax.comm.UnsupportedCommOperationException > > ...and for the default hardware support: > javax.comm.SerialPort > javax.comm.SerialPortEvent > javax.comm.SerialPortEventListener > javax.comm.ParralelPort > javax.comm.ParralelPortEvent > javax.comm.ParralelPortEventListener > > ...but RXTX aditional hardware support has to go somewhere else like: > org.rxtx.RS485Port > org.rxtx.RS485PortEvent > org.rxtx.RS485PortEventListener > org.rxtx.I2CPort > org.rxtx.I2CPortEvent > org.rxtx.I2CPortEventListener > > Right? > The one thing this discussion does not cover is in SerialPort.java. See the extensions to commapi listed after the following line: /* ---------------------- end of commapi ------------------------ */ The intent is not to break commapi but it could be perceived as so. The extensions added have been placed there as requested by users of RXTX. It would be nice to discuss these modifications with Sun and perhaps have some added to the final version of CommAPI. Some of them may not make sense while others do. Some can not be implemented in a platform neutral fashion. It would not make sense for RXTX to just bring these into Sun's namespace without due process. This is why I am fundamentally apposed to people "poisoning" Sun's namespace with RXTX 2.1 although I understand that is not their intent. These modifications are not advertised and their use is discouraged. But they are there. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Mon Jul 10 06:47:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 10 Jul 2006 14:47:24 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607081330.24381.pascal@quies.net> Message-ID: <200607101447.25071.pascal@quies.net> Op maandag 10 juli 2006 14:07, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > > Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: > >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > >>> Is the gnu.io namespace still necessary? I couldn't find the problem. > >> > >> Hi Pascal > >> > >> CommAPI is a little different in that it was grandfathered into the > >> javax namespace with its own license at the time. > >> > >> It is my understanding that if CommAPI went through the JSR process, > >> anyone would _clearly_ be able to implement a javax.comm package and > >> RXTX would then be one of the first to do so. I believe Doug has > >> expressed some interest in RXTX trying to work with the JSR process. > >> > >> Besides the license questions, there is the fact that RXTX has > >> extensions to CommAPI which could cause confusion in the namespace. Not > >> being a lawyer and *really* not liking to talk to lawyers in my free > >> time, it is better to be safe than sorry. The lawyers tend to come in > >> wolf packs when they do come. > >> > >> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay > >> there as long as we are just geeks trying to figure out if a license > >> does or does not allow us to implement in the javax.comm namespace. > > > > Nicely said. :) > > > > The whole point of namespaces is to create a universal registry of, in > > this case, classes. This gnu.io namespace is very inconvenient. > > > > We feel the same way about lawyers. However I'd like to go into the > > details of the license (see attachment) if you don't mind? > > > > The first license does not apply since RXTX does not use the software. > > The second one at point 3 specifies our options. > > > >> 3. You may not modify the Java Platform Interface ("JPI", identified as > >> classes contained within the "java" package or any subpackages of the > >> "java" package), by creating additional classes within the JPI or > >> otherwise causing the addition to or modification of the classes in the > >> JPI. > > > > RXTX is a extension. > > > >> In the event that you create an additional class and associated API(s) > >> which (i) extends the functionality of the Java platform, and (ii) is > >> exposed to third party software developers for the purpose of developing > >> additional software which invokes such additional API, you must promptly > >> publish broadly an accurate specification for such API for free use by > >> all developers. > > > > That's the way we operate. :) > > > >> You may not create, or authorize your licensees to create additional > >> classes, interfaces, or subpackages that are in any way identified as > >> "java", "javax", "sun" or similar convention as specified by Sun in any > >> naming convention designation. > > > > They don't want additional components in the Communication API since they > > don't want a mess in theire namespace. > > > > So we *can* use javax.comm for the core: > > javax.comm.CommDriver > > javax.comm.CommPort > > javax.comm.CommPortIdentifier > > javax.comm.CommPortOwnershipListener > > javax.comm.NoSuchPortException > > javax.comm.PortInUseException > > javax.comm.UnsupportedCommOperationException > > > > ...and for the default hardware support: > > javax.comm.SerialPort > > javax.comm.SerialPortEvent > > javax.comm.SerialPortEventListener > > javax.comm.ParralelPort > > javax.comm.ParralelPortEvent > > javax.comm.ParralelPortEventListener > > > > ...but RXTX aditional hardware support has to go somewhere else like: > > org.rxtx.RS485Port > > org.rxtx.RS485PortEvent > > org.rxtx.RS485PortEventListener > > org.rxtx.I2CPort > > org.rxtx.I2CPortEvent > > org.rxtx.I2CPortEventListener > > > > Right? > > The one thing this discussion does not cover is in SerialPort.java. See > the extensions to commapi listed after the following line: > > /* ---------------------- end of commapi ------------------------ */ > > The intent is not to break commapi but it could be perceived as so. The > extensions added have been placed there as requested by users of RXTX. It > would be nice to discuss these modifications with Sun and perhaps have > some added to the final version of CommAPI. > > Some of them may not make sense while others do. Some can not be > implemented in a platform neutral fashion. It would not make sense > for RXTX to just bring these into Sun's namespace without due process. > > This is why I am fundamentally apposed to people "poisoning" Sun's > namespace with RXTX 2.1 although I understand that is not their intent. > > These modifications are not advertised and their use is discouraged. But > they are there. Hi Trent, So you are saying that gnu.io.SerialPort has some aditional methods over javax.comm.SerialPort? That does not change the API at all but it would be a problem if people would start using those methods in the javax.comm namespace in the same way like some people use the com.sun namespace. Could wrapper classes at javax.comm do the job? In that way RXTX stays in its namespace, javadoc can notice the aditional methods and the Communication API will be available as expected. From pascal at quies.net Mon Jul 10 06:48:09 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 10 Jul 2006 14:48:09 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> References: <200607081944.41123.pascal@quies.net> <200607091701.24661.pascal@quies.net> <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> Message-ID: <200607101448.09594.pascal@quies.net> Op maandag 10 juli 2006 10:53, schreef Joachim Buechse: > If all you want is to use RXTX, then: > > - put the native lib in your application directory > - include the javax.comm classes and RXTX classes in your application > classpath > - add the little stub class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > before the javax.comm classes in your application classpath. > > Alternatively you could also include the native lib in your > application jar, extract it at runtime to a temp file, load it with > System.load(). So java will load the native libraries automaticly if they are in the same directory as the Java application? Why isn't this very interresting information noticed in the documentation or is that too obvious and I simply didn't knew? From naranjo.manuel at gmail.com Mon Jul 10 06:56:10 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Mon, 10 Jul 2006 09:56:10 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> <44B1452C.60208@gmail.com> Message-ID: <44B24E6A.1010805@gmail.com> Trent Jarvi wrote: > On Sun, 9 Jul 2006, Manuel Naranjo wrote: > >> Trent Jarvi wrote: >>> Hi Manuel >>> >>> I do not know of another way. If you look at rxtx.org, even the >>> compiled version is hard to find, always late and not what you want. At >>> rxtx.org we just worry about the source and do a minimal effort to >>> provide binaries. >> Then that probes my theory, RXTX is much better than Java comm :) >> >>> I'd love nothing more than someone to start selling RXTX binaries or >>> working with us like Doug is to deliver the problems solved to users. >>> The Free here is Freedom. Not price. There is a need for services >>> rxtx.org is not able to provide well. That said I do not ever expect to >>> recieve anything. It just makes sense for everyone to work together and >>> compete outside of the source. >> I would like to contribute with the project giving support, I have >> worked using JSmooth and IzPack, and been able to make things that make >> RXTX easier to use and install. I will try to debug them, and send them >> to the mailing list, so you can do what ever you want with this :). >> Regards, > > > Hi Manuel > > This is interesting. There are some checks and balances that we do at > rxtx.org to make sure random material does not get in. It isn't personal > just a low bar that must be crossed. After you get your changes in, you > will know that others must cross the same bar. The basic question asked > is "Does this change reflect the intent and work of those that have > contributed to RXTX." > > Perhaps Doug is the best person to be the bar here. I'm more than willing > to admit my limitations and obviously this is a limitation I face. > > If Doug is willing to take this task, I'd be glad to give him CVS write > access which is more than overdue as he is the official maintainer now :) > He then could optionally give you write access if your changes are fine > and you represent a bar for new changes. I trust Doug. > > We do take the bar seriously as you can see. But it is not intended to > prevent fair use of RXTX or prevent facilitating new uses. If we don't > manage expectations here, there will be all sorts of problems and issues. > > -- > Trent Jarvi > tjarvi at qbang.org > > Trent, What I want to send you is not a modification to rxtx, it just a developers helper if you want to put a name to it. I have make an IzPack installer, which installs RXTX binaries depending on underlaying OS. And make an JSmooth warper that launches my app with out the need to have rxtx installed on the host JVM folder, it only need the RXTX to be in the bin\ of my app. I think this is more useful for Wiki than to the main project. Another thing I have experience in PalmOS programming, when ever I have time, I will investigate about the JNI of J2ME and try to port RXTX to Palm, I do not know when I will start, because I have a lot of work now. Regards, Manuel From christopher.dawes at the-logic-group.com Mon Jul 10 08:00:15 2006 From: christopher.dawes at the-logic-group.com (christopher.dawes@the-logic-group.com) Date: Mon, 10 Jul 2006 15:00:15 +0100 Subject: [Rxtx] Chris Dawes/Retaillogic/NISABA is out of the office. Message-ID: I will be out of the office starting 10/07/2006 and will not return until 11/07/2008. Hello, unfortunately I no longer work for The Logic Group, if you're trying to contact me on a work related issue please contact Pete Avery (pete.avery at the-logic-group.com) however if it is a personal matter please e-mail root at ants.me.uk or phone 07899 842 759. Thanks Christopher Dawes From tjarvi at qbang.org Mon Jul 10 08:19:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 10 Jul 2006 08:19:52 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607101447.25071.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607081330.24381.pascal@quies.net> <200607101447.25071.pascal@quies.net> Message-ID: On Mon, 10 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 10 juli 2006 14:07, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: >>>> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>>>> Is the gnu.io namespace still necessary? I couldn't find the problem. >>>> >>>> Hi Pascal >>>> >>>> CommAPI is a little different in that it was grandfathered into the >>>> javax namespace with its own license at the time. >>>> >>>> It is my understanding that if CommAPI went through the JSR process, >>>> anyone would _clearly_ be able to implement a javax.comm package and >>>> RXTX would then be one of the first to do so. I believe Doug has >>>> expressed some interest in RXTX trying to work with the JSR process. >>>> >>>> Besides the license questions, there is the fact that RXTX has >>>> extensions to CommAPI which could cause confusion in the namespace. Not >>>> being a lawyer and *really* not liking to talk to lawyers in my free >>>> time, it is better to be safe than sorry. The lawyers tend to come in >>>> wolf packs when they do come. >>>> >>>> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay >>>> there as long as we are just geeks trying to figure out if a license >>>> does or does not allow us to implement in the javax.comm namespace. >>> >>> Nicely said. :) >>> >>> The whole point of namespaces is to create a universal registry of, in >>> this case, classes. This gnu.io namespace is very inconvenient. >>> >>> We feel the same way about lawyers. However I'd like to go into the >>> details of the license (see attachment) if you don't mind? >>> >>> The first license does not apply since RXTX does not use the software. >>> The second one at point 3 specifies our options. >>> >>>> 3. You may not modify the Java Platform Interface ("JPI", identified as >>>> classes contained within the "java" package or any subpackages of the >>>> "java" package), by creating additional classes within the JPI or >>>> otherwise causing the addition to or modification of the classes in the >>>> JPI. >>> >>> RXTX is a extension. >>> >>>> In the event that you create an additional class and associated API(s) >>>> which (i) extends the functionality of the Java platform, and (ii) is >>>> exposed to third party software developers for the purpose of developing >>>> additional software which invokes such additional API, you must promptly >>>> publish broadly an accurate specification for such API for free use by >>>> all developers. >>> >>> That's the way we operate. :) >>> >>>> You may not create, or authorize your licensees to create additional >>>> classes, interfaces, or subpackages that are in any way identified as >>>> "java", "javax", "sun" or similar convention as specified by Sun in any >>>> naming convention designation. >>> >>> They don't want additional components in the Communication API since they >>> don't want a mess in theire namespace. >>> >>> So we *can* use javax.comm for the core: >>> javax.comm.CommDriver >>> javax.comm.CommPort >>> javax.comm.CommPortIdentifier >>> javax.comm.CommPortOwnershipListener >>> javax.comm.NoSuchPortException >>> javax.comm.PortInUseException >>> javax.comm.UnsupportedCommOperationException >>> >>> ...and for the default hardware support: >>> javax.comm.SerialPort >>> javax.comm.SerialPortEvent >>> javax.comm.SerialPortEventListener >>> javax.comm.ParralelPort >>> javax.comm.ParralelPortEvent >>> javax.comm.ParralelPortEventListener >>> >>> ...but RXTX aditional hardware support has to go somewhere else like: >>> org.rxtx.RS485Port >>> org.rxtx.RS485PortEvent >>> org.rxtx.RS485PortEventListener >>> org.rxtx.I2CPort >>> org.rxtx.I2CPortEvent >>> org.rxtx.I2CPortEventListener >>> >>> Right? >> >> The one thing this discussion does not cover is in SerialPort.java. See >> the extensions to commapi listed after the following line: >> >> /* ---------------------- end of commapi ------------------------ */ >> >> The intent is not to break commapi but it could be perceived as so. The >> extensions added have been placed there as requested by users of RXTX. It >> would be nice to discuss these modifications with Sun and perhaps have >> some added to the final version of CommAPI. >> >> Some of them may not make sense while others do. Some can not be >> implemented in a platform neutral fashion. It would not make sense >> for RXTX to just bring these into Sun's namespace without due process. >> >> This is why I am fundamentally apposed to people "poisoning" Sun's >> namespace with RXTX 2.1 although I understand that is not their intent. >> >> These modifications are not advertised and their use is discouraged. But >> they are there. > > Hi Trent, > > So you are saying that gnu.io.SerialPort has some aditional methods over > javax.comm.SerialPort? > That does not change the API at all but it would be a problem if people would > start using those methods in the javax.comm namespace in the same way like > some people use the com.sun namespace. > Could wrapper classes at javax.comm do the job? In that way RXTX stays in its > namespace, javadoc can notice the aditional methods and the Communication API > will be available as expected. Hi Pascal Yes. There are additional methods in gnu.io.SerialPort. We clearly mark those as extensions to CommAPI and discourage their use. There just isn't a way to get the intended functionality out of CommAPI without them. I think the right thing to do here may be to remove these methods to avoid unintentional polution of the javax namespace if people are going to be putting these classes in that namespace. The way people are using RXTX 2.1 is not the same as it was originally pictured. Thats fine but we need to be responsible. We need to prevent what could be a problem. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Mon Jul 10 08:57:10 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 10 Jul 2006 16:57:10 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101447.25071.pascal@quies.net> Message-ID: <200607101657.11223.pascal@quies.net> > Yes. There are additional methods in gnu.io.SerialPort. We clearly mark > those as extensions to CommAPI and discourage their use. There just isn't > a way to get the intended functionality out of CommAPI without them. If you don't want the users to use the methods then make them class protected (remove the word "public" before the method) and if you can't do that we might do the following: ---- SerialPort.java package javax.comm class SerialPort extends gnu.io.SerialPort { public void rxtxOnlyMethod() { throw new Error("Don't use this method here!\nUse gnu.io.SerialPort instead"); } ---- end From neville_seed at yahoo.com Mon Jul 10 10:20:12 2006 From: neville_seed at yahoo.com (neville seed) Date: Mon, 10 Jul 2006 09:20:12 -0700 (PDT) Subject: [Rxtx] writing first application and compiling In-Reply-To: Message-ID: <20060710162012.9888.qmail@web51015.mail.yahoo.com> Can anyone recommend a starting place for writing, compiling and uploading the first app, ie a simple hello world. It seems that the PALM SDK does not have a build environment. I am happy to develop under linux of windows. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From bob_tai2001 at yahoo.com Mon Jul 10 14:48:30 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 10 Jul 2006 13:48:30 -0700 (PDT) Subject: [Rxtx] Java installer Message-ID: <20060710204830.53745.qmail@web32810.mail.mud.yahoo.com> Hi Manuel, I found your post from the newsletter, hope I am not off topic. You mention there is a IZpack installer for Rxtx? I been waiting for this type of deplyment idea from Rxtx! is this documented in the web site? I am in windows environment but didn't want to create classpath for each workstation. I rather install :) I apologize for cutting into this topic. Bob > >Trent, >What I want to send you is not a modification to rxtx, it just a >developers helper if you want to put a name to it. I have make an IzPack installer, which installs RXTX binaries depending on underlaying OS. And make an JSmooth warper that launches my app with out the need to have rxtx installed on the host JVM folder, it only need the RXTX to be in the bin\ of my app. I think this is more useful for Wiki than to the main project. Another thing I have experience in PalmOS programming, when ever I have time, I will investigate about the JNI of J2ME and try to port RXTX to Palm, I do not know when I will start, because I have a lot of work now. Regards, Manuel __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From naranjo.manuel at gmail.com Mon Jul 10 15:10:21 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Mon, 10 Jul 2006 18:10:21 -0300 Subject: [Rxtx] Java installer In-Reply-To: <20060710204830.53745.qmail@web32810.mail.mud.yahoo.com> References: <20060710204830.53745.qmail@web32810.mail.mud.yahoo.com> Message-ID: <44B2C23D.8050901@gmail.com> Bob, Hi, not this is not a RXTX installer, I have develop an installer with IzPack which actually installs RXTX and my hole app, and I think this can be useful for RXTX users, Regards, Manuel > Hi Manuel, > > I found your post from the newsletter, hope I am not > off topic. You mention there is a IZpack installer > for Rxtx? I been waiting for this type of deplyment > idea from Rxtx! is this documented in the web site? > I am in windows environment but didn't want to create > classpath for each workstation. I rather install :) > > I apologize for cutting into this topic. > > Bob > >> Trent, >> What I want to send you is not a modification to > rxtx, it just a >> developers > helper if you want to put a name to it. I have make an > IzPack > installer, > which installs RXTX binaries depending on underlaying > OS. And make an > JSmooth warper that launches my app with out the need > to have rxtx > installed > on the host JVM folder, it only need the RXTX to be in > the bin\ of my > app. > I think this is more useful for Wiki than to the main > project. > Another thing I have experience in PalmOS programming, > when ever I have > time, > I will investigate about the JNI of J2ME and try to > port RXTX to Palm, > I do not know when I will start, because I have a lot > of work now. > Regards, > Manuel > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From brian at mbari.org Tue Jul 11 11:59:24 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 11 Jul 2006 10:59:24 -0700 Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: References: <44AC7902.8070407@adventnet.com> Message-ID: <485C28F0-CA08-4393-9E34-4C8E7F22C125@mbari.org> Hi Trent, On Jul 7, 2006, at 6:15 PM, Trent Jarvi wrote: > On Fri, 7 Jul 2006, Brian Schlining wrote: >> Also, for some command/response applications that I've tried with >> RXTX, I >> find that if I write to the serialport and then immediately try to >> read from >> it I get byte arrays filled with zeros, no matter what I set the >> recieveTimeout to (this has occurred on both Mac OS X and >> Windows). The >> workaround that I found was to very briefly put the I/O thread to >> sleep, like >> so: >> >> // DO set up and get I/O streams >> //in = serialPort.getInputStream(); >> //out = serialPort.getOutputStream(); >> >> out.write(someByteArray); >> try { >> Thread.sleep(10); >> catch (InterruptedException e) { >> // handle exception >> } >> in.read(anotherByteArray); >> >> Note: I've never had to put the thread to sleep using Java comm, >> only with >> RXTX. Anyone know why this might be? > > Hi Brian > > Interesting. Is this something that can be reproduced with a loopback > connection or something commonly available? I was unaware of this > behavior. Is it restricted to something that quickly opens, > writes, reads > and closes the port by chance? I've encountered this while using RXTX to talk to VCR's that support RS422; I've never tried it with a loopback connection. Note that connection setup is: PC[RS232] <---> RS232/422 Converter <---> VCR[RS422] The application I'm using it for opens a connection and keeps it open for the life of the application. It makes a lot of read and writes when running...probably about as fast as the VCR hardware supports; with Javacomm, I think it was on the order of an IO transaction every 40ms. However even if I perform an IO read/write every 2 seconds with RXTX I still encounter the same problem, so it's not a matter of the frequency of the IO transactions. If you want to look at the code a test example can be found at https://svn.sourceforge.net/svnroot/vars/trunk/vars/src/test/java/ test/org/mbari/vcr/SimpleReadRxtx.java. The actual production code is at https://svn.sourceforge.net/svnroot/vars/trunk/vars/src/main/java/ org/mbari/vcr/rs422/VCR.java. The methods that you might be interested in to see how the code is used are initComm(), sendCommand (), getResponse() in VCR.java. You'll notice Thread.sleep(IO_DELAY) sprinkled in the sendCommand() methods and getResponse(). Without that I get arrays of zeros returned. If the IO_DELAY is less than 15ms then sending commands works fine but reading the responses is not reliable; I mostly get problems when trying to read the last few bytes or a response. Again, everything works fine with Sun's Javacomm w/o the Thread.sleep() on windows. Also, FYI, I tried to run this on a Mac using RXTX 2.0, but I ran into thread synchronization issues. These issues went away when I switched to RXTX 2.1. Cheers B ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining MBARI Software Engineer brian at mbari.org (831)775-1855 http://www.mbari.org/staff/brian I went to the woods because I wished to live deliberately, to front only the essential facts of life, and see if I could not learn what it had to teach, and not, when I came to die, discover that I had not lived. ~ Henry Thoreau -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060711/59b607f3/attachment-0353.html From ajmas at sympatico.ca Wed Jul 12 13:46:51 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 12 Jul 2006 15:46:51 -0400 Subject: [Rxtx] writing first application and compiling Message-ID: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Take a look in the Wiki. I have added a couple of examples in there: http://rxtx.qbang.org/wiki/index.php/Examples Andre > > From: neville seed > Date: 2006/07/10 Mon PM 12:20:12 EDT > To: RXTX Developers and Users > Subject: [Rxtx] writing first application and compiling > > > Can anyone recommend a starting place for writing, > compiling and uploading the first app, ie a simple > hello world. > > It seems that the PALM SDK does not have a build > environment. I am happy to develop under linux of windows. > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Jul 12 19:22:25 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 12 Jul 2006 19:22:25 -0600 (MDT) Subject: [Rxtx] writing first application and compiling In-Reply-To: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Thank you for doing this Andre. I'm sure it will get well used by people learning. I think the old commapi examples are no longer easily available so these are really needed. On Wed, 12 Jul 2006, Andre-John Mas wrote: > Hi, > > Take a look in the Wiki. I have added a couple of examples in there: > > http://rxtx.qbang.org/wiki/index.php/Examples > > Andre > >> >> From: neville seed >> Date: 2006/07/10 Mon PM 12:20:12 EDT >> To: RXTX Developers and Users >> Subject: [Rxtx] writing first application and compiling >> >> >> Can anyone recommend a starting place for writing, >> compiling and uploading the first app, ie a simple >> hello world. >> >> It seems that the PALM SDK does not have a build >> environment. I am happy to develop under linux of windows. >> >> __________________________________________________ >> Do You Yahoo!? >> Tired of spam? Yahoo! Mail has the best spam protection around >> http://mail.yahoo.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Thu Jul 13 17:21:26 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Thu, 13 Jul 2006 19:21:26 -0400 Subject: [Rxtx] writing first application and compiling In-Reply-To: References: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <54D55D35-A143-43AA-AF03-B89ADE9B9246@sympatico.ca> No problems. I would also like to encourage anyone else to contribute other useful stuff they might have. On 12-Jul-06, at 21:22 , Trent Jarvi wrote: > > Thank you for doing this Andre. > > I'm sure it will get well used by people learning. I think the old > commapi examples are no longer easily available so these are really > needed. > > On Wed, 12 Jul 2006, Andre-John Mas wrote: > >> Hi, >> >> Take a look in the Wiki. I have added a couple of examples in there: >> >> http://rxtx.qbang.org/wiki/index.php/Examples >> >> Andre >> >>> >>> From: neville seed >>> Date: 2006/07/10 Mon PM 12:20:12 EDT >>> To: RXTX Developers and Users >>> Subject: [Rxtx] writing first application and compiling >>> >>> >>> Can anyone recommend a starting place for writing, >>> compiling and uploading the first app, ie a simple >>> hello world. >>> >>> It seems that the PALM SDK does not have a build >>> environment. I am happy to develop under linux of windows. >>> >>> __________________________________________________ >>> Do You Yahoo!? >>> Tired of spam? Yahoo! Mail has the best spam protection around >>> http://mail.yahoo.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Sat Jul 8 15:05:46 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sat, 08 Jul 2006 17:05:46 -0400 Subject: [Rxtx] License question. In-Reply-To: <200607082219.59514.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> Message-ID: <44B01E2A.9010207@suespammers.org> Pascal S. de Kloe wrote: > I thought of the same thing. The modified BSD license would certainly make it > more eazy and acceptable for Sun to include RXTX in theire products. > > Unfortunately in general people who chose GPL don't like other licenses. ;) i have a general preference for BSD, but i'll defend RXTX here. RXTX is LGPL, not GPL. they're different, look it up. richard From pascal at quies.net Sun Jul 16 17:40:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 17 Jul 2006 01:40:13 +0200 Subject: [Rxtx] Java installer In-Reply-To: <200607101657.11223.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> Message-ID: <200607170140.14116.pascal@quies.net> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: > > Yes. There are additional methods in gnu.io.SerialPort. We clearly mark > > those as extensions to CommAPI and discourage their use. There just > > isn't a way to get the intended functionality out of CommAPI without > > them. > > If you don't want the users to use the methods then make them class > protected (remove the word "public" before the method) and if you can't do > that we might do the following: > > ---- SerialPort.java > package javax.comm > > class SerialPort extends gnu.io.SerialPort { > > public void > rxtxOnlyMethod() { > throw new Error("Don't use this method here!\nUse gnu.io.SerialPort > instead"); > } > ---- end So how about it, Trent? Can we ship those classes with the next release? From pascal at quies.net Sun Jul 16 17:45:42 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 17 Jul 2006 01:45:42 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> References: <200607081944.41123.pascal@quies.net> <200607091701.24661.pascal@quies.net> <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> Message-ID: <200607170145.43156.pascal@quies.net> Op maandag 10 juli 2006 10:53, schreef Joachim Buechse: > Alternatively you could also include the native lib in your > application jar, extract it at runtime to a temp file, load it with > System.load(). That works indeed. :) I'll finish my "detection class" with such a loader and the RXTX package tomorrow. Then one can simply include the JAR in the classpath and run org.rxtx.CommunicationAPI.initialize() to make sure the API is available. From tjarvi at qbang.org Sun Jul 16 18:59:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 16 Jul 2006 18:59:06 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607170140.14116.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> <200607170140.14116.pascal@quies.net> Message-ID: On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>> Yes. There are additional methods in gnu.io.SerialPort. We clearly mark >>> those as extensions to CommAPI and discourage their use. There just >>> isn't a way to get the intended functionality out of CommAPI without >>> them. >> >> If you don't want the users to use the methods then make them class >> protected (remove the word "public" before the method) and if you can't do >> that we might do the following: >> >> ---- SerialPort.java >> package javax.comm >> >> class SerialPort extends gnu.io.SerialPort { >> >> public void >> rxtxOnlyMethod() { >> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >> instead"); >> } >> ---- end > > So how about it, Trent? > > Can we ship those classes with the next release? Hi Pascal I'm not going to say what people can or can not ship. I'm going to propose removing all of the above extensions from SerialPort.java. I think it is the best thing to do after cooling off a bit. But thats all I've considered at this point. I'm in favor of removing the extensions and staying in gnu.io which more importantly means staying at arms length from javax. I can remove the extensions, put a windows fix in, bump the versions and tag the releases without changing packages if everyone agrees to that. If people want to know why CommAPI has not gone through a JSR which makes it clear rxtx can be in javax.comm and explains how conformancy is determined, I do not think this is the right forum though you can freely do so. -- Trent Jarvi tjarvi at qbang.org From phillip at uow.edu.au Sun Jul 16 22:08:30 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Mon, 17 Jul 2006 14:08:30 +1000 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application" in Mac OSX Message-ID: Hi I downloaded RXTX 2.1-7r2 http://rxtx.org/ (latest download), found the MacOSX folder, manually installed RXTXcomm.jar and librxtxSerial.jnilib in / Library/Java/Extensions and manually setup /var/spool/ucp and became a member of it. I have tried two programs (both built in XCode - TwoWaySerialComm and SerialDemo). Both can find the serial ports but throw a 'port in use exception' with the error "Unknown Application" when I try to open the port. The following is part of the code of TwoWaySerialComm void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { System.out.println("Current owner is " + portIdentifier.getCurrentOwner()); System.out.println("Name is " + this.getClass().getName()); CommPort commPort = portIdentifier.open(this.getClass ().getName(),2000); //throws exception if ( commPort instanceof SerialPort ) The method connect is called from main: public static void main ( String[] args ) { try { listPorts(); (new TwoWaySerialComm()).connect("/dev/tty.KeySerial1"); The following is the console run log of a program TwoWaySerialComm [Session started at 2006-07-14 14:50:29 +1000.] Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.modem - Serial /dev/cu.modem - Serial /dev/tty.KeySerial1 - Serial /dev/cu.KeySerial1 - Serial /dev/tty.USA28X2b2P2.2 - Serial /dev/cu.USA28X2b2P2.2 - Serial 6 ports found Current owner is null Name is TwoWaySerialComm gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:48) at TwoWaySerialComm.main(TwoWaySerialComm.java:163) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at apple.launcher.LaunchRunner.run(LaunchRunner.java:88) at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:50) at apple.launcher.JavaApplicationLauncher.launch (JavaApplicationLauncher.java:52) TwoWaySerialComm has exited with status 0. I am stuck, Can you help me please. thanks Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From pascal at quies.net Mon Jul 17 06:12:09 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 17 Jul 2006 14:12:09 +0200 Subject: [Rxtx] JSR In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607170140.14116.pascal@quies.net> Message-ID: <200607171412.09571.pascal@quies.net> Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: > On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > > Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: > >>> Yes. There are additional methods in gnu.io.SerialPort. We clearly > >>> mark those as extensions to CommAPI and discourage their use. There > >>> just isn't a way to get the intended functionality out of CommAPI > >>> without them. > >> > >> If you don't want the users to use the methods then make them class > >> protected (remove the word "public" before the method) and if you can't > >> do that we might do the following: > >> > >> ---- SerialPort.java > >> package javax.comm > >> > >> class SerialPort extends gnu.io.SerialPort { > >> > >> public void > >> rxtxOnlyMethod() { > >> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort > >> instead"); > >> } > >> ---- end > > > > So how about it, Trent? > > > > Can we ship those classes with the next release? > > Hi Pascal > > I'm not going to say what people can or can not ship. I'm going to > propose removing all of the above extensions from SerialPort.java. I > think it is the best thing to do after cooling off a bit. > > But thats all I've considered at this point. I'm in favor of removing the > extensions and staying in gnu.io which more importantly means staying at > arms length from javax. > > I can remove the extensions, put a windows fix in, bump the versions and > tag the releases without changing packages if everyone agrees to that. > If people want to know why CommAPI has not gone through a JSR which makes > it clear rxtx can be in javax.comm and explains how conformancy is > determined, I do not think this is the right forum though you can freely > do so. Hi Trent, If I understand it correctly you don't want to put those javax.comm classes in the distribution until a JSR completes. :( Sun wants a JSR too to change the API: > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. How about it? I can spend 5 hours a week. From tjarvi at qbang.org Mon Jul 17 07:32:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 07:32:06 -0600 (MDT) Subject: [Rxtx] JSR In-Reply-To: <200607171412.09571.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607170140.14116.pascal@quies.net> <200607171412.09571.pascal@quies.net> Message-ID: On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: >> On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: >>> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>>> Yes. There are additional methods in gnu.io.SerialPort. We clearly >>>>> mark those as extensions to CommAPI and discourage their use. There >>>>> just isn't a way to get the intended functionality out of CommAPI >>>>> without them. >>>> >>>> If you don't want the users to use the methods then make them class >>>> protected (remove the word "public" before the method) and if you can't >>>> do that we might do the following: >>>> >>>> ---- SerialPort.java >>>> package javax.comm >>>> >>>> class SerialPort extends gnu.io.SerialPort { >>>> >>>> public void >>>> rxtxOnlyMethod() { >>>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>>> instead"); >>>> } >>>> ---- end >>> >>> So how about it, Trent? >>> >>> Can we ship those classes with the next release? >> >> Hi Pascal >> >> I'm not going to say what people can or can not ship. I'm going to >> propose removing all of the above extensions from SerialPort.java. I >> think it is the best thing to do after cooling off a bit. >> >> But thats all I've considered at this point. I'm in favor of removing the >> extensions and staying in gnu.io which more importantly means staying at >> arms length from javax. >> >> I can remove the extensions, put a windows fix in, bump the versions and >> tag the releases without changing packages if everyone agrees to that. >> If people want to know why CommAPI has not gone through a JSR which makes >> it clear rxtx can be in javax.comm and explains how conformancy is >> determined, I do not think this is the right forum though you can freely >> do so. > > Hi Trent, > > If I understand it correctly you don't want to put those javax.comm classes in > the distribution until a JSR completes. :( > > Sun wants a JSR too to change the API: >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. > > How about it? I can spend 5 hours a week. Yes. I'm all in favor of this. Dr. Doug Lyon is our fearless leader in these matters and has final say. He has asked everyone if they have an issue with going through the JSR. I have seen no responses though some may have responeded to him in private. I am now working for The MathWorks in a related field. To best represent the RXTX community, we have asked Doug to be the neutral maintainer. This does not mean he is taking on all the work like making releases. He has the ability to and the power. But thats not really spending his time efficiently. It does mean when there are decisions to be made that may have conflicts, he has final say. The easy solution :) is to bug Trent or Doug and see if they will just go into javax.comm namespace. The right solution is to work with Doug and try to get the JSR process completed. I'm willing to help too as time permits. I'm willing to work with Doug. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Jul 17 09:11:20 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 17 Jul 2006 11:11:20 -0400 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Message-ID: <20060717151120.RSBG13653.tomts36-srv.bellnexxia.net@smtp1.sympatico.ca> I am told that this is an issue that will be resolved in 2.1-8. The changes are already in version control, so you can use that. I have and it resolved the problem for me. Phillip McKerrow wrote: > > Hi > > I downloaded RXTX 2.1-7r2 http://rxtx.org/ (latest download), > found the MacOSX folder, > manually installed RXTXcomm.jar and librxtxSerial.jnilib in / > Library/Java/Extensions and > manually setup /var/spool/ucp and became a member of it. > > I have tried two programs (both built in XCode - TwoWaySerialComm and > SerialDemo). Both can find the serial ports but throw a 'port in use > exception' with the error "Unknown Application" when I try to open > the port. > > The following is part of the code of TwoWaySerialComm > void connect ( String portName ) throws Exception > { > CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > if ( portIdentifier.isCurrentlyOwned() ) > { > System.out.println("Error: Port is currently in use"); > } > else > { > System.out.println("Current owner is " + > portIdentifier.getCurrentOwner()); > System.out.println("Name is " + this.getClass().getName()); > CommPort commPort = portIdentifier.open(this.getClass > ().getName(),2000); //throws exception > > if ( commPort instanceof SerialPort ) > > > The method connect is called from main: > public static void main ( String[] args ) > { > try > { > listPorts(); > (new TwoWaySerialComm()).connect("/dev/tty.KeySerial1"); > > > The following is the console run log of a program TwoWaySerialComm > [Session started at 2006-07-14 14:50:29 +1000.] > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > /dev/tty.modem - Serial > /dev/cu.modem - Serial > /dev/tty.KeySerial1 - Serial > /dev/cu.KeySerial1 - Serial > /dev/tty.USA28X2b2P2.2 - Serial > /dev/cu.USA28X2b2P2.2 - Serial > 6 ports found > Current owner is null > Name is TwoWaySerialComm > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at TwoWaySerialComm.connect(TwoWaySerialComm.java:48) > at TwoWaySerialComm.main(TwoWaySerialComm.java:163) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at apple.launcher.LaunchRunner.run(LaunchRunner.java:88) > at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:50) > at apple.launcher.JavaApplicationLauncher.launch > (JavaApplicationLauncher.java:52) > > TwoWaySerialComm has exited with status 0. > > I am stuck, Can you help me please. > > thanks > Phillip > > > ---------------------------------------------------------------------- > Phillip McKerrow http:// > www.uow.edu.au/~phillip/ > School of Information Technology and Computer Science > University of Wollongong * > Northfields Avenue, * * > Wollongong, NSW, 2522. + > AUSTRALIA * the land of the > southern cross > tel : +61 2 4221 3771 fax : +61 2 4221 4170 > > God so loved the world that he gave his one and only Son (Jesus), > that whoever believes in him shall not perish but have eternal life. > John 3:16 > ---------------------------------------------------------------------- > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Mon Jul 17 10:34:14 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 17 Jul 2006 12:34:14 -0400 Subject: [Rxtx] summary of issues In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607170140.14116.pascal@quies.net> <200607171412.09571.pascal@quies.net> Message-ID: Hi All, As I see it, at this stage of the discussion, I think it would be helpful to summarize the concerns. Let me see if I can get this straight, and please correct me, if I am wrong: 1. Sun is making no progress on improving the CommAPI spec. 2. We are seeking to reinvigorate a JSR for the CommAPI in order to keep sun involved. 3. Meanwhile we are extending the RXTX API, with non- commAPI improvements. 4. People are worried that the improvements will be non-portable, when the commAPI re-activates. 5. I have asked for feedback on the JSR approach and obtained zero response. 6. My limited imagination does not see any drawback to taking the JSR approach (except, possibly, from the overhead of a committee, or some license issue that I do not understand). 7. http://www.jcp.org/en/jsr/detail?id=922 shows the status of the JSR now. Status: Withdrawn The sun contact is: vincent.zhang at sun.com I have written to Vincent at Sun to ask him what would be involved with reactivation of JSR 922. If I hear back I will let you know. If there are any objections or suggestions, please let me know. Thanks! - Doug >On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > >> Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: >>> On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: >>>> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>>>> Yes. There are additional methods in gnu.io.SerialPort. We clearly >>>>>> mark those as extensions to CommAPI and discourage their use. There >>>>>> just isn't a way to get the intended functionality out of CommAPI >>>>>> without them. >>>>> >>>>> If you don't want the users to use the methods then make them class >>>>> protected (remove the word "public" before the method) and if you can't >>>>> do that we might do the following: >>>>> >>>>> ---- SerialPort.java >>>>> package javax.comm >>>>> >>>>> class SerialPort extends gnu.io.SerialPort { >>>>> >>>>> public void >>>>> rxtxOnlyMethod() { >>>>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>>>> instead"); >>>>> } >>>>> ---- end >>>> >>>> So how about it, Trent? >>>> >>>> Can we ship those classes with the next release? >>> >>> Hi Pascal >>> >>> I'm not going to say what people can or can not ship. I'm going to >>> propose removing all of the above extensions from SerialPort.java. I >>> think it is the best thing to do after cooling off a bit. >>> >>> But thats all I've considered at this point. I'm in favor of removing the >>> extensions and staying in gnu.io which more importantly means staying at >>> arms length from javax. >>> >>> I can remove the extensions, put a windows fix in, bump the versions and >>> tag the releases without changing packages if everyone agrees to that. >>> If people want to know why CommAPI has not gone through a JSR which makes >>> it clear rxtx can be in javax.comm and explains how conformancy is >>> determined, I do not think this is the right forum though you can freely >>> do so. >> >> Hi Trent, >> >> If I understand it correctly you don't want to put those >>javax.comm classes in >> the distribution until a JSR completes. :( >> >> Sun wants a JSR too to change the API: >>> Ultimately the COMMAPI would be better served if a Java >>> Community Process JSR (http://www.jcp.org) was opened and >>> the COMMAPI was rearchitected to provide a more pluggable >>> framework to improve cross-platform support. Such an >>> architecture would embody a better defined and better >>> documented SPI interface, including a way for comm. ports >>> to be revealed to the client application through the API >>> via platform-aware plugins. Similarly, native code used >>> to access comm port in general could be handled more >>> flexibly using a plugin model, whereby on any platform, >>> multiple native modules could be in use simultaneously. >> >> How about it? I can spend 5 hours a week. > >Yes. I'm all in favor of this. Dr. Doug Lyon is our fearless leader in >these matters and has final say. He has asked everyone if they have an >issue with going through the JSR. I have seen no responses though some >may have responeded to him in private. > >I am now working for The MathWorks in a related field. To best represent >the RXTX community, we have asked Doug to be the neutral maintainer. >This does not mean he is taking on all the work like making releases. He >has the ability to and the power. But thats not really spending his time >efficiently. It does mean when there are decisions to be made that may >have conflicts, he has final say. > >The easy solution :) is to bug Trent or Doug and see if they will just go >into javax.comm namespace. The right solution is to work with Doug and >try to get the JSR process completed. I'm willing to help too as time >permits. > >I'm willing to work with Doug. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jul 17 11:31:58 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 17 Jul 2006 13:31:58 -0400 Subject: [Rxtx] JSR Message-ID: <20060717173158.USWI24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> In the meantime could these methods not be added to a child class. This way the extra functionality can be provided, but you would have to explictly check to see of the class is an RXTX specifc interface. For example: class RxTxCommPort extends CommPort { //RxTx specific methods } CommPort port = commPortIdentifierInstance.open(...); if ( port instanceof RxTxCommPort ) { // do RxTx specifc stuff } // continue doing usual stuff Andre > > From: "Pascal S. de Kloe" > Date: 2006/07/17 Mon AM 08:12:09 EDT > To: RXTX Developers and Users > Subject: [Rxtx] JSR > > Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: > > On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > > > Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: > > >>> Yes. There are additional methods in gnu.io.SerialPort. We clearly > > >>> mark those as extensions to CommAPI and discourage their use. There > > >>> just isn't a way to get the intended functionality out of CommAPI > > >>> without them. > > >> > > >> If you don't want the users to use the methods then make them class > > >> protected (remove the word "public" before the method) and if you can't > > >> do that we might do the following: > > >> > > >> ---- SerialPort.java > > >> package javax.comm > > >> > > >> class SerialPort extends gnu.io.SerialPort { > > >> > > >> public void > > >> rxtxOnlyMethod() { > > >> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort > > >> instead"); > > >> } > > >> ---- end > > > > > > So how about it, Trent? > > > > > > Can we ship those classes with the next release? > > > > Hi Pascal > > > > I'm not going to say what people can or can not ship. I'm going to > > propose removing all of the above extensions from SerialPort.java. I > > think it is the best thing to do after cooling off a bit. > > > > But thats all I've considered at this point. I'm in favor of removing the > > extensions and staying in gnu.io which more importantly means staying at > > arms length from javax. > > > > I can remove the extensions, put a windows fix in, bump the versions and > > tag the releases without changing packages if everyone agrees to that. > > If people want to know why CommAPI has not gone through a JSR which makes > > it clear rxtx can be in javax.comm and explains how conformancy is > > determined, I do not think this is the right forum though you can freely > > do so. > > Hi Trent, > > If I understand it correctly you don't want to put those javax.comm classes in > the distribution until a JSR completes. :( > > Sun wants a JSR too to change the API: > > Ultimately the COMMAPI would be better served if a Java > > Community Process JSR (http://www.jcp.org) was opened and > > the COMMAPI was rearchitected to provide a more pluggable > > framework to improve cross-platform support. Such an > > architecture would embody a better defined and better > > documented SPI interface, including a way for comm. ports > > to be revealed to the client application through the API > > via platform-aware plugins. Similarly, native code used > > to access comm port in general could be handled more > > flexibly using a plugin model, whereby on any platform, > > multiple native modules could be in use simultaneously. > > How about it? I can spend 5 hours a week. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From joachim at buechse.de Mon Jul 17 11:59:19 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 17 Jul 2006 19:59:19 +0200 Subject: [Rxtx] Bumping versions In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> <200607170140.14116.pascal@quies.net> Message-ID: <6ABAF770-41AE-4BA0-800D-2DCC8025FCA8@buechse.de> Hello Trent, I would appreciate if we could get to a version 2.1.8. In fact as several recent posting have shown, almost anyone working on OSX would appreciate getting there. Should anything be removed before that? I dont know. There is nothing wrong with having 2.1.9 following shortly after 2.1.8. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 17.07.2006, at 02:59, Trent Jarvi wrote: > On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > >> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>> Yes. There are additional methods in gnu.io.SerialPort. We >>>> clearly mark >>>> those as extensions to CommAPI and discourage their use. There >>>> just >>>> isn't a way to get the intended functionality out of CommAPI >>>> without >>>> them. >>> >>> If you don't want the users to use the methods then make them class >>> protected (remove the word "public" before the method) and if you >>> can't do >>> that we might do the following: >>> >>> ---- SerialPort.java >>> package javax.comm >>> >>> class SerialPort extends gnu.io.SerialPort { >>> >>> public void >>> rxtxOnlyMethod() { >>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>> instead"); >>> } >>> ---- end >> >> So how about it, Trent? >> >> Can we ship those classes with the next release? > > Hi Pascal > > I'm not going to say what people can or can not ship. I'm going to > propose removing all of the above extensions from SerialPort.java. I > think it is the best thing to do after cooling off a bit. > > But thats all I've considered at this point. I'm in favor of > removing the > extensions and staying in gnu.io which more importantly means > staying at > arms length from javax. > > I can remove the extensions, put a windows fix in, bump the > versions and > tag the releases without changing packages if everyone agrees to that. > If people want to know why CommAPI has not gone through a JSR which > makes > it clear rxtx can be in javax.comm and explains how conformancy is > determined, I do not think this is the right forum though you can > freely > do so. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jul 17 12:40:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 12:40:32 -0600 (MDT) Subject: [Rxtx] Bumping versions In-Reply-To: <6ABAF770-41AE-4BA0-800D-2DCC8025FCA8@buechse.de> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> <200607170140.14116.pascal@quies.net> <6ABAF770-41AE-4BA0-800D-2DCC8025FCA8@buechse.de> Message-ID: Hi Joachim I will work with you towards that. I'm going to the Linux Symposium this week which should mean I have time to tinker. I'll work on rxtx while riding in a carpool to Ottawa. On Mon, 17 Jul 2006, Joachim Buechse wrote: > Hello Trent, > > I would appreciate if we could get to a version 2.1.8. In fact as > several recent posting have shown, almost anyone working on OSX would > appreciate getting there. Should anything be removed before that? I > dont know. There is nothing wrong with having 2.1.9 following shortly > after 2.1.8. > > Regards, > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 17.07.2006, at 02:59, Trent Jarvi wrote: > >> On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: >> >>> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>>> Yes. There are additional methods in gnu.io.SerialPort. We >>>>> clearly mark >>>>> those as extensions to CommAPI and discourage their use. There >>>>> just >>>>> isn't a way to get the intended functionality out of CommAPI >>>>> without >>>>> them. >>>> >>>> If you don't want the users to use the methods then make them class >>>> protected (remove the word "public" before the method) and if you >>>> can't do >>>> that we might do the following: >>>> >>>> ---- SerialPort.java >>>> package javax.comm >>>> >>>> class SerialPort extends gnu.io.SerialPort { >>>> >>>> public void >>>> rxtxOnlyMethod() { >>>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>>> instead"); >>>> } >>>> ---- end >>> >>> So how about it, Trent? >>> >>> Can we ship those classes with the next release? >> >> Hi Pascal >> >> I'm not going to say what people can or can not ship. I'm going to >> propose removing all of the above extensions from SerialPort.java. I >> think it is the best thing to do after cooling off a bit. >> >> But thats all I've considered at this point. I'm in favor of >> removing the >> extensions and staying in gnu.io which more importantly means >> staying at >> arms length from javax. >> >> I can remove the extensions, put a windows fix in, bump the >> versions and >> tag the releases without changing packages if everyone agrees to that. >> If people want to know why CommAPI has not gone through a JSR which >> makes >> it clear rxtx can be in javax.comm and explains how conformancy is >> determined, I do not think this is the right forum though you can >> freely >> do so. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pascal at quies.net Mon Jul 17 17:54:56 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Tue, 18 Jul 2006 01:54:56 +0200 Subject: [Rxtx] summary of issues In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> Message-ID: <200607180154.56359.pascal@quies.net> Op maandag 17 juli 2006 18:34, schreef Dr. Douglas Lyon: > Hi All, > As I see it, at this stage of the discussion, I think it would be helpful > to summarize the concerns. Let me see if I can get this > straight, and please correct me, if I am wrong: Thank you. :) > 1. Sun is making no progress on improving the CommAPI spec. > 2. We are seeking to reinvigorate a JSR for the CommAPI in order > to keep sun involved. Sun wants a JSR becouse they have other concerns than a almost obsolete piece of hardware. > 3. Meanwhile we are extending the RXTX API, with non- > commAPI improvements. > 4. People are worried that the improvements will be non-portable, > when the commAPI re-activates. > 5. I have asked for feedback on the JSR approach and obtained > zero response. > 6. My limited imagination does not see any drawback to taking > the JSR approach (except, possibly, from the overhead of a committee, or > some license issue that I do not understand). > 7. http://www.jcp.org/en/jsr/detail?id=922 shows the status of the JSR now. > Status: Withdrawn > The sun contact is: vincent.zhang at sun.com > I have written to Vincent at Sun to ask him what would be involved with > reactivation of JSR 922. We don't need to communicate with the employees but we need a plan. We need a working implementation with a free license. They have offered us some ideas like in the 2.0.3 README (see attachment). Is there a plan based on the differences of the various platforms? Is there a API purposal? Is there a plan of the JNI? If not I am willing to help. I can write/represent the POSIX part with special interrest of the free UNIX systems. -------------- next part -------------- DISTRIBUTION NOTES: This distribution contains the comm.jar file original part of the COMMAPI 2.0.3 release. The 2.0.3 release itself is no longer distributed. comm.jar, which contains the comm API java class files (eg. Sun's binary implementation of the interface classes), is being made available, unsupported, with no obligation to fix bugs, at the request of the RXTX project. The RxTx project (http://www.rxtx.org), uses the comm.jar class files, but provides their own native library components to provide support for other platforms. The 2.0.3 comm.jar is being provided in this way because as of COMMAPI 3.x, the java binary implementation forked and became incompatible with the RxTx project's native code. Due to the lack of a clear business case, and to resource constraints, no additional resources are being provided to provide an alternative engineering solution at the time of writing. RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: Ultimately the COMMAPI would be better served if a Java Community Process JSR (http://www.jcp.org) was opened and the COMMAPI was rearchitected to provide a more pluggable framework to improve cross-platform support. Such an architecture would embody a better defined and better documented SPI interface, including a way for comm. ports to be revealed to the client application through the API via platform-aware plugins. Similarly, native code used to access comm port in general could be handled more flexibly using a plugin model, whereby on any platform, multiple native modules could be in use simultaneously. Since there are now various ways serial ports can be implemented and accessed, modular comm. port JNI native libraries would be of benefit insofar as removing the burden of over-generalization from any single native component, or inversely, by relieving the implicit constraint that comm. drivers be accessed only via a monolithic mechanism, such as the UNIX vnode interface. paul.klissner at sun.com 6/10/06 From tjarvi at qbang.org Mon Jul 17 18:24:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 18:24:47 -0600 (MDT) Subject: [Rxtx] summary of issues In-Reply-To: <200607180154.56359.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607180154.56359.pascal@quies.net> Message-ID: On Tue, 18 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 17 juli 2006 18:34, schreef Dr. Douglas Lyon: >> Hi All, >> As I see it, at this stage of the discussion, I think it would be helpful >> to summarize the concerns. Let me see if I can get this >> straight, and please correct me, if I am wrong: > > Thank you. :) > >> 1. Sun is making no progress on improving the CommAPI spec. >> 2. We are seeking to reinvigorate a JSR for the CommAPI in order >> to keep sun involved. > > Sun wants a JSR becouse they have other concerns than a almost obsolete piece > of hardware. > >> 3. Meanwhile we are extending the RXTX API, with non- >> commAPI improvements. >> 4. People are worried that the improvements will be non-portable, >> when the commAPI re-activates. >> 5. I have asked for feedback on the JSR approach and obtained >> zero response. >> 6. My limited imagination does not see any drawback to taking >> the JSR approach (except, possibly, from the overhead of a committee, or >> some license issue that I do not understand). >> 7. http://www.jcp.org/en/jsr/detail?id=922 shows the status of the JSR now. >> Status: Withdrawn >> The sun contact is: vincent.zhang at sun.com >> I have written to Vincent at Sun to ask him what would be involved with >> reactivation of JSR 922. > > We don't need to communicate with the employees but we need a plan. We need a > working implementation with a free license. They have offered us some ideas > like in the 2.0.3 README (see attachment). > > Is there a plan based on the differences of the various platforms? Is there a > API purposal? Is there a plan of the JNI? > > If not I am willing to help. I can write/represent the POSIX part with special > interrest of the free UNIX systems. > Not to put words in your mouth but it sounds like you would rather not be in javax.comm namespace at all and do something like a VFS for serial ports as suggested in the readme? Maybe call it a VCS for character streams. That sounds like a major version change rather than an incremental change. So a vote for cutting the ropes and floating in the current? rxtx 3.0 or whatever abandoning current application requirements and perhaps largely rewriting rxtx.. Thats possible and could happen at the same time. An email to Vincent sounds polite enough at this stage. -- Trent Jarvi tjarvi at qbang.org From phillip at uow.edu.au Mon Jul 17 19:33:19 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Tue, 18 Jul 2006 11:33:19 +1000 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application in Mac OSX" Message-ID: <7DBE5FEB-EA06-45BC-ABBE-A9990281E32D@uow.edu.au> Hi We found a workaround - Problem fixed by creating /var/lock directory - seems that they changed the directory from /var/spool/uucp for the lock file but didn't update the documentation. audfg5:~ phillip$ sudo mkdir /var/lock Password: audfg5:~ phillip$ ls -ld /var/lock drwxr-xr-x 2 root wheel 68 Jul 18 09:51 /var/lock audfg5:~ phillip$ sudo chmod 775 /var/lock audfg5:~ phillip$ ls -ld /var/lock drwxrwxr-x 2 root wheel 68 Jul 18 09:51 /var/lock audfg5:~ phillip$ sudo chgrp uucp /var/lock audfg5:~ phillip$ ls -ld /var/lock drwxrwxr-x 2 root uucp 68 Jul 18 09:51 /var/lock audfg5:~ phillip$ ls -l /var/lock total 8 -r--r--r-- 1 phillip uucp 11 Jul 18 09:58 LK.003.009.002 Now both programs work and we get a warning on the console: RXTX Warning: Removing stale lock file. /var/lock/LK.003.009.002 Do we still need the /var/spool/uucp directory?? thanks Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From tjarvi at qbang.org Mon Jul 17 19:40:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 19:40:26 -0600 (MDT) Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application in Mac OSX" In-Reply-To: <7DBE5FEB-EA06-45BC-ABBE-A9990281E32D@uow.edu.au> References: <7DBE5FEB-EA06-45BC-ABBE-A9990281E32D@uow.edu.au> Message-ID: On Tue, 18 Jul 2006, Phillip McKerrow wrote: > Hi > We found a workaround - Problem fixed by creating /var/lock directory > - seems that they changed the directory from /var/spool/uucp for the > lock file but didn't update the documentation. > > audfg5:~ phillip$ sudo mkdir /var/lock > Password: > audfg5:~ phillip$ ls -ld /var/lock > drwxr-xr-x 2 root wheel 68 Jul 18 09:51 /var/lock > audfg5:~ phillip$ sudo chmod 775 /var/lock > audfg5:~ phillip$ ls -ld /var/lock > drwxrwxr-x 2 root wheel 68 Jul 18 09:51 /var/lock > audfg5:~ phillip$ sudo chgrp uucp /var/lock > audfg5:~ phillip$ ls -ld /var/lock > drwxrwxr-x 2 root uucp 68 Jul 18 09:51 /var/lock > audfg5:~ phillip$ ls -l /var/lock > total 8 > -r--r--r-- 1 phillip uucp 11 Jul 18 09:58 LK.003.009.002 > > Now both programs work and we get a warning on the console: > RXTX Warning: Removing stale lock file. /var/lock/LK.003.009.002 > > Do we still need the /var/spool/uucp directory?? > [The new code in CVS will not use Lockfiles on Mac OS X.] The above can happen if you did not close the port before exiting the program. The warning is harmless. RXTX notes that the old program is not running and removes the stale lockfile. -- Trent Jarvi tjarvi at qbang.org From phillip at uow.edu.au Tue Jul 18 01:07:40 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Tue, 18 Jul 2006 17:07:40 +1000 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX Message-ID: Hi I am trying to run a precompiled Java program (JavaKit for setting up the TINI processor over a serial link from http://www.maxim-ic.com/ products/tini/software/downloads.cfm). It uses javax.comm for serial communication. 1. I downloaded the Sparc Solaris version of comm.jar and placed it in /Library/Java/Extensions with RXTXcomm.jar and librxtxSerial.jnilib. 2. I added a javax.com.properties file to /System/Library/Frameworks/ JavaVM.framework/Versions/CurrentJDK/Home/lib It is a text file with one line Driver=gnu.io.RXTXCommDriver 3. When I execute JavaKit it crashes with the following console output audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver (CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:109) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Exception in thread "main" java.lang.UnsatisfiedLinkError: isSessionActive at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts (Portmapping.java:155) at com.sun.comm.Portmapping.refreshPortDatabase (Portmapping.java:100) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:138) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ Home/lib/ext instead of /Library/Java/Extensions it makes no difference: If I use the generic version of comm,jar file from Sun, JavaKit brings up a gui but can't find the serial ports: The console output is: audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while loading driver gnu.io.RXTXCommDriver Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no SolarisSerialParallel in java.library.path Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while loading driver com.sun.comm.SolarisDriver Am I doing something wrong in my efforts to get this going? Should I have another file loaded somewhere or have I run into a bug in RXTX?? thanks again for your help. Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From joachim at buechse.de Tue Jul 18 02:53:38 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 18 Jul 2006 10:53:38 +0200 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: References: Message-ID: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> 2.1.7 is the gnu.io.* version. You need 2.0.7 ie the javax.comm.* version. --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 18.07.2006, at 09:07, Phillip McKerrow wrote: > Hi > > I am trying to run a precompiled Java program (JavaKit for setting up > the TINI processor over a serial link from http://www.maxim-ic.com/ > products/tini/software/downloads.cfm). It uses javax.comm for serial > communication. > > 1. I downloaded the Sparc Solaris version of comm.jar and placed it > in /Library/Java/Extensions with RXTXcomm.jar and > librxtxSerial.jnilib. > > 2. I added a javax.com.properties file to /System/Library/Frameworks/ > JavaVM.framework/Versions/CurrentJDK/Home/lib > It is a text file with one line > Driver=gnu.io.RXTXCommDriver > > 3. When I execute JavaKit it crashes with the following console output > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver > (CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:109) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > Exception in thread "main" java.lang.UnsatisfiedLinkError: > isSessionActive > at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > at com.sun.comm.Portmapping.registerCommPorts > (Portmapping.java:155) > at com.sun.comm.Portmapping.refreshPortDatabase > (Portmapping.java:100) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:138) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > > If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ > Home/lib/ext > instead of /Library/Java/Extensions it makes no difference: > > If I use the generic version of comm,jar file from Sun, JavaKit > brings up a gui but can't find the serial ports: The console > output is: > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while > loading driver gnu.io.RXTXCommDriver > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no > SolarisSerialParallel in java.library.path > Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while > loading driver com.sun.comm.SolarisDriver > > > Am I doing something wrong in my efforts to get this going? Should I > have another file loaded somewhere or have I run into a bug in RXTX?? > > thanks again for your help. > > Phillip > > > ---------------------------------------------------------------------- > Phillip McKerrow http:// > www.uow.edu.au/~phillip/ > School of Information Technology and Computer Science > University of Wollongong * > Northfields Avenue, * * > Wollongong, NSW, 2522. + > AUSTRALIA * the land of the > southern cross > tel : +61 2 4221 3771 fax : +61 2 4221 > 4170 > > God so loved the world that he gave his one and only Son (Jesus), > that whoever believes in him shall not perish but have eternal life. > John 3:16 > ---------------------------------------------------------------------- > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alex at det.ua.pt Tue Jul 18 03:29:15 2006 From: alex at det.ua.pt (Alexandre Mota) Date: Tue, 18 Jul 2006 10:29:15 +0100 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: Message-ID: Hello Edit the JavaKit.java in order to use the gnu.io and compile everything. If you have the RXTX already installed and working it will work. I am using it on linux and windows with jdk 1.5. Best Regards Alexandre -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Phillip McKerrow Sent: ter?a-feira, 18 de Julho de 2006 8:08 To: rxtx at qbang.org Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX Hi I am trying to run a precompiled Java program (JavaKit for setting up the TINI processor over a serial link from http://www.maxim-ic.com/ products/tini/software/downloads.cfm). It uses javax.comm for serial communication. 1. I downloaded the Sparc Solaris version of comm.jar and placed it in /Library/Java/Extensions with RXTXcomm.jar and librxtxSerial.jnilib. 2. I added a javax.com.properties file to /System/Library/Frameworks/ JavaVM.framework/Versions/CurrentJDK/Home/lib It is a text file with one line Driver=gnu.io.RXTXCommDriver 3. When I execute JavaKit it crashes with the following console output audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver (CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:109) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Exception in thread "main" java.lang.UnsatisfiedLinkError: isSessionActive at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts (Portmapping.java:155) at com.sun.comm.Portmapping.refreshPortDatabase (Portmapping.java:100) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:138) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ Home/lib/ext instead of /Library/Java/Extensions it makes no difference: If I use the generic version of comm,jar file from Sun, JavaKit brings up a gui but can't find the serial ports: The console output is: audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while loading driver gnu.io.RXTXCommDriver Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no SolarisSerialParallel in java.library.path Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while loading driver com.sun.comm.SolarisDriver Am I doing something wrong in my efforts to get this going? Should I have another file loaded somewhere or have I run into a bug in RXTX?? thanks again for your help. Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jul 18 04:52:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 18 Jul 2006 04:52:02 -0600 (MDT) Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: References: Message-ID: On Tue, 18 Jul 2006, Phillip McKerrow wrote: > Hi > > I am trying to run a precompiled Java program (JavaKit for setting up > the TINI processor over a serial link from http://www.maxim-ic.com/ > products/tini/software/downloads.cfm). It uses javax.comm for serial > communication. > > 1. I downloaded the Sparc Solaris version of comm.jar and placed it > in /Library/Java/Extensions with RXTXcomm.jar and > librxtxSerial.jnilib. > > 2. I added a javax.com.properties file to /System/Library/Frameworks/ > JavaVM.framework/Versions/CurrentJDK/Home/lib > It is a text file with one line > Driver=gnu.io.RXTXCommDriver > > 3. When I execute JavaKit it crashes with the following console output > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver > (CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:109) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > Exception in thread "main" java.lang.UnsatisfiedLinkError: > isSessionActive > at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > at com.sun.comm.Portmapping.registerCommPorts > (Portmapping.java:155) > at com.sun.comm.Portmapping.refreshPortDatabase > (Portmapping.java:100) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:138) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > > If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ > Home/lib/ext > instead of /Library/Java/Extensions it makes no difference: > > If I use the generic version of comm,jar file from Sun, JavaKit > brings up a gui but can't find the serial ports: The console output is: > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while > loading driver gnu.io.RXTXCommDriver > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no > SolarisSerialParallel in java.library.path > Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while > loading driver com.sun.comm.SolarisDriver > > > Am I doing something wrong in my efforts to get this going? Should I > have another file loaded somewhere or have I run into a bug in RXTX?? > > thanks again for your help. > RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for that. Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Tue Jul 18 16:14:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 18 Jul 2006 18:14:38 -0400 Subject: [Rxtx] jcp and jsr In-Reply-To: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> References: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> Message-ID: Hi All, I have been in touch with: Paul Klissner Please read what Paul writes below. I am not sure, but this might be a good chance for the RXTX group to take action. As to what we should write for the JSR, I am thinking about something in the javax.comm namespace. What is the collective feeling about that? Thanks! - Doug Paul writes: "I think a JSR should be opened, but I don't see any point in proceeding with 922, which never formed and expert group, or provided a specification or reference implementation. It was a placeholder, and the title wasn't even relevant. I think we should discuss our ideas about what we'd like to accomplish and javax.comm and see if we can reach an agreement. You would submit a JSR through the Java Community Process, and if you do, I'd like to represent Sun on the expert group, and contribute to the effort. We may want to start with a fresh specification, borrowing what we want from the current javax.com, adding what we need, and creating a reference implementation. Paul" From pascal at quies.net Tue Jul 18 18:12:26 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 02:12:26 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> Message-ID: <200607190212.27131.pascal@quies.net> Hi Dr., The namespace is the last thing we need to worry about. Let's start with the common goals. For instance the current API is not very object oriented. It might be a good idea to have a static set of objects available representing every supported port available on the system in realtime. Each object should clearly know its own state and its capabilities. To get a port there could be a method like synchronized void connect(PortUser) where PortUser is a interface which handles the interaction with a input and a output stream and listers like PortStillAvailableListener, PortBufferListener and a DataAvailableListener. What is the collective feeling about that? Op woensdag 19 juli 2006 00:14, schreef Dr. Douglas Lyon: > Hi All, > I have been in touch with: > Paul Klissner > Please read what Paul writes below. > I am not sure, but this might be a good chance for > the RXTX group to take action. > As to what we should write for the JSR, I am thinking > about something in the javax.comm namespace. > What is the collective feeling about that? > Thanks! > - Doug > > Paul writes: > "I think a JSR should be opened, but I don't see any point > in proceeding with 922, which never formed and expert group, > or provided a specification or reference implementation. > It was a placeholder, and the title wasn't even relevant. > > I think we should discuss our ideas about what we'd like > to accomplish and javax.comm and see if we can reach an > agreement. > > You would submit a JSR through the Java Community Process, > and if you do, I'd like to represent Sun on the expert group, > and contribute to the effort. We may want to start with > a fresh specification, borrowing what we want from the > current javax.com, adding what we need, and creating > a reference implementation. From phillip at uow.edu.au Tue Jul 18 23:44:25 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Wed, 19 Jul 2006 15:44:25 +1000 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application in Mac OSX" Message-ID: <7EEF3F56-A406-4532-BB3D-AA642A4818CA@uow.edu.au> > > Do we still need the /var/spool/uucp directory?? > > >> Trent Jarvi wrote >>[The new code in CVS will not use Lockfiles on Mac OS X.] Great, that should make installation easier. When will the next version be released? Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From phillip at uow.edu.au Wed Jul 19 00:14:26 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Wed, 19 Jul 2006 16:14:26 +1000 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: References: Message-ID: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> > > Edit the JavaKit.java in order to use the gnu.io and compile > everything. > > Alexandre > Unfotunately all I have is a .jar that contains it. I haven't found the source on their web site. > From: Joachim Buechse > 2.1.7 is the gnu.io.* version. You need 2.0.7 ie the javax.comm.* > version. > > RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for > that. > > Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. > > Trent Jarv I found the rxtx download page and downloaded rxtx-2.0-7pre1 (source/ Mac) The Install folder in ForPackageMaker has librxtxSerial.jnilib and java.com.properties but instead of RXTXComm.jar it has jcl.jar (I have no idea what is is for - it doesn't seem to be a replacement for RXTXCom.jar) I tried to run the XCode project to build it but there is a syntax error - nativeSetSerialPortParams returns a void not a jboolean. Also, there is no target to make RXTXComm.jar JNIEXPORT void JNICALL Java_gnu_io_RXTXPort_nativeSetSerialPortParams (JNIEnv *, jobject, jint, jint, jint, jint); Can you tell me where to find either a working copy of 2.0 for Mac OSX, or RXTXComm.jar or a working XCode project for Version 2. This is getting very frustrating. thanks Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From joachim at buechse.de Wed Jul 19 01:17:03 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 19 Jul 2006 09:17:03 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607190212.27131.pascal@quies.net> References: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> <200607190212.27131.pascal@quies.net> Message-ID: <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> The static objects will work for Windows and Linux, however for OSX they will create problems: - ports can appear and disappear at any time with VCP drivers for USB - the port names are not known until the usb-port is "plugged in" Please do not forget that tty ports can be opened by several applications concurrently. All of those will "loose" the port if anyone opens the corresponding cu port. As this naming based mechanism does not exist on Windows (maybe it does via an API) it should probably be reflected in the API. In other words there are "two levels of open": - Open for reading status lines (1) - Open for reading/writing data (2) I am not sure if state (1) should also allow the modification of certain status lines (ie to set a modem ready). I am also not sure if the api should unify corresponding cu. and tty. ports into one single port. Regards, Joachim On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: > For instance the current API is not very object oriented. > It might be a good idea to have a static set of objects available > representing > every supported port available on the system in realtime. Each > object should > clearly know its own state and its capabilities. To get a port > there could be > a method like synchronized void connect(PortUser) where PortUser is a > interface which handles the interaction with a input and a output > stream and > listers like PortStillAvailableListener, PortBufferListener and a > DataAvailableListener. > > What is the collective feeling about that? From joachim at buechse.de Wed Jul 19 01:29:53 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 19 Jul 2006 09:29:53 +0200 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> References: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> Message-ID: <2D32167B-3830-41D6-9FDD-462301F0453F@buechse.de> As you have already downloaded the source, just cd into the main folder and do a "cvs up -d" this will remove some outdated files and create a new XCode project which should compile without problems. You may also want to search the mail archive or checkout README.OSX for my suggestion on how to avoid the javax.comm.properties file by creating a class com.sun.comm.SolarisDriver. Regards, Joachim PS: I can feel your pain... it was the same for me. In fact I never understood why there are different native or java implementations for 2.0 and 2.1. The two versions could easily be unified by using the simplest of OO programing (intermediate abstract classes). But I guess at the time of branching the direction was not clear. Also the licences are not the same... On 19.07.2006, at 08:14, Phillip McKerrow wrote: >> RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for >> that. >> >> Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. >> >> Trent Jarv > > I found the rxtx download page and downloaded rxtx-2.0-7pre1 (source/ > Mac) > > The Install folder in ForPackageMaker has librxtxSerial.jnilib and > java.com.properties but instead of RXTXComm.jar it has jcl.jar (I > have no idea what is is for - it doesn't seem to be a replacement for > RXTXCom.jar) > > I tried to run the XCode project to build it but there is a syntax > error - nativeSetSerialPortParams returns a void not a jboolean. > Also, there is no target to make RXTXComm.jar > > JNIEXPORT void JNICALL Java_gnu_io_RXTXPort_nativeSetSerialPortParams > (JNIEnv *, jobject, jint, jint, jint, jint); > > Can you tell me where to find either a working copy of 2.0 for Mac > OSX, or RXTXComm.jar or a working XCode project for Version 2. This > is getting very frustrating. > > thanks > > Phillip > > ---------------------------------------------------------------------- > Phillip McKerrow http:// > www.uow.edu.au/~phillip/ > School of Information Technology and Computer Science > University of Wollongong * > Northfields Avenue, * * > Wollongong, NSW, 2522. + > AUSTRALIA * the land of the > southern cross > tel : +61 2 4221 3771 fax : +61 2 4221 > 4170 > > God so loved the world that he gave his one and only Son (Jesus), > that whoever believes in him shall not perish but have eternal life. > John 3:16 > ---------------------------------------------------------------------- > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alex at det.ua.pt Wed Jul 19 03:02:40 2006 From: alex at det.ua.pt (Alexandre Mota) Date: Wed, 19 Jul 2006 10:02:40 +0100 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> References: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> Message-ID: <44BDF530.5080502@det.ua.pt> Phillip McKerrow wrote: >>Edit the JavaKit.java in order to use the gnu.io and compile >>everything. >> >>Alexandre >> >> >> >Unfotunately all I have is a .jar that contains it. I haven't found >the source on their web site. > > > > Download http://files.dalsemi.com/pub/tini/tini1_17.tgz Decompress it and you will find the JavaKiTSrc.jar in the src dir. Decompress it with jar -xf JavaKitSrc.jar and you will get all the source files you need. Alexandre PS: Remenber that puting JavaKit into work is allways a pain... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060719/f5172a01/attachment-0346.html From lyon at docjava.com Wed Jul 19 05:27:47 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 19 Jul 2006 07:27:47 -0400 Subject: [Rxtx] RXTX binary for mac In-Reply-To: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> References: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> Message-ID: Hi All, I have some older RXTX binaries that are deployed in a webstart application. You can try it with: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp The libs are signed and packed for webstart disto by me. http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/ Shows them. - DL > > >> Edit the JavaKit.java in order to use the gnu.io and compile? >> everything. >> >> Alexandre >> >Unfotunately all I have is a .jar that contains it. I haven't found? >the source on their web site. > > >> From: Joachim Buechse >> 2.1.7 is the gnu.io.* version. You need 2.0.7 ie the javax.comm.* >> version. >> > >> RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for? >> that. >> >> Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. >> >> Trent Jarv > >I found the rxtx download page and downloaded rxtx-2.0-7pre1 (source/ >Mac) > >The Install folder in ForPackageMaker has librxtxSerial.jnilib and? >java.com.properties but instead of RXTXComm.jar it has jcl.jar (I? >have no idea what is is for - it doesn't seem to be a replacement for? >RXTXCom.jar) > >I tried to run the XCode project to build it but there is a syntax? >error - nativeSetSerialPortParams returns a void not a jboolean.?? >Also, there is no target to make RXTXComm.jar > >JNIEXPORT void JNICALL Java_gnu_io_RXTXPort_nativeSetSerialPortParams > (JNIEnv *, jobject, jint, jint, jint, jint); > >Can you tell me where to find either a working copy of 2.0 for Mac? >OSX, or RXTXComm.jar or a working XCode project for Version 2. This? >is getting very frustrating. > >thanks > >Phillip > >---------------------------------------------------------------------- >Phillip McKerrow http:// >www.uow.edu.au/~phillip/ >School of Information Technology and Computer Science >University of Wollongong * >Northfields Avenue, * * >Wollongong, NSW, 2522. + >AUSTRALIA * the land of the? >southern cross >tel : +61 2 4221 3771 fax : +61 2 4221 4170 > >God so loved the world that he gave his one and only Son (Jesus), >that whoever believes in him shall not perish but have eternal life. >John 3:16 >---------------------------------------------------------------------- > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Wed Jul 19 06:11:27 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 14:11:27 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> Message-ID: <200607191411.27566.pascal@quies.net> Hi Joachim, Thanks for the constructive critisism. :) Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: > The static objects will work for Windows and Linux, however for OSX > they will create problems: > - ports can appear and disappear at any time with VCP drivers for USB > - the port names are not known until the usb-port is "plugged in" Ports can appear and disappear on *any* OS with USB support. Some Linux distributions even create and remove devicefiles on the fly. With the current API you fetch a list of all available ports and then you try to cast one. What happens if the port is no longer available at that time? What happens if a port vanishes during the data transfer? Of course you can catch exceptions but that makes the code quite messy. The idea was to get a PortStillAvailableListener interface. In that way the implementation is free to handle a cleanup or wait for return routine in a OO way. The I/O streams should just lock. The word static was not ment as persistent but as Java static available. Considder the following: java.lang.hw.HardwareConfiguration { public enum PortType { RS232, I2C, etc. }; /** Gets the currently available ports of type {@code PortType}. */ public static java.lang.hw.Port[] getPorts(PortType); } com.example.Driver implements PortUser, implements PortStillAvailableListener { public portNoLongerAvailable(PortEvent event) { // cleanup & dismiss. } } com.example.Application { public static void main(String[] args) { Driver someDriver = new Driver(); Port radomPort = HardwareConfiguration.getPorts( HardwareConfiguration.PortType.RS232)[1]; myDevice.addStillAvailableListener(someDriver); myDevice.connect(someDriver); } } > Please do not forget that tty ports can be opened by several > applications concurrently. All of those will "loose" the port if > anyone opens the corresponding cu port. Indeed we need a good overview of the differences between the various platforms. Should we create a document or a Wiki for this purpose? FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: http://www.openbsd.org/cgi-bin/man.cgi?query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html Linux uses /var/lock: http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES Is there absolutely no way to get a lock under Windows? > As this naming based > mechanism does not exist on Windows (maybe it does via an API) it > should probably be reflected in the API. In other words there are > "two levels of open": > > - Open for reading status lines (1) > - Open for reading/writing data (2) > > I am not sure if state (1) should also allow the modification of > certain status lines (ie to set a modem ready). I'm not sure I understand. Do you mean canonical and noncanonical mode? How far is Windows with the canonical mode. Is it comparable to POSIX? > I am also not sure if > the api should unify corresponding cu. and tty. ports into one single > port. I think the API should hide low-level details like devicefiles. Who is participating anyway? Is it just the four of us? Cheers, Pascal > On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: > > For instance the current API is not very object oriented. > > It might be a good idea to have a static set of objects available > > representing > > every supported port available on the system in realtime. Each > > object should > > clearly know its own state and its capabilities. To get a port > > there could be > > a method like synchronized void connect(PortUser) where PortUser is a > > interface which handles the interaction with a input and a output > > stream and > > listers like PortStillAvailableListener, PortBufferListener and a > > DataAvailableListener. > > > > What is the collective feeling about that? From joachim at buechse.de Wed Jul 19 07:09:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 19 Jul 2006 15:09:27 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191411.27566.pascal@quies.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> Message-ID: <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> Pascal, I think that the PortNoLongerAvailableListener creates more problems than it solves. I think that exceptions are much better suited for this case. There might be an additional method "Port.isOpen" or "Port.isAvailable" which interested applications may call at times best suited. Most implementations will only find out, that a port disappeared when trying to read or write. Anything else would require polling with a high frequency or kernel hooks that do not exist (in POSIX). Any kind of call back like portNoLongerAvailable() creates the risk of deadlocks and races which require an involved implementation as the library does not know what it is calling (ie a user might try to call close from the callback which can block a very long time). Callbacks introduce concurrency which unneccessarily increases the complexity. Regards, Joachim On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: > Hi Joachim, > > Thanks for the constructive critisism. :) > > Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >> The static objects will work for Windows and Linux, however for OSX >> they will create problems: >> - ports can appear and disappear at any time with VCP drivers for USB >> - the port names are not known until the usb-port is "plugged in" > > Ports can appear and disappear on *any* OS with USB support. Some > Linux > distributions even create and remove devicefiles on the fly. > > With the current API you fetch a list of all available ports and > then you try > to cast one. What happens if the port is no longer available at > that time? > What happens if a port vanishes during the data transfer? Of course > you can > catch exceptions but that makes the code quite messy. > > The idea was to get a PortStillAvailableListener interface. In that > way the > implementation is free to handle a cleanup or wait for return > routine in a OO > way. The I/O streams should just lock. > > The word static was not ment as persistent but as Java static > available. > Considder the following: > > java.lang.hw.HardwareConfiguration { > public enum PortType { RS232, I2C, etc. }; > > /** Gets the currently available ports of type {@code PortType}. */ > public static java.lang.hw.Port[] getPorts(PortType); > } > > com.example.Driver implements PortUser, implements > PortStillAvailableListener > { > public portNoLongerAvailable(PortEvent event) { > // cleanup & dismiss. > } > } > > com.example.Application { > public static void main(String[] args) { > Driver someDriver = new Driver(); > Port radomPort = HardwareConfiguration.getPorts( > HardwareConfiguration.PortType.RS232)[1]; > myDevice.addStillAvailableListener(someDriver); > myDevice.connect(someDriver); > } > } > >> Please do not forget that tty ports can be opened by several >> applications concurrently. All of those will "loose" the port if >> anyone opens the corresponding cu port. > > Indeed we need a good overview of the differences between the various > platforms. Should we create a document or a Wiki for this purpose? > > FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: > http://www.openbsd.org/cgi-bin/man.cgi? > query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD > +Current&arch=i386&format=html > > Linux uses /var/lock: > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > Is there absolutely no way to get a lock under Windows? > >> As this naming based >> mechanism does not exist on Windows (maybe it does via an API) it >> should probably be reflected in the API. In other words there are >> "two levels of open": >> >> - Open for reading status lines (1) >> - Open for reading/writing data (2) >> >> I am not sure if state (1) should also allow the modification of >> certain status lines (ie to set a modem ready). > > I'm not sure I understand. Do you mean canonical and noncanonical > mode? > > How far is Windows with the canonical mode. Is it comparable to POSIX? > >> I am also not sure if >> the api should unify corresponding cu. and tty. ports into one single >> port. > > I think the API should hide low-level details like devicefiles. > > > Who is participating anyway? Is it just the four of us? > > Cheers, > > Pascal > > >> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>> For instance the current API is not very object oriented. >>> It might be a good idea to have a static set of objects available >>> representing >>> every supported port available on the system in realtime. Each >>> object should >>> clearly know its own state and its capabilities. To get a port >>> there could be >>> a method like synchronized void connect(PortUser) where PortUser >>> is a >>> interface which handles the interaction with a input and a output >>> stream and >>> listers like PortStillAvailableListener, PortBufferListener and a >>> DataAvailableListener. >>> >>> What is the collective feeling about that? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Wed Jul 19 08:33:08 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Wed, 19 Jul 2006 11:33:08 -0300 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191411.27566.pascal@quies.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> Message-ID: <44BE42A4.3030203@gmail.com> > Linux uses /var/lock: > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > Is there absolutely no way to get a lock under Windows? Indeed Windows block ports when someone open ones. Java Comm could manage this feature. > Who is participating anyway? Is it just the four of us? I can help too. Regards, Manuel From pascal at quies.net Wed Jul 19 09:01:17 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 17:01:17 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> References: <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> Message-ID: <200607191701.17607.pascal@quies.net> In the POSIX world things are simple. If any transaction fails with ENOTTY we lock the I/O streams and create a PortNoLongerAvailableEvent. We *might* even go so far as to start a thread which polls the tty say once a second afther a PortNoLongerAvailableEvent and kill it if there is succes with a PortAvailableAgainEvent but there won't be anything like deadlocks and races. I promise. ;) Methods like isOpen and isAvailable require polling which is exactly what we both don't want and they can't be reliable since it is a moment. A clean sepparation of the functional code and Listeners for events makes the code better readable and more flexible. PS If OS X has a notification system for changes in the available ports this OS specific functionality is more simple to implement too. Op woensdag 19 juli 2006 15:09, schreef Joachim Buechse: > Pascal, > > I think that the PortNoLongerAvailableListener creates more problems > than it solves. > > I think that exceptions are much better suited for this case. There > might be an additional method "Port.isOpen" or "Port.isAvailable" > which interested applications may call at times best suited. > > Most implementations will only find out, that a port disappeared when > trying to read or write. Anything else would require polling with a > high frequency or kernel hooks that do not exist (in POSIX). Any kind > of call back like portNoLongerAvailable() creates the risk of > deadlocks and races which require an involved implementation as the > library does not know what it is calling (ie a user might try to call > close from the callback which can block a very long time). Callbacks > introduce concurrency which unneccessarily increases the complexity. > > Regards, > Joachim From jredman at ergotech.com Wed Jul 19 09:20:39 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 09:20:39 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191411.27566.pascal@quies.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> Message-ID: <44BE4DC7.7@ergotech.com> Pascal S. de Kloe wrote: >> I am also not sure if >> the api should unify corresponding cu. and tty. ports into one single >> port. > > I think the API should hide low-level details like devicefiles. Not all ports have device files. It's long been my goal to add support for virtual serial ports, that is, serial ports on Ethernet terminal servers, for example integrating RFC2217. This means that the port name is some combination of an IP address and TCP port number. Nothing in /dev. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From brian at mbari.org Wed Jul 19 10:04:51 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 19 Jul 2006 09:04:51 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BE42A4.3030203@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <44BE42A4.3030203@gmail.com> Message-ID: <5FDA8DB5-FD08-4EAA-81A7-C46A7CF6FA18@mbari.org> >> Who is participating anyway? Is it just the four of us? > I'm not much of a POSIX or C guy. But I do a lot of OO design. I'm happy to throw my 2 cents in too. Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060719/404de230/attachment-0345.html From pascal at quies.net Wed Jul 19 10:16:16 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 18:16:16 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BE4DC7.7@ergotech.com> References: <200607191411.27566.pascal@quies.net> <44BE4DC7.7@ergotech.com> Message-ID: <200607191816.17099.pascal@quies.net> Op woensdag 19 juli 2006 17:20, schreef Jim Redman: > Pascal S. de Kloe wrote: > >> I am also not sure if > >> the api should unify corresponding cu. and tty. ports into one single > >> port. > > > > I think the API should hide low-level details like devicefiles. > > Not all ports have device files. It's long been my goal to add support > for virtual serial ports, that is, serial ports on Ethernet terminal > servers, for example integrating RFC2217. This means that the port name > is some combination of an IP address and TCP port number. Nothing in /dev. > > Jim This idea doesn't need any native calls at all, right? How would you like to realize that? Jini? I'm sure you knew that the server is already there: http://www.viara.cn/en/jts.htm From pascal at quies.net Wed Jul 19 10:17:12 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 18:17:12 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <5FDA8DB5-FD08-4EAA-81A7-C46A7CF6FA18@mbari.org> References: <44BE42A4.3030203@gmail.com> <5FDA8DB5-FD08-4EAA-81A7-C46A7CF6FA18@mbari.org> Message-ID: <200607191817.12769.pascal@quies.net> Op woensdag 19 juli 2006 18:04, schreef Brian Schlining: > >> Who is participating anyway? Is it just the four of us? > > I'm not much of a POSIX or C guy. But I do a lot of OO design. I'm > happy to throw my 2 cents in too. > > Brian Schlining > Software Engineer > http://www.mbari.org Excellent! :) We need a lot of opinions from all kinds of users. From jredman at ergotech.com Wed Jul 19 10:54:18 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 10:54:18 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191816.17099.pascal@quies.net> References: <200607191411.27566.pascal@quies.net> <44BE4DC7.7@ergotech.com> <200607191816.17099.pascal@quies.net> Message-ID: <44BE63BA.9090905@ergotech.com> Pascal, Pascal S. de Kloe wrote: > Op woensdag 19 juli 2006 17:20, schreef Jim Redman: >> Pascal S. de Kloe wrote: >>>> I am also not sure if >>>> the api should unify corresponding cu. and tty. ports into one single >>>> port. >>> I think the API should hide low-level details like devicefiles. >> Not all ports have device files. It's long been my goal to add support >> for virtual serial ports, that is, serial ports on Ethernet terminal >> servers, for example integrating RFC2217. This means that the port name >> is some combination of an IP address and TCP port number. Nothing in /dev. >> >> Jim > > This idea doesn't need any native calls at all, right? No native calls, it's just a Socket link. > > How would you like to realize that? I keep wondering that myself. I had in mind port names that are, for example, "192.168.0.99:3000". These would need to be added to the properties file (or the -D option). I'm open for suggestion. It's conceptually, it's the same as USB. Instead of USB->Serial it's Ethernet->Serial. The difference is that the USB devices create virtual serial ports within the OS. Some Ethernet devices also do this, but since, unlike USB communications, TCP/IP is supported natively within Java such a driver is unnecessary. > Jini? Is that still alive and kicking? > > I'm sure you knew that the server is already there: > > http://www.viara.cn/en/jts.htm Yes, that library is part of the plan. These devices are real serial ports. Somewhere, out in the Ether there's a DB9/DB25 cable with RS232/485 bits flowing over it. Since these are real ports, I'd like the ports to look like real serial ports (SerialPort) and not have to handle them as special cases. We have a bunch of code that deals with serial devices (PLCs, Barcode, Temperature Controllers, RFID, SECS, etc. etc.) and to rewrite each one of those to handle this case doesn't make much sense when the correct place to encapsulate a serial port is in the SerialPort layer. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From pascal at quies.net Wed Jul 19 12:44:01 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 20:44:01 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BE63BA.9090905@ergotech.com> References: <200607191816.17099.pascal@quies.net> <44BE63BA.9090905@ergotech.com> Message-ID: <200607192044.01966.pascal@quies.net> Op woensdag 19 juli 2006 18:54, schreef Jim Redman: > I keep wondering that myself. I had in mind port names that are, for > example, "192.168.0.99:3000". These would need to be added to the > properties file (or the -D option). > > I'm open for suggestion. Jini works very well especialy for ethernets like the one you describe. It's a shame that it never got the attention it deserves. > > Jini? > > Is that still alive and kicking? Not that it does matter becouse Java software doesn't need much maintenance. ;) Have a look at http://www.jini.org/. From Paul.Klissner at Sun.COM Wed Jul 19 15:45:38 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 14:45:38 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> Message-ID: <44BEA802.7060508@sun.com> Joachim Buechse wrote: > Pascal, > > I think that the PortNoLongerAvailableListener creates more problems > than it solves. > > I think that exceptions are much better suited for this case. There > might be an additional method "Port.isOpen" or "Port.isAvailable" > which interested applications may call at times best suited. > > Most implementations will only find out, that a port disappeared when > trying to read or write. Anything else would require polling with a > high frequency or kernel hooks that do not exist (in POSIX). Any kind > of call back like portNoLongerAvailable() creates the risk of > deadlocks and races which require an involved implementation as the > library does not know what it is calling (ie a user might try to call > close from the callback which can block a very long time). Callbacks > introduce concurrency which unneccessarily increases the complexity. I think we should find out what are the minimum requirements to get a JSR open, form an expert group, and get that group discussing these things in the JSR. I'm not pushing for Sun to sponsor it, as I think there is a community interest already and that it deserves an independent life and commitment. ACCESS EXCEPTIONS: ----------------- I agree, exceptions of this sort are the way to go. Exceptions are already simpler than having to err check at each function call, so a big improvement. No need to architect a more trouble prone complexity into the API. PROJECT SCOPE: ------------- Also, we should think carefully about what the scope of this project would be. Should it be javax."comm" which handles both serial and parallel (is parallel going by the wayside). Should it be split into two project: javax.EIA232 (or javax.RS232), and javax.IEEE1284? Should we differentiate between single-ended serial protocols, like EIA232, I2C, 2-WIRE, SPI, vs. quasi-multidrop and full multidrop busses such as EIA422, EIA432 and EIA485? If we really were to add I2C support to the API, we'd have to delve into the semantics more, because there could be some implicit decoding of the bus the API users would want to see. At this point, I'm thinking they're all different, and should be their own projects.. perhaps there could be an umbrella layer that abstracted out some of the generic issues like device ownership and access, perhaps not. javax.eia232 javax.eia485 or (javax.EIX4xx?) javax.i2c, javax.spi (or javax.chipbus?) DRIVER PLUGINS: -------------- Taking javax.eia232 for example, I think we need an architecture that allows for multiple plugins to provide multiple simultaneous drivers/adapters to allow for heterogeneous providers on a single system. For example, not only can there be USB based serial devices but networked serial devices, for example accessing devices on thin clients. PORTMAPPING: ----------- For Sun's javax.comm 3.0, we introduced a portmapping abstraction layer, that creates a mechansim to help administer the view (filtering)of available ports given to the application, and the name of such ports. I hope we can consider the right platform neutral way to accomplish that. In javax.comm as it is now, the API has to know where to go and look to find ports. In 3.x I added the ability to specify where to look for standard ports as properties to make it more flexible, but for our thin client platform, which can represent a very dynamic buffet of ports splayed in the leaf nodes of a tree that isn't good enough. That complicates things for the users (having to specify and manage unique and long path names to ports which can come and go), so there is an option whereby the user can configure something like "com1" such that on a thin client it represents the first port of the first USB/serial dongle connected. Javax.comm knows how to find that in the context of the current thin client, but the administrator doesn't have to worry about it. How to architect the API flexibly enough to allow for this kind of thing needs to be considered. Paul > > Regards, > Joachim > > On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: > >> Hi Joachim, >> >> Thanks for the constructive critisism. :) >> >> Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >>> The static objects will work for Windows and Linux, however for OSX >>> they will create problems: >>> - ports can appear and disappear at any time with VCP drivers for USB >>> - the port names are not known until the usb-port is "plugged in" >> Ports can appear and disappear on *any* OS with USB support. Some >> Linux >> distributions even create and remove devicefiles on the fly. >> >> With the current API you fetch a list of all available ports and >> then you try >> to cast one. What happens if the port is no longer available at >> that time? >> What happens if a port vanishes during the data transfer? Of course >> you can >> catch exceptions but that makes the code quite messy. >> >> The idea was to get a PortStillAvailableListener interface. In that >> way the >> implementation is free to handle a cleanup or wait for return >> routine in a OO >> way. The I/O streams should just lock. >> >> The word static was not ment as persistent but as Java static >> available. >> Considder the following: >> >> java.lang.hw.HardwareConfiguration { >> public enum PortType { RS232, I2C, etc. }; >> >> /** Gets the currently available ports of type {@code PortType}. */ >> public static java.lang.hw.Port[] getPorts(PortType); >> } >> >> com.example.Driver implements PortUser, implements >> PortStillAvailableListener >> { >> public portNoLongerAvailable(PortEvent event) { >> // cleanup & dismiss. >> } >> } >> >> com.example.Application { >> public static void main(String[] args) { >> Driver someDriver = new Driver(); >> Port radomPort = HardwareConfiguration.getPorts( >> HardwareConfiguration.PortType.RS232)[1]; >> myDevice.addStillAvailableListener(someDriver); >> myDevice.connect(someDriver); >> } >> } >> >>> Please do not forget that tty ports can be opened by several >>> applications concurrently. All of those will "loose" the port if >>> anyone opens the corresponding cu port. >> Indeed we need a good overview of the differences between the various >> platforms. Should we create a document or a Wiki for this purpose? >> >> FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: >> http://www.openbsd.org/cgi-bin/man.cgi? >> query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD >> +Current&arch=i386&format=html >> >> Linux uses /var/lock: >> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES >> >> Is there absolutely no way to get a lock under Windows? >> >>> As this naming based >>> mechanism does not exist on Windows (maybe it does via an API) it >>> should probably be reflected in the API. In other words there are >>> "two levels of open": >>> >>> - Open for reading status lines (1) >>> - Open for reading/writing data (2) >>> >>> I am not sure if state (1) should also allow the modification of >>> certain status lines (ie to set a modem ready). >> I'm not sure I understand. Do you mean canonical and noncanonical >> mode? >> >> How far is Windows with the canonical mode. Is it comparable to POSIX? >> >>> I am also not sure if >>> the api should unify corresponding cu. and tty. ports into one single >>> port. >> I think the API should hide low-level details like devicefiles. >> >> >> Who is participating anyway? Is it just the four of us? >> >> Cheers, >> >> Pascal >> >> >>> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>>> For instance the current API is not very object oriented. >>>> It might be a good idea to have a static set of objects available >>>> representing >>>> every supported port available on the system in realtime. Each >>>> object should >>>> clearly know its own state and its capabilities. To get a port >>>> there could be >>>> a method like synchronized void connect(PortUser) where PortUser >>>> is a >>>> interface which handles the interaction with a input and a output >>>> stream and >>>> listers like PortStillAvailableListener, PortBufferListener and a >>>> DataAvailableListener. >>>> >>>> What is the collective feeling about that? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Wed Jul 19 16:32:37 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 16:32:37 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEA802.7060508@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <44BEB305.3030208@ergotech.com> For one, I'd object to the splitting of 232 and 485 and question why it's necessary. Often the only difference between 232 access and 485 access is whether there's a converter attached to the serial port. Put another way, while 485 is multidrop, I think that's an application level issue rather than a driver level issue. If the issue is electrical, I don't think that it's possible to reliably support receiver switching of a 2-wire 485 network within Java, the timing is just too tight, so your stuck with requiring a 485 converter that automatically switches (not an onerous burden for us) or some OS level intervention. Anyway, if we're going to start differentiating at the electrical level we still support some current loop systems (Siemens S5 PLC if you care). Jim Paul Klissner wrote: > Joachim Buechse wrote: >> Pascal, >> >> I think that the PortNoLongerAvailableListener creates more problems >> than it solves. >> >> I think that exceptions are much better suited for this case. There >> might be an additional method "Port.isOpen" or "Port.isAvailable" >> which interested applications may call at times best suited. >> >> Most implementations will only find out, that a port disappeared when >> trying to read or write. Anything else would require polling with a >> high frequency or kernel hooks that do not exist (in POSIX). Any kind >> of call back like portNoLongerAvailable() creates the risk of >> deadlocks and races which require an involved implementation as the >> library does not know what it is calling (ie a user might try to call >> close from the callback which can block a very long time). Callbacks >> introduce concurrency which unneccessarily increases the complexity. > > I think we should find out what are the minimum requirements > to get a JSR open, form an expert group, and get that group > discussing these things in the JSR. I'm not pushing for > Sun to sponsor it, as I think there is a community interest > already and that it deserves an independent life and > commitment. > > ACCESS EXCEPTIONS: > ----------------- > I agree, exceptions of this sort are the way to go. > Exceptions are already simpler than having to err > check at each function call, so a big improvement. > No need to architect a more trouble prone complexity > into the API. > > PROJECT SCOPE: > ------------- > > Also, we should think carefully about what the scope of > this project would be. Should it be javax."comm" which > handles both serial and parallel (is parallel going by the > wayside). Should it be split into two project: > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > > Should we differentiate between single-ended serial > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > quasi-multidrop and full multidrop busses such as > EIA422, EIA432 and EIA485? If we really were to > add I2C support to the API, we'd have to delve into > the semantics more, because there could be some > implicit decoding of the bus the API users would > want to see. > > At this point, I'm thinking they're all different, > and should be their own projects.. perhaps there > could be an umbrella layer that abstracted out > some of the generic issues like device ownership > and access, perhaps not. > > javax.eia232 > javax.eia485 or (javax.EIX4xx?) > javax.i2c, javax.spi (or javax.chipbus?) > > DRIVER PLUGINS: > -------------- > Taking javax.eia232 for example, I think we need an > architecture that allows for multiple plugins to > provide multiple simultaneous drivers/adapters to > allow for heterogeneous providers on a single system. > For example, not only can there be USB based serial > devices but networked serial devices, for example > accessing devices on thin clients. > > PORTMAPPING: > ----------- > For Sun's javax.comm 3.0, we introduced a portmapping > abstraction layer, that creates a mechansim to help > administer the view (filtering)of available ports given > to the application, and the name of such ports. I hope we > can consider the right platform neutral way to > accomplish that. > > In javax.comm as it is now, the API has to know > where to go and look to find ports. In 3.x I added > the ability to specify where to look for standard > ports as properties to make it more flexible, but > for our thin client platform, which can represent > a very dynamic buffet of ports splayed in the > leaf nodes of a tree that isn't good enough. > That complicates things for the users (having > to specify and manage unique and long path names > to ports which can come and go), so there is > an option whereby the user can configure > something like "com1" such that on a thin client > it represents the first port of the first USB/serial > dongle connected. Javax.comm knows how to find > that in the context of the current thin client, > but the administrator doesn't have to worry about it. > > How to architect the API flexibly enough to allow > for this kind of thing needs to be considered. > > Paul > > > >> Regards, >> Joachim >> >> On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: >> >>> Hi Joachim, >>> >>> Thanks for the constructive critisism. :) >>> >>> Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >>>> The static objects will work for Windows and Linux, however for OSX >>>> they will create problems: >>>> - ports can appear and disappear at any time with VCP drivers for USB >>>> - the port names are not known until the usb-port is "plugged in" >>> Ports can appear and disappear on *any* OS with USB support. Some >>> Linux >>> distributions even create and remove devicefiles on the fly. >>> >>> With the current API you fetch a list of all available ports and >>> then you try >>> to cast one. What happens if the port is no longer available at >>> that time? >>> What happens if a port vanishes during the data transfer? Of course >>> you can >>> catch exceptions but that makes the code quite messy. >>> >>> The idea was to get a PortStillAvailableListener interface. In that >>> way the >>> implementation is free to handle a cleanup or wait for return >>> routine in a OO >>> way. The I/O streams should just lock. >>> >>> The word static was not ment as persistent but as Java static >>> available. >>> Considder the following: >>> >>> java.lang.hw.HardwareConfiguration { >>> public enum PortType { RS232, I2C, etc. }; >>> >>> /** Gets the currently available ports of type {@code PortType}. */ >>> public static java.lang.hw.Port[] getPorts(PortType); >>> } >>> >>> com.example.Driver implements PortUser, implements >>> PortStillAvailableListener >>> { >>> public portNoLongerAvailable(PortEvent event) { >>> // cleanup & dismiss. >>> } >>> } >>> >>> com.example.Application { >>> public static void main(String[] args) { >>> Driver someDriver = new Driver(); >>> Port radomPort = HardwareConfiguration.getPorts( >>> HardwareConfiguration.PortType.RS232)[1]; >>> myDevice.addStillAvailableListener(someDriver); >>> myDevice.connect(someDriver); >>> } >>> } >>> >>>> Please do not forget that tty ports can be opened by several >>>> applications concurrently. All of those will "loose" the port if >>>> anyone opens the corresponding cu port. >>> Indeed we need a good overview of the differences between the various >>> platforms. Should we create a document or a Wiki for this purpose? >>> >>> FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: >>> http://www.openbsd.org/cgi-bin/man.cgi? >>> query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD >>> +Current&arch=i386&format=html >>> >>> Linux uses /var/lock: >>> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES >>> >>> Is there absolutely no way to get a lock under Windows? >>> >>>> As this naming based >>>> mechanism does not exist on Windows (maybe it does via an API) it >>>> should probably be reflected in the API. In other words there are >>>> "two levels of open": >>>> >>>> - Open for reading status lines (1) >>>> - Open for reading/writing data (2) >>>> >>>> I am not sure if state (1) should also allow the modification of >>>> certain status lines (ie to set a modem ready). >>> I'm not sure I understand. Do you mean canonical and noncanonical >>> mode? >>> >>> How far is Windows with the canonical mode. Is it comparable to POSIX? >>> >>>> I am also not sure if >>>> the api should unify corresponding cu. and tty. ports into one single >>>> port. >>> I think the API should hide low-level details like devicefiles. >>> >>> >>> Who is participating anyway? Is it just the four of us? >>> >>> Cheers, >>> >>> Pascal >>> >>> >>>> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>>>> For instance the current API is not very object oriented. >>>>> It might be a good idea to have a static set of objects available >>>>> representing >>>>> every supported port available on the system in realtime. Each >>>>> object should >>>>> clearly know its own state and its capabilities. To get a port >>>>> there could be >>>>> a method like synchronized void connect(PortUser) where PortUser >>>>> is a >>>>> interface which handles the interaction with a input and a output >>>>> stream and >>>>> listers like PortStillAvailableListener, PortBufferListener and a >>>>> DataAvailableListener. >>>>> >>>>> What is the collective feeling about that? >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Paul.Klissner at Sun.COM Wed Jul 19 17:31:36 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 16:31:36 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEB305.3030208@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> Message-ID: <44BEC0D8.4050806@sun.com> Jim Redman wrote: > For one, I'd object to the splitting of 232 and 485 and question why > it's necessary. Often the only difference between 232 access and 485 > access is whether there's a converter attached to the serial port. > > Put another way, while 485 is multidrop, I think that's an application > level issue rather than a driver level issue. > > If the issue is electrical, I don't think that it's possible to reliably > support receiver switching of a 2-wire 485 network within Java, the > timing is just too tight, so your stuck with requiring a 485 converter > that automatically switches (not an onerous burden for us) or some OS > level intervention. > > Anyway, if we're going to start differentiating at the electrical level > we still support some current loop systems (Siemens S5 PLC if you care). > > Jim To be honest, I've not done anything with 422, 423 or 485, so I have no objection to keeping them together if there isn't enough of a protocol distinction to make it worth seperating them out. I'd just like to find another suitable name than javax.comm, unless the JSR wants to start with javax.comm 4.0, since all the previous 'major revisions' are accounted for. javax.serialport? Paul > > Paul Klissner wrote: >> Joachim Buechse wrote: >>> Pascal, >>> >>> I think that the PortNoLongerAvailableListener creates more problems >>> than it solves. >>> >>> I think that exceptions are much better suited for this case. There >>> might be an additional method "Port.isOpen" or "Port.isAvailable" >>> which interested applications may call at times best suited. >>> >>> Most implementations will only find out, that a port disappeared when >>> trying to read or write. Anything else would require polling with a >>> high frequency or kernel hooks that do not exist (in POSIX). Any kind >>> of call back like portNoLongerAvailable() creates the risk of >>> deadlocks and races which require an involved implementation as the >>> library does not know what it is calling (ie a user might try to call >>> close from the callback which can block a very long time). Callbacks >>> introduce concurrency which unneccessarily increases the complexity. >> I think we should find out what are the minimum requirements >> to get a JSR open, form an expert group, and get that group >> discussing these things in the JSR. I'm not pushing for >> Sun to sponsor it, as I think there is a community interest >> already and that it deserves an independent life and >> commitment. >> >> ACCESS EXCEPTIONS: >> ----------------- >> I agree, exceptions of this sort are the way to go. >> Exceptions are already simpler than having to err >> check at each function call, so a big improvement. >> No need to architect a more trouble prone complexity >> into the API. >> >> PROJECT SCOPE: >> ------------- >> >> Also, we should think carefully about what the scope of >> this project would be. Should it be javax."comm" which >> handles both serial and parallel (is parallel going by the >> wayside). Should it be split into two project: >> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >> >> Should we differentiate between single-ended serial >> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >> quasi-multidrop and full multidrop busses such as >> EIA422, EIA432 and EIA485? If we really were to >> add I2C support to the API, we'd have to delve into >> the semantics more, because there could be some >> implicit decoding of the bus the API users would >> want to see. >> >> At this point, I'm thinking they're all different, >> and should be their own projects.. perhaps there >> could be an umbrella layer that abstracted out >> some of the generic issues like device ownership >> and access, perhaps not. >> >> javax.eia232 >> javax.eia485 or (javax.EIX4xx?) >> javax.i2c, javax.spi (or javax.chipbus?) >> >> DRIVER PLUGINS: >> -------------- >> Taking javax.eia232 for example, I think we need an >> architecture that allows for multiple plugins to >> provide multiple simultaneous drivers/adapters to >> allow for heterogeneous providers on a single system. >> For example, not only can there be USB based serial >> devices but networked serial devices, for example >> accessing devices on thin clients. >> >> PORTMAPPING: >> ----------- >> For Sun's javax.comm 3.0, we introduced a portmapping >> abstraction layer, that creates a mechansim to help >> administer the view (filtering)of available ports given >> to the application, and the name of such ports. I hope we >> can consider the right platform neutral way to >> accomplish that. >> >> In javax.comm as it is now, the API has to know >> where to go and look to find ports. In 3.x I added >> the ability to specify where to look for standard >> ports as properties to make it more flexible, but >> for our thin client platform, which can represent >> a very dynamic buffet of ports splayed in the >> leaf nodes of a tree that isn't good enough. >> That complicates things for the users (having >> to specify and manage unique and long path names >> to ports which can come and go), so there is >> an option whereby the user can configure >> something like "com1" such that on a thin client >> it represents the first port of the first USB/serial >> dongle connected. Javax.comm knows how to find >> that in the context of the current thin client, >> but the administrator doesn't have to worry about it. >> >> How to architect the API flexibly enough to allow >> for this kind of thing needs to be considered. >> >> Paul >> >> >> >>> Regards, >>> Joachim >>> >>> On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: >>> >>>> Hi Joachim, >>>> >>>> Thanks for the constructive critisism. :) >>>> >>>> Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >>>>> The static objects will work for Windows and Linux, however for OSX >>>>> they will create problems: >>>>> - ports can appear and disappear at any time with VCP drivers for USB >>>>> - the port names are not known until the usb-port is "plugged in" >>>> Ports can appear and disappear on *any* OS with USB support. Some >>>> Linux >>>> distributions even create and remove devicefiles on the fly. >>>> >>>> With the current API you fetch a list of all available ports and >>>> then you try >>>> to cast one. What happens if the port is no longer available at >>>> that time? >>>> What happens if a port vanishes during the data transfer? Of course >>>> you can >>>> catch exceptions but that makes the code quite messy. >>>> >>>> The idea was to get a PortStillAvailableListener interface. In that >>>> way the >>>> implementation is free to handle a cleanup or wait for return >>>> routine in a OO >>>> way. The I/O streams should just lock. >>>> >>>> The word static was not ment as persistent but as Java static >>>> available. >>>> Considder the following: >>>> >>>> java.lang.hw.HardwareConfiguration { >>>> public enum PortType { RS232, I2C, etc. }; >>>> >>>> /** Gets the currently available ports of type {@code PortType}. */ >>>> public static java.lang.hw.Port[] getPorts(PortType); >>>> } >>>> >>>> com.example.Driver implements PortUser, implements >>>> PortStillAvailableListener >>>> { >>>> public portNoLongerAvailable(PortEvent event) { >>>> // cleanup & dismiss. >>>> } >>>> } >>>> >>>> com.example.Application { >>>> public static void main(String[] args) { >>>> Driver someDriver = new Driver(); >>>> Port radomPort = HardwareConfiguration.getPorts( >>>> HardwareConfiguration.PortType.RS232)[1]; >>>> myDevice.addStillAvailableListener(someDriver); >>>> myDevice.connect(someDriver); >>>> } >>>> } >>>> >>>>> Please do not forget that tty ports can be opened by several >>>>> applications concurrently. All of those will "loose" the port if >>>>> anyone opens the corresponding cu port. >>>> Indeed we need a good overview of the differences between the various >>>> platforms. Should we create a document or a Wiki for this purpose? >>>> >>>> FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: >>>> http://www.openbsd.org/cgi-bin/man.cgi? >>>> query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD >>>> +Current&arch=i386&format=html >>>> >>>> Linux uses /var/lock: >>>> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES >>>> >>>> Is there absolutely no way to get a lock under Windows? >>>> >>>>> As this naming based >>>>> mechanism does not exist on Windows (maybe it does via an API) it >>>>> should probably be reflected in the API. In other words there are >>>>> "two levels of open": >>>>> >>>>> - Open for reading status lines (1) >>>>> - Open for reading/writing data (2) >>>>> >>>>> I am not sure if state (1) should also allow the modification of >>>>> certain status lines (ie to set a modem ready). >>>> I'm not sure I understand. Do you mean canonical and noncanonical >>>> mode? >>>> >>>> How far is Windows with the canonical mode. Is it comparable to POSIX? >>>> >>>>> I am also not sure if >>>>> the api should unify corresponding cu. and tty. ports into one single >>>>> port. >>>> I think the API should hide low-level details like devicefiles. >>>> >>>> >>>> Who is participating anyway? Is it just the four of us? >>>> >>>> Cheers, >>>> >>>> Pascal >>>> >>>> >>>>> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>>>>> For instance the current API is not very object oriented. >>>>>> It might be a good idea to have a static set of objects available >>>>>> representing >>>>>> every supported port available on the system in realtime. Each >>>>>> object should >>>>>> clearly know its own state and its capabilities. To get a port >>>>>> there could be >>>>>> a method like synchronized void connect(PortUser) where PortUser >>>>>> is a >>>>>> interface which handles the interaction with a input and a output >>>>>> stream and >>>>>> listers like PortStillAvailableListener, PortBufferListener and a >>>>>> DataAvailableListener. >>>>>> >>>>>> What is the collective feeling about that? >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Wed Jul 19 18:03:40 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 18:03:40 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEC0D8.4050806@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> Message-ID: <44BEC85C.2030809@ergotech.com> Paul Klissner wrote: > I'd just like to find another suitable name than javax.comm, unless > the JSR wants to start with javax.comm 4.0, since all the previous > 'major revisions' are accounted for. javax.serialport? Which perhaps brings us back to what are we trying to fix and how badly. There are a number of 3rd party implementation of Java Comm, at least one from IBM - part of what was J9, now Websphere, or something (presumbly soon to get a name that has eclipse in it sometime soon). Esmertec has one, and there are few others rolling around. If RXTX is the only implementation of the JSR with no backward compatibility, we've just forked Java Serial support and we (for a least one) will be worse off. We won't be able to use the new support because of a lack of support on J2ME platforms that we have no control over and RXTX/current JavaComm will be in maintenance mode or unsupported on all other platforms. So, is there any chance of building a compatibility requirement into this. To pick are really bad example JDBC has support for a DataSource or a Driver. Could we have an ExcellentSerialPort with a fallback to a SerialPort on a class not found exception? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From pascal at quies.net Wed Jul 19 18:22:45 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Thu, 20 Jul 2006 02:22:45 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEC85C.2030809@ergotech.com> References: <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> Message-ID: <200607200222.46023.pascal@quies.net> Op donderdag 20 juli 2006 02:03, schreef Jim Redman: > Which perhaps brings us back to what are we trying to fix and how badly. The initail problem was the license. :) RXTX is sitting in this gnu.comm namespace and is afraid to go to javax.comm. Getting a JSR would solve this problem. And while we're at it we might as well improve the situation with the various platforms. I made some sugestions that where denied as too complex. Cheers, Pascal From Paul.Klissner at Sun.COM Wed Jul 19 19:09:35 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 18:09:35 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607200222.46023.pascal@quies.net> References: <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <200607200222.46023.pascal@quies.net> Message-ID: <44BED7CF.5080405@sun.com> Pascal S. de Kloe wrote: > Op donderdag 20 juli 2006 02:03, schreef Jim Redman: >> Which perhaps brings us back to what are we trying to fix and how badly. > > The initail problem was the license. :) > > RXTX is sitting in this gnu.comm namespace and is afraid to go to javax.comm. > Getting a JSR would solve this problem. > > And while we're at it we might as well improve the situation with the various > platforms. I made some sugestions that where denied as too complex. "Denied" is a bit harsh :) I'll re-examine your e-mails to see if my preferences change. It's not like your proposition has been put up to a formal vote, just discussion. Paul From Paul.Klissner at Sun.COM Wed Jul 19 19:28:47 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 18:28:47 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEC85C.2030809@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> Message-ID: <44BEDC4F.9030403@sun.com> Jim Redman wrote: > Paul Klissner wrote: >> I'd just like to find another suitable name than javax.comm, unless >> the JSR wants to start with javax.comm 4.0, since all the previous >> 'major revisions' are accounted for. javax.serialport? > > Which perhaps brings us back to what are we trying to fix and how badly. The goals I'm most interested in at the moment are: 1. A pluggable platform portmapping scheme wherein each platform can determine which ports to present to the application, and preferably as some configurable logical name. For example on the Sun Ray thin client platform, if an application aquiring a view of serial ports available on the system, it will be informed of Sun Ray serial ports if the application is running in a session currently directed to that particular Sun Ray unit, even though the serial port's device node happens to be server-side deeply nested in a leaf node. If the application is not running on a Sun Ray the port doesn't show up. The Sun Ray plugin would make the decision about when and which ports to present to the application. 2. Pluggable driver-side interface where multiple platform-specific drivers can be utilized simultaneously to introduce more flexibility with the back end. > There are a number of 3rd party implementation of Java Comm, at least > one from IBM - part of what was J9, now Websphere, or something > (presumbly soon to get a name that has eclipse in it sometime soon). > Esmertec has one, and there are few others rolling around. I have not been advocating gutting the API, since much of it is perfectly adequate. I'm not totally opposed to making substantial changes or improvements depending on other people's needs. There's no reason previous versions of javax.comm need to suddenly disappear if products need legacy support. > > If RXTX is the only implementation of the JSR with no backward > compatibility, we've just forked Java Serial support and we (for a least > one) will be worse off. We won't be able to use the new support because > of a lack of support on J2ME platforms that we have no control over and > RXTX/current JavaComm will be in maintenance mode or unsupported on all > other platforms. There can't be *that* many platforms this is ported to. And it will be no javax.usb. Seems like most of the standard platforms will be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, JDBC... > > So, is there any chance of building a compatibility requirement into > this. To pick are really bad example JDBC has support for a DataSource > or a Driver. Could we have an ExcellentSerialPort with a fallback to a > SerialPort on a class not found exception? Maybe, or maybe we just let people know what we are doing and try to figure out how to get their applications ported. Might not be that difficult. From my standpoint anyway, earthshaking changes aren't really necessary. Others might disagree. Paul From rwelty at averillpark.net Wed Jul 19 19:35:54 2006 From: rwelty at averillpark.net (Richard P. Welty) Date: Wed, 19 Jul 2006 21:35:54 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter Message-ID: <44BEDDFA.7020108@averillpark.net> I'm returning to the use of rxtx after 2 years off doing things that don't need serial ports. I'm trying to get my laptop (fedora core 1) talking to a set of portable auto scales through a Keyspan USB adapter (in my past use of rxtx, I had actual serial ports, but those days are long gone.) I have the keyspan kernel module loaded, and lsusb shows the device as correctly identified. I'm missing the bit of magic needed to get rxtx to provide the port in response to CommPortIdentifier.getPortIdentifiers() thanks in advance for any help, richard From jredman at ergotech.com Wed Jul 19 19:43:25 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 19:43:25 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BED7CF.5080405@sun.com> References: <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <200607200222.46023.pascal@quies.net> <44BED7CF.5080405@sun.com> Message-ID: <44BEDFBD.4020404@ergotech.com> Paul Klissner wrote: > Pascal S. de Kloe wrote: >> Op donderdag 20 juli 2006 02:03, schreef Jim Redman: >>> Which perhaps brings us back to what are we trying to fix and how badly. >> The initail problem was the license. :) >> >> RXTX is sitting in this gnu.comm namespace and is afraid to go to javax.comm. >> Getting a JSR would solve this problem. >> >> And while we're at it we might as well improve the situation with the various >> platforms. I made some sugestions that where denied as too complex. > > "Denied" is a bit harsh :) I'll re-examine your e-mails > to see if my preferences change. It's not like your > proposition has been put up to a formal vote, just discussion. OK, I'll officially float backwards compatibility in the form of "It should be possible to use anything that comes out of the JSR in place of an existing java comm implementation". I wonder if "Denied" is too harsh for that one :) Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From ajmas at sympatico.ca Wed Jul 19 19:47:06 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Wed, 19 Jul 2006 21:47:06 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEDDFA.7020108@averillpark.net> References: <44BEDDFA.7020108@averillpark.net> Message-ID: <35101C10-59A5-4F02-AEEE-DB69112F8130@sympatico.ca> Do you see an associated device in /dev ? On 19-Jul-06, at 21:35 , Richard P. Welty wrote: > I'm returning to the use of rxtx after 2 years off doing > things that don't need serial ports. > > I'm trying to get my laptop (fedora core 1) talking to a > set of portable auto scales through a Keyspan USB adapter > (in my past use of rxtx, I had actual serial ports, but those > days are long gone.) I have the keyspan kernel module loaded, > and lsusb shows the device as correctly identified. I'm missing > the bit of magic needed to get rxtx to provide the port > in response to CommPortIdentifier.getPortIdentifiers() > > thanks in advance for any help, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Wed Jul 19 19:54:03 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 19:54:03 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEDC4F.9030403@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> Message-ID: <44BEE23B.30908@ergotech.com> Paul, For the record we're STILL supporting some PersonalJava platforms. We're _almost_ at the point where we can assume that the platforms will have a Collections framework, but routinely compile with a 1.1 check so that we don't make that assumption unnecessarily. Of 50+ non-graphical Factory Automation JavaBeans we have 2 that require Java2 (Reporting and JavaScripting), and we have people asking for a back-port. Embedded platforms don't change in a hurry. Unlike desktop platforms, embedded systems are expected to last 5-10+ years. There are factory automation vendors in the pharmaceutical industry who are buying systems on eBay because that's the FDA validate platform. It must be that make/model, spec'd sometime in the mid-90's. So... If you make an incompatible change TODAY figure we can start using that code _at the earliest_ somewhere around 2012 or the low teens. Are we _really_ the only people on the list supporting embedded/factory automation platforms? Jim Paul Klissner wrote: > Jim Redman wrote: >> Paul Klissner wrote: >>> I'd just like to find another suitable name than javax.comm, unless >>> the JSR wants to start with javax.comm 4.0, since all the previous >>> 'major revisions' are accounted for. javax.serialport? >> Which perhaps brings us back to what are we trying to fix and how badly. > The goals I'm most interested in at the moment are: > > 1. A pluggable platform portmapping scheme wherein each platform > can determine which ports to present to the application, and > preferably as some configurable logical name. > > For example on the Sun Ray thin client platform, if an application > aquiring a view of serial ports available on the system, it will > be informed of Sun Ray serial ports if the application is running > in a session currently directed to that particular Sun Ray unit, > even though the serial port's device node happens to be server-side > deeply nested in a leaf node. If the application is not running on > a Sun Ray the port doesn't show up. The Sun Ray plugin would make > the decision about when and which ports to present to the application. > > 2. Pluggable driver-side interface where multiple platform-specific > drivers can be utilized simultaneously to introduce more flexibility > with the back end. > >> There are a number of 3rd party implementation of Java Comm, at least >> one from IBM - part of what was J9, now Websphere, or something >> (presumbly soon to get a name that has eclipse in it sometime soon). >> Esmertec has one, and there are few others rolling around. > > I have not been advocating gutting the API, since much of it is > perfectly adequate. I'm not totally opposed to making substantial > changes or improvements depending on other people's needs. There's > no reason previous versions of javax.comm need to suddenly disappear > if products need legacy support. > > >> If RXTX is the only implementation of the JSR with no backward >> compatibility, we've just forked Java Serial support and we (for a least >> one) will be worse off. We won't be able to use the new support because >> of a lack of support on J2ME platforms that we have no control over and >> RXTX/current JavaComm will be in maintenance mode or unsupported on all >> other platforms. > > There can't be *that* many platforms this is ported to. And it will > be no javax.usb. Seems like most of the standard platforms will > be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, > JDBC... > >> So, is there any chance of building a compatibility requirement into >> this. To pick are really bad example JDBC has support for a DataSource >> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >> SerialPort on a class not found exception? > > Maybe, or maybe we just let people know what we are doing and > try to figure out how to get their applications ported. Might not > be that difficult. From my standpoint anyway, earthshaking > changes aren't really necessary. Others might disagree. > > Paul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tod at todbot.com Wed Jul 19 19:59:52 2006 From: tod at todbot.com (Tod E. Kurt) Date: Wed, 19 Jul 2006 18:59:52 -0700 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEDDFA.7020108@averillpark.net> References: <44BEDDFA.7020108@averillpark.net> Message-ID: Hi, "lsusb" doesn't show if you have the proper drivers loaded for the specific USB device, just that a USB device is plugged in. The text identifiers sent by the USB device aren't used by the OS except for things like lsusb. Look at the output of "dmesg" or /var/log/messages and see if you have a lines that looks like: keyspan 1-1:1.0: Keyspan 1 port adapter converter detected usb 1-1: Keyspan 1 port adapter converter now attached to ttyUSB0 If you do, then you've got a serial port at "/dev/ttyUSB0", and you can use minicom or whatever (even RXTX!) to play with it. If you get a message like: usb.c: USB device 4 (vend/prod 0x06cd/0x0121) is not claimed by any active driver. Then the USB driver can't find the 'keyspan' driver. If you're sure you have this driver, then hotplug isn't working for some reason. You could try running the command: % sudo modprobe keyspan And see if anything useful happens. You should see the 'keyspan' driver when you type "lsmod" to list the currently loaded kernel modules. -=tod On Jul 19, 2006, at 6:35 PM, Richard P. Welty wrote: > I'm returning to the use of rxtx after 2 years off doing > things that don't need serial ports. > > I'm trying to get my laptop (fedora core 1) talking to a > set of portable auto scales through a Keyspan USB adapter > (in my past use of rxtx, I had actual serial ports, but those > days are long gone.) I have the keyspan kernel module loaded, > and lsusb shows the device as correctly identified. I'm missing > the bit of magic needed to get rxtx to provide the port > in response to CommPortIdentifier.getPortIdentifiers() > > thanks in advance for any help, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From rwelty at suespammers.org Wed Jul 19 20:05:18 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Wed, 19 Jul 2006 22:05:18 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <35101C10-59A5-4F02-AEEE-DB69112F8130@sympatico.ca> References: <44BEDDFA.7020108@averillpark.net> <35101C10-59A5-4F02-AEEE-DB69112F8130@sympatico.ca> Message-ID: <44BEE4DE.9080707@suespammers.org> Andr?-John Mas wrote: > Do you see an associated device in /dev ? Well, there are lots of /dev/ttyUSB devices, there, but nothing jumps out as having been assigned to the keyspan. But then, I'm not that knowledgable about the USB mapping here; this is the first time I've tried to use one this way and I'm on the steep part of the learning curve. richard From rwelty at suespammers.org Wed Jul 19 20:08:20 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Wed, 19 Jul 2006 22:08:20 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: References: <44BEDDFA.7020108@averillpark.net> Message-ID: <44BEE594.50402@suespammers.org> Tod E. Kurt wrote: > Then the USB driver can't find the 'keyspan' driver. If you're sure > you have this driver, then hotplug isn't working for some reason. > You could try running the command: Ok, it looks like the keyspan driver may be the problem; it's having some sort of problem loading it. I'll have to look into this further tomorrow night. thanks, richard From pascal at quies.net Wed Jul 19 20:11:21 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Thu, 20 Jul 2006 04:11:21 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEDFBD.4020404@ergotech.com> References: <44BED7CF.5080405@sun.com> <44BEDFBD.4020404@ergotech.com> Message-ID: <200607200411.22012.pascal@quies.net> Op donderdag 20 juli 2006 03:43, schreef Jim Redman: > Paul Klissner wrote: > > Pascal S. de Kloe wrote: > >> Op donderdag 20 juli 2006 02:03, schreef Jim Redman: > >>> Which perhaps brings us back to what are we trying to fix and how > >>> badly. > >> > >> The initail problem was the license. :) > >> > >> RXTX is sitting in this gnu.comm namespace and is afraid to go to > >> javax.comm. Getting a JSR would solve this problem. > >> > >> And while we're at it we might as well improve the situation with the > >> various platforms. I made some sugestions that where denied as too > >> complex. > > > > "Denied" is a bit harsh :) I'll re-examine your e-mails > > to see if my preferences change. It's not like your > > proposition has been put up to a formal vote, just discussion. > > OK, I'll officially float backwards compatibility in the form of "It > should be possible to use anything that comes out of the JSR in place of > an existing java comm implementation". > > I wonder if "Denied" is too harsh for that one :) > > Jim Hehehe. I don't have any troubles with people voting against my ideas at all so don't worry Paul. :) However, it is exactly the compatibilty thing where Jim is talking about what makes me want to make a *huge* change if any. From jredman at ergotech.com Wed Jul 19 20:25:50 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 20:25:50 -0600 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEE594.50402@suespammers.org> References: <44BEDDFA.7020108@averillpark.net> <44BEE594.50402@suespammers.org> Message-ID: <44BEE9AE.3030200@ergotech.com> Some who remembers this better than me please help. You also need something like: -Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3 When you start the application. This can be put in a properties files (where?). Jim Richard P. Welty wrote: > Tod E. Kurt wrote: > >> Then the USB driver can't find the 'keyspan' driver. If you're sure >> you have this driver, then hotplug isn't working for some reason. >> You could try running the command: > > Ok, it looks like the keyspan driver may be the problem; it's having > some sort of problem loading it. I'll have to look into this further > tomorrow night. > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From ajmas at sympatico.ca Wed Jul 19 20:32:52 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Wed, 19 Jul 2006 22:32:52 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEE9AE.3030200@ergotech.com> References: <44BEDDFA.7020108@averillpark.net> <44BEE594.50402@suespammers.org> <44BEE9AE.3030200@ergotech.com> Message-ID: Are you sure about this? I know on MacOS X no such configuration was needed. If this is indeed true, this is poor design, in this day and age of dynamic devices. On 19-Jul-06, at 22:25 , Jim Redman wrote: > Some who remembers this better than me please help. > > You also need something like: > > -Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyUSB0:/dev/ttyUSB1:/ > dev/ttyUSB2:/dev/ttyUSB3 > > When you start the application. This can be put in a properties files > (where?). > > Jim > > Richard P. Welty wrote: >> Tod E. Kurt wrote: >> >>> Then the USB driver can't find the 'keyspan' driver. If you're sure >>> you have this driver, then hotplug isn't working for some reason. >>> You could try running the command: >> >> Ok, it looks like the keyspan driver may be the problem; it's having >> some sort of problem loading it. I'll have to look into this further >> tomorrow night. >> >> thanks, >> richard >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Wed Jul 19 20:41:01 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Wed, 19 Jul 2006 22:41:01 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEE9AE.3030200@ergotech.com> References: <44BEDDFA.7020108@averillpark.net> <44BEE594.50402@suespammers.org> <44BEE9AE.3030200@ergotech.com> Message-ID: <44BEED3D.5020304@suespammers.org> Jim Redman wrote: > Some who remembers this better than me please help. > > You also need something like: > > -Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3 > > When you start the application. This can be put in a properties files > (where?). Thanks for all the help, guys. Thinking back on how this laptop came to be in its current state, I'm of the opinion a format and complete rebuild with a newer version of Fedora is in order before I waste any more time in diagnosis. The problems I'm seeing clearly have nothing to do with RXTX and everything to do with how many upgrades have been chained together getting this laptop from whereever I started (RH 7.0 or 7.1) to FC1. It could probably be fixed in place, but I shudder to think about the amount of time needed to figure out the proper fix. But the software I'm putting together will need to run on Y2K/XP and Mac OS X, so I'll be following portability and installer discussions on this list rather intently (http://scale-app.sourceforge.net for anyone who cares.) richard From Paul.Klissner at Sun.COM Wed Jul 19 22:53:53 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 21:53:53 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEE23B.30908@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> Message-ID: <44BF0C61.4020900@sun.com> Jim Redman wrote: > Paul, > > For the record we're STILL supporting some PersonalJava platforms. > We're _almost_ at the point where we can assume that the platforms will > have a Collections framework, but routinely compile with a 1.1 check so > that we don't make that assumption unnecessarily. Of 50+ non-graphical > Factory Automation JavaBeans we have 2 that require Java2 (Reporting and > JavaScripting), and we have people asking for a back-port. > > Embedded platforms don't change in a hurry. Unlike desktop platforms, > embedded systems are expected to last 5-10+ years. > > There are factory automation vendors in the pharmaceutical industry who > are buying systems on eBay because that's the FDA validate platform. It > must be that make/model, spec'd sometime in the mid-90's. > > So... If you make an incompatible change TODAY figure we can start using > that code _at the earliest_ somewhere around 2012 or the low teens. > > Are we _really_ the only people on the list supporting embedded/factory > automation platforms? > > Jim Do you provide your own implementation classes? Why can't you just continue to use 2.1 for the embedded platform until 2012 if you're locked down? Are you worried bugs won't get fixed? Sun might consider open sourcing the 2.1 Java source. I can't promise that, but it's been discussed and hasn't met resistance, except from me, because I wasn't super impressed with the code. I can probably be persuaded to champion open sourcing that and going through the process/legal machinations within Sun if it frees us to pursue a JSR for a new generation of javax.comm where we can have a chunk of common code in Open Source and each platform is simply responsible for it's platform specific plugins. I don't have many opinions about this set in stone because there are a lot of technical and pragmatic considerations such as yours the community has that I am probably not aware of or sufficiently sensitive to yet. I don't feel I really have the bird's eye view of all of this yet. The other thing is, I can only offer 10% of my time right now, according to my management, which is why I'm not pushing to be the spec lead for the JSR, and want only to be a participant to represent Sun's interests on the E.G. There is nothing sacred about Sun employees in the JCP as far as a JSR initiated by another entity is concerned. I am not the person everything needs to be cleared through. Ideas I have will pass or fail based on their merit and the community perception just like anyone else's. Paul > > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul Klissner wrote: >>>> I'd just like to find another suitable name than javax.comm, unless >>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>> 'major revisions' are accounted for. javax.serialport? >>> Which perhaps brings us back to what are we trying to fix and how badly. >> The goals I'm most interested in at the moment are: >> >> 1. A pluggable platform portmapping scheme wherein each platform >> can determine which ports to present to the application, and >> preferably as some configurable logical name. >> >> For example on the Sun Ray thin client platform, if an application >> aquiring a view of serial ports available on the system, it will >> be informed of Sun Ray serial ports if the application is running >> in a session currently directed to that particular Sun Ray unit, >> even though the serial port's device node happens to be server-side >> deeply nested in a leaf node. If the application is not running on >> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >> the decision about when and which ports to present to the application. >> >> 2. Pluggable driver-side interface where multiple platform-specific >> drivers can be utilized simultaneously to introduce more flexibility >> with the back end. >> >>> There are a number of 3rd party implementation of Java Comm, at least >>> one from IBM - part of what was J9, now Websphere, or something >>> (presumbly soon to get a name that has eclipse in it sometime soon). >>> Esmertec has one, and there are few others rolling around. >> I have not been advocating gutting the API, since much of it is >> perfectly adequate. I'm not totally opposed to making substantial >> changes or improvements depending on other people's needs. There's >> no reason previous versions of javax.comm need to suddenly disappear >> if products need legacy support. >> >> >>> If RXTX is the only implementation of the JSR with no backward >>> compatibility, we've just forked Java Serial support and we (for a least >>> one) will be worse off. We won't be able to use the new support because >>> of a lack of support on J2ME platforms that we have no control over and >>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>> other platforms. >> There can't be *that* many platforms this is ported to. And it will >> be no javax.usb. Seems like most of the standard platforms will >> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >> JDBC... >> >>> So, is there any chance of building a compatibility requirement into >>> this. To pick are really bad example JDBC has support for a DataSource >>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>> SerialPort on a class not found exception? >> Maybe, or maybe we just let people know what we are doing and >> try to figure out how to get their applications ported. Might not >> be that difficult. From my standpoint anyway, earthshaking >> changes aren't really necessary. Others might disagree. >> >> Paul >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From Paul.Klissner at Sun.COM Thu Jul 20 00:27:41 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 23:27:41 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BF0C61.4020900@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> Message-ID: <44BF225D.80104@sun.com> Paul Klissner wrote: > Jim Redman wrote: >> Paul, >> >> For the record we're STILL supporting some PersonalJava platforms. >> We're _almost_ at the point where we can assume that the platforms will >> have a Collections framework, but routinely compile with a 1.1 check so >> that we don't make that assumption unnecessarily. Of 50+ non-graphical >> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >> JavaScripting), and we have people asking for a back-port. >> >> Embedded platforms don't change in a hurry. Unlike desktop platforms, >> embedded systems are expected to last 5-10+ years. >> >> There are factory automation vendors in the pharmaceutical industry who >> are buying systems on eBay because that's the FDA validate platform. It >> must be that make/model, spec'd sometime in the mid-90's. >> >> So... If you make an incompatible change TODAY figure we can start using >> that code _at the earliest_ somewhere around 2012 or the low teens. >> >> Are we _really_ the only people on the list supporting embedded/factory >> automation platforms? >> >> Jim > > Do you provide your own implementation classes? > > Why can't you just continue to use 2.1 for the embedded platform until > 2012 if you're locked down? Are you worried bugs won't get fixed? > Sun might consider open sourcing the 2.1 Java source. Excuse me, I meant 2.0.3 > I can't promise > that, but it's been discussed and hasn't met resistance, except > from me, because I wasn't super impressed with the code. I can probably > be persuaded to champion open sourcing that and going through the > process/legal machinations within Sun if it frees us to pursue > a JSR for a new generation of javax.comm where we can have a chunk of > common code in Open Source and each platform is simply responsible > for it's platform specific plugins. > > I don't have many opinions about this set in stone because there > are a lot of technical and pragmatic considerations such as yours > the community has that I am probably not aware of or sufficiently > sensitive to yet. I don't feel I really have the bird's eye view > of all of this yet. > > The other thing is, I can only offer 10% of my time right now, > according to my management, which is why I'm not pushing to > be the spec lead for the JSR, and want only to be a participant > to represent Sun's interests on the E.G. There is nothing sacred > about Sun employees in the JCP as far as a JSR initiated by another > entity is concerned. I am not the person everything needs to be > cleared through. Ideas I have will pass or fail based on their > merit and the community perception just like anyone else's. > > Paul > >> Paul Klissner wrote: >>> Jim Redman wrote: >>>> Paul Klissner wrote: >>>>> I'd just like to find another suitable name than javax.comm, unless >>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>> 'major revisions' are accounted for. javax.serialport? >>>> Which perhaps brings us back to what are we trying to fix and how badly. >>> The goals I'm most interested in at the moment are: >>> >>> 1. A pluggable platform portmapping scheme wherein each platform >>> can determine which ports to present to the application, and >>> preferably as some configurable logical name. >>> >>> For example on the Sun Ray thin client platform, if an application >>> aquiring a view of serial ports available on the system, it will >>> be informed of Sun Ray serial ports if the application is running >>> in a session currently directed to that particular Sun Ray unit, >>> even though the serial port's device node happens to be server-side >>> deeply nested in a leaf node. If the application is not running on >>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>> the decision about when and which ports to present to the application. >>> >>> 2. Pluggable driver-side interface where multiple platform-specific >>> drivers can be utilized simultaneously to introduce more flexibility >>> with the back end. >>> >>>> There are a number of 3rd party implementation of Java Comm, at least >>>> one from IBM - part of what was J9, now Websphere, or something >>>> (presumbly soon to get a name that has eclipse in it sometime soon). >>>> Esmertec has one, and there are few others rolling around. >>> I have not been advocating gutting the API, since much of it is >>> perfectly adequate. I'm not totally opposed to making substantial >>> changes or improvements depending on other people's needs. There's >>> no reason previous versions of javax.comm need to suddenly disappear >>> if products need legacy support. >>> >>> >>>> If RXTX is the only implementation of the JSR with no backward >>>> compatibility, we've just forked Java Serial support and we (for a least >>>> one) will be worse off. We won't be able to use the new support because >>>> of a lack of support on J2ME platforms that we have no control over and >>>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>>> other platforms. >>> There can't be *that* many platforms this is ported to. And it will >>> be no javax.usb. Seems like most of the standard platforms will >>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>> JDBC... >>> >>>> So, is there any chance of building a compatibility requirement into >>>> this. To pick are really bad example JDBC has support for a DataSource >>>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>>> SerialPort on a class not found exception? >>> Maybe, or maybe we just let people know what we are doing and >>> try to figure out how to get their applications ported. Might not >>> be that difficult. From my standpoint anyway, earthshaking >>> changes aren't really necessary. Others might disagree. >>> >>> Paul >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Thu Jul 20 00:50:21 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 20 Jul 2006 08:50:21 +0200 Subject: [Rxtx] jcp and jsr Message-ID: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> Hi all, I work with SNIJDER Micro Systems. We're doing embedded Java and just heard about this discussion by way of Ted Kosan from the embedded Java community. We think Jim is right about the compatibility issues for embedded Java platforms. Our own embedded Java platform (see http://www.embedded-web.com ) uses a 3rd party implementation of javax.comm written by the JVM vendor. As Jim says, changes take much longer to propagate in the embedded space. If the 'new' javax.comm is not backwards compatible, embedded JVM vendors (esmertec, IBM, Tao Group, etc.) will probably evaluate whether it makes sense for them to support the new API. Some will eventually adopt it, but that will take time. Some will just stay with the current API, thus increasing the gap between embedded Java developers and desktop Java developers (different APIs to do the same thing) This is a very real problem in our opinion. Also taking into account that many desktop computers nowadays don't even have standard serial ports, I believe that the embedded Java community already gathers a significant share of the potential javax.comm users. I think backwards compatibility should be seriously considered. Best regards, Guillermo Jim Redman wrote: >Paul Klissner wrote: > > I'd just like to find another suitable name than javax.comm, unless > > the JSR wants to start with javax.comm 4.0, since all the previous > > 'major revisions' are accounted for. javax.serialport? > >Which perhaps brings us back to what are we trying to fix and how badly. > >There are a number of 3rd party implementation of Java Comm, at least >one from IBM - part of what was J9, now Websphere, or something >(presumbly soon to get a name that has eclipse in it sometime soon). >Esmertec has one, and there are few others rolling around. > >If RXTX is the only implementation of the JSR with no backward >compatibility, we've just forked Java Serial support and we (for a least >one) will be worse off. We won't be able to use the new support because >of a lack of support on J2ME platforms that we have no control over and >RXTX/current JavaComm will be in maintenance mode or unsupported on all >other platforms. > >So, is there any chance of building a compatibility requirement into >this. To pick are really bad example JDBC has support for a DataSource >or a Driver. Could we have an ExcellentSerialPort with a fallback to a >SerialPort on a class not found exception? > >Jim -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Thu Jul 20 00:57:04 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 20 Jul 2006 08:57:04 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> References: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> Message-ID: <7.0.1.0.0.20060720085221.036d88e8@sms.nl> Paul Klissner wrote: >Jim Redman wrote: > > Paul, > > > > For the record we're STILL supporting some PersonalJava platforms. > > We're _almost_ at the point where we can assume that the platforms will > > have a Collections framework, but routinely compile with a 1.1 check so > > that we don't make that assumption unnecessarily. Of 50+ non-graphical > > Factory Automation JavaBeans we have 2 that require Java2 (Reporting and > > JavaScripting), and we have people asking for a back-port. > > > > Embedded platforms don't change in a hurry. Unlike desktop platforms, > > embedded systems are expected to last 5-10+ years. > > > > There are factory automation vendors in the pharmaceutical industry who > > are buying systems on eBay because that's the FDA validate platform. It > > must be that make/model, spec'd sometime in the mid-90's. > > > > So... If you make an incompatible change TODAY figure we can start using > > that code _at the earliest_ somewhere around 2012 or the low teens. > > > > Are we _really_ the only people on the list supporting embedded/factory > > automation platforms? > > > > Jim > >Do you provide your own implementation classes? > >Why can't you just continue to use 2.1 for the embedded platform until >2012 if you're locked down? Are you worried bugs won't get fixed? If embedded platforms keep using the "old" (current) javax.comm API but the desktop Java world starts to use a new, backwards-incompatible API, then this will result in more trouble for embedded Java application developers as they will no longer be able to use the same API on desktop systems and embedded platforms. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Thu Jul 20 00:59:16 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 20 Jul 2006 08:59:16 +0200 Subject: [Rxtx] jcp and jsr Message-ID: <7.0.1.0.0.20060720085812.036d9c28@sms.nl> Pascal S. de Kloe wrote: >Who is participating anyway? Is it just the four of us? > >Cheers, > >Pascal We would be more than happy to participate if we can be of any help. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From Paul.Klissner at Sun.COM Thu Jul 20 02:23:42 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Thu, 20 Jul 2006 01:23:42 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <7.0.1.0.0.20060720085221.036d88e8@sms.nl> References: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> <7.0.1.0.0.20060720085221.036d88e8@sms.nl> Message-ID: <44BF3D8E.4030705@sun.com> Guillermo Rodriguez Garcia wrote: > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul, >>> >>> For the record we're STILL supporting some PersonalJava platforms. >>> We're _almost_ at the point where we can assume that the platforms will >>> have a Collections framework, but routinely compile with a 1.1 check so >>> that we don't make that assumption unnecessarily. Of 50+ non-graphical >>> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >>> JavaScripting), and we have people asking for a back-port. >>> >>> Embedded platforms don't change in a hurry. Unlike desktop platforms, >>> embedded systems are expected to last 5-10+ years. >>> >>> There are factory automation vendors in the pharmaceutical industry who >>> are buying systems on eBay because that's the FDA validate platform. It >>> must be that make/model, spec'd sometime in the mid-90's. >>> >>> So... If you make an incompatible change TODAY figure we can start using >>> that code _at the earliest_ somewhere around 2012 or the low teens. >>> >>> Are we _really_ the only people on the list supporting embedded/factory >>> automation platforms? >>> >>> Jim >> Do you provide your own implementation classes? >> >> Why can't you just continue to use 2.1 for the embedded platform until >> 2012 if you're locked down? Are you worried bugs won't get fixed? > > If embedded platforms keep using the "old" (current) javax.comm API but > the desktop Java world starts to use a new, backwards-incompatible API, > then this will result in more trouble for embedded Java application > developers as they will no longer be able to use the same API on desktop > systems and embedded platforms. OK, I understand the situation more clearly now. The kinds of changes I'm opting don't seem difficult to design in a backward compatible way. I haven't scrutinized the other requests on the list. I guess it will be interesting to hear what the proponents for other changes have to say. Paul > > Guillermo > > -- > Guillermo Rodriguez Garcia > > Snijder Micro Systems phone +31-493-351020 > G. Rodriguez Garcia fax +31-493-351530 > Visser 25 email guille at sms.nl > NL5751 BL Deurne > The Netherlands http://www.snijder.com > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jul 20 02:46:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 20 Jul 2006 10:46:09 +0200 Subject: [Rxtx] quo vadis API/namespace (Re: jcp and jsr) In-Reply-To: <44BEDC4F.9030403@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> Message-ID: Paul, for the first time in many months, I have the impression, that we have the same agenda;-) If the "driver-level"-api changes however "nobody" will be disappointed. However, regarding the user-level-api I disagree. As fundamental changes to the API have been suggested several times I must be ignoring something. I would be delighted to learn were the current API fails - i.e. what can not be done or is overly complex based on the current API. Of course it is better fun to start something from scratch, but unless there are really substantial gains from completely redesigning an API I don't see the point. The promise of Java is to write once (which I interpret as write against the same API for all platforms). Getting VM providers like esmertec to support a new/replacement API is not a simple task, it requires a business case which for the biggest part simply does not exist. If we keep the javax.comm namespace and keep the "user-level"-api a superset of the current PortIdentifier/Port-api, the same application can work against javax.comm 2.0/3.0/future.x. Of course a factory/wrapping approach can always unify different APIs but this adds more implementation/ testing complexity to every application. So in short: Unless we find a strong argument why javax.comm can't be used I prefer that we keep it. Unless we find a strong feature / use- case that can not be handled with (an extension of) the current CommPort/CommPortIndentifier I'd prefer to keep that as well. Regards, Joachim On 20.07.2006, at 03:28, Paul Klissner wrote: > The goals I'm most interested in at the moment are: > > 1. A pluggable platform portmapping scheme wherein each platform > can determine which ports to present to the application, and > preferably as some configurable logical name. > > For example on the Sun Ray thin client platform, if an application > aquiring a view of serial ports available on the system, it will > be informed of Sun Ray serial ports if the application is running > in a session currently directed to that particular Sun Ray unit, > even though the serial port's device node happens to be server-side > deeply nested in a leaf node. If the application is not running on > a Sun Ray the port doesn't show up. The Sun Ray plugin would make > the decision about when and which ports to present to the application. > > 2. Pluggable driver-side interface where multiple platform-specific > drivers can be utilized simultaneously to introduce more flexibility > with the back end. > >> There are a number of 3rd party implementation of Java Comm, at least >> one from IBM - part of what was J9, now Websphere, or something >> (presumbly soon to get a name that has eclipse in it sometime soon). >> Esmertec has one, and there are few others rolling around. > > I have not been advocating gutting the API, since much of it is > perfectly adequate. I'm not totally opposed to making substantial > changes or improvements depending on other people's needs. There's > no reason previous versions of javax.comm need to suddenly disappear > if products need legacy support. > > >> >> If RXTX is the only implementation of the JSR with no backward >> compatibility, we've just forked Java Serial support and we (for a >> least >> one) will be worse off. We won't be able to use the new support >> because >> of a lack of support on J2ME platforms that we have no control >> over and >> RXTX/current JavaComm will be in maintenance mode or unsupported >> on all >> other platforms. > > There can't be *that* many platforms this is ported to. And it will > be no javax.usb. Seems like most of the standard platforms will > be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, > JDBC... > >> >> So, is there any chance of building a compatibility requirement into >> this. To pick are really bad example JDBC has support for a >> DataSource >> or a Driver. Could we have an ExcellentSerialPort with a fallback >> to a >> SerialPort on a class not found exception? > > Maybe, or maybe we just let people know what we are doing and > try to figure out how to get their applications ported. Might not > be that difficult. From my standpoint anyway, earthshaking > changes aren't really necessary. Others might disagree. > > Paul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Luis.Moreira at jet.uk Thu Jul 20 03:56:38 2006 From: Luis.Moreira at jet.uk (Luis Moreira) Date: Thu, 20 Jul 2006 10:56:38 +0100 Subject: [Rxtx] problems with setting up Rxtx Message-ID: Hi Guys, I have just joined the list and I am very new to JAVA. I am investigating serial communications and I just realised that the JAVAX.COMM package does not support windows anymore. I then looked at alternatives and the RXTX package came up. The problem I have at the moment is not using the classes but, rather how to install RXTX package so that I can use the classes, what do I need to install to support it and how if I write a program using it, do I make it portable. Best regards Luis From lyon at docjava.com Thu Jul 20 07:16:55 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 20 Jul 2006 09:16:55 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> Message-ID: Hi All, There has been some discussion about plugins for serial communications. As I see it, what Java really needs is a NativeLibraryManager. This is a rather much larger charge than "just" RXTX. The RXTX basic mode of operation is that we associate static blocks of code with a "System.load". Failure occurs when the class containing such a block of code is loaded AND the native library is not found. What are some of the options? 1. Do nothing, let the program fail with an exception. 2. try to catch an UnsatisfiedLinkError as a part of making the driver. 3. Search the java.library.path to see if the driver is present (i.e., guard the input). 4. Other?? In the case of either step 2 or 3, we need to fix the lack of a library. What are the options for fixing a library? 1. Do nothing, but give the user an interesting error with instructions on what to do. 2. Attempt to find the library on the file system (perhaps with user help). 3. Attempt to download the library and install it (perhaps with user permission). 4. Attempt to internalize the library as a UUEncoded serialized object and install it (better ask the user, again!). 5. Other?? My attempts at making RXTX more robust on install have led to mixed results. Altering the java.library.path has led to a bit of byte-code engineering (as this is loaded at JVM start time). Internalizing of libraries is attractive, until you realize how many libraries are involved. Dyanmically changing libraries during development is very attractive, for developers, who are changing libraries often. It is also very interesting for those who want to control the version of the libraries in the run-time. For example, something like the following will guard the input to the system load: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getInstance() { if (driver != null) return driver; if (!NativeLibDetect.isLibInPath("rxtxSerial")) fixDriver(); if (NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } At the other extreme, something like: try { System.load("rxtxSerial"); } catch (UnsatisfiedLinkError e) { System.out.println("could not load lib"); } Will at least attempt to handle the missing lib, in a simple way. Perhaps some error handling is better than none. To fix the driver, I can beam it down from a web page, using: private static void fixDriver() { File tmpDir = new File( SystemUtils.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); try { UrlUtils.getUrl(getResourceUrl(), tmpDir); String nativeLib = getNativeLibName(); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(nativeLib); if (b == null) { System.out.println("could not get:" + nativeLib); return; } File f = getRxtxHome(); Futil.writeBytes(getRxtxLibFile(), b); SystemUtils.appendJavaLibraryPath(f); } catch (IOException e) { e.printStackTrace(); } } Where the libraries are stored in the hacky dispatch: private static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isMacOs()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); System.out.println("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } Appending to the library path is tricky, at run-time: public static void appendJavaLibraryPath(File p) { if (p.isFile()) System.out.println("warning: appendJavaLibraryPath:" + "only directories are findable:"+p); System.out.println("appending:"+p+" to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:"+System.getProperty(javaLibraryPa th)); } The key is altering the core visibility of the sys_paths in the class loader: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } No, it isn't simple (nor even easy) but once the API is set we have a kind of NativeLibraryManager that helps us to make libraries, like RXTX more robust. As far as I know, there is nothing quite like it (unless you all know differently). Is there any interest in this? Forgive me if this is too far off the beaten path, but the inability to load a native library remains a source of fragility in the RXTX system, IMHO. Thanks for your thoughts! - Doug From jredman at ergotech.com Thu Jul 20 08:06:41 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 20 Jul 2006 08:06:41 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BF0C61.4020900@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> Message-ID: <44BF8DF1.4040101@ergotech.com> Paul, The issue with a new, incompatible implementation is, as you've identified below, is support for the old API. Open sourcing would be helpful, but then someone (us?) would have to maintain the source through changing versions of Window, and RXTX on Linux platforms. Or we'd have to have to versions of our codebase, which doesn't appeal too much. The maintenance issue is not impossible, but I think that in essence I'm agreeing with a comment you made earlier. IF a huge change is required, then lets get on with it. However, if the changes that are required are just extensions and enhancements, with some low-level re-engineering, then can we keep a compatible high-level API so that people needing the new features can use an extended API and those who need cross-platform compatibility can continue to use the existing features. Jim Paul Klissner wrote: > Jim Redman wrote: >> Paul, >> >> For the record we're STILL supporting some PersonalJava platforms. >> We're _almost_ at the point where we can assume that the platforms will >> have a Collections framework, but routinely compile with a 1.1 check so >> that we don't make that assumption unnecessarily. Of 50+ non-graphical >> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >> JavaScripting), and we have people asking for a back-port. >> >> Embedded platforms don't change in a hurry. Unlike desktop platforms, >> embedded systems are expected to last 5-10+ years. >> >> There are factory automation vendors in the pharmaceutical industry who >> are buying systems on eBay because that's the FDA validate platform. It >> must be that make/model, spec'd sometime in the mid-90's. >> >> So... If you make an incompatible change TODAY figure we can start using >> that code _at the earliest_ somewhere around 2012 or the low teens. >> >> Are we _really_ the only people on the list supporting embedded/factory >> automation platforms? >> >> Jim > > Do you provide your own implementation classes? > > Why can't you just continue to use 2.1 for the embedded platform until > 2012 if you're locked down? Are you worried bugs won't get fixed? > Sun might consider open sourcing the 2.1 Java source. I can't promise > that, but it's been discussed and hasn't met resistance, except > from me, because I wasn't super impressed with the code. I can probably > be persuaded to champion open sourcing that and going through the > process/legal machinations within Sun if it frees us to pursue > a JSR for a new generation of javax.comm where we can have a chunk of > common code in Open Source and each platform is simply responsible > for it's platform specific plugins. > > I don't have many opinions about this set in stone because there > are a lot of technical and pragmatic considerations such as yours > the community has that I am probably not aware of or sufficiently > sensitive to yet. I don't feel I really have the bird's eye view > of all of this yet. > > The other thing is, I can only offer 10% of my time right now, > according to my management, which is why I'm not pushing to > be the spec lead for the JSR, and want only to be a participant > to represent Sun's interests on the E.G. There is nothing sacred > about Sun employees in the JCP as far as a JSR initiated by another > entity is concerned. I am not the person everything needs to be > cleared through. Ideas I have will pass or fail based on their > merit and the community perception just like anyone else's. > > Paul > >> Paul Klissner wrote: >>> Jim Redman wrote: >>>> Paul Klissner wrote: >>>>> I'd just like to find another suitable name than javax.comm, unless >>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>> 'major revisions' are accounted for. javax.serialport? >>>> Which perhaps brings us back to what are we trying to fix and how badly. >>> The goals I'm most interested in at the moment are: >>> >>> 1. A pluggable platform portmapping scheme wherein each platform >>> can determine which ports to present to the application, and >>> preferably as some configurable logical name. >>> >>> For example on the Sun Ray thin client platform, if an application >>> aquiring a view of serial ports available on the system, it will >>> be informed of Sun Ray serial ports if the application is running >>> in a session currently directed to that particular Sun Ray unit, >>> even though the serial port's device node happens to be server-side >>> deeply nested in a leaf node. If the application is not running on >>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>> the decision about when and which ports to present to the application. >>> >>> 2. Pluggable driver-side interface where multiple platform-specific >>> drivers can be utilized simultaneously to introduce more flexibility >>> with the back end. >>> >>>> There are a number of 3rd party implementation of Java Comm, at least >>>> one from IBM - part of what was J9, now Websphere, or something >>>> (presumbly soon to get a name that has eclipse in it sometime soon). >>>> Esmertec has one, and there are few others rolling around. >>> I have not been advocating gutting the API, since much of it is >>> perfectly adequate. I'm not totally opposed to making substantial >>> changes or improvements depending on other people's needs. There's >>> no reason previous versions of javax.comm need to suddenly disappear >>> if products need legacy support. >>> >>> >>>> If RXTX is the only implementation of the JSR with no backward >>>> compatibility, we've just forked Java Serial support and we (for a least >>>> one) will be worse off. We won't be able to use the new support because >>>> of a lack of support on J2ME platforms that we have no control over and >>>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>>> other platforms. >>> There can't be *that* many platforms this is ported to. And it will >>> be no javax.usb. Seems like most of the standard platforms will >>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>> JDBC... >>> >>>> So, is there any chance of building a compatibility requirement into >>>> this. To pick are really bad example JDBC has support for a DataSource >>>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>>> SerialPort on a class not found exception? >>> Maybe, or maybe we just let people know what we are doing and >>> try to figure out how to get their applications ported. Might not >>> be that difficult. From my standpoint anyway, earthshaking >>> changes aren't really necessary. Others might disagree. >>> >>> Paul >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Paul.Klissner at Sun.COM Thu Jul 20 09:31:38 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Thu, 20 Jul 2006 08:31:38 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BF8DF1.4040101@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> <44BF8DF1.4040101@ergotech.com> Message-ID: <44BFA1DA.10301@sun.com> Jim Redman wrote: > Paul, > > The issue with a new, incompatible implementation is, as you've > identified below, is support for the old API. Open sourcing would be > helpful, but then someone (us?) would have to maintain the source > through changing versions of Window, and RXTX on Linux platforms. Or > we'd have to have to versions of our codebase, which doesn't appeal too > much. > > The maintenance issue is not impossible, but I think that in essence I'm > agreeing with a comment you made earlier. > > IF a huge change is required, then lets get on with it. However, if the > changes that are required are just extensions and enhancements, with > some low-level re-engineering, then can we keep a compatible high-level > API so that people needing the new features can use an extended API and > those who need cross-platform compatibility can continue to use the > existing features. > > Jim Guillermo made a crystal clear case and I understand the problem that that will be caused by forking the API in any sense of the word. I only want to uphold Sun's interests and resolve the problems we ran into with the RXTX community when Sun added portmapping to 3.0, which was not easily undone and was implemented as kind of a hack because it wasn't directly supported by the javax.comm architection. As I mentioned previously the changes I want to make have primarily to do with adding platform-specific portmapping via plugins, and supporting multiple javax.comm backend drivers on the same host (some ports would use one driver, others ports might use another). Also I'd like to address some bugfixes that were done in Sun's version 3.0 (including better error reporting, and more robust code for locating configuration files). Besides that, I'm not aware of any deficiences, but I've glanced other e-mails where people have suggested some. It would be good to get a summary of everyone's wishes. I've stated mine. I given much thought to what it would take to properly address EIA-422, EIA-423 and EIA-485 (if any); but those would probably be extensions. Sounds like the differences might be transparent to the API. I'll look into that more. Paul > > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul, >>> >>> For the record we're STILL supporting some PersonalJava platforms. >>> We're _almost_ at the point where we can assume that the platforms will >>> have a Collections framework, but routinely compile with a 1.1 check so >>> that we don't make that assumption unnecessarily. Of 50+ non-graphical >>> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >>> JavaScripting), and we have people asking for a back-port. >>> >>> Embedded platforms don't change in a hurry. Unlike desktop platforms, >>> embedded systems are expected to last 5-10+ years. >>> >>> There are factory automation vendors in the pharmaceutical industry who >>> are buying systems on eBay because that's the FDA validate platform. It >>> must be that make/model, spec'd sometime in the mid-90's. >>> >>> So... If you make an incompatible change TODAY figure we can start using >>> that code _at the earliest_ somewhere around 2012 or the low teens. >>> >>> Are we _really_ the only people on the list supporting embedded/factory >>> automation platforms? >>> >>> Jim >> Do you provide your own implementation classes? >> >> Why can't you just continue to use 2.1 for the embedded platform until >> 2012 if you're locked down? Are you worried bugs won't get fixed? >> Sun might consider open sourcing the 2.1 Java source. I can't promise >> that, but it's been discussed and hasn't met resistance, except >> from me, because I wasn't super impressed with the code. I can probably >> be persuaded to champion open sourcing that and going through the >> process/legal machinations within Sun if it frees us to pursue >> a JSR for a new generation of javax.comm where we can have a chunk of >> common code in Open Source and each platform is simply responsible >> for it's platform specific plugins. >> >> I don't have many opinions about this set in stone because there >> are a lot of technical and pragmatic considerations such as yours >> the community has that I am probably not aware of or sufficiently >> sensitive to yet. I don't feel I really have the bird's eye view >> of all of this yet. >> >> The other thing is, I can only offer 10% of my time right now, >> according to my management, which is why I'm not pushing to >> be the spec lead for the JSR, and want only to be a participant >> to represent Sun's interests on the E.G. There is nothing sacred >> about Sun employees in the JCP as far as a JSR initiated by another >> entity is concerned. I am not the person everything needs to be >> cleared through. Ideas I have will pass or fail based on their >> merit and the community perception just like anyone else's. >> >> Paul >> >>> Paul Klissner wrote: >>>> Jim Redman wrote: >>>>> Paul Klissner wrote: >>>>>> I'd just like to find another suitable name than javax.comm, unless >>>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>>> 'major revisions' are accounted for. javax.serialport? >>>>> Which perhaps brings us back to what are we trying to fix and how badly. >>>> The goals I'm most interested in at the moment are: >>>> >>>> 1. A pluggable platform portmapping scheme wherein each platform >>>> can determine which ports to present to the application, and >>>> preferably as some configurable logical name. >>>> >>>> For example on the Sun Ray thin client platform, if an application >>>> aquiring a view of serial ports available on the system, it will >>>> be informed of Sun Ray serial ports if the application is running >>>> in a session currently directed to that particular Sun Ray unit, >>>> even though the serial port's device node happens to be server-side >>>> deeply nested in a leaf node. If the application is not running on >>>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>>> the decision about when and which ports to present to the application. >>>> >>>> 2. Pluggable driver-side interface where multiple platform-specific >>>> drivers can be utilized simultaneously to introduce more flexibility >>>> with the back end. >>>> >>>>> There are a number of 3rd party implementation of Java Comm, at least >>>>> one from IBM - part of what was J9, now Websphere, or something >>>>> (presumbly soon to get a name that has eclipse in it sometime soon). >>>>> Esmertec has one, and there are few others rolling around. >>>> I have not been advocating gutting the API, since much of it is >>>> perfectly adequate. I'm not totally opposed to making substantial >>>> changes or improvements depending on other people's needs. There's >>>> no reason previous versions of javax.comm need to suddenly disappear >>>> if products need legacy support. >>>> >>>> >>>>> If RXTX is the only implementation of the JSR with no backward >>>>> compatibility, we've just forked Java Serial support and we (for a least >>>>> one) will be worse off. We won't be able to use the new support because >>>>> of a lack of support on J2ME platforms that we have no control over and >>>>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>>>> other platforms. >>>> There can't be *that* many platforms this is ported to. And it will >>>> be no javax.usb. Seems like most of the standard platforms will >>>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>>> JDBC... >>>> >>>>> So, is there any chance of building a compatibility requirement into >>>>> this. To pick are really bad example JDBC has support for a DataSource >>>>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>>>> SerialPort on a class not found exception? >>>> Maybe, or maybe we just let people know what we are doing and >>>> try to figure out how to get their applications ported. Might not >>>> be that difficult. From my standpoint anyway, earthshaking >>>> changes aren't really necessary. Others might disagree. >>>> >>>> Paul >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From Paul.Klissner at Sun.COM Thu Jul 20 09:45:11 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Thu, 20 Jul 2006 08:45:11 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BFA1DA.10301@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> <44BF8DF1.4040101@ergotech.com> <44BFA1DA.10301@sun.com> Message-ID: <44BFA507.3020001@sun.com> Paul Klissner wrote: > Jim Redman wrote: >> Paul, >> >> The issue with a new, incompatible implementation is, as you've >> identified below, is support for the old API. Open sourcing would be >> helpful, but then someone (us?) would have to maintain the source >> through changing versions of Window, and RXTX on Linux platforms. Or >> we'd have to have to versions of our codebase, which doesn't appeal >> too much. >> >> The maintenance issue is not impossible, but I think that in essence >> I'm agreeing with a comment you made earlier. >> >> IF a huge change is required, then lets get on with it. However, if >> the changes that are required are just extensions and enhancements, >> with some low-level re-engineering, then can we keep a compatible >> high-level API so that people needing the new features can use an >> extended API and those who need cross-platform compatibility can >> continue to use the existing features. >> >> Jim > > Guillermo made a crystal clear case and I understand the problem > that that will be caused by forking the API in any sense of the > word. I only want to uphold Sun's interests and resolve the problems > we ran into with the RXTX community when Sun added portmapping > to 3.0, which was not easily undone and was implemented as kind > of a hack because it wasn't directly supported by the javax.comm > architection. ^^^"architecture" > > As I mentioned previously the changes I want to make have primarily > to do with adding platform-specific portmapping via plugins, > and supporting multiple javax.comm backend drivers on the same > host (some ports would use one driver, others ports might use another). > > Also I'd like to address some bugfixes that were done in Sun's > version 3.0 (including better error reporting, and more robust > code for locating configuration files). Besides that, I'm not > aware of any deficiences, but I've glanced other e-mails where > people have suggested some. It would be good to get a summary > of everyone's wishes. I've stated mine. > > I given much thought to what it would take to properly address ^^^haven't > EIA-422, EIA-423 and EIA-485 (if any); but those would > probably be extensions. Sounds like the differences might > be transparent to the API. I'll look into that more. > > Paul > > >> >> Paul Klissner wrote: >>> Jim Redman wrote: >>>> Paul, >>>> >>>> For the record we're STILL supporting some PersonalJava platforms. >>>> We're _almost_ at the point where we can assume that the platforms >>>> will have a Collections framework, but routinely compile with a 1.1 >>>> check so that we don't make that assumption unnecessarily. Of 50+ >>>> non-graphical Factory Automation JavaBeans we have 2 that require >>>> Java2 (Reporting and JavaScripting), and we have people asking for a >>>> back-port. >>>> >>>> Embedded platforms don't change in a hurry. Unlike desktop >>>> platforms, embedded systems are expected to last 5-10+ years. >>>> >>>> There are factory automation vendors in the pharmaceutical industry >>>> who are buying systems on eBay because that's the FDA validate >>>> platform. It must be that make/model, spec'd sometime in the mid-90's. >>>> >>>> So... If you make an incompatible change TODAY figure we can start >>>> using that code _at the earliest_ somewhere around 2012 or the low >>>> teens. >>>> >>>> Are we _really_ the only people on the list supporting >>>> embedded/factory automation platforms? >>>> >>>> Jim >>> Do you provide your own implementation classes? >>> >>> Why can't you just continue to use 2.1 for the embedded platform until >>> 2012 if you're locked down? Are you worried bugs won't get fixed? >>> Sun might consider open sourcing the 2.1 Java source. I can't promise >>> that, but it's been discussed and hasn't met resistance, except >>> from me, because I wasn't super impressed with the code. I can probably >>> be persuaded to champion open sourcing that and going through the >>> process/legal machinations within Sun if it frees us to pursue >>> a JSR for a new generation of javax.comm where we can have a chunk of >>> common code in Open Source and each platform is simply responsible >>> for it's platform specific plugins. >>> >>> I don't have many opinions about this set in stone because there >>> are a lot of technical and pragmatic considerations such as yours >>> the community has that I am probably not aware of or sufficiently >>> sensitive to yet. I don't feel I really have the bird's eye view >>> of all of this yet. >>> >>> The other thing is, I can only offer 10% of my time right now, >>> according to my management, which is why I'm not pushing to >>> be the spec lead for the JSR, and want only to be a participant >>> to represent Sun's interests on the E.G. There is nothing sacred >>> about Sun employees in the JCP as far as a JSR initiated by another >>> entity is concerned. I am not the person everything needs to be >>> cleared through. Ideas I have will pass or fail based on their >>> merit and the community perception just like anyone else's. >>> >>> Paul >>> >>>> Paul Klissner wrote: >>>>> Jim Redman wrote: >>>>>> Paul Klissner wrote: >>>>>>> I'd just like to find another suitable name than javax.comm, unless >>>>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>>>> 'major revisions' are accounted for. javax.serialport? >>>>>> Which perhaps brings us back to what are we trying to fix and how >>>>>> badly. >>>>> The goals I'm most interested in at the moment are: >>>>> >>>>> 1. A pluggable platform portmapping scheme wherein each platform >>>>> can determine which ports to present to the application, and >>>>> preferably as some configurable logical name. >>>>> >>>>> For example on the Sun Ray thin client platform, if an application >>>>> aquiring a view of serial ports available on the system, it will >>>>> be informed of Sun Ray serial ports if the application is running >>>>> in a session currently directed to that particular Sun Ray unit, >>>>> even though the serial port's device node happens to be server-side >>>>> deeply nested in a leaf node. If the application is not running on >>>>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>>>> the decision about when and which ports to present to the application. >>>>> >>>>> 2. Pluggable driver-side interface where multiple platform-specific >>>>> drivers can be utilized simultaneously to introduce more flexibility >>>>> with the back end. >>>>> >>>>>> There are a number of 3rd party implementation of Java Comm, at >>>>>> least one from IBM - part of what was J9, now Websphere, or >>>>>> something (presumbly soon to get a name that has eclipse in it >>>>>> sometime soon). Esmertec has one, and there are few others rolling >>>>>> around. >>>>> I have not been advocating gutting the API, since much of it is >>>>> perfectly adequate. I'm not totally opposed to making substantial >>>>> changes or improvements depending on other people's needs. There's >>>>> no reason previous versions of javax.comm need to suddenly disappear >>>>> if products need legacy support. >>>>> >>>>> >>>>>> If RXTX is the only implementation of the JSR with no backward >>>>>> compatibility, we've just forked Java Serial support and we (for a >>>>>> least one) will be worse off. We won't be able to use the new >>>>>> support because of a lack of support on J2ME platforms that we >>>>>> have no control over and RXTX/current JavaComm will be in >>>>>> maintenance mode or unsupported on all other platforms. >>>>> There can't be *that* many platforms this is ported to. And it will >>>>> be no javax.usb. Seems like most of the standard platforms will >>>>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>>>> JDBC... >>>>> >>>>>> So, is there any chance of building a compatibility requirement >>>>>> into this. To pick are really bad example JDBC has support for a >>>>>> DataSource or a Driver. Could we have an ExcellentSerialPort with >>>>>> a fallback to a SerialPort on a class not found exception? >>>>> Maybe, or maybe we just let people know what we are doing and >>>>> try to figure out how to get their applications ported. Might not >>>>> be that difficult. From my standpoint anyway, earthshaking >>>>> changes aren't really necessary. Others might disagree. >>>>> >>>>> Paul >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From jredman at ergotech.com Thu Jul 20 10:30:01 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 20 Jul 2006 10:30:01 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BFA507.3020001@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> <44BF8DF1.4040101@ergotech.com> <44BFA1DA.10301@sun.com> <44BFA507.3020001@sun.com> Message-ID: <44BFAF89.5010003@ergotech.com> Thast what hapens if you post late at nihgt nad erly in the moning as wel. :) Paul Klissner wrote: > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul, >>> >>> The issue with a new, incompatible implementation is, as you've >>> identified below, is support for the old API. Open sourcing would be >>> helpful, but then someone (us?) would have to maintain the source >>> through changing versions of Window, and RXTX on Linux platforms. Or >>> we'd have to have to versions of our codebase, which doesn't appeal >>> too much. >>> >>> The maintenance issue is not impossible, but I think that in essence >>> I'm agreeing with a comment you made earlier. >>> >>> IF a huge change is required, then lets get on with it. However, if >>> the changes that are required are just extensions and enhancements, >>> with some low-level re-engineering, then can we keep a compatible >>> high-level API so that people needing the new features can use an >>> extended API and those who need cross-platform compatibility can >>> continue to use the existing features. >>> >>> Jim >> Guillermo made a crystal clear case and I understand the problem >> that that will be caused by forking the API in any sense of the >> word. I only want to uphold Sun's interests and resolve the problems >> we ran into with the RXTX community when Sun added portmapping >> to 3.0, which was not easily undone and was implemented as kind >> of a hack because it wasn't directly supported by the javax.comm >> architection. > ^^^"architecture" >> As I mentioned previously the changes I want to make have primarily >> to do with adding platform-specific portmapping via plugins, >> and supporting multiple javax.comm backend drivers on the same >> host (some ports would use one driver, others ports might use another). >> >> Also I'd like to address some bugfixes that were done in Sun's >> version 3.0 (including better error reporting, and more robust >> code for locating configuration files). Besides that, I'm not >> aware of any deficiences, but I've glanced other e-mails where >> people have suggested some. It would be good to get a summary >> of everyone's wishes. I've stated mine. >> >> I given much thought to what it would take to properly address > ^^^haven't >> EIA-422, EIA-423 and EIA-485 (if any); but those would >> probably be extensions. Sounds like the differences might >> be transparent to the API. I'll look into that more. >> >> Paul >> >> >>> Paul Klissner wrote: >>>> Jim Redman wrote: >>>>> Paul, >>>>> >>>>> For the record we're STILL supporting some PersonalJava platforms. >>>>> We're _almost_ at the point where we can assume that the platforms >>>>> will have a Collections framework, but routinely compile with a 1.1 >>>>> check so that we don't make that assumption unnecessarily. Of 50+ >>>>> non-graphical Factory Automation JavaBeans we have 2 that require >>>>> Java2 (Reporting and JavaScripting), and we have people asking for a >>>>> back-port. >>>>> >>>>> Embedded platforms don't change in a hurry. Unlike desktop >>>>> platforms, embedded systems are expected to last 5-10+ years. >>>>> >>>>> There are factory automation vendors in the pharmaceutical industry >>>>> who are buying systems on eBay because that's the FDA validate >>>>> platform. It must be that make/model, spec'd sometime in the mid-90's. >>>>> >>>>> So... If you make an incompatible change TODAY figure we can start >>>>> using that code _at the earliest_ somewhere around 2012 or the low >>>>> teens. >>>>> >>>>> Are we _really_ the only people on the list supporting >>>>> embedded/factory automation platforms? >>>>> >>>>> Jim >>>> Do you provide your own implementation classes? >>>> >>>> Why can't you just continue to use 2.1 for the embedded platform until >>>> 2012 if you're locked down? Are you worried bugs won't get fixed? >>>> Sun might consider open sourcing the 2.1 Java source. I can't promise >>>> that, but it's been discussed and hasn't met resistance, except >>>> from me, because I wasn't super impressed with the code. I can probably >>>> be persuaded to champion open sourcing that and going through the >>>> process/legal machinations within Sun if it frees us to pursue >>>> a JSR for a new generation of javax.comm where we can have a chunk of >>>> common code in Open Source and each platform is simply responsible >>>> for it's platform specific plugins. >>>> >>>> I don't have many opinions about this set in stone because there >>>> are a lot of technical and pragmatic considerations such as yours >>>> the community has that I am probably not aware of or sufficiently >>>> sensitive to yet. I don't feel I really have the bird's eye view >>>> of all of this yet. >>>> >>>> The other thing is, I can only offer 10% of my time right now, >>>> according to my management, which is why I'm not pushing to >>>> be the spec lead for the JSR, and want only to be a participant >>>> to represent Sun's interests on the E.G. There is nothing sacred >>>> about Sun employees in the JCP as far as a JSR initiated by another >>>> entity is concerned. I am not the person everything needs to be >>>> cleared through. Ideas I have will pass or fail based on their >>>> merit and the community perception just like anyone else's. >>>> >>>> Paul >>>> >>>>> Paul Klissner wrote: >>>>>> Jim Redman wrote: >>>>>>> Paul Klissner wrote: >>>>>>>> I'd just like to find another suitable name than javax.comm, unless >>>>>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>>>>> 'major revisions' are accounted for. javax.serialport? >>>>>>> Which perhaps brings us back to what are we trying to fix and how >>>>>>> badly. >>>>>> The goals I'm most interested in at the moment are: >>>>>> >>>>>> 1. A pluggable platform portmapping scheme wherein each platform >>>>>> can determine which ports to present to the application, and >>>>>> preferably as some configurable logical name. >>>>>> >>>>>> For example on the Sun Ray thin client platform, if an application >>>>>> aquiring a view of serial ports available on the system, it will >>>>>> be informed of Sun Ray serial ports if the application is running >>>>>> in a session currently directed to that particular Sun Ray unit, >>>>>> even though the serial port's device node happens to be server-side >>>>>> deeply nested in a leaf node. If the application is not running on >>>>>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>>>>> the decision about when and which ports to present to the application. >>>>>> >>>>>> 2. Pluggable driver-side interface where multiple platform-specific >>>>>> drivers can be utilized simultaneously to introduce more flexibility >>>>>> with the back end. >>>>>> >>>>>>> There are a number of 3rd party implementation of Java Comm, at >>>>>>> least one from IBM - part of what was J9, now Websphere, or >>>>>>> something (presumbly soon to get a name that has eclipse in it >>>>>>> sometime soon). Esmertec has one, and there are few others rolling >>>>>>> around. >>>>>> I have not been advocating gutting the API, since much of it is >>>>>> perfectly adequate. I'm not totally opposed to making substantial >>>>>> changes or improvements depending on other people's needs. There's >>>>>> no reason previous versions of javax.comm need to suddenly disappear >>>>>> if products need legacy support. >>>>>> >>>>>> >>>>>>> If RXTX is the only implementation of the JSR with no backward >>>>>>> compatibility, we've just forked Java Serial support and we (for a >>>>>>> least one) will be worse off. We won't be able to use the new >>>>>>> support because of a lack of support on J2ME platforms that we >>>>>>> have no control over and RXTX/current JavaComm will be in >>>>>>> maintenance mode or unsupported on all other platforms. >>>>>> There can't be *that* many platforms this is ported to. And it will >>>>>> be no javax.usb. Seems like most of the standard platforms will >>>>>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>>>>> JDBC... >>>>>> >>>>>>> So, is there any chance of building a compatibility requirement >>>>>>> into this. To pick are really bad example JDBC has support for a >>>>>>> DataSource or a Driver. Could we have an ExcellentSerialPort with >>>>>>> a fallback to a SerialPort on a class not found exception? >>>>>> Maybe, or maybe we just let people know what we are doing and >>>>>> try to figure out how to get their applications ported. Might not >>>>>> be that difficult. From my standpoint anyway, earthshaking >>>>>> changes aren't really necessary. Others might disagree. >>>>>> >>>>>> Paul >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Thu Jul 20 10:31:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 20 Jul 2006 10:31:57 -0600 (MDT) Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEA802.7060508@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: > PROJECT SCOPE: > ------------- > > Also, we should think carefully about what the scope of > this project would be. Should it be javax."comm" which > handles both serial and parallel (is parallel going by the > wayside). Should it be split into two project: > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > > Should we differentiate between single-ended serial > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > quasi-multidrop and full multidrop busses such as > EIA422, EIA432 and EIA485? If we really were to > add I2C support to the API, we'd have to delve into > the semantics more, because there could be some > implicit decoding of the bus the API users would > want to see. > Hi Paul The way RXTX works, which is a fair representation of the people using the API, is complete support for RIA232, minimal support for IEEE1284. From what I understand, Sun was going along the same lines. If we combined both projects, we would have half a parallel port implementation. I see maybe 4 requests for features not in the parallel support a year. The other protocols should not be limited by a JSR which is going to be focused upon serial port interests. The IEA485 hacks in RXTX along with I2C and Raw should _not_ be considered a strong basis for extending the API to cover these protocols. If people want to do real implementations, they should not face a 'standard' which wasnt really focused upon their interests. I think we understand the parallel port issues fairly well but have not implemented many features and I don't know if we would. So a versatile API is favorable but I do not think we have the proper community to represent much more than Serial. We could provide a framework or maybe just a model for further work with other standards. -- Trent Jarvi tjarvi at qbang.org From naranjo.manuel at gmail.com Thu Jul 20 10:49:33 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Thu, 20 Jul 2006 13:49:33 -0300 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <44BFB41D.4010604@gmail.com> Trent Jarvi wrote: >> PROJECT SCOPE: >> ------------- >> >> Also, we should think carefully about what the scope of >> this project would be. Should it be javax."comm" which >> handles both serial and parallel (is parallel going by the >> wayside). Should it be split into two project: >> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >> >> Should we differentiate between single-ended serial >> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >> quasi-multidrop and full multidrop busses such as >> EIA422, EIA432 and EIA485? If we really were to >> add I2C support to the API, we'd have to delve into >> the semantics more, because there could be some >> implicit decoding of the bus the API users would >> want to see. >> > > Hi Paul > > The way RXTX works, which is a fair representation of the people using the > API, is complete support for RIA232, minimal support for IEEE1284. From > what I understand, Sun was going along the same lines. If we combined > both projects, we would have half a parallel port implementation. I see > maybe 4 requests for features not in the parallel support a year. > > The other protocols should not be limited by a JSR which is going to be > focused upon serial port interests. The IEA485 hacks in RXTX along with > I2C and Raw should _not_ be considered a strong basis for extending the > API to cover these protocols. If people want to do real implementations, > they should not face a 'standard' which wasnt really focused upon their > interests. I think we understand the parallel port issues fairly well but > have not implemented many features and I don't know if we would. > > So a versatile API is favorable but I do not think we have the proper > community to represent much more than Serial. We could provide a > framework or maybe just a model for further work with other standards. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Hi, I agree with Trent, as far as I have seen most projects that were using RXTX and Java Comm where designed to work only with Serial Ports. What is fact is that a Parallel port can not be modeled at all like a Serial Port, except that they both expose and Input Stream and an Output Stream. As I have read there is a huge market of embedded applications using port accessing. We could take two different aproaches with the JSR, one could be define a way to access every kind of port independent of the implementation of the port himself. We could access Serial, Parallel, I2C, USB, etc. But we will have huge problems with it, because we will have to face a lot of low level programming which of course will be platform dependent, and that is were the write one use everywhere of Java could dye. The other approach is to define an Api that only supports Serial Ports, compatible with the one that is defined in javax.comm 2.0, and make some classes that extend that packages, maybe even in another package, like AWT and JSWING do. We then could eventually extend to other kinds of ports but that will require a lot of work more. I'm not a person specialized on Informatical Engineering, so I do not think I can give a hand on Low Level programming, I do can help with the Java part, debugging and testing. Regards, Manuel From brian at mbari.org Thu Jul 20 11:19:33 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 20 Jul 2006 10:19:33 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <8BFCAB48-6302-44CD-ABF0-560BC04AD26E@mbari.org> > The way RXTX works, which is a fair representation of the people > using the > API, is complete support for RIA232, minimal support for IEEE1284. > From > what I understand, Sun was going along the same lines. If we combined > both projects, we would have half a parallel port implementation. > I see > maybe 4 requests for features not in the parallel support a year. > > The other protocols should not be limited by a JSR which is going > to be > focused upon serial port interests. The IEA485 hacks in RXTX along > with > I2C and Raw should _not_ be considered a strong basis for extending > the > API to cover these protocols. If people want to do real > implementations, > they should not face a 'standard' which wasnt really focused upon > their > interests. I think we understand the parallel port issues fairly > well but > have not implemented many features and I don't know if we would. > > So a versatile API is favorable but I do not think we have the proper > community to represent much more than Serial. We could provide a > framework or maybe just a model for further work with other standards. I agree completely. Folks use RXTX for serial ports. In my field (Oceanography), we uses RS232 to talk to nearly all our instruments. So we really need a great implementation of serial port communications in Java that runs on a variety of architectures. I'd prefer if the JSR focused on that. >> I given much thought to what it would take to properly address >> > ^^^haven't > >> EIA-422, EIA-423 and EIA-485 (if any); but those would >> probably be extensions. Sounds like the differences might >> be transparent to the API. I'll look into that more. I've had good luck using the current implementation of RXTX with RS422, although you'll need to use a pin converter. my 2 cents. Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060720/fb956c68/attachment-0344.html From pascal at quies.net Fri Jul 21 15:43:40 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Fri, 21 Jul 2006 23:43:40 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: Message-ID: <200607212343.40882.pascal@quies.net> Op donderdag 20 juli 2006 15:16, schreef Dr. Douglas Lyon: > Hi All, > There has been some discussion about plugins for serial communications. > > As I see it, what Java really needs is a NativeLibraryManager. This is > a rather much larger charge than "just" RXTX. > > The RXTX basic mode of operation is that we associate static > blocks of code with a "System.load". > > Failure occurs when the class containing such a block of code is > loaded AND the native library is not found. > > What are some of the options? > > 1. Do nothing, let the program fail with an exception. > 2. try to catch an UnsatisfiedLinkError as a part of making > the driver. > 3. Search the java.library.path to see if the driver is present > (i.e., guard the input). > 4. Other?? > > In the case of either step 2 or 3, we need to fix the lack of a library. > > What are the options for fixing a library? > 1. Do nothing, but give the user an interesting error with instructions on > what to do. > 2. Attempt to find the library on the file system (perhaps with user help). > 3. Attempt to download the library and install it (perhaps with user > permission). > 4. Attempt to internalize the library as a UUEncoded serialized object and > install it (better ask the user, again!). > 5. Other?? 5. Put the binaries together with the attached classes in a jar. Joachim told me that and it works! I forgot to publish the results. :$ ---- begin example import org.rxtx.CommunicationAPI; ... CommunicationAPI commExtension = new CommunicationAPI(); try { commExtenios.loadNativeLibraries(); } catch (Exception e) { // We *need* javax.comm } // Now we have the extension available. ... ---- end example Do you like it? Commens anyone? The path to the libraries is in the form of /native/rxtx/-/{libserial,libparallel} so /native/rxtx/windows-i386/libserial would do. I asked for binaries but only Joachim offered me help with OS X on the next release. Does anyone have javax.comm warper classes? -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 6781 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060721/b39a5592/CommunicationAPI-0343.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: PlatformNotSupportedException.java Type: text/x-java Size: 1621 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060721/b39a5592/PlatformNotSupportedException-0343.bin From pascal at quies.net Fri Jul 21 15:45:30 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Fri, 21 Jul 2006 23:45:30 +0200 Subject: [Rxtx] quo vadis API/namespace (Re: jcp and jsr) In-Reply-To: References: <44BEDC4F.9030403@sun.com> Message-ID: <200607212345.30495.pascal@quies.net> Op donderdag 20 juli 2006 10:46, schreef Joachim Buechse: > So in short: Unless we find a strong argument why javax.comm can't be > used I prefer that we keep it. Unless we find a strong feature / use- > case that can not be handled with (an extension of) the current > CommPort/CommPortIndentifier I'd prefer to keep that as well. I seem to be the only one who sees failures in the API so lets keep it that way. Now how do we get a JSR/lisence if we don't want any changes? :P From lyon at docjava.com Sat Jul 22 06:07:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 22 Jul 2006 08:07:03 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607212343.40882.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> Message-ID: Hi All, I like the idea of the native lib in a jar with other classes. An alternative I did not know would work. Now, if you place the rxtx classes and native library in the same jar, do they both have to be in any specific place in order to be found? In my approach, you can locate the native library at run-time, and you need not alter any environmental variables nor mangle the JDK home. Thus, each user can have a different native library, one for development and one for release, for example. Regards, - Doug >Op donderdag 20 juli 2006 15:16, schreef Dr. Douglas Lyon: >> Hi All, >> There has been some discussion about plugins for serial communications. >> >> As I see it, what Java really needs is a NativeLibraryManager. This is >> a rather much larger charge than "just" RXTX. >> >> The RXTX basic mode of operation is that we associate static >> blocks of code with a "System.load". >> >> Failure occurs when the class containing such a block of code is >> loaded AND the native library is not found. >> >> What are some of the options? >> >> 1. Do nothing, let the program fail with an exception. >> 2. try to catch an UnsatisfiedLinkError as a part of making >> the driver. >> 3. Search the java.library.path to see if the driver is present >> (i.e., guard the input). >> 4. Other?? >> >> In the case of either step 2 or 3, we need to fix the lack of a library. >> >> What are the options for fixing a library? >> 1. Do nothing, but give the user an interesting error with instructions on >> what to do. >> 2. Attempt to find the library on the file system (perhaps with user help). >> 3. Attempt to download the library and install it (perhaps with user >> permission). >> 4. Attempt to internalize the library as a UUEncoded serialized object and >> install it (better ask the user, again!). >> 5. Other?? > >5. Put the binaries together with the attached classes in a jar. > >Joachim told me that and it works! I forgot to publish the results. :$ > > >---- begin example >import org.rxtx.CommunicationAPI; > >... >CommunicationAPI commExtension = new CommunicationAPI(); >try { > commExtenios.loadNativeLibraries(); >} catch (Exception e) { > // We *need* javax.comm >} > >// Now we have the extension available. >... >---- end example > > >Do you like it? Commens anyone? > > >The path to the libraries is in the form >of /native/rxtx/-/{libserial,libparallel} >so /native/rxtx/windows-i386/libserial would do. > >I asked for binaries but only Joachim offered me help with OS X on the next >release. > >Does anyone have javax.comm warper classes? > >Attachment converted: PowerBookHd:CommunicationAPI.java (TEXT/ttxt) (001C1686) >Attachment converted: PowerBookHd:PlatformNotSupporte#1C1687.java >(TEXT/ttxt) (001C1687) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 22 07:06:06 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 15:06:06 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607212343.40882.pascal@quies.net> Message-ID: <200607221506.07140.pascal@quies.net> > Now, if you place the rxtx classes and native library in the same > jar, do they both have to be in any specific place in order to be found? Answer: > >The path to the libraries is in the form > >of /native/rxtx/-/{libserial,libparallel} > >so /native/rxtx/windows-i386/libserial would do. I'me looking for the various os.name and os.arch values right now. From lyon at docjava.com Sat Jul 22 08:06:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 22 Jul 2006 10:06:26 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607221506.07140.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> <200607221506.07140.pascal@quies.net> Message-ID: Hi All, Here is how I have arranged my signed versions of the native binaries: http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/windows/native.jar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/native.jar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/linux/native.jar Then I do: public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isMacOs()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); System.out.println("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } My new-age NativeLibraryManger concept-thang allows you to write stuff like: /** * This method fixes the driver by beaming over * to the tmp directory a native.jar file. * The native.jar file is signed and its * native libs are beamed over to the user home directory * ~/.rxtx/
* Finally, the java.library.path is altered to include
* ~/.rxtx/ */ private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), NativeLibraryManager.mapLibraryName("rxtxSerial")); } catch (IOException e) { e.printStackTrace(); } } I do a lazy singleton design pattern: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getInstance() { if (driver != null) return driver; if (!NativeLibraryManager.isLibInPath("rxtxSerial")) fixDriver(); if (NativeLibraryManager.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } I am at a cross-roads here, since a file-based distro might be preferable to a URL based distro. To make this really general, and to "remember" where the last version of a native library came from, I serialize a bean into user preferences The user can then store native libraries anywhere, remembering the location in the preferences. What is the general feeling about this? Thanks! - Doug > > Now, if you place the rxtx classes and native library in the same >> jar, do they both have to be in any specific place in order to be found? > >Answer: > >> >The path to the libraries is in the form >> >of /native/rxtx/-/{libserial,libparallel} >> >so /native/rxtx/windows-i386/libserial would do. > >I'me looking for the various os.name and os.arch values right now. >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Sat Jul 22 10:30:55 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 22 Jul 2006 11:30:55 -0500 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607212343.40882.pascal@quies.net> Message-ID: <44C252BF.6040404@cox.net> Dr. Douglas Lyon wrote: > Hi All, > I like the idea of the native lib in a jar with other classes. > An alternative I did not know would work. I have several applications that run with a security policy. In these applications, native library loading will require an appropriate FilePermission that should be known about ahead of time. The current native library implementation will require the native library to be extracted from the jar and written to disk, requiring a FilePermission("...","write") for that file, and then will also require read access to load the library. I personally don't want to give write access to a JVM for a shared library which can provide a point of abuse by errant code. Gregg Wonderly From gergg at cox.net Sat Jul 22 10:33:52 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 22 Jul 2006 11:33:52 -0500 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607212343.40882.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> Message-ID: <44C25370.9070506@cox.net> >Pascal S. de Kloe wrote: >>> I am also not sure if >>> the api should unify corresponding cu. and tty. ports into one single >>> port. >> >> I think the API should hide low-level details like devicefiles. > >Not all ports have device files. It's long been my goal to add support >for virtual serial ports, that is, serial ports on Ethernet terminal >servers, for example integrating RFC2217. This means that the port name >is some combination of an IP address and TCP port number. Nothing in /dev. What I think would make the most sense is a simple "device" enumeration Server Provider Interface that would bring port objects into the JVM based on the platform JVM providers knowledge of how to enumerate those ports. Application writers would provide a plugin using the SPI that would codify those devices into named entities that they are interested in. public interface HardwarePort { public String getName(); public String getHardwareID(); public String getManufacturer(); public List getCapabilities(); public Object getImplementation(); } public interface PortCapability { public String getDescription(); public CapabilityId getIdentifier(); } public enum CapabilityId { INPUT, // Can receive input OUTPUT, // Can send output ASYNCHRONOUS, // Can send and receive at the same time SYNCHRONOUS, // No synchronous I/O ADDRESSABLE // Port has an address associated } Then, you might imagine that the enumerated capabilities had a standardized/specified interface that you'd find implemented on ports that had such capabilities. The getImplementation() method would return the implementation class provided by the JVM provider that had all of the interfaces tied to it. These are just some quick thoughts, pick away at them. I am very interested in getting a new comm api in place which can provide the ability for all USB connected devices to have drivers provided as 100% java for all non-timing critical types of device interfaces. The JVM provider should have an SPI to write to which will enable them to abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into something that we can talk 100% java to. That's my big desire. Starting with something simple which gives a good start in that direction would be great! Gregg Wonderly From pascal at quies.net Sat Jul 22 10:43:27 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 18:43:27 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <44C252BF.6040404@cox.net> References: <44C252BF.6040404@cox.net> Message-ID: <200607221843.27765.pascal@quies.net> Op zaterdag 22 juli 2006 18:30, schreef Gregg Wonderly: > Dr. Douglas Lyon wrote: > > Hi All, > > I like the idea of the native lib in a jar with other classes. > > An alternative I did not know would work. > > I have several applications that run with a security policy. In these > applications, native library loading will require an appropriate > FilePermission that should be known about ahead of time. The current > native library implementation will require the native library to be > extracted from the jar and written to disk, requiring a > FilePermission("...","write") for that file, and then will also require > read access to load the library. I personally don't want to give write > access to a JVM for a shared library which can provide a point of abuse by > errant code. > > Gregg Wonderly That's indeed a pitty limitation. It creates a lot of possible exceptions too. On the other hand, any native lib passes the securiy model. Applications who can access hardware ports can be expected to create files, right? From pascal at quies.net Sat Jul 22 10:54:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 18:54:13 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607221506.07140.pascal@quies.net> Message-ID: <200607221854.13467.pascal@quies.net> Hi Dr., We're both trying to do the same thing. The CommunicationAPI does not only look at the OS but it also indexes the available hardware architectures and does not need OsUtils. Any Java 2 runtime will do. The plan was to make a single JAR with the binaries for all supported platforms, the RXTX gnu.io package and the javax.comm wrapers. A signed version would be nice. A few questions remain tough. Does anybody know how Sun uses the SunOS and Solaris identifiers for the Java property os.name? Op zaterdag 22 juli 2006 16:06, schreef Dr. Douglas Lyon: > Hi All, > Here is how I have arranged my signed versions of the native > binaries: > http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/windows/native.j >ar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/native.jar > http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/linux/native.jar > > Then I do: > public static URL getResourceUrl() throws MalformedURLException { > String rxtxUrl = "http://show.docjava.com:8086/" + > "book/cgij/code/jnlp/libs/rxtx/"; > if (OsUtils.isLinux()) > return new URL(rxtxUrl + "linux/native.jar"); > if (OsUtils.isMacOs()) > return new URL(rxtxUrl + "mac/native.jar"); > if (OsUtils.isWindows()) > return new URL(rxtxUrl + "windows/native.jar"); > System.out.println("no automatic install supported for this > platform. " + > "Please e-mail lyon at docjava.com with a bug report"); > return null; > } > > My new-age NativeLibraryManger concept-thang allows you to > write stuff like: > > /** > * This method fixes the driver by beaming over > * to the tmp directory a native.jar file. > * The native.jar file is signed and its > * native libs are beamed over to the user home directory > * ~/.rxtx/
> * Finally, the java.library.path is altered to include
> * ~/.rxtx/ > */ > private static void fixDriver() { > > try { > NativeLibraryManager.fixDriver(getResourceUrl(), > NativeLibraryManager.mapLibraryName("rxtxSerial")); > } catch (IOException e) { > e.printStackTrace(); > } > } > > I do a lazy singleton design pattern: > > public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public synchronized static RXTXCommDriver getInstance() { > if (driver != null) return driver; > if (!NativeLibraryManager.isLibInPath("rxtxSerial")) > fixDriver(); > if (NativeLibraryManager.isLibInPath("rxtxSerial")) { > driver = new RXTXCommDriver(); > driver.initialize(); > } > return driver; > } > > I am at a cross-roads here, since a file-based distro might be preferable > to a URL based distro. To make this really general, and to "remember" where > the last version of a native library came from, I serialize a bean into > user preferences > The user can then store native libraries anywhere, remembering the location > in the preferences. > > What is the general feeling about this? > > Thanks! > - Doug > > > > Now, if you place the rxtx classes and native library in the same > >> > >> jar, do they both have to be in any specific place in order to be > >> found? > > > >Answer: > >> >The path to the libraries is in the form > >> >of /native/rxtx/-/{libserial,libparallel} > >> >so /native/rxtx/windows-i386/libserial would do. > > > >I'me looking for the various os.name and os.arch values right now. > >_______________________________________________ > >Rxtx mailing list > >Rxtx at qbang.org > >http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Sat Jul 22 11:17:51 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 22 Jul 2006 19:17:51 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <44C252BF.6040404@cox.net> References: <200607212343.40882.pascal@quies.net> <44C252BF.6040404@cox.net> Message-ID: <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> We could easily have a stub method / flag that allows you to explicitly load the native library (via System.loadLibrary ie from the java.library.path). In this case the "auto-extraction" would not take place. On 22.07.2006, at 18:30, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> Hi All, >> I like the idea of the native lib in a jar with other classes. >> An alternative I did not know would work. > > I have several applications that run with a security policy. In these > applications, native library loading will require an appropriate > FilePermission > that should be known about ahead of time. The current native library > implementation will require the native library to be extracted from > the jar and > written to disk, requiring a FilePermission("...","write") for that > file, and > then will also require read access to load the library. I > personally don't want > to give write access to a JVM for a shared library which can > provide a point of > abuse by errant code. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 22 11:20:19 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 19:20:19 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607221506.07140.pascal@quies.net> Message-ID: <200607221920.20096.pascal@quies.net> The attachment setup.zip contains a very small update of CommunicationAPI and a good start with the various platforms. All we need to do is fill those directories with binaries. Various binaries are missing the pararlel library. Why is that? -------------- next part -------------- A non-text attachment was scrubbed... Name: setup.zip Type: application/x-zip Size: 8459 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060722/12770623/setup-0342.bin From gregg at cytetech.com Thu Jul 20 21:32:55 2006 From: gregg at cytetech.com (Gregg Wonderly) Date: Thu, 20 Jul 2006 22:32:55 -0500 Subject: [Rxtx] jcp and jsr Message-ID: <44C04AE7.9050800@cytetech.com> >Pascal S. de Kloe wrote: >>> I am also not sure if >>> the api should unify corresponding cu. and tty. ports into one single >>> port. >> >> I think the API should hide low-level details like devicefiles. > >Not all ports have device files. It's long been my goal to add support >for virtual serial ports, that is, serial ports on Ethernet terminal >servers, for example integrating RFC2217. This means that the port name >is some combination of an IP address and TCP port number. Nothing in /dev. What I think would make the most sense is a simple "device" enumeration Server Provider Interface that would bring port objects into the JVM based on the platform JVM providers knowledge of how to enumerate those ports. Application writers would provide a plugin using the SPI that would codify those devices into named entities that they are interested in. public interface HardwarePort { public String getName(); public String getHardwareID(); public String getManufacturer(); public List getCapabilities(); public Object getImplementation(); } public interface PortCapability { public String getDescription(); public CapabilityId getIdentifier(); } public enum CapabilityId { INPUT, // Can receive input OUTPUT, // Can send output ASYNCHRONOUS, // Can send and receive at the same time SYNCHRONOUS, // No synchronous I/O ADDRESSABLE // Port has an address associated } Then, you might imagine that the enumerated capabilities had a standardized/specified interface that you'd find implemented on ports that had such capabilities. The getImplementation() method would return the implementation class provided by the JVM provider that had all of the interfaces tied to it. These are just some quick thoughts, pick away at them. I am very interested in getting a new comm api in place which can provide the ability for all USB connected devices to have drivers provided as 100% java for all non-timing critical types of device interfaces. The JVM provider should have an SPI to write to which will enable them to abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into something that we can talk 100% java to. That's my big desire. Starting with something simple which gives a good start in that direction would be great! Gregg Wonderly From pascal at quies.net Sat Jul 22 11:32:03 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 19:32:03 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44C25370.9070506@cox.net> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> Message-ID: <200607221932.04194.pascal@quies.net> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: > >Pascal S. de Kloe wrote: > >>> I am also not sure if > >>> the api should unify corresponding cu. and tty. ports into one single > >>> port. > >> > >> I think the API should hide low-level details like devicefiles. > > > >Not all ports have device files. It's long been my goal to add support > >for virtual serial ports, that is, serial ports on Ethernet terminal > >servers, for example integrating RFC2217. This means that the port name > >is some combination of an IP address and TCP port number. Nothing in > > /dev. > > What I think would make the most sense is a simple "device" enumeration > Server Provider Interface that would bring port objects into the JVM based > on the platform JVM providers knowledge of how to enumerate those ports. > Application writers would provide a plugin using the SPI that would codify > those devices into named entities that they are interested in. > > public interface HardwarePort { > public String getName(); > public String getHardwareID(); > public String getManufacturer(); > public List getCapabilities(); > public Object getImplementation(); > } > > public interface PortCapability { > public String getDescription(); > public CapabilityId getIdentifier(); > } > > public enum CapabilityId { > INPUT, // Can receive input > OUTPUT, // Can send output > ASYNCHRONOUS, // Can send and receive at the same time > SYNCHRONOUS, // No synchronous I/O > ADDRESSABLE // Port has an address associated > } > > Then, you might imagine that the enumerated capabilities had a > standardized/specified interface that you'd find implemented on ports that > had such capabilities. > > The getImplementation() method would return the implementation class > provided by the JVM provider that had all of the interfaces tied to it. > > These are just some quick thoughts, pick away at them. > > I am very interested in getting a new comm api in place which can provide > the ability for all USB connected devices to have drivers provided as 100% > java for all non-timing critical types of device interfaces. > > The JVM provider should have an SPI to write to which will enable them to > abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into something > that we can talk 100% java to. > > That's my big desire. Starting with something simple which gives a good > start in that direction would be great! That was exactly my wish too. The point people brought up was: 1) It's too complex. 2) What does it solve? In both facts they are right. It'll take a *long* time to plan such a thing right but if it works you have a product. Anyway, I'd like to join. ;) From joachim at buechse.de Sat Jul 22 11:37:11 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 22 Jul 2006 19:37:11 +0200 Subject: [Rxtx] Strange error (show stopper) Message-ID: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> I just discovered a strange error in RXTX on OSX. SerialDemo.java manages to corrupt the event_info_structure by a simple OpenPort,ClosePort - this could be in relation to the deadlock problem that was reported recently. Could anyone try to reproduce this on Solaris or some other system which is neither WIN32 nor Linux (ie which uses a drain thread). In SerialImp.c : RXTXPort(interruptEventLoop) Apparently the event_info_structure gets corrupted shortly after pthread_kill(index->drain_tid, SIGABRT); In particular, the index->closing flag gets overwritten by a pointer value. **** Adding the following debugging code: pthread_kill(index->drain_tid, SIGABRT); sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i \n", index->fd, index, index->closing ); report( message ); /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ usleep(50 * 1000); sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i \n", index->fd, index, index->closing ); report( message ); **** gives me: 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 drain_loop: received EINTR------------------ drain_loop exiting --------------------- entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 eventLoop: got interrupt 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 **** Modifying SerialImp.h : event_info_struct by moving the prev*, next* pointers jmethodID checkMonitorThread; struct event_info_struct *dummy, *dummy2; fd_set rfds; struct timeval tv_sleep; int closing; struct event_info_struct *next, *prev; *** (ie replacing their original position with dummys and moving them *** behind the closing flag) results in this: 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 drain_loop: received EINTR------------------ drain_loop exiting --------------------- entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 eventLoop: got interrupt 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 *** I was not able to track down the problem. If anyone could check wether this happens on other platforms as well, we may get closer to a fix. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich From joachim at buechse.de Sat Jul 22 11:46:35 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 22 Jul 2006 19:46:35 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607221932.04194.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> Message-ID: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> It seems that Gregg's suggestion could be implemented without changing the existing "user-level" API of javax.comm. Most of the information suggested for HardwarePort is not accessible from within the POSSIX-API but this is a different story. It is clear that javax.comm can never provide a way to talk to all USB devices, simply because some USB devices have several endpoints. But it could provide a means of talking to devices that function as a bidirectional-pipe (ie any USB to serial bridge). Regards, Joachim On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>> Pascal S. de Kloe wrote: >>>>> I am also not sure if >>>>> the api should unify corresponding cu. and tty. ports into one >>>>> single >>>>> port. >>>> >>>> I think the API should hide low-level details like devicefiles. >>> >>> Not all ports have device files. It's long been my goal to add >>> support >>> for virtual serial ports, that is, serial ports on Ethernet terminal >>> servers, for example integrating RFC2217. This means that the >>> port name >>> is some combination of an IP address and TCP port number. >>> Nothing in >>> /dev. >> >> What I think would make the most sense is a simple "device" >> enumeration >> Server Provider Interface that would bring port objects into the >> JVM based >> on the platform JVM providers knowledge of how to enumerate those >> ports. >> Application writers would provide a plugin using the SPI that >> would codify >> those devices into named entities that they are interested in. >> >> public interface HardwarePort { >> public String getName(); >> public String getHardwareID(); >> public String getManufacturer(); >> public List getCapabilities(); >> public Object getImplementation(); >> } >> >> public interface PortCapability { >> public String getDescription(); >> public CapabilityId getIdentifier(); >> } >> >> public enum CapabilityId { >> INPUT, // Can receive input >> OUTPUT, // Can send output >> ASYNCHRONOUS, // Can send and receive at the same time >> SYNCHRONOUS, // No synchronous I/O >> ADDRESSABLE // Port has an address associated >> } >> >> Then, you might imagine that the enumerated capabilities had a >> standardized/specified interface that you'd find implemented on >> ports that >> had such capabilities. >> >> The getImplementation() method would return the implementation class >> provided by the JVM provider that had all of the interfaces tied >> to it. >> >> These are just some quick thoughts, pick away at them. >> >> I am very interested in getting a new comm api in place which can >> provide >> the ability for all USB connected devices to have drivers provided >> as 100% >> java for all non-timing critical types of device interfaces. >> >> The JVM provider should have an SPI to write to which will enable >> them to >> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >> something >> that we can talk 100% java to. >> >> That's my big desire. Starting with something simple which gives >> a good >> start in that direction would be great! > > That was exactly my wish too. > > The point people brought up was: > 1) It's too complex. > 2) What does it solve? > > In both facts they are right. It'll take a *long* time to plan such > a thing > right but if it works you have a product. Anyway, I'd like to join. ;) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Jul 22 11:55:23 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 22 Jul 2006 14:55:23 -0300 Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: <44C2668B.5080703@gmail.com> Joachim Buechse escribi?: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. > > It is clear that javax.comm can never provide a way to talk to all > USB devices, simply because some USB devices have several endpoints. > But it could provide a means of talking to devices that function as a > bidirectional-pipe (ie any USB to serial bridge). > > Regards, > Joachim Hi, About USB, why do not we contact the guys that make a library to support USB under Java from Linux? I think there is all ready an JSR for USB access, what we could do to this JSR is help to implement Usb access from other OSes. Regards, Manuel > > On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > >> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>> Pascal S. de Kloe wrote: >>>>>> I am also not sure if >>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>> single >>>>>> port. >>>>> I think the API should hide low-level details like devicefiles. >>>> Not all ports have device files. It's long been my goal to add >>>> support >>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>> servers, for example integrating RFC2217. This means that the >>>> port name >>>> is some combination of an IP address and TCP port number. >>>> Nothing in >>>> /dev. >>> What I think would make the most sense is a simple "device" >>> enumeration >>> Server Provider Interface that would bring port objects into the >>> JVM based >>> on the platform JVM providers knowledge of how to enumerate those >>> ports. >>> Application writers would provide a plugin using the SPI that >>> would codify >>> those devices into named entities that they are interested in. >>> >>> public interface HardwarePort { >>> public String getName(); >>> public String getHardwareID(); >>> public String getManufacturer(); >>> public List getCapabilities(); >>> public Object getImplementation(); >>> } >>> >>> public interface PortCapability { >>> public String getDescription(); >>> public CapabilityId getIdentifier(); >>> } >>> >>> public enum CapabilityId { >>> INPUT, // Can receive input >>> OUTPUT, // Can send output >>> ASYNCHRONOUS, // Can send and receive at the same time >>> SYNCHRONOUS, // No synchronous I/O >>> ADDRESSABLE // Port has an address associated >>> } >>> >>> Then, you might imagine that the enumerated capabilities had a >>> standardized/specified interface that you'd find implemented on >>> ports that >>> had such capabilities. >>> >>> The getImplementation() method would return the implementation class >>> provided by the JVM provider that had all of the interfaces tied >>> to it. >>> >>> These are just some quick thoughts, pick away at them. >>> >>> I am very interested in getting a new comm api in place which can >>> provide >>> the ability for all USB connected devices to have drivers provided >>> as 100% >>> java for all non-timing critical types of device interfaces. >>> >>> The JVM provider should have an SPI to write to which will enable >>> them to >>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>> something >>> that we can talk 100% java to. >>> >>> That's my big desire. Starting with something simple which gives >>> a good >>> start in that direction would be great! >> That was exactly my wish too. >> >> The point people brought up was: >> 1) It's too complex. >> 2) What does it solve? >> >> In both facts they are right. It'll take a *long* time to plan such >> a thing >> right but if it works you have a product. Anyway, I'd like to join. ;) >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Sat Jul 22 11:58:00 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Sat, 22 Jul 2006 13:58:00 -0400 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> Message-ID: <41E45C85-4A22-4C5B-915F-62ED36BACCF2@sympatico.ca> A couple of questions: - what version are you using? - does this happen with the version in cvs? Andre On 22-Jul-06, at 13:37 , Joachim Buechse wrote: > I just discovered a strange error in RXTX on OSX. SerialDemo.java > manages to corrupt the event_info_structure by a simple > OpenPort,ClosePort - this could be in relation to the deadlock > problem that was reported recently. > > Could anyone try to reproduce this on Solaris or some other system > which is neither WIN32 nor Linux (ie which uses a drain thread). > > In SerialImp.c : RXTXPort(interruptEventLoop) > > Apparently the event_info_structure gets corrupted shortly after > > pthread_kill(index->drain_tid, SIGABRT); > > In particular, the index->closing flag gets overwritten by a pointer > value. > > > **** Adding the following debugging code: > > pthread_kill(index->drain_tid, SIGABRT); > sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ > usleep(50 * 1000); > sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > > **** gives me: > > 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 > > **** Modifying SerialImp.h : event_info_struct by moving the > prev*, next* pointers > > jmethodID checkMonitorThread; > struct event_info_struct *dummy, *dummy2; > fd_set rfds; > struct timeval tv_sleep; > int closing; > struct event_info_struct *next, *prev; > > *** (ie replacing their original position with dummys and moving them > *** behind the closing flag) results in this: > > 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 > > > *** I was not able to track down the problem. If anyone could check > wether this happens on other platforms as well, we may get closer to > a fix. > > Regards, > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Paul.Klissner at Sun.COM Sat Jul 22 12:19:41 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Sat, 22 Jul 2006 11:19:41 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: <44C26C3D.8020501@sun.com> Joachim Buechse wrote: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. > > It is clear that javax.comm can never provide a way to talk to all > USB devices, simply because some USB devices have several endpoints. > But it could provide a means of talking to devices that function as a > bidirectional-pipe (ie any USB to serial bridge). If the 'back end' driver could be java as well an .so then driver's could be written using javax.usb, which is available currently for Linux. Paul > > Regards, > Joachim > > On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > >> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>> Pascal S. de Kloe wrote: >>>>>> I am also not sure if >>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>> single >>>>>> port. >>>>> I think the API should hide low-level details like devicefiles. >>>> Not all ports have device files. It's long been my goal to add >>>> support >>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>> servers, for example integrating RFC2217. This means that the >>>> port name >>>> is some combination of an IP address and TCP port number. >>>> Nothing in >>>> /dev. >>> What I think would make the most sense is a simple "device" >>> enumeration >>> Server Provider Interface that would bring port objects into the >>> JVM based >>> on the platform JVM providers knowledge of how to enumerate those >>> ports. >>> Application writers would provide a plugin using the SPI that >>> would codify >>> those devices into named entities that they are interested in. >>> >>> public interface HardwarePort { >>> public String getName(); >>> public String getHardwareID(); >>> public String getManufacturer(); >>> public List getCapabilities(); >>> public Object getImplementation(); >>> } >>> >>> public interface PortCapability { >>> public String getDescription(); >>> public CapabilityId getIdentifier(); >>> } >>> >>> public enum CapabilityId { >>> INPUT, // Can receive input >>> OUTPUT, // Can send output >>> ASYNCHRONOUS, // Can send and receive at the same time >>> SYNCHRONOUS, // No synchronous I/O >>> ADDRESSABLE // Port has an address associated >>> } >>> >>> Then, you might imagine that the enumerated capabilities had a >>> standardized/specified interface that you'd find implemented on >>> ports that >>> had such capabilities. >>> >>> The getImplementation() method would return the implementation class >>> provided by the JVM provider that had all of the interfaces tied >>> to it. >>> >>> These are just some quick thoughts, pick away at them. >>> >>> I am very interested in getting a new comm api in place which can >>> provide >>> the ability for all USB connected devices to have drivers provided >>> as 100% >>> java for all non-timing critical types of device interfaces. >>> >>> The JVM provider should have an SPI to write to which will enable >>> them to >>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>> something >>> that we can talk 100% java to. >>> >>> That's my big desire. Starting with something simple which gives >>> a good >>> start in that direction would be great! >> That was exactly my wish too. >> >> The point people brought up was: >> 1) It's too complex. >> 2) What does it solve? >> >> In both facts they are right. It'll take a *long* time to plan such >> a thing >> right but if it works you have a product. Anyway, I'd like to join. ;) >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 22 12:48:15 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 20:48:15 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607221920.20096.pascal@quies.net> References: <200607221920.20096.pascal@quies.net> Message-ID: <200607222048.16215.pascal@quies.net> http://quies.net/communicationapi.jar Fixed a few typo's and it works on Linux i386. It should also work on Windows i386. The rest is missing libParallel or more... -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 6664 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060722/5fd7c1ce/CommunicationAPI-0342.bin From Paul.Klissner at Sun.COM Sat Jul 22 12:53:12 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Sat, 22 Jul 2006 11:53:12 -0700 Subject: [Rxtx] jcp and jsr (libusb, javax.usb) In-Reply-To: <44C2668B.5080703@gmail.com> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> <44C2668B.5080703@gmail.com> Message-ID: <44C27418.1090309@sun.com> Manuel Naranjo wrote: > Joachim Buechse escribi?: >> It seems that Gregg's suggestion could be implemented without >> changing the existing "user-level" API of javax.comm. Most of the >> information suggested for HardwarePort is not accessible from within >> the POSSIX-API but this is a different story. >> >> It is clear that javax.comm can never provide a way to talk to all >> USB devices, simply because some USB devices have several endpoints. >> But it could provide a means of talking to devices that function as a >> bidirectional-pipe (ie any USB to serial bridge). >> >> Regards, >> Joachim > > Hi, > About USB, why do not we contact the guys that make a library to support > USB under Java from Linux? > I think there is all ready an JSR for USB access, what we could do to this > JSR is help to implement Usb access from other OSes. JAVAX.USB --------- javax.usb already a SourceForge project. I was Sun's rep on the expert group for JSR-80, javax.usb. I lived and breathed it for a 1.5 yrs working with spec lead from IBM on it. It's for real and the linux implementation works (not sure about the Win32 port on sourceforge). IBM even created a porting layer to simplify porting it to other platforms by implementing in Java all of the numerous 'clerical' functions of the API in Java so that the porting layer is absolutely minimal. The hardest part is managing the hotpluggable device tree topology as objects, and depending on one's platform or coding skills probably wouldn't take more than a week or two to get right. LIBUSB 1.0 (*NOT* libusb 0.1.8) ---------- There is also the native C library libusb. libusb 0.1.8 is weak, but libusb 1.0 under development holds the promise of being an extrordinarily robust C API to access USB devices through, and could definitely use some help getting people to port it to other platforms. I've attached the proposed libusb 1.0 API header which Sun worked with Johannes on for months before he went off into oblivion. The API has stalled and a fire might need to be lit under Johannes or it might need to be forked to get it moving again, but the spec for 1.0 is awesome, and this puppy is ready to turn into something sweet with some fresh blood on it. And it is a really good technology to become aquainted with... hint hint. Both of those APIs are really excellent and hold great promise for the community and use of USB technology in general. One of my goals, now which competes for my time with other higher priority projects was to layer an implementation of javax.usb over libusb 1.0, so that javax.usb would follow libusb to any platform and only one port would be required. But since libusb 1.0 is moving slowly, largely because the current sourceforge gatekeeper for the project, Johannes Erdfelt's lack of energy and sparse communication, it might be faster to simply port javax.usb to Mac OS, Win, Solaris and BSD if some people could get behind those, unless someone want's to get behind making libusb happen. >>>> >>>> public enum CapabilityId { >>>> INPUT, // Can receive input >>>> OUTPUT, // Can send output >>>> ASYNCHRONOUS, // Can send and receive at the same time >>>> SYNCHRONOUS, // No synchronous I/O >>>> ADDRESSABLE // Port has an address associated >>>> } My understanding is that synchronous/asynchronous refers to the way the data is clocked. I think FULLDUPLEX/HALFDUPLEX is what the author meant, or needs to be added. Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: libusb.h Type: text/x-sun-h-file Size: 26696 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060722/4a43e034/libusb-0342.bin From pascal at quies.net Sat Jul 22 17:53:31 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 01:53:31 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> References: <44C252BF.6040404@cox.net> <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> Message-ID: <200607230153.32328.pascal@quies.net> Hi Joachim, I'm not getting it. How do you easily get a "stub method / flag"? Op zaterdag 22 juli 2006 19:17, schreef Joachim Buechse: > We could easily have a stub method / flag that allows you to > explicitly load the native library (via System.loadLibrary ie from > the java.library.path). In this case the "auto-extraction" would not > take place. > > On 22.07.2006, at 18:30, Gregg Wonderly wrote: > > Dr. Douglas Lyon wrote: > >> Hi All, > >> I like the idea of the native lib in a jar with other classes. > >> An alternative I did not know would work. > > > > I have several applications that run with a security policy. In these > > applications, native library loading will require an appropriate > > FilePermission > > that should be known about ahead of time. The current native library > > implementation will require the native library to be extracted from > > the jar and > > written to disk, requiring a FilePermission("...","write") for that > > file, and > > then will also require read access to load the library. I > > personally don't want > > to give write access to a JVM for a shared library which can > > provide a point of > > abuse by errant code. > > > > Gregg Wonderly > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat Jul 22 18:46:33 2006 From: jredman at ergotech.com (Jim Redman) Date: Sat, 22 Jul 2006 18:46:33 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44C26C3D.8020501@sun.com> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> <44C26C3D.8020501@sun.com> Message-ID: <44C2C6E9.8020408@ergotech.com> Paul, I think that you've already proposed a "pluggable" underlying architecture and I think that this might be better implemented there. If you need some more examples, I'd like to have a Bluetooth interface (with dynamic discovery). Jim Paul Klissner wrote: > Joachim Buechse wrote: >> It seems that Gregg's suggestion could be implemented without >> changing the existing "user-level" API of javax.comm. Most of the >> information suggested for HardwarePort is not accessible from within >> the POSSIX-API but this is a different story. >> >> It is clear that javax.comm can never provide a way to talk to all >> USB devices, simply because some USB devices have several endpoints. >> But it could provide a means of talking to devices that function as a >> bidirectional-pipe (ie any USB to serial bridge). > > If the 'back end' driver could be java as well an .so > then driver's could be written using javax.usb, which > is available currently for Linux. > > Paul > > > >> Regards, >> Joachim >> >> On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: >> >>> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>>> Pascal S. de Kloe wrote: >>>>>>> I am also not sure if >>>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>>> single >>>>>>> port. >>>>>> I think the API should hide low-level details like devicefiles. >>>>> Not all ports have device files. It's long been my goal to add >>>>> support >>>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>>> servers, for example integrating RFC2217. This means that the >>>>> port name >>>>> is some combination of an IP address and TCP port number. >>>>> Nothing in >>>>> /dev. >>>> What I think would make the most sense is a simple "device" >>>> enumeration >>>> Server Provider Interface that would bring port objects into the >>>> JVM based >>>> on the platform JVM providers knowledge of how to enumerate those >>>> ports. >>>> Application writers would provide a plugin using the SPI that >>>> would codify >>>> those devices into named entities that they are interested in. >>>> >>>> public interface HardwarePort { >>>> public String getName(); >>>> public String getHardwareID(); >>>> public String getManufacturer(); >>>> public List getCapabilities(); >>>> public Object getImplementation(); >>>> } >>>> >>>> public interface PortCapability { >>>> public String getDescription(); >>>> public CapabilityId getIdentifier(); >>>> } >>>> >>>> public enum CapabilityId { >>>> INPUT, // Can receive input >>>> OUTPUT, // Can send output >>>> ASYNCHRONOUS, // Can send and receive at the same time >>>> SYNCHRONOUS, // No synchronous I/O >>>> ADDRESSABLE // Port has an address associated >>>> } >>>> >>>> Then, you might imagine that the enumerated capabilities had a >>>> standardized/specified interface that you'd find implemented on >>>> ports that >>>> had such capabilities. >>>> >>>> The getImplementation() method would return the implementation class >>>> provided by the JVM provider that had all of the interfaces tied >>>> to it. >>>> >>>> These are just some quick thoughts, pick away at them. >>>> >>>> I am very interested in getting a new comm api in place which can >>>> provide >>>> the ability for all USB connected devices to have drivers provided >>>> as 100% >>>> java for all non-timing critical types of device interfaces. >>>> >>>> The JVM provider should have an SPI to write to which will enable >>>> them to >>>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>>> something >>>> that we can talk 100% java to. >>>> >>>> That's my big desire. Starting with something simple which gives >>>> a good >>>> start in that direction would be great! >>> That was exactly my wish too. >>> >>> The point people brought up was: >>> 1) It's too complex. >>> 2) What does it solve? >>> >>> In both facts they are right. It'll take a *long* time to plan such >>> a thing >>> right but if it works you have a product. Anyway, I'd like to join. ;) >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From lyon at docjava.com Sun Jul 23 04:27:22 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 06:27:22 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607222048.16215.pascal@quies.net> References: <200607221920.20096.pascal@quies.net> <200607222048.16215.pascal@quies.net> Message-ID: The Class.forName is a static method. Therefore myClass.forName Should be Class.forName and myClass becomes an unused parameter. - DL >http://quies.net/communicationapi.jar > >Fixed a few typo's and it works on Linux i386. It should also work on Windows >i386. The rest is missing libParallel or more... > > >Attachment converted: PowerBookHd:CommunicationAPI 1.java >(TEXT/ttxt) (001C1A15) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Jul 23 04:32:45 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 06:32:45 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607222048.16215.pascal@quies.net> References: <200607221920.20096.pascal@quies.net> <200607222048.16215.pascal@quies.net> Message-ID: Also, the is Java2 check does not check if you are running under jdk1.5 - DL >http://quies.net/communicationapi.jar > >Fixed a few typo's and it works on Linux i386. It should also work on Windows >i386. The rest is missing libParallel or more... > > >Attachment converted: PowerBookHd:CommunicationAPI 1.java >(TEXT/ttxt) (001C1A15) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Jul 23 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 06:54:12 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607221843.27765.pascal@quies.net> References: <44C252BF.6040404@cox.net> <200607221843.27765.pascal@quies.net> Message-ID: Hi All, Perhaps Java web start can address Gregg's concerns. The native libs are placed into a signed jar for distribution. As to the assertion that serial-port based programs need file io abilities, that seems true, to me. Particularly for /dev/ttyN type native libs or libs that use lock files. The question of how to obtain a signed application that is given file-io authority may be settled by using a signing technology. Even applets can be signed, to enable improved access to the file system. What else can we try? Any ideas? Thanks! - Doug >Op zaterdag 22 juli 2006 18:30, schreef Gregg Wonderly: >> Dr. Douglas Lyon wrote: >> > Hi All, >> > I like the idea of the native lib in a jar with other classes. >> > An alternative I did not know would work. >> >> I have several applications that run with a security policy. In these >> applications, native library loading will require an appropriate >> FilePermission that should be known about ahead of time. The current >> native library implementation will require the native library to be >> extracted from the jar and written to disk, requiring a >> FilePermission("...","write") for that file, and then will also require >> read access to load the library. I personally don't want to give write >> access to a JVM for a shared library which can provide a point of abuse by >> errant code. >> >> Gregg Wonderly > >That's indeed a pitty limitation. It creates a lot of possible exceptions too. > >On the other hand, any native lib passes the securiy model. Applications who >can access hardware ports can be expected to create files, right? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 04:57:33 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 12:57:33 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607222048.16215.pascal@quies.net> Message-ID: <200607231257.34284.pascal@quies.net> Op zondag 23 juli 2006 12:27, schreef Dr. Douglas Lyon: > The Class.forName is a static method. Therefore > myClass.forName Should be Class.forName and > myClass becomes an unused parameter. > - DL Thank you. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 6625 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060723/00f3b627/CommunicationAPI-0342.bin From pascal at quies.net Sun Jul 23 05:02:59 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 13:02:59 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607222048.16215.pascal@quies.net> Message-ID: <200607231302.59252.pascal@quies.net> Op zondag 23 juli 2006 12:32, schreef Dr. Douglas Lyon: > Also, the is Java2 check does not check if you are running under > jdk1.5 > - DL Could you please explain? The JDK 1.5 will pass the check just fine. From lyon at docjava.com Sun Jul 23 05:34:10 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 07:34:10 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607221854.13467.pascal@quies.net> References: <200607221506.07140.pascal@quies.net> <200607221854.13467.pascal@quies.net> Message-ID: Hi All, Please call me Doug (the Dr. is for the classroom). Thanks! - Doug >Hi Dr., > >We're both trying to do the same thing. > >The CommunicationAPI does not only look at the OS but it also indexes the >available hardware architectures and does not need OsUtils. Any Java 2 >runtime will do. > >The plan was to make a single JAR with the binaries for all supported >platforms, the RXTX gnu.io package and the javax.comm wrapers. > >A signed version would be nice. > >A few questions remain tough. Does anybody know how Sun uses the SunOS and >Solaris identifiers for the Java property os.name? > > > >Op zaterdag 22 juli 2006 16:06, schreef Dr. Douglas Lyon: >> Hi All, >> Here is how I have arranged my signed versions of the native >> binaries: >> http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/windows/native.j >>ar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/native.jar >> http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/linux/native.jar >> >> Then I do: >> public static URL getResourceUrl() throws MalformedURLException { >> String rxtxUrl = "http://show.docjava.com:8086/" + >> "book/cgij/code/jnlp/libs/rxtx/"; >> if (OsUtils.isLinux()) >> return new URL(rxtxUrl + "linux/native.jar"); >> if (OsUtils.isMacOs()) >> return new URL(rxtxUrl + "mac/native.jar"); >> if (OsUtils.isWindows()) >> return new URL(rxtxUrl + "windows/native.jar"); >> System.out.println("no automatic install supported for this >> platform. " + >> "Please e-mail lyon at docjava.com with a bug report"); >> return null; >> } >> >> My new-age NativeLibraryManger concept-thang allows you to >> write stuff like: >> >> /** >> * This method fixes the driver by beaming over >> * to the tmp directory a native.jar file. >> * The native.jar file is signed and its >> * native libs are beamed over to the user home directory >> * ~/.rxtx/
>> * Finally, the java.library.path is altered to include
>> * ~/.rxtx/ >> */ >> private static void fixDriver() { >> >> try { >> NativeLibraryManager.fixDriver(getResourceUrl(), >> NativeLibraryManager.mapLibraryName("rxtxSerial")); >> } catch (IOException e) { >> e.printStackTrace(); >> } >> } >> >> I do a lazy singleton design pattern: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public synchronized static RXTXCommDriver getInstance() { >> if (driver != null) return driver; >> if (!NativeLibraryManager.isLibInPath("rxtxSerial")) >> fixDriver(); >> if (NativeLibraryManager.isLibInPath("rxtxSerial")) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> } >> return driver; >> } >> >> I am at a cross-roads here, since a file-based distro might be preferable >> to a URL based distro. To make this really general, and to "remember" where >> the last version of a native library came from, I serialize a bean into >> user preferences >> The user can then store native libraries anywhere, remembering the location >> in the preferences. >> >> What is the general feeling about this? >> >> Thanks! >> - Doug >> >> > > Now, if you place the rxtx classes and native library in the same >> >> >> >> jar, do they both have to be in any specific place in order to be >> >> found? >> > >> >Answer: >> >> >The path to the libraries is in the form >> >> >of /native/rxtx/-/{libserial,libparallel} >> >> >so /native/rxtx/windows-i386/libserial would do. >> > >> >I'me looking for the various os.name and os.arch values right now. >> >_______________________________________________ >> >Rxtx mailing list >> >Rxtx at qbang.org >> >http://mailman.qbang.org/mailman/listinfo/rxtx > > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 06:12:33 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 14:12:33 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607221843.27765.pascal@quies.net> Message-ID: <200607231412.34078.pascal@quies.net> Op zondag 23 juli 2006 12:54, schreef Dr. Douglas Lyon: > Hi All, > Perhaps Java web start can address Gregg's concerns. > The native libs are placed into a signed jar for distribution. > As to the assertion that serial-port based programs need file io > abilities, that seems true, to me. Particularly for /dev/ttyN type > native libs or libs that use lock files. > The question of how to obtain a signed application that is given > file-io authority may be settled by using a signing technology. > > Even applets can be signed, to enable improved access to the file > system. > > What else can we try? Any ideas? It might be a good idea to use a more optimized version for youre networked applications. These native libraries are huge for some reason. Can you build a "downloader"? From lyon at docjava.com Sun Jul 23 06:46:43 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 08:46:43 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607231302.59252.pascal@quies.net> References: <200607222048.16215.pascal@quies.net> <200607231302.59252.pascal@quies.net> Message-ID: public static void main(String[] args) { System.out.println("isJava2="+System.getProperty("java.version")); } Prints out 1.5_06 on my system, but you seem to need the "1.2" to be present on the system...right? RXTX does work under 1.5, at least on my system. - DL >Op zondag 23 juli 2006 12:32, schreef Dr. Douglas Lyon: >> Also, the is Java2 check does not check if you are running under >> jdk1.5 >> - DL > >Could you please explain? >The JDK 1.5 will pass the check just fine. >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Jul 23 06:58:02 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 08:58:02 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607231412.34078.pascal@quies.net> References: <200607221843.27765.pascal@quies.net> <200607231412.34078.pascal@quies.net> Message-ID: Hi All, Yes, I do have a download, as to the question of "huge": ls -al native.jar -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar 28kbytes is not really huge, right? In fact, if you uncompress the jar, you get: -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so Which is almost 80kbytes, so the jar is 40% of the native libs size, and it is signed. At least on the Linux version, it is smaller. I did not check the other versions. And with java web start, the JNLP only downloads the native jar if it is new or changed. And it only downloads the native jar used for the target platform. Here is how the jnlp looks, FYI... addbk.JAddressBook.Main DocJava, Inc. I have been playing around with "eager" and "lazy" directives, but I can't really tell the difference. Cheers! - Doug >Op zondag 23 juli 2006 12:54, schreef Dr. Douglas Lyon: >> Hi All, >> Perhaps Java web start can address Gregg's concerns. >> The native libs are placed into a signed jar for distribution. >> As to the assertion that serial-port based programs need file io >> abilities, that seems true, to me. Particularly for /dev/ttyN type >> native libs or libs that use lock files. >> The question of how to obtain a signed application that is given >> file-io authority may be settled by using a signing technology. >> >> Even applets can be signed, to enable improved access to the file >> system. >> >> What else can we try? Any ideas? > >It might be a good idea to use a more optimized version for youre networked >applications. These native libraries are huge for some reason. >Can you build a "downloader"? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 07:53:54 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 15:53:54 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607231302.59252.pascal@quies.net> Message-ID: <200607231553.55088.pascal@quies.net> Op zondag 23 juli 2006 14:46, schreef Dr. Douglas Lyon: > public static void main(String[] args) { > System.out.println("isJava2="+System.getProperty("java.version")); > > } > Prints out 1.5_06 on my system, but you seem to need the "1.2" to be > present on the system...right? if (System.getProperty("java.version").compareTo("1.2") < 0) throw new Error("RXTX requires a Java 2 platform."); The line requires a version string of "1.2" or higher. Sun decided to name all versions since 1.2 as Java 2. (That is why there is this 2 in J2SE.) The error should never happen anyway if you compile the code with the -target 1.2 flag. From pascal at quies.net Sun Jul 23 07:55:52 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 15:55:52 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607231412.34078.pascal@quies.net> Message-ID: <200607231555.52419.pascal@quies.net> Op zondag 23 juli 2006 14:58, schreef Dr. Douglas Lyon: > Hi All, > Yes, I do have a download, as to the question of "huge": > ls -al native.jar > -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar > 28kbytes is not really huge, right? > In fact, if you uncompress the jar, you get: > -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so > -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so > Which is almost 80kbytes, so the jar is 40% of the native libs size, and > it is signed. > At least on the Linux version, it is smaller. I did not check the > other versions. > > And with java web start, the JNLP only downloads the native jar if it is > new or changed. > And it only downloads the native jar used for the target platform. > > Here is how the jnlp looks, FYI... > codebase="http://show.docjava.com:8086/book/cgij/code/jnlp/"> > > addbk.JAddressBook.Main > DocJava, Inc. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have been playing around with "eager" and "lazy" directives, > but I can't really tell the difference. > > Cheers! > - Doug That is a nice sollution. Is there a tag for the architecture too becouse now you assume i386 and that is of course not necesairy true. From joachim at buechse.de Sun Jul 23 11:17:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 23 Jul 2006 19:17:29 +0200 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <41E45C85-4A22-4C5B-915F-62ED36BACCF2@sympatico.ca> References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> <41E45C85-4A22-4C5B-915F-62ED36BACCF2@sympatico.ca> Message-ID: <0B7FC525-4C71-49E8-B652-CCF6C67B4A58@buechse.de> This happens with the versions in CVS (2.07+ and 2.17+). On 22.07.2006, at 19:58, Andr?-John Mas wrote: > A couple of questions: > - what version are you using? > - does this happen with the version in cvs? > > Andre > > On 22-Jul-06, at 13:37 , Joachim Buechse wrote: > >> I just discovered a strange error in RXTX on OSX. SerialDemo.java >> manages to corrupt the event_info_structure by a simple >> OpenPort,ClosePort - this could be in relation to the deadlock >> problem that was reported recently. >> >> Could anyone try to reproduce this on Solaris or some other system >> which is neither WIN32 nor Linux (ie which uses a drain thread). >> >> In SerialImp.c : RXTXPort(interruptEventLoop) >> >> Apparently the event_info_structure gets corrupted shortly after >> >> pthread_kill(index->drain_tid, SIGABRT); >> >> In particular, the index->closing flag gets overwritten by a pointer >> value. >> >> >> **** Adding the following debugging code: >> >> pthread_kill(index->drain_tid, SIGABRT); >> sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i >> \n", index->fd, index, index->closing ); >> report( message ); >> /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ >> usleep(50 * 1000); >> sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i >> \n", index->fd, index, index->closing ); >> report( message ); >> >> **** gives me: >> >> 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 >> drain_loop: received EINTR------------------ drain_loop exiting >> --------------------- >> entering check_tiocmget_changes >> leaving check_tiocmget_changes >> port_has_changed_fionread: change is 0 >> eventLoop: got interrupt >> 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 >> >> **** Modifying SerialImp.h : event_info_struct by moving the >> prev*, next* pointers >> >> jmethodID checkMonitorThread; >> struct event_info_struct *dummy, *dummy2; >> fd_set rfds; >> struct timeval tv_sleep; >> int closing; >> struct event_info_struct *next, *prev; >> >> *** (ie replacing their original position with dummys and moving them >> *** behind the closing flag) results in this: >> >> 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 >> drain_loop: received EINTR------------------ drain_loop exiting >> --------------------- >> entering check_tiocmget_changes >> leaving check_tiocmget_changes >> port_has_changed_fionread: change is 0 >> eventLoop: got interrupt >> 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 >> >> >> *** I was not able to track down the problem. If anyone could check >> wether this happens on other platforms as well, we may get closer to >> a fix. >> >> Regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Sun Jul 23 11:44:48 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 23 Jul 2006 19:44:48 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607230153.32328.pascal@quies.net> References: <44C252BF.6040404@cox.net> <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> <200607230153.32328.pascal@quies.net> Message-ID: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> Gregg's concern was, that extracting the library from the jar and loading it via System.load needs file access privileges. To solve this concern, all that's required is a static method/flag that triggers loading via System.loadLibrary instead (of course, then he needs to make sure, that the library is on the java.library.path). This could also be handled via a system property of course. Regards, Joachim On 23.07.2006, at 01:53, Pascal S. de Kloe wrote: > Hi Joachim, > > I'm not getting it. > How do you easily get a "stub method / flag"? > > > Op zaterdag 22 juli 2006 19:17, schreef Joachim Buechse: >> We could easily have a stub method / flag that allows you to >> explicitly load the native library (via System.loadLibrary ie from >> the java.library.path). In this case the "auto-extraction" would not >> take place. >> >> On 22.07.2006, at 18:30, Gregg Wonderly wrote: >>> Dr. Douglas Lyon wrote: >>>> Hi All, >>>> I like the idea of the native lib in a jar with other classes. >>>> An alternative I did not know would work. >>> >>> I have several applications that run with a security policy. In >>> these >>> applications, native library loading will require an appropriate >>> FilePermission >>> that should be known about ahead of time. The current native >>> library >>> implementation will require the native library to be extracted from >>> the jar and >>> written to disk, requiring a FilePermission("...","write") for that >>> file, and >>> then will also require read access to load the library. I >>> personally don't want >>> to give write access to a JVM for a shared library which can >>> provide a point of >>> abuse by errant code. >>> >>> Gregg Wonderly >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 13:34:17 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 21:34:17 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> References: <200607230153.32328.pascal@quies.net> <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> Message-ID: <200607232134.17451.pascal@quies.net> Aaah, the penny drops. I was reading it as the stub method _root_ flag like using the root of a jar as a context for java.library.path. Thanks for explaining. :) I'll build it right away. Op zondag 23 juli 2006 19:44, schreef Joachim Buechse: > Gregg's concern was, that extracting the library from the jar and > loading it via System.load needs file access privileges. To solve > this concern, all that's required is a static method/flag that > triggers loading via System.loadLibrary instead (of course, then he > needs to make sure, that the library is on the java.library.path). > This could also be handled via a system property of course. > > Regards, > Joachim > > On 23.07.2006, at 01:53, Pascal S. de Kloe wrote: > > Hi Joachim, > > > > I'm not getting it. > > How do you easily get a "stub method / flag"? > > > > Op zaterdag 22 juli 2006 19:17, schreef Joachim Buechse: > >> We could easily have a stub method / flag that allows you to > >> explicitly load the native library (via System.loadLibrary ie from > >> the java.library.path). In this case the "auto-extraction" would not > >> take place. > >> > >> On 22.07.2006, at 18:30, Gregg Wonderly wrote: > >>> Dr. Douglas Lyon wrote: > >>>> Hi All, > >>>> I like the idea of the native lib in a jar with other classes. > >>>> An alternative I did not know would work. > >>> > >>> I have several applications that run with a security policy. In > >>> these > >>> applications, native library loading will require an appropriate > >>> FilePermission > >>> that should be known about ahead of time. The current native > >>> library > >>> implementation will require the native library to be extracted from > >>> the jar and > >>> written to disk, requiring a FilePermission("...","write") for that > >>> file, and > >>> then will also require read access to load the library. I > >>> personally don't want > >>> to give write access to a JVM for a shared library which can > >>> provide a point of > >>> abuse by errant code. > >>> > >>> Gregg Wonderly > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 18:10:45 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 02:10:45 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607232134.17451.pascal@quies.net> References: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> <200607232134.17451.pascal@quies.net> Message-ID: <200607240210.45992.pascal@quies.net> Hello gentleman, The CommunicationAPI class / utility is almost ready. Could you please have a final look and give your opinion? Does anybody know how the SunOS and the Solaris os.name is used? Sun uses just sparc as the description for os.arch. Is it safe to use the 32-bit binaries? @Gregg You can extract the necessary libraries during the installation with the extractNativeLibraries method to the application directory so they get loaded automatically. Is that good enough? @Trent Would you include this class afther any possible comments in the distribution? -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 10884 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060723/d2e99122/CommunicationAPI-0341.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: PlatformNotSupportedException.java Type: text/x-java Size: 1621 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060723/d2e99122/PlatformNotSupportedException-0341.bin From lyon at docjava.com Sun Jul 23 18:14:08 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 20:14:08 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607231555.52419.pascal@quies.net> References: <200607231412.34078.pascal@quies.net> <200607231555.52419.pascal@quies.net> Message-ID: Hi All, The present JNLP distro that I use: > > >> >> > Works for Macs using G3 and G4's. I have not tested this with an i386 mac, as I do not have one. And it only works with i386 based linux... As far as architecture goes: Allows for a chip arch, and this might address your question. The real bottleneck is that you need one of everything to test a deployment, or you have to know a bunch of people (like on this list!) to do a proper test. Cheers! - Doug >Op zondag 23 juli 2006 14:58, schreef Dr. Douglas Lyon: >> Hi All, >> Yes, I do have a download, as to the question of "huge": >> ls -al native.jar >> -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar >> 28kbytes is not really huge, right? >> In fact, if you uncompress the jar, you get: >> -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so >> -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so >> Which is almost 80kbytes, so the jar is 40% of the native libs size, and >> it is signed. >> At least on the Linux version, it is smaller. I did not check the >> other versions. >> >> And with java web start, the JNLP only downloads the native jar if it is >> new or changed. >> And it only downloads the native jar used for the target platform. >> >> Here is how the jnlp looks, FYI... >> > codebase="http://show.docjava.com:8086/book/cgij/code/jnlp/"> >> >> addbk.JAddressBook.Main >> DocJava, Inc. >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > >> >> > > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> I have been playing around with "eager" and "lazy" directives, >> but I can't really tell the difference. >> >> Cheers! >> - Doug > >That is a nice sollution. > >Is there a tag for the architecture too becouse now you assume i386 and that >is of course not necesairy true. >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Sun Jul 23 10:38:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 23 Jul 2006 11:38:50 -0500 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607221843.27765.pascal@quies.net> References: <44C252BF.6040404@cox.net> <200607221843.27765.pascal@quies.net> Message-ID: <44C3A61A.3060706@cox.net> Pascal S. de Kloe wrote: > Op zaterdag 22 juli 2006 18:30, schreef Gregg Wonderly: >>I have several applications that run with a security policy. In these >>applications, native library loading will require an appropriate >>FilePermission that should be known about ahead of time. The current >>native library implementation will require the native library to be >>extracted from the jar and written to disk, requiring a >>FilePermission("...","write") for that file, and then will also require >>read access to load the library. I personally don't want to give write >>access to a JVM for a shared library which can provide a point of abuse by >>errant code. > That's indeed a pitty limitation. It creates a lot of possible exceptions too. > > On the other hand, any native lib passes the securiy model. Applications who > can access hardware ports can be expected to create files, right? The use of an appropriate security policy is a deployment time configuration. There needs to be appropriate limits that confine the software to its intended tasks. Gregg Wonderly From gergg at cox.net Sun Jul 23 10:56:39 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 23 Jul 2006 11:56:39 -0500 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607221920.20096.pascal@quies.net> <200607222048.16215.pascal@quies.net> Message-ID: <44C3AA47.4060003@cox.net> Dr. Douglas Lyon wrote: > The Class.forName is a static method. Therefore > myClass.forName Should be Class.forName and > myClass becomes an unused parameter. Or better yet, make that parameter a context classloader and call Class.forName( classname, classloader); so that the location of the codebase for loading classes can be separate from the applications classpath. Gregg Wonderly From tjarvi at qbang.org Sun Jul 23 20:26:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 20:26:04 -0600 (MDT) Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: I do not see a point of having CommAPI do much more than basic termios interfaces and possibly parallel ports. The kernels can deliver that interface just fine for USB and other types. One problem with the current implementation for USB and IrDA is hotplug. There is a HAL daemon that can send connect and disconnect events which should probably be added to a new API. Sun is also working on a HAL port for Solaris. It is hackish but I saw at the Linux symposium that it will be getting attention and improving. The point being that these events could be included not that HAL is the end of all problems. It would appear to me that anything further in USB space should be done with the/a USB API to avoid duplication of efforts. USB is only one of many low level options for termios interfaces. On Sat, 22 Jul 2006, Joachim Buechse wrote: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. > > It is clear that javax.comm can never provide a way to talk to all > USB devices, simply because some USB devices have several endpoints. > But it could provide a means of talking to devices that function as a > bidirectional-pipe (ie any USB to serial bridge). > > Regards, > Joachim > > On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > >> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>> Pascal S. de Kloe wrote: >>>>>> I am also not sure if >>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>> single >>>>>> port. >>>>> >>>>> I think the API should hide low-level details like devicefiles. >>>> >>>> Not all ports have device files. It's long been my goal to add >>>> support >>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>> servers, for example integrating RFC2217. This means that the >>>> port name >>>> is some combination of an IP address and TCP port number. >>>> Nothing in >>>> /dev. >>> >>> What I think would make the most sense is a simple "device" >>> enumeration >>> Server Provider Interface that would bring port objects into the >>> JVM based >>> on the platform JVM providers knowledge of how to enumerate those >>> ports. >>> Application writers would provide a plugin using the SPI that >>> would codify >>> those devices into named entities that they are interested in. >>> >>> public interface HardwarePort { >>> public String getName(); >>> public String getHardwareID(); >>> public String getManufacturer(); >>> public List getCapabilities(); >>> public Object getImplementation(); >>> } >>> >>> public interface PortCapability { >>> public String getDescription(); >>> public CapabilityId getIdentifier(); >>> } >>> >>> public enum CapabilityId { >>> INPUT, // Can receive input >>> OUTPUT, // Can send output >>> ASYNCHRONOUS, // Can send and receive at the same time >>> SYNCHRONOUS, // No synchronous I/O >>> ADDRESSABLE // Port has an address associated >>> } >>> >>> Then, you might imagine that the enumerated capabilities had a >>> standardized/specified interface that you'd find implemented on >>> ports that >>> had such capabilities. >>> >>> The getImplementation() method would return the implementation class >>> provided by the JVM provider that had all of the interfaces tied >>> to it. >>> >>> These are just some quick thoughts, pick away at them. >>> >>> I am very interested in getting a new comm api in place which can >>> provide >>> the ability for all USB connected devices to have drivers provided >>> as 100% >>> java for all non-timing critical types of device interfaces. >>> >>> The JVM provider should have an SPI to write to which will enable >>> them to >>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>> something >>> that we can talk 100% java to. >>> >>> That's my big desire. Starting with something simple which gives >>> a good >>> start in that direction would be great! >> >> That was exactly my wish too. >> >> The point people brought up was: >> 1) It's too complex. >> 2) What does it solve? >> >> In both facts they are right. It'll take a *long* time to plan such >> a thing >> right but if it works you have a product. Anyway, I'd like to join. ;) >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jul 23 20:31:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 20:31:45 -0600 (MDT) Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607231412.34078.pascal@quies.net> References: <200607221843.27765.pascal@quies.net> <200607231412.34078.pascal@quies.net> Message-ID: On Sun, 23 Jul 2006, Pascal S. de Kloe wrote: > Op zondag 23 juli 2006 12:54, schreef Dr. Douglas Lyon: >> Hi All, >> Perhaps Java web start can address Gregg's concerns. >> The native libs are placed into a signed jar for distribution. >> As to the assertion that serial-port based programs need file io >> abilities, that seems true, to me. Particularly for /dev/ttyN type >> native libs or libs that use lock files. >> The question of how to obtain a signed application that is given >> file-io authority may be settled by using a signing technology. >> >> Even applets can be signed, to enable improved access to the file >> system. >> >> What else can we try? Any ideas? > > It might be a good idea to use a more optimized version for youre networked > applications. These native libraries are huge for some reason. > Can you build a "downloader"? It may be that the binaries are not stripped. "strip librtxserial.so" for instance. That will remove the symbols which are not usually needed in production. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jul 23 20:49:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 20:49:16 -0600 (MDT) Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607240210.45992.pascal@quies.net> References: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> <200607232134.17451.pascal@quies.net> <200607240210.45992.pascal@quies.net> Message-ID: On Mon, 24 Jul 2006, Pascal S. de Kloe wrote: > Hello gentleman, > > The CommunicationAPI class / utility is almost ready. > Could you please have a final look and give your opinion? > > > Does anybody know how the SunOS and the Solaris os.name is used? > > Sun uses just sparc as the description for os.arch. Is it safe to use the > 32-bit binaries? > > > > @Gregg > You can extract the necessary libraries during the installation with the > extractNativeLibraries method to the application directory so they get loaded > automatically. Is that good enough? > > @Trent > Would you include this class afther any possible comments in the distribution? > Hi Pascal, It would appear to me that this is a tool for using the API, not an API. So perhaps the classname is not the best choice. The class also has a main which would not make a great deal of sense to include in the library to me. It would make a nice example for the contrib directory or a new utility directory though. Documentation of its availability in the main document could make it stand out from the other contrib files. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jul 23 21:27:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 21:27:48 -0600 (MDT) Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> Message-ID: On Sat, 22 Jul 2006, Joachim Buechse wrote: > I just discovered a strange error in RXTX on OSX. SerialDemo.java > manages to corrupt the event_info_structure by a simple > OpenPort,ClosePort - this could be in relation to the deadlock > problem that was reported recently. > > Could anyone try to reproduce this on Solaris or some other system > which is neither WIN32 nor Linux (ie which uses a drain thread). > > In SerialImp.c : RXTXPort(interruptEventLoop) > > Apparently the event_info_structure gets corrupted shortly after > > pthread_kill(index->drain_tid, SIGABRT); > > In particular, the index->closing flag gets overwritten by a pointer > value. > > > **** Adding the following debugging code: > > pthread_kill(index->drain_tid, SIGABRT); > sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ > usleep(50 * 1000); > sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > > **** gives me: > > 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 > > **** Modifying SerialImp.h : event_info_struct by moving the > prev*, next* pointers > > jmethodID checkMonitorThread; > struct event_info_struct *dummy, *dummy2; > fd_set rfds; > struct timeval tv_sleep; > int closing; > struct event_info_struct *next, *prev; > > *** (ie replacing their original position with dummys and moving them > *** behind the closing flag) results in this: > > 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 > > > *** I was not able to track down the problem. If anyone could check > wether this happens on other platforms as well, we may get closer to > a fix. > Hi Joachim Interesting. I did run many tests with that code on may OSs. To be fair, the tests are just starting to get into good shape again. I'm still tagging releases with a bit of feel and not enough process. I'll look at this some more tomorrow night. The SIGABRT was added recently as part of the close speedups. Thats from memory. I can provide the exact patch that introduced that tomorrow. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jul 23 22:22:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 22:22:26 -0600 (MDT) Subject: [Rxtx] clarification Message-ID: It should be clear that doug is the maintainer of rxtx.org now. I'll be running around very fast trying to make that easier for him but if you want something in rxtx, it is doug that does that. There are some things doug isnt very good at. He needs some help there. If he asks others for their opinion, thats his call. If he asks others for help, thats his call. This was setup to help the community. I hope everyone makes good use of it as they are now. I'm very happy with what I see but I want to make it clear that nobody should be asking me to be in rxtx. I have interests but they may not always be yours. -- Trent Jarvi tjarvi at qbang.org From guille at sms.nl Mon Jul 24 00:32:26 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Mon, 24 Jul 2006 08:32:26 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <7.0.1.0.0.20060724082455.038aa518@sms.nl> At 18:31 20/07/2006, Trent Jarvi wrote: > > PROJECT SCOPE: > > ------------- > > > > Also, we should think carefully about what the scope of > > this project would be. Should it be javax."comm" which > > handles both serial and parallel (is parallel going by the > > wayside). Should it be split into two project: > > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > > > > Should we differentiate between single-ended serial > > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > > quasi-multidrop and full multidrop busses such as > > EIA422, EIA432 and EIA485? If we really were to > > add I2C support to the API, we'd have to delve into > > the semantics more, because there could be some > > implicit decoding of the bus the API users would > > want to see. > > > >Hi Paul > >The way RXTX works, which is a fair representation of the people using the >API, is complete support for RIA232, minimal support for IEEE1284. From >what I understand, Sun was going along the same lines. If we combined >both projects, we would have half a parallel port implementation. I see >maybe 4 requests for features not in the parallel support a year. > >The other protocols should not be limited by a JSR which is going to be >focused upon serial port interests. The IEA485 hacks in RXTX along with >I2C and Raw should _not_ be considered a strong basis for extending the >API to cover these protocols. If people want to do real implementations, >they should not face a 'standard' which wasnt really focused upon their >interests. I think we understand the parallel port issues fairly well but >have not implemented many features and I don't know if we would. I agree with all of this. API requirements for I2C, SPI, etc. are very different from those for RS232/485/422. Our embedded Java platform has APIs for all of these and more and they don't share a lot apart from the fact that they all use Input/OutputStreams (and in the case of SPI you still need to cater with the fact that every time you want to read you must also write to the device.) If I was to design javax.comm from scratch, I think I would focus on serial ports exclusively (== whatever the underlying OS represents as serial ports). Even parallel is a bit out of place IMHO, although I understand it needs to stay for backwards compatibility. >So a versatile API is favorable but I do not think we have the proper >community to represent much more than Serial. Yes, I think the same. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From joachim at buechse.de Mon Jul 24 01:33:14 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 24 Jul 2006 09:33:14 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607231412.34078.pascal@quies.net> <200607231555.52419.pascal@quies.net> Message-ID: <106C7BEC-EC26-4A05-8E94-61E2C9F2A54E@buechse.de> Or you put your project on Sourceforge and use this: http://sourceforge.net/docs/compile_farm#hosts On 24.07.2006, at 02:14, Dr. Douglas Lyon wrote: > Hi All, > The present JNLP distro that I use: >>> >>> >> download="eager" /> >>> >> > > Works for Macs using G3 and G4's. I have not tested > this with an i386 mac, as I do not have one. And it only works > with i386 based linux... > > As far as architecture goes: > > > > Allows for a chip arch, and this might address your question. > > The real bottleneck is that you need one of everything to test a > deployment, > or you have to know a bunch of people (like on this list!) to do a > proper test. > > Cheers! > - Doug > > >> Op zondag 23 juli 2006 14:58, schreef Dr. Douglas Lyon: >>> Hi All, >>> Yes, I do have a download, as to the question of "huge": >>> ls -al native.jar >>> -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar >>> 28kbytes is not really huge, right? >>> In fact, if you uncompress the jar, you get: >>> -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so >>> -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so >>> Which is almost 80kbytes, so the jar is 40% of the native libs >>> size, and >>> it is signed. >>> At least on the Linux version, it is smaller. I did not check the >>> other versions. >>> >>> And with java web start, the JNLP only downloads the native jar >>> if it is >>> new or changed. >>> And it only downloads the native jar used for the target platform. >>> >>> Here is how the jnlp looks, FYI... >>> >> codebase="http://show.docjava.com:8086/book/cgij/code/ >>> jnlp/"> >>> >>> addbk.JAddressBook.Main >>> DocJava, Inc. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> download="eager" /> >>> >>> >>> >>> >>> >> download="lazy" /> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I have been playing around with "eager" and "lazy" directives, >>> but I can't really tell the difference. >>> >>> Cheers! >>> - Doug >> >> That is a nice sollution. >> >> Is there a tag for the architecture too becouse now you assume >> i386 and that >> is of course not necesairy true. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jul 24 02:13:15 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 24 Jul 2006 10:13:15 +0200 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> Message-ID: <939306BB-2AEE-4D20-906E-9A9B40C76125@buechse.de> The pthread_kill is followed by a sleep. When the sleep returns the structure is damaged. I did not find the source that overwrites the closing field - it is correctly set by the exiting drain thread. But something overwrites it afterwards. I currently believe that this existed for some time but was never seen because the previous versions did not rely on the structure to be in good shape when tearing down connections. However I may be completely wrong and it is an OSX problem. To help me find the source, it would be nice to get some indications what the 2 debug lines I suggested return on other platforms. Joachim On 24.07.2006, at 05:27, Trent Jarvi wrote: > On Sat, 22 Jul 2006, Joachim Buechse wrote: > >> I just discovered a strange error in RXTX on OSX. SerialDemo.java >> manages to corrupt the event_info_structure by a simple >> OpenPort,ClosePort - this could be in relation to the deadlock >> problem that was reported recently. >> >> Could anyone try to reproduce this on Solaris or some other system >> which is neither WIN32 nor Linux (ie which uses a drain thread). >> >> In SerialImp.c : RXTXPort(interruptEventLoop) >> >> Apparently the event_info_structure gets corrupted shortly after >> >> pthread_kill(index->drain_tid, SIGABRT); >> >> In particular, the index->closing flag gets overwritten by a pointer >> value. > > Hi Joachim > > Interesting. I did run many tests with that code on may OSs. To > be fair, > the tests are just starting to get into good shape again. I'm still > tagging releases with a bit of feel and not enough process. I'll > look at > this some more tomorrow night. > > The SIGABRT was added recently as part of the close speedups. > Thats from > memory. I can provide the exact patch that introduced that tomorrow. > > -- > Trent Jarvi > tjarvi at qbang.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Mon Jul 24 05:58:21 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 13:58:21 +0200 Subject: [Rxtx] =?iso-8859-1?q?NativeLibraryManager_-_A_general_solution_a?= =?iso-8859-1?q?n_to_old=09problem=2E?= In-Reply-To: <44C3AA47.4060003@cox.net> References: <44C3AA47.4060003@cox.net> Message-ID: <200607241358.21366.pascal@quies.net> Op zondag 23 juli 2006 18:56, schreef Gregg Wonderly: > Dr. Douglas Lyon wrote: > > The Class.forName is a static method. Therefore > > myClass.forName Should be Class.forName and > > myClass becomes an unused parameter. > > Or better yet, make that parameter a context classloader and call > > Class.forName( classname, classloader); > > so that the location of the codebase for loading classes can be separate > from the applications classpath. I agree. -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 10719 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060724/693f269d/CommunicationAPI-0341.bin From pascal at quies.net Mon Jul 24 06:05:53 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 14:05:53 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607240210.45992.pascal@quies.net> Message-ID: <200607241405.53456.pascal@quies.net> Op maandag 24 juli 2006 04:49, schreef Trent Jarvi: > > @Trent > > Would you include this class afther any possible comments in the > > distribution? > > Hi Pascal, > > It would appear to me that this is a tool for using the API, not an API. > So perhaps the classname is not the best choice. > > The class also has a main which would not make a great deal of sense to > include in the library to me. It would make a nice example for the > contrib directory or a new utility directory though. Documentation of its > availability in the main document could make it stand out from the other > contrib files. The name-change and the removal of main() would ofcourse be no problem. You really don't want to distribute binaries, huh? How can the developers of RXTX know whether it works on a machine they don't have? Anyway, I don't see anotherway to get a version of the extension "that just works" than to build my own distribution. :@ I also can't believe that nobody on this list has binaries for official supported platforms like Windows IA64 and Windows x86_64 unless the build fails on these platforms (which would be nice to know). http://java.sun.com/j2se/1.4.2/system-configurations.html http://java.sun.com/j2se/1.5.0/system-configurations.html From pascal at quies.net Mon Jul 24 06:08:45 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 14:08:45 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <106C7BEC-EC26-4A05-8E94-61E2C9F2A54E@buechse.de> References: <106C7BEC-EC26-4A05-8E94-61E2C9F2A54E@buechse.de> Message-ID: <200607241408.45956.pascal@quies.net> Op maandag 24 juli 2006 09:33, schreef Joachim Buechse: > Or you put your project on Sourceforge and use this: > > http://sourceforge.net/docs/compile_farm#hosts That's nice. :) I'll host a distribution on Sourceforge real soon. HP also has a such a facility for PA-RISC and IA64 architectures at http://www.testdrive.hp.com/ The other day I was thinking about building a big bittorrent with Qemu images for developers. The number of platforms seems impressive: http://qemu.org/status.html With each image compressed with bzip2 a clean installation of OpenBSD and FreeBSD and a Debian Woody + gmake + gcc for each Qemu platform will take about 1.5GB. From lyon at docjava.com Mon Jul 24 07:07:02 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 24 Jul 2006 09:07:02 -0400 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060724082455.038aa518@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: Hi All, There has been a lot of discussion regarding RS485. Let me see if I can summarize this, please correct me if I am wrong; I am deliberately ignoring connector and electrical issues, focusing, instead, on protocol and software issues. Also, I have never used RS485, and I don't know much about it. 1. Serial ports that claim RS232 are typically used in the data link layer of the OSI model of networking. Basically, this means that they work with a point-to-point protocol and are meant to connect two devices. 2. Within the RS232 standard there are framing bits (start and stop bits) and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. Thats' it. 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) you do it in software, not in the RS232 standard. 4. RS485 is different from RS232 in that it is in the Network Layer of the OSI model of networking. 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in a factory). RS-485 is similar to RS-422, but RS-422 allows just one driver with multiple receivers whereas RS-485 supports multiple drivers and receivers. 6. RS-485 is a serial bus with multiple nodes and thus must handle network link layer protocols. By using high-impedance receivers, you can have as many as 256 nodes. 7. The RS-485 can be implemented with RXTX in the core and a layer of software on top to handle media access control (MAC sublayer). There are also hardware converters. http://www.rs485.com/pconverters.html for example. However, some of these require software control. There is some support in the form of the Rs485.java class, in RXTX. 8. The RS-485 specification will add to the size of the JSR 9. Javax.comm specification, version 2.0 (the Real OLD version) says: This version of the Java communications API contains support for RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not mentioned. 10. DO people want to add RS485 to a new JSR? Would it make sense for the RS-485 people to speak up now? Please let me know if you think my summary is wrong. Thanks! - Doug >At 18:31 20/07/2006, Trent Jarvi wrote: >> > PROJECT SCOPE: >> > ------------- >> > >> > Also, we should think carefully about what the scope of >> > this project would be. Should it be javax."comm" which >> > handles both serial and parallel (is parallel going by the >> > wayside). Should it be split into two project: >> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >> > >> > Should we differentiate between single-ended serial >> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >> > quasi-multidrop and full multidrop busses such as >> > EIA422, EIA432 and EIA485? If we really were to >> > add I2C support to the API, we'd have to delve into >> > the semantics more, because there could be some >> > implicit decoding of the bus the API users would >> > want to see. >> > >> >>Hi Paul >> >>The way RXTX works, which is a fair representation of the people using the >>API, is complete support for RIA232, minimal support for IEEE1284. From >>what I understand, Sun was going along the same lines. If we combined >>both projects, we would have half a parallel port implementation. I see >>maybe 4 requests for features not in the parallel support a year. >> >>The other protocols should not be limited by a JSR which is going to be >>focused upon serial port interests. The IEA485 hacks in RXTX along with >>I2C and Raw should _not_ be considered a strong basis for extending the >>API to cover these protocols. If people want to do real implementations, >>they should not face a 'standard' which wasnt really focused upon their >>interests. I think we understand the parallel port issues fairly well but >>have not implemented many features and I don't know if we would. > >I agree with all of this. API requirements for I2C, SPI, etc. are very >different from those for RS232/485/422. Our embedded Java platform has >APIs for all of these and more and they don't share a lot apart from the >fact that they all use Input/OutputStreams (and in the case of SPI you >still need to cater with the fact that every time you want to read you >must also write to the device.) > >If I was to design javax.comm from scratch, I think I would focus on >serial ports exclusively (== whatever the underlying OS represents as >serial ports). Even parallel is a bit out of place IMHO, although I >understand it needs to stay for backwards compatibility. > > >>So a versatile API is favorable but I do not think we have the proper >>community to represent much more than Serial. > >Yes, I think the same. > >Guillermo >-- >Guillermo Rodriguez Garcia > >Snijder Micro Systems phone +31-493-351020 >G. Rodriguez Garcia fax +31-493-351530 >Visser 25 email guille at sms.nl >NL5751 BL Deurne >The Netherlands http://www.snijder.com > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Mon Jul 24 07:46:55 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Mon, 24 Jul 2006 10:46:55 -0300 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: <44C4CF4F.1080706@gmail.com> Doug: I do not think that RS485 is a must by now. I do think we must make a JSR to standarize a bit Serial Ports accessing. Maybe we can make a JSR just for serial ports, and then start trying with other kind of ports and make others JSR. Or try to expand our first JSR, but I trully do not know if that can be made. About other ports besides RS485, the others I2C, SPI, etc, run at a very low level, maybe too close to the processor for Java. I do not know if Java is fast enough to access this ports, even more as this ports depends directly from the architecture, the write once run every way of Java is somekind useless at this level, so I do not think this is suitable for us. Regards, Manuel > Hi All, > There has been a lot of discussion regarding RS485. > > Let me see if I can summarize this, please correct me if I am wrong; > I am deliberately ignoring connector and electrical issues, focusing, > instead, on protocol and software issues. Also, I have never used > RS485, and I don't know much about it. > > 1. Serial ports that claim RS232 are typically used in > the data link layer of the OSI model of networking. Basically, this means > that they work with a point-to-point protocol and are meant to connect two > devices. > > 2. Within the RS232 standard there are framing bits (start and stop bits) > and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. > Thats' it. > > 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) > you do it in software, not in the RS232 standard. > > 4. RS485 is different from RS232 in that it is in the Network Layer of > the OSI model of networking. > > 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > a factory). > RS-485 is similar to RS-422, but RS-422 allows just one driver with > multiple receivers whereas RS-485 supports multiple drivers and > receivers. > > 6. RS-485 is a serial bus with multiple nodes and thus must handle network > link layer protocols. By using high-impedance receivers, you can have > as many as 256 nodes. > > 7. The RS-485 can be implemented with RXTX in the core and a layer of software > on top to handle media access control (MAC sublayer). There are also > hardware converters. > http://www.rs485.com/pconverters.html for example. However, some of > these require software control. There is some support in the form of > the Rs485.java class, > in RXTX. > > 8. The RS-485 specification will add to the size of the JSR > > 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > This version of the Java communications API contains support for > RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > mentioned. > > 10. DO people want to add RS485 to a new JSR? > > Would it make sense for the RS-485 people to speak up now? > Please let me know if you think my summary is wrong. > > Thanks! > - Doug > > > > > > >> At 18:31 20/07/2006, Trent Jarvi wrote: >> >>> > PROJECT SCOPE: >>> > ------------- >>> > >>> > Also, we should think carefully about what the scope of >>> > this project would be. Should it be javax."comm" which >>> > handles both serial and parallel (is parallel going by the >>> > wayside). Should it be split into two project: >>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>> > >>> > Should we differentiate between single-ended serial >>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>> > quasi-multidrop and full multidrop busses such as >>> > EIA422, EIA432 and EIA485? If we really were to >>> > add I2C support to the API, we'd have to delve into >>> > the semantics more, because there could be some >>> > implicit decoding of the bus the API users would >>> > want to see. >>> > >>> >>> Hi Paul >>> >>> The way RXTX works, which is a fair representation of the people using the >>> API, is complete support for RIA232, minimal support for IEEE1284. From >>> what I understand, Sun was going along the same lines. If we combined >>> both projects, we would have half a parallel port implementation. I see >>> maybe 4 requests for features not in the parallel support a year. >>> >>> The other protocols should not be limited by a JSR which is going to be >>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>> I2C and Raw should _not_ be considered a strong basis for extending the >>> API to cover these protocols. If people want to do real implementations, >>> they should not face a 'standard' which wasnt really focused upon their >>> interests. I think we understand the parallel port issues fairly well but >>> have not implemented many features and I don't know if we would. >>> >> I agree with all of this. API requirements for I2C, SPI, etc. are very >> different from those for RS232/485/422. Our embedded Java platform has >> APIs for all of these and more and they don't share a lot apart from the >> fact that they all use Input/OutputStreams (and in the case of SPI you >> still need to cater with the fact that every time you want to read you >> must also write to the device.) >> >> If I was to design javax.comm from scratch, I think I would focus on >> serial ports exclusively (== whatever the underlying OS represents as >> serial ports). Even parallel is a bit out of place IMHO, although I >> understand it needs to stay for backwards compatibility. >> >> >> >>> So a versatile API is favorable but I do not think we have the proper >>> community to represent much more than Serial. >>> >> Yes, I think the same. >> >> Guillermo >> -- >> Guillermo Rodriguez Garcia >> >> Snijder Micro Systems phone +31-493-351020 >> G. Rodriguez Garcia fax +31-493-351530 >> Visser 25 email guille at sms.nl >> NL5751 BL Deurne >> The Netherlands http://www.snijder.com >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From gergg at cox.net Mon Jul 24 07:51:53 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 08:51:53 -0500 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607240210.45992.pascal@quies.net> References: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> <200607232134.17451.pascal@quies.net> <200607240210.45992.pascal@quies.net> Message-ID: <44C4D079.80609@cox.net> Pascal S. de Kloe wrote: > @Gregg > You can extract the necessary libraries during the installation with the > extractNativeLibraries method to the application directory so they get loaded > automatically. Is that good enough? If you start the JVM with -Djava.security.manager what permissions are required? Can you send me a policy that is applicable so that I can review what permissions are being required? Gregg Wonderly From gergg at cox.net Mon Jul 24 07:54:22 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 08:54:22 -0500 Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: <44C4D10E.50604@cox.net> Joachim Buechse wrote: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. Sorry for the late reply here. My intent was this. That there could be a low level port/device SPI that could be put in place once, and then overtime we could layer other APIs, including an updated javax.comm which would make use of this SPI. Gregg Wonderly From cmalan at lhar.co.za Mon Jul 24 08:04:01 2006 From: cmalan at lhar.co.za (Christo Malan) Date: Mon, 24 Jul 2006 16:04:01 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: <44C4D351.603@lhar.co.za> Hi I don't think RS-485 belong in rxtx, the scope of the spec is not wide enough as it only specify the electrical layer. Their is no data protocol recommended or defined. This mean that we have no idea when to sample for a bit, how long is a bit and how many bits before we can say new data is available. Christo Dr. Douglas Lyon wrote: > Hi All, > There has been a lot of discussion regarding RS485. > > Let me see if I can summarize this, please correct me if I am wrong; > I am deliberately ignoring connector and electrical issues, focusing, > instead, on protocol and software issues. Also, I have never used > RS485, and I don't know much about it. > > 1. Serial ports that claim RS232 are typically used in > the data link layer of the OSI model of networking. Basically, this means > that they work with a point-to-point protocol and are meant to connect two > devices. > > 2. Within the RS232 standard there are framing bits (start and stop bits) > and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. > Thats' it. > > 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) > you do it in software, not in the RS232 standard. > > 4. RS485 is different from RS232 in that it is in the Network Layer of > the OSI model of networking. > > 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > a factory). > RS-485 is similar to RS-422, but RS-422 allows just one driver with > multiple receivers whereas RS-485 supports multiple drivers and > receivers. > > 6. RS-485 is a serial bus with multiple nodes and thus must handle network > link layer protocols. By using high-impedance receivers, you can have > as many as 256 nodes. > > 7. The RS-485 can be implemented with RXTX in the core and a layer of software > on top to handle media access control (MAC sublayer). There are also > hardware converters. > http://www.rs485.com/pconverters.html for example. However, some of > these require software control. There is some support in the form of > the Rs485.java class, > in RXTX. > > 8. The RS-485 specification will add to the size of the JSR > > 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > This version of the Java communications API contains support for > RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > mentioned. > > 10. DO people want to add RS485 to a new JSR? > > Would it make sense for the RS-485 people to speak up now? > Please let me know if you think my summary is wrong. > > Thanks! > - Doug > > > > > > >> At 18:31 20/07/2006, Trent Jarvi wrote: >> >>> > PROJECT SCOPE: >>> > ------------- >>> > >>> > Also, we should think carefully about what the scope of >>> > this project would be. Should it be javax."comm" which >>> > handles both serial and parallel (is parallel going by the >>> > wayside). Should it be split into two project: >>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>> > >>> > Should we differentiate between single-ended serial >>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>> > quasi-multidrop and full multidrop busses such as >>> > EIA422, EIA432 and EIA485? If we really were to >>> > add I2C support to the API, we'd have to delve into >>> > the semantics more, because there could be some >>> > implicit decoding of the bus the API users would >>> > want to see. >>> > >>> >>> Hi Paul >>> >>> The way RXTX works, which is a fair representation of the people using the >>> API, is complete support for RIA232, minimal support for IEEE1284. From >>> what I understand, Sun was going along the same lines. If we combined >>> both projects, we would have half a parallel port implementation. I see >>> maybe 4 requests for features not in the parallel support a year. >>> >>> The other protocols should not be limited by a JSR which is going to be >>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>> I2C and Raw should _not_ be considered a strong basis for extending the >>> API to cover these protocols. If people want to do real implementations, >>> they should not face a 'standard' which wasnt really focused upon their >>> interests. I think we understand the parallel port issues fairly well but >>> have not implemented many features and I don't know if we would. >>> >> I agree with all of this. API requirements for I2C, SPI, etc. are very >> different from those for RS232/485/422. Our embedded Java platform has >> APIs for all of these and more and they don't share a lot apart from the >> fact that they all use Input/OutputStreams (and in the case of SPI you >> still need to cater with the fact that every time you want to read you >> must also write to the device.) >> >> If I was to design javax.comm from scratch, I think I would focus on >> serial ports exclusively (== whatever the underlying OS represents as >> serial ports). Even parallel is a bit out of place IMHO, although I >> understand it needs to stay for backwards compatibility. >> >> >> >>> So a versatile API is favorable but I do not think we have the proper >>> community to represent much more than Serial. >>> >> Yes, I think the same. >> >> Guillermo >> -- >> Guillermo Rodriguez Garcia >> >> Snijder Micro Systems phone +31-493-351020 >> G. Rodriguez Garcia fax +31-493-351530 >> Visser 25 email guille at sms.nl >> NL5751 BL Deurne >> The Netherlands http://www.snijder.com >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > From pascal at quies.net Mon Jul 24 08:19:03 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 16:19:03 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <44C4D079.80609@cox.net> References: <200607240210.45992.pascal@quies.net> <44C4D079.80609@cox.net> Message-ID: <200607241619.04053.pascal@quies.net> Op maandag 24 juli 2006 15:51, schreef Gregg Wonderly: > Pascal S. de Kloe wrote: > > @Gregg > > You can extract the necessary libraries during the installation with the > > extractNativeLibraries method to the application directory so they get > > loaded automatically. Is that good enough? > > If you start the JVM with -Djava.security.manager what permissions are > required? Can you send me a policy that is applicable so that I can review > what permissions are being required? Just look at the javadoc in CommunicationAPI.java for SecurityExceptions. ;) From gergg at cox.net Mon Jul 24 08:21:49 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 09:21:49 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4CF4F.1080706@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> Message-ID: <44C4D77D.5080200@cox.net> Manuel Francisco Naranjo wrote: > Doug: > I do not think that RS485 is a must by now. I do think we must make a > JSR to standarize a bit Serial Ports accessing. Maybe we can make a JSR > just for serial ports, and then start trying with other kind of ports > and make others JSR. Or try to expand our first JSR, but I trully do > not know if that can be made. I think that anyone aimed at the javax.comm space should be interested in creating a hardware access SPI first. This is the predominate stumbling block for java having access to various hardware devices. The more we can promote as a standard, the more we can expect consistency and availability! > About other ports besides RS485, the others I2C, SPI, etc, run at a very > low level, maybe too close to the processor for Java. SPI (not service provider interface) is a great protocol for disparet systems because the clocking is synchronous based on the fastest speed available at each end. This means that you can do SPI, today, in java by connecting serial port signal lines, or parallel port data lines to an SPI device, and bit banging the protocol. It won't be lightening fast, but it will be very much functional. What would make the most since is the ability for applications to designate various signalling line sources such as serial signaling lines and parallel port data lines as SPI data, slave select and clock signals, and plug those into an existing API. public class SPISlaveSelectLine { public SPISlaveSelectLine( int slave, SignalPort sp ) { ... } } public class SPIClockLine { public SPIClockLine( SignalPort sp ) { ... } } public class SPIDataLine { public SPIDataLine( SignalPort sp ) { ... } } I'd really like to see the embedded systems community take up this task and push these kinds of things forward. Having standard APIs would make it possible to run your software on aJile's AJ processors, the Muvium PIC environment, javacard, J2ME, etc. Imagine being able to plug a cellphone into the wall, attach a cable which has signalling lines and presto a remote terminal for monitoring and control. Data collection is a very needed capability as the next wave of technology evolution. The Java platform is not enabled with APIs to do this trivially yet. So, it doesn't look viable to many... Gregg Wonderly From guille at sms.nl Mon Jul 24 08:37:21 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 16:37:21 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: <1153751841.44c4db21de4bb@webmail.eatserver.nl> Hi Doug, Some comments below. Quoting "Dr. Douglas Lyon" : > Hi All, > There has been a lot of discussion regarding RS485. > > Let me see if I can summarize this, please correct me if I am wrong; > I am deliberately ignoring connector and electrical issues, focusing, > instead, on protocol and software issues. Also, I have never used > RS485, and I don't know much about it. > > 1. Serial ports that claim RS232 are typically used in > the data link layer of the OSI model of networking. Basically, this means > that they work with a point-to-point protocol and are meant to connect two > devices. It is actually physical + link (layers 1 and 2 of the OSI model), but yes, this is essentially right. > > 2. Within the RS232 standard there are framing bits (start and stop bits) > and error control bits (parity). The flow control is xon-xoff or DTR, CTS, > RTS. Thats' it. I'm not even sure that the RS232 standard talks about xon-xoff and such, I think it does not do much more than defining the electrical signals. Also note that RS232 was originally defined for the DTE-DCE interface (e.g. a device such as a modem connected to a computer). The current use of RS232 as a "general purpose" point to point link is a generalization of the RS232 standard. > > 3. If you want more than that from RS232 (forward error correction, ARQ, > etc.) > you do it in software, not in the RS232 standard. > > 4. RS485 is different from RS232 in that it is in the Network Layer of > the OSI model of networking. I would not put it that way. RS485 is very similar to RS232 with three main differences: - Only tx/rx, no extra signals such as DTR, RTS, CTS, etc (but then many "RS232" serial ports don't have them either) - Different electrical specs (which do not concern us here) - Multidrop and only one node talks at a given time (half duplex) But it does not define addresses (many RS485-based protocol use addresses for the nodes but that's not part of the RS485 standard), routing, etc. For software developers it still looks like a serial port (which it is!) except for the half-duplex part. More on this below. So RS485 is still about layers 1 and 2, same as RS232. I think all of this could be easier if we talk about UARTs instead of "RS232/RS485/RS422". All of these three are typically UARTs with some sort of buffer to get the electrical levels right: RS232 interface == UART + RS232 buffer/transceiver RS485 interface == UART + RS485 buffer/transceiver RS422 interface == UART + RS422 buffer/transceiver > > 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > a factory). > RS-485 is similar to RS-422, but RS-422 allows just one driver with > multiple receivers whereas RS-485 supports multiple drivers and > receivers. RS422 is exactly the same as RS485 except that it uses 4 wires instead of 2 wires so it can be full duplex again (but again this depends on the protocol you layer on top) > > 6. RS-485 is a serial bus with multiple nodes and thus must handle network > link layer protocols. By using high-impedance receivers, you can have > as many as 256 nodes. > > 7. The RS-485 can be implemented with RXTX in the core and a layer of > software > on top to handle media access control (MAC sublayer). There are also > hardware converters. > http://www.rs485.com/pconverters.html for example. However, some of > these require software control. There is some support in the form of > the Rs485.java class, > in RXTX. > > 8. The RS-485 specification will add to the size of the JSR > > 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > This version of the Java communications API contains support for > RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > mentioned. > > 10. DO people want to add RS485 to a new JSR? > > Would it make sense for the RS-485 people to speak up now? > Please let me know if you think my summary is wrong. Basically, for a software developer the only difference between RS485 and RS232 is the half-duplex nature of RS485, which means that you cannot receive and send at the same time. This has some implications depending on how RS485 is implemented in hardware, and on the (application) protocol defined on top of RS485. As I said, a RS485 interface is normally implemented using a standard UART plus a RS485 buffer/transceiver. RS485 buffers/transceivers can be in transmit mode or in receive mode. In a given RS485 bus, only one node should be in transmit mode at any given time, with the rest of the nodes 'listening' until it is their turn to transmit (and it is the application level protocol the one defines who should transmit next.) The RS485 chips used as buffers/transceivers normally have a control pin that is used to switch them into transmit or receive mode. There are typically three ways to handle this: 1. One of the control signals from the UART, such as RTS, DTR, etc. is connected to this control pin. The software must explicitly toggle this signal in order to switch the RS485 buffer/transceiver into transmit or receive mode. This puts a lot of burden on the software side and is sometimes unreliable because of complex timing issues as well as issues with buffering at the device driver level, but it is still a popular solution. 2. The UART itself knows about RS485 and can be configured to control the RS485 buffer/transceiver automatically, without any sort of software intervention. This is a very good solution since it is transparent to the software. However most UARTs don't know about RS485. 3. Standard UART + some custom hardware to control the direction pin. This is also transparent to the software. RS232/RS485 converters are an example of this approach. Implications for the software: For 3/ the software does not need to do anything special. For 2/ all you need is some sort of mechanism to tell the UART to enter RS485-mode (typically a ioctlex). For 1/ there is no simple solution. The timing issues make it difficult to implement this sort of mechanism in user space so it is often done at the device driver level. If this is the case, then all one needs is a mechanism to tell the driver to enter RS485-mode (again, a ioctlex). If this is NOT the case, then the application will need to take care. To do this more or less reliably, you would probably need a couple of things: - Some way to disable software buffering (and FIFOs if possible) - Some way to poll the UART's serial transmit register so that you can determine exactly when all data has been sent (many UARTs don't even support this) and switch to receive mode. - High resolution timers. - Real-time capabilities. Pretty strict requirements as you can see, which is why this approach never works very well except for very specific applications. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From naranjo.manuel at gmail.com Mon Jul 24 08:39:15 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Mon, 24 Jul 2006 11:39:15 -0300 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D77D.5080200@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> Message-ID: <44C4DB93.8080008@gmail.com> Gregg: Thanks for taking me out of the dark ;). Trully I did not know that SPI was an underlaying level of Serial ports, and Parallel ports. I give back what I said. I also would like to see my cell phone plug to every were, and be able to program it with java, is just that I do not know if we are going to get ourselves in a very almost unfinishable task. Regards, Manuel > Manuel Francisco Naranjo wrote: > >> Doug: >> I do not think that RS485 is a must by now. I do think we must make a >> JSR to standarize a bit Serial Ports accessing. Maybe we can make a JSR >> > > just for serial ports, and then start trying with other kind of ports > > and make others JSR. Or try to expand our first JSR, but I trully do > > not know if that can be made. > > I think that anyone aimed at the javax.comm space should be interested in > creating a hardware access SPI first. This is the predominate stumbling > block for java having access to various hardware devices. The more we can > promote as a standard, the more we can expect consistency and availability! > > >> About other ports besides RS485, the others I2C, SPI, etc, run at a very >> low level, maybe too close to the processor for Java. >> > > SPI (not service provider interface) is a great protocol for disparet systems > because the clocking is synchronous based on the fastest speed available at each > end. This means that you can do SPI, today, in java by connecting serial port > signal lines, or parallel port data lines to an SPI device, and bit banging the > protocol. It won't be lightening fast, but it will be very much functional. > What would make the most since is the ability for applications to designate > various signalling line sources such as serial signaling lines and parallel port > data lines as SPI data, slave select and clock signals, and plug those into an > existing API. > > public class SPISlaveSelectLine { > public SPISlaveSelectLine( int slave, SignalPort sp ) { > ... > } > } > > public class SPIClockLine { > public SPIClockLine( SignalPort sp ) { > ... > } > } > > public class SPIDataLine { > public SPIDataLine( SignalPort sp ) { > ... > } > } > > I'd really like to see the embedded systems community take up this task and push > these kinds of things forward. Having standard APIs would make it possible to > run your software on aJile's AJ processors, the Muvium PIC environment, > javacard, J2ME, etc. Imagine being able to plug a cellphone into the wall, > attach a cable which has signalling lines and presto a remote terminal for > monitoring and control. > > Data collection is a very needed capability as the next wave of technology > evolution. The Java platform is not enabled with APIs to do this trivially yet. > So, it doesn't look viable to many... > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From guille at sms.nl Mon Jul 24 08:41:21 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 16:41:21 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D351.603@lhar.co.za> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: <1153752081.44c4dc11eedf3@webmail.eatserver.nl> Quoting Christo Malan : > Hi > > I don't think RS-485 belong in rxtx, the scope of the spec is not wide > enough as it only specify the electrical layer. Their is no data > protocol recommended or defined. RS485 is exactly at the same level as RS232, no more and no less. > This mean that we have no idea when to > sample for a bit, how long is a bit and how many bits before we can say > new data is available. A "RS485 serial port" is just a UART whose output complies with the RS485 electrical spec, just as a "RS232 serial port" is just a UART whose output complies with the RS232 electrical spec. Bit times, sampling intervals, character structure etc. are the same for both protocols... Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From tjarvi at qbang.org Mon Jul 24 08:44:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 24 Jul 2006 08:44:53 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D351.603@lhar.co.za> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: A JSR/JCP would not just involve RXTX. In fact it would be very nice to have others with expertise in various areas like I2C, IrDA, RS485, RS422, ... involved. Within the RXTX community, I do not think we have enough depth to tackle RS485 alone. I'm aware of some of the low level issues but to be honest, I've never actually used it. The RS485 classes in RXTX are more like notes to myself about the issues involved without hardware solutions. In operating systems like Linux, this may be much less of an issue in the future. Linux is putting realtime patches now in the kernels which could make RS485 over EIA232 possible. This is probably the last chance RS485 has to get into a published spec for a long time though. Right now, I do not think its reasonable to include it in the process. Others could make that less of a problem. On Mon, 24 Jul 2006, Christo Malan wrote: > Hi > > I don't think RS-485 belong in rxtx, the scope of the spec is not wide > enough as it only specify the electrical layer. Their is no data > protocol recommended or defined. This mean that we have no idea when to > sample for a bit, how long is a bit and how many bits before we can say > new data is available. > > Christo > > Dr. Douglas Lyon wrote: >> Hi All, >> There has been a lot of discussion regarding RS485. >> >> Let me see if I can summarize this, please correct me if I am wrong; >> I am deliberately ignoring connector and electrical issues, focusing, >> instead, on protocol and software issues. Also, I have never used >> RS485, and I don't know much about it. >> >> 1. Serial ports that claim RS232 are typically used in >> the data link layer of the OSI model of networking. Basically, this means >> that they work with a point-to-point protocol and are meant to connect two >> devices. >> >> 2. Within the RS232 standard there are framing bits (start and stop bits) >> and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. >> Thats' it. >> >> 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) >> you do it in software, not in the RS232 standard. >> >> 4. RS485 is different from RS232 in that it is in the Network Layer of >> the OSI model of networking. >> >> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in >> a factory). >> RS-485 is similar to RS-422, but RS-422 allows just one driver with >> multiple receivers whereas RS-485 supports multiple drivers and >> receivers. >> >> 6. RS-485 is a serial bus with multiple nodes and thus must handle network >> link layer protocols. By using high-impedance receivers, you can have >> as many as 256 nodes. >> >> 7. The RS-485 can be implemented with RXTX in the core and a layer of software >> on top to handle media access control (MAC sublayer). There are also >> hardware converters. >> http://www.rs485.com/pconverters.html for example. However, some of >> these require software control. There is some support in the form of >> the Rs485.java class, >> in RXTX. >> >> 8. The RS-485 specification will add to the size of the JSR >> >> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: >> This version of the Java communications API contains support for >> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not >> mentioned. >> >> 10. DO people want to add RS485 to a new JSR? >> >> Would it make sense for the RS-485 people to speak up now? >> Please let me know if you think my summary is wrong. >> >> Thanks! >> - Doug >> >> >> >> >> >> >>> At 18:31 20/07/2006, Trent Jarvi wrote: >>> >>>> > PROJECT SCOPE: >>>> > ------------- >>>> > >>>> > Also, we should think carefully about what the scope of >>>> > this project would be. Should it be javax."comm" which >>>> > handles both serial and parallel (is parallel going by the >>>> > wayside). Should it be split into two project: >>>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>>> > >>>> > Should we differentiate between single-ended serial >>>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>>> > quasi-multidrop and full multidrop busses such as >>>> > EIA422, EIA432 and EIA485? If we really were to >>>> > add I2C support to the API, we'd have to delve into >>>> > the semantics more, because there could be some >>>> > implicit decoding of the bus the API users would >>>> > want to see. >>>> > >>>> >>>> Hi Paul >>>> >>>> The way RXTX works, which is a fair representation of the people using the >>>> API, is complete support for RIA232, minimal support for IEEE1284. From >>>> what I understand, Sun was going along the same lines. If we combined >>>> both projects, we would have half a parallel port implementation. I see >>>> maybe 4 requests for features not in the parallel support a year. >>>> >>>> The other protocols should not be limited by a JSR which is going to be >>>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>>> I2C and Raw should _not_ be considered a strong basis for extending the >>>> API to cover these protocols. If people want to do real implementations, >>>> they should not face a 'standard' which wasnt really focused upon their >>>> interests. I think we understand the parallel port issues fairly well but >>>> have not implemented many features and I don't know if we would. >>>> >>> I agree with all of this. API requirements for I2C, SPI, etc. are very >>> different from those for RS232/485/422. Our embedded Java platform has >>> APIs for all of these and more and they don't share a lot apart from the >>> fact that they all use Input/OutputStreams (and in the case of SPI you >>> still need to cater with the fact that every time you want to read you >>> must also write to the device.) >>> >>> If I was to design javax.comm from scratch, I think I would focus on >>> serial ports exclusively (== whatever the underlying OS represents as >>> serial ports). Even parallel is a bit out of place IMHO, although I >>> understand it needs to stay for backwards compatibility. >>> >>> >>> >>>> So a versatile API is favorable but I do not think we have the proper >>>> community to represent much more than Serial. >>>> >>> Yes, I think the same. >>> >>> Guillermo >>> -- >>> Guillermo Rodriguez Garcia >>> >>> Snijder Micro Systems phone +31-493-351020 >>> G. Rodriguez Garcia fax +31-493-351530 >>> Visser 25 email guille at sms.nl >>> NL5751 BL Deurne >>> The Netherlands http://www.snijder.com >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From guille at sms.nl Mon Jul 24 08:47:47 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 16:47:47 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D77D.5080200@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> Message-ID: <1153752467.44c4dd93c08f7@webmail.eatserver.nl> Hi Gregg, Quoting Gregg Wonderly : > SPI (not service provider interface) is a great protocol for disparet systems > > because the clocking is synchronous based on the fastest speed available at > each > end. This means that you can do SPI, today, in java by connecting serial > port > signal lines, or parallel port data lines to an SPI device, and bit banging > the > protocol. It won't be lightening fast, but it will be very much functional. [...] > I'd really like to see the embedded systems community take up this task and > push > these kinds of things forward. Having standard APIs would make it possible > to > run your software on aJile's AJ processors, the Muvium PIC environment, > javacard, J2ME, etc. Imagine being able to plug a cellphone into the wall, > attach a cable which has signalling lines and presto a remote terminal for > monitoring and control. As an embedded Java vendor, SNIJDER Micro Systems certainly sees the value of standardized APIs to talk to different types of communication buses including SPI, I2C, 1-Wire, etc., for embedded applications. However we think this has nothing to do with javax.comm. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From guille at sms.nl Mon Jul 24 09:05:22 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 17:05:22 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4DB93.8080008@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <44C4DB93.8080008@gmail.com> Message-ID: <1153753522.44c4e1b24f2e1@webmail.eatserver.nl> Quoting Manuel Francisco Naranjo : > Gregg: > Thanks for taking me out of the dark ;). Trully I did not know that SPI > was an underlaying level of Serial ports, and Parallel ports. In fact it isn't; it is just another serial protocol, just like I2C. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From jredman at ergotech.com Mon Jul 24 09:29:10 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 09:29:10 -0600 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: <44C4E746.8070808@ergotech.com> Folks, The RS232/485/422/etc. etc. is a complete red herring (http://en.wikipedia.org/wiki/Red_herring in case you don't know the expression). The differences between the two are at the electrical level, not at the RXTX level. I'll provide a concrete example and see if we can get away from this issue. There's an industrial serial communications standard - Modbus. Modbus capable devices are very common and can be purchased, generally, with an RS232 or a 485 or a 422 - you decide when you buy it. Some actually provide both 232 and 485 on the same connector. Now, within our environment you configure a Modbus JavaBean. One of the parameters is the "Station Number". The station number is required for both RS232 and RS485 devices - the protocol doesn't change based on the electrical requirements of the device. Now I can configure an application talking to, say, station 2 and station 7. I can add an RS485 converter to the computer serial port and put two physical devices there, configured as station 2 and station 7 and everything works fine. HOWEVER, over RS232 some devices will respond to both station 2 and station 7. So THE SAME APPLICATION will work with both 232 and 485. The only changes are hardware related. This same behavior is true of a number of 485 "networks" and many industrial devices that have 485 interfaces have 232 as an option using the same protocol. Jim Trent Jarvi wrote: > A JSR/JCP would not just involve RXTX. In fact it would be very nice to > have others with expertise in various areas like I2C, IrDA, RS485, RS422, > ... involved. > > Within the RXTX community, I do not think we have enough depth to tackle > RS485 alone. I'm aware of some of the low level issues but to be honest, > I've never actually used it. The RS485 classes in RXTX are more like > notes to myself about the issues involved without hardware solutions. In > operating systems like Linux, this may be much less of an issue in the > future. Linux is putting realtime patches now in the kernels which could > make RS485 over EIA232 possible. > > This is probably the last chance RS485 has to get into a published spec > for a long time though. Right now, I do not think its reasonable to > include it in the process. Others could make that less of a problem. > > On Mon, 24 Jul 2006, Christo Malan wrote: > >> Hi >> >> I don't think RS-485 belong in rxtx, the scope of the spec is not wide >> enough as it only specify the electrical layer. Their is no data >> protocol recommended or defined. This mean that we have no idea when to >> sample for a bit, how long is a bit and how many bits before we can say >> new data is available. >> >> Christo >> >> Dr. Douglas Lyon wrote: >>> Hi All, >>> There has been a lot of discussion regarding RS485. >>> >>> Let me see if I can summarize this, please correct me if I am wrong; >>> I am deliberately ignoring connector and electrical issues, focusing, >>> instead, on protocol and software issues. Also, I have never used >>> RS485, and I don't know much about it. >>> >>> 1. Serial ports that claim RS232 are typically used in >>> the data link layer of the OSI model of networking. Basically, this means >>> that they work with a point-to-point protocol and are meant to connect two >>> devices. >>> >>> 2. Within the RS232 standard there are framing bits (start and stop bits) >>> and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. >>> Thats' it. >>> >>> 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) >>> you do it in software, not in the RS232 standard. >>> >>> 4. RS485 is different from RS232 in that it is in the Network Layer of >>> the OSI model of networking. >>> >>> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in >>> a factory). >>> RS-485 is similar to RS-422, but RS-422 allows just one driver with >>> multiple receivers whereas RS-485 supports multiple drivers and >>> receivers. >>> >>> 6. RS-485 is a serial bus with multiple nodes and thus must handle network >>> link layer protocols. By using high-impedance receivers, you can have >>> as many as 256 nodes. >>> >>> 7. The RS-485 can be implemented with RXTX in the core and a layer of software >>> on top to handle media access control (MAC sublayer). There are also >>> hardware converters. >>> http://www.rs485.com/pconverters.html for example. However, some of >>> these require software control. There is some support in the form of >>> the Rs485.java class, >>> in RXTX. >>> >>> 8. The RS-485 specification will add to the size of the JSR >>> >>> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: >>> This version of the Java communications API contains support for >>> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not >>> mentioned. >>> >>> 10. DO people want to add RS485 to a new JSR? >>> >>> Would it make sense for the RS-485 people to speak up now? >>> Please let me know if you think my summary is wrong. >>> >>> Thanks! >>> - Doug >>> >>> >>> >>> >>> >>> >>>> At 18:31 20/07/2006, Trent Jarvi wrote: >>>> >>>>>> PROJECT SCOPE: >>>>>> ------------- >>>>>> >>>>>> Also, we should think carefully about what the scope of >>>>>> this project would be. Should it be javax."comm" which >>>>>> handles both serial and parallel (is parallel going by the >>>>>> wayside). Should it be split into two project: >>>>>> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>>>>> >>>>>> Should we differentiate between single-ended serial >>>>>> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>>>>> quasi-multidrop and full multidrop busses such as >>>>>> EIA422, EIA432 and EIA485? If we really were to >>>>>> add I2C support to the API, we'd have to delve into >>>>>> the semantics more, because there could be some >>>>>> implicit decoding of the bus the API users would >>>>>> want to see. >>>>>> >>>>> Hi Paul >>>>> >>>>> The way RXTX works, which is a fair representation of the people using the >>>>> API, is complete support for RIA232, minimal support for IEEE1284. From >>>>> what I understand, Sun was going along the same lines. If we combined >>>>> both projects, we would have half a parallel port implementation. I see >>>>> maybe 4 requests for features not in the parallel support a year. >>>>> >>>>> The other protocols should not be limited by a JSR which is going to be >>>>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>>>> I2C and Raw should _not_ be considered a strong basis for extending the >>>>> API to cover these protocols. If people want to do real implementations, >>>>> they should not face a 'standard' which wasnt really focused upon their >>>>> interests. I think we understand the parallel port issues fairly well but >>>>> have not implemented many features and I don't know if we would. >>>>> >>>> I agree with all of this. API requirements for I2C, SPI, etc. are very >>>> different from those for RS232/485/422. Our embedded Java platform has >>>> APIs for all of these and more and they don't share a lot apart from the >>>> fact that they all use Input/OutputStreams (and in the case of SPI you >>>> still need to cater with the fact that every time you want to read you >>>> must also write to the device.) >>>> >>>> If I was to design javax.comm from scratch, I think I would focus on >>>> serial ports exclusively (== whatever the underlying OS represents as >>>> serial ports). Even parallel is a bit out of place IMHO, although I >>>> understand it needs to stay for backwards compatibility. >>>> >>>> >>>> >>>>> So a versatile API is favorable but I do not think we have the proper >>>>> community to represent much more than Serial. >>>>> >>>> Yes, I think the same. >>>> >>>> Guillermo >>>> -- >>>> Guillermo Rodriguez Garcia >>>> >>>> Snijder Micro Systems phone +31-493-351020 >>>> G. Rodriguez Garcia fax +31-493-351530 >>>> Visser 25 email guille at sms.nl >>>> NL5751 BL Deurne >>>> The Netherlands http://www.snijder.com >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From jredman at ergotech.com Mon Jul 24 09:50:21 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 09:50:21 -0600 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D77D.5080200@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> Message-ID: <44C4EC3D.6010204@ergotech.com> Jim, How about we go back to basics and define a serial port. Under Java, I can open /dev/ttyS0, COM1:, etc and read/write a serial port. So what does RXTX bring to the table? If we can define what we need from the product at a high level (functional spec.) then we can look at what's wrong underneath (design requirements). I can do this fairly easily. Functionally, I want support for SerialPort - a superset of that would be fine. SerialPort provides an abstraction that provides everything I need for accessing serial devices. At the design level, I'd like a "pluggable" architecture. That is, I'd like to able to accommodate anything that it makes sense to implement in terms of the SerialPort interface. An obvious plugin is one that supports the current RXTX serial port access - through device files. But _I'd_ like a plugin for serial ports over Ethernet, serial ports over BlueTooth (including discovery), etc. I'm sure others could think of modules they'd like i2c, SPI, etc. etc. I'm not sure that ANY of these should be part of the spec. although perhaps the device file based version could be part of a reference implementation. I don't know that this is really much different from the existing architecture. I doubt that much code could be shared between, for example, a BlueTooth serial port and a /dev/ttyS0 serial port, but perhaps those more familiar with the code could comment. I suspect some cleanup of registration, etc. would be needed to formalize plugins, but I doubt it's too great. Some time ago I learnt the definition of a "Goal". It should be concrete, winnable and build unity. So, I have laid out a concrete goal, build to a superset of the SerialPort interface, it's winnable because it's not a complete rewrite of RXTX and it builds unity because anyone's pet electrical specification can be added. A simplistic view, tell me where I went wrong. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From lyon at docjava.com Mon Jul 24 10:06:40 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 24 Jul 2006 12:06:40 -0400 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4E746.8070808@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> Message-ID: >Hi All, Wow, what an informed and interesting debate from my most innocent and well-intentioned of e-mails. I must say that I am learning a great deal from this list! When I speak about RS232 I wanted to focus on the protocol, not the connector shape or pin-out or electrical issues. Issues like that are addressed by the rs232c standard. The RS232 is a really loaded term! The C revision of the standard was issued in 1969 in part to accommodate electrical characteristics. Revision D was issued in 1986. The current revision is TIA-232-F Interface Between Data Terminal Equipment and Data Circuit-Terminating Equipment Employing Serial Binary Data Interchange, issued in 1997. None of this is of any particular relevance to the basic underlying question: Should the next JSR attempt to address the multi-drop abilities of RS-485? Thanks! - Doug >Folks, > >The RS232/485/422/etc. etc. is a complete red herring >(http://en.wikipedia.org/wiki/Red_herring in case you don't know the >expression). The differences between the two are at the electrical >level, not at the RXTX level. I'll provide a concrete example and see >if we can get away from this issue. > >There's an industrial serial communications standard - Modbus. Modbus >capable devices are very common and can be purchased, generally, with an >RS232 or a 485 or a 422 - you decide when you buy it. Some actually >provide both 232 and 485 on the same connector. Now, within our >environment you configure a Modbus JavaBean. One of the parameters is >the "Station Number". The station number is required for both RS232 and >RS485 devices - the protocol doesn't change based on the electrical >requirements of the device. Now I can configure an application talking >to, say, station 2 and station 7. I can add an RS485 converter to the >computer serial port and put two physical devices there, configured as >station 2 and station 7 and everything works fine. HOWEVER, over RS232 >some devices will respond to both station 2 and station 7. So THE SAME >APPLICATION will work with both 232 and 485. The only changes are >hardware related. This same behavior is true of a number of 485 >"networks" and many industrial devices that have 485 interfaces have 232 >as an option using the same protocol. > >Jim > > >Trent Jarvi wrote: >> A JSR/JCP would not just involve RXTX. In fact it would be very nice to >> have others with expertise in various areas like I2C, IrDA, RS485, RS422, >> ... involved. >> >> Within the RXTX community, I do not think we have enough depth to tackle >> RS485 alone. I'm aware of some of the low level issues but to be honest, >> I've never actually used it. The RS485 classes in RXTX are more like >> notes to myself about the issues involved without hardware solutions. In >> operating systems like Linux, this may be much less of an issue in the >> future. Linux is putting realtime patches now in the kernels which could >> make RS485 over EIA232 possible. >> >> This is probably the last chance RS485 has to get into a published spec >> for a long time though. Right now, I do not think its reasonable to >> include it in the process. Others could make that less of a problem. >> >> On Mon, 24 Jul 2006, Christo Malan wrote: >> >>> Hi >>> >>> I don't think RS-485 belong in rxtx, the scope of the spec is not wide >>> enough as it only specify the electrical layer. Their is no data >>> protocol recommended or defined. This mean that we have no idea when to >>> sample for a bit, how long is a bit and how many bits before we can say >>> new data is available. >>> >>> Christo >>> >>> Dr. Douglas Lyon wrote: >>>> Hi All, >>>> There has been a lot of discussion regarding RS485. >>>> >>>> Let me see if I can summarize this, please correct me if I am wrong; >>>> I am deliberately ignoring connector and electrical issues, focusing, >>>> instead, on protocol and software issues. Also, I have never used >>>> RS485, and I don't know much about it. > >>> >>>> 1. Serial ports that claim RS232 are typically used in >>>> the data link layer of the OSI model of networking. Basically, this means >>>> that they work with a point-to-point protocol and are meant to connect two > >>> devices. >>>> >>>> 2. Within the RS232 standard there are framing bits (start and stop bits) >>>> and error control bits (parity). The flow control is xon-xoff or >>>>DTR, CTS, RTS. >>>> Thats' it. >>>> >>>> 3. If you want more than that from RS232 (forward error >>>>correction, ARQ, etc.) >>>> you do it in software, not in the RS232 standard. >>>> >>>> 4. RS485 is different from RS232 in that it is in the Network Layer of >>>> the OSI model of networking. >>>> >>>> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in >>>> a factory). >>>> RS-485 is similar to RS-422, but RS-422 allows just one driver with >>>> multiple receivers whereas RS-485 supports multiple drivers and >>>> receivers. >>>> >>>> 6. RS-485 is a serial bus with multiple nodes and thus must handle network >>>> link layer protocols. By using high-impedance receivers, you can have >>>> as many as 256 nodes. >>>> >>>> 7. The RS-485 can be implemented with RXTX in the core and a >>>>layer of software >>>> on top to handle media access control (MAC sublayer). There are also >>>> hardware converters. >>>> http://www.rs485.com/pconverters.html for example. However, some of >>>> these require software control. There is some support in the form of >>>> the Rs485.java class, >>>> in RXTX. >>>> >>>> 8. The RS-485 specification will add to the size of the JSR >>>> >>>> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: >>>> This version of the Java communications API contains support for >>>> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not >>>> mentioned. >>>> >>>> 10. DO people want to add RS485 to a new JSR? >>>> >>>> Would it make sense for the RS-485 people to speak up now? >>>> Please let me know if you think my summary is wrong. >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>> >>>> >>>> >>>> >>>>> At 18:31 20/07/2006, Trent Jarvi wrote: >>>>> >>>>>>> PROJECT SCOPE: >>>>>>> ------------- >>>>>>> >>>>>>> Also, we should think carefully about what the scope of >>>>>>> this project would be. Should it be javax."comm" which >>>>>>> handles both serial and parallel (is parallel going by the >>>>>>> wayside). Should it be split into two project: >>>>>>> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>>>>>> >>>>>>> Should we differentiate between single-ended serial >>>>>>> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>>>>>> quasi-multidrop and full multidrop busses such as >>>>>>> EIA422, EIA432 and EIA485? If we really were to >>>>>>> add I2C support to the API, we'd have to delve into >>>>>>> the semantics more, because there could be some >>>>>>> implicit decoding of the bus the API users would >>>>>>> want to see. >>>>>>> >>>>>> Hi Paul >>>>>> >>>>>> The way RXTX works, which is a fair representation of the >>>>>>people using the >>>>>> API, is complete support for RIA232, minimal support for IEEE1284. From >>>>>> what I understand, Sun was going along the same lines. If we combined >>>>>> both projects, we would have half a parallel port implementation. I see >>>>>> maybe 4 requests for features not in the parallel support a year. >>>>>> >>>>>> The other protocols should not be limited by a JSR which is going to be >>>>>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>>>>> I2C and Raw should _not_ be considered a strong basis for extending the >>>>>> API to cover these protocols. If people want to do real >>>>>>implementations, >>>>>> they should not face a 'standard' which wasnt really focused upon their >>>>>> interests. I think we understand the parallel port issues >>>>>>fairly well but >>>>>> have not implemented many features and I don't know if we would. >>>>>> >>>>> I agree with all of this. API requirements for I2C, SPI, etc. are very >>>>> different from those for RS232/485/422. Our embedded Java platform has >>>>> APIs for all of these and more and they don't share a lot apart from the >>>>> fact that they all use Input/OutputStreams (and in the case of SPI you > >>>> still need to cater with the fact that every time you want to read you >>>>> must also write to the device.) >>>>> >>>>> If I was to design javax.comm from scratch, I think I would focus on >>>>> serial ports exclusively (== whatever the underlying OS represents as > >>>> serial ports). Even parallel is a bit out of place IMHO, although I >>>>> understand it needs to stay for backwards compatibility. >>>>> >>>>> >>>>> >>>>>> So a versatile API is favorable but I do not think we have the proper >>>>>> community to represent much more than Serial. >>>>>> >>>>> Yes, I think the same. >>>>> >>>>> Guillermo >>>>> -- >>>>> Guillermo Rodriguez Garcia >>>>> >>>>> Snijder Micro Systems phone +31-493-351020 >>>>> G. Rodriguez Garcia fax +31-493-351530 >>>>> Visser 25 email guille at sms.nl >>>>> NL5751 BL Deurne >>>>> The Netherlands http://www.snijder.com >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >-- >Jim Redman >(505) 662 5156 x85 >http://www.ergotech.com >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Mon Jul 24 10:16:44 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 18:16:44 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> Message-ID: <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> Hi Doug, Quoting "Dr. Douglas Lyon" : > >Hi All, > > > Wow, what an informed and interesting debate from my most > innocent and well-intentioned of e-mails. > > I must say that I am learning a great deal from this list! > > When I speak about > RS232 I wanted to focus on the protocol, not the connector shape or > pin-out or electrical issues. Issues like that are addressed by the > rs232c standard. > The RS232 is a really loaded term! Right. Maybe we should be talking about "serial ports" instead. At the functional level it does not make any difference whether it is RS232, RS485, or RS422... except maybe for the direction control in the case of RS485 ports. [...] > > None of this is of any particular relevance to the basic underlying > question: > > Should the next JSR attempt to address the multi-drop abilities of RS-485? What I would suggest is to just add a new 'ioctlex'-like method to the SerialPort API: A method that you'd use to pass platform- or implementation-specific info to the underlying driver or OS to do things such as "enabling RS485 mode" or "disable FIFOs" or "poll the TSR register". No need to define any function codes. This is for stuff that is platform- or implementation-specific and as such cannot be easily abstracted anyway. The goal is to accomodate hat those systems that have serial ports with special, non-standard capabilities without forcing developers to leave javax.comm. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From Paul.Klissner at Sun.COM Mon Jul 24 10:45:33 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Mon, 24 Jul 2006 09:45:33 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> Message-ID: <44C4F92D.6090807@sun.com> >> None of this is of any particular relevance to the basic underlying >> question: >> >> Should the next JSR attempt to address the multi-drop abilities of RS-485? > > What I would suggest is to just add a new 'ioctlex'-like method > to the SerialPort API: A method that you'd use to pass platform- > or implementation-specific info to the underlying driver or OS > to do things such as "enabling RS485 mode" or "disable FIFOs" or > "poll the TSR register". > > No need to define any function codes. This is for stuff that is > platform- or implementation-specific and as such cannot be easily > abstracted anyway. Detrimental to platform independence. Paul From berkland at spamcop.net Mon Jul 24 11:07:58 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 24 Jul 2006 13:07:58 -0400 Subject: [Rxtx] jcp and jsr In-Reply-To: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> Message-ID: <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> Gregg Wonderly wrote: > That there could be a low level port/device SPI > that could be put in place once, and then overtime > we could layer other APIs, including an updated > javax.comm which would make use of this SPI. I think there is great merit in this suggestion. I would like to see the ability to register a new "port" along with a custom handler in the Java client code before attempting to access the port. e.g . CommManager.getInstance().registerPortImpl("USB1:", new HidPortAdapter(/*vendorId=*/ "1234", /*deviceId=*/ "4321"); CommManager.getInstance().registerPortImpl("Ether1:", new InetPortAdapter(/*ipAndPort=*/ "192.168.1.101:8088"); It would allow other protocols that this group doesn't have depth in to be developed by someone who does on an "as needed" basis. Additionally, the value of this would be with some devices that implement basically the same protocol that was initially used over RS232 for a USB (via an HID) or Ethernet interface. There are a number of these in POS hardware. The existing JavaPOS driver written against JavaCOMM 2.0 could be reused by plugging in an HID or IP adapter before attempting to access the device. It might also be valuable to use something like an extended version of the portmapping file found in JavaCOMM 3.0. A configuration file could allow this definition to take place outside of any Java client code. Such a mapping file wouldn't even need to be part of the JSR API or reference implementation. It could be handled in a specific implementation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060724/7f51342e/attachment-0340.html From guille at sms.nl Mon Jul 24 11:14:54 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 19:14:54 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4F92D.6090807@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> Message-ID: <1153761294.44c5000ec1360@webmail.eatserver.nl> Quoting Paul Klissner : > >> None of this is of any particular relevance to the basic underlying > >> question: > >> > >> Should the next JSR attempt to address the multi-drop abilities of > RS-485? > > > > What I would suggest is to just add a new 'ioctlex'-like method > > to the SerialPort API: A method that you'd use to pass platform- > > or implementation-specific info to the underlying driver or OS > > to do things such as "enabling RS485 mode" or "disable FIFOs" or > > "poll the TSR register". > > > > No need to define any function codes. This is for stuff that is > > platform- or implementation-specific and as such cannot be easily > > abstracted anyway. > > Detrimental to platform independence. Yes, it is. But as you go closer and closer to the hardware level some things are by nature platform-dependent, and sometimes just cannot be solved in a platform-independent way. In these cases, is it better to have no solution at all than having one that is less than perfect? Put it another way, would you prefer having people say "I just cannot do this in Java; I'll go somewhere else" rather than "I can do this in Java -- only not in a platform-independent way" ? Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From gergg at cox.net Mon Jul 24 11:34:00 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 12:34:00 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153752467.44c4dd93c08f7@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> Message-ID: <44C50488.1040508@cox.net> Guillermo Rodriguez wrote: > As an embedded Java vendor, SNIJDER Micro Systems certainly sees the > value of standardized APIs to talk to different types of communication > buses including SPI, I2C, 1-Wire, etc., for embedded applications. > However we think this has nothing to do with javax.comm. I don't think this is only about javax.comm. Certainly that's important. I'm just wading into this conversation mainstream and trying to say: If you are going to do anything about "fixing" javax.comm to work on all platforms, please, please, please start with a hardware port SPI definition that lets you get to serial ports, and then provide the existing javax.com API and whatever new API you think is necessary (I don't have any really issues with the existing API directly). Then, there will be a place for others interesting in SPI, i2C, USB and other things to get started with providing access to devices that are also interesting in Java applications, and directly, in embedded Java applications. Gregg Wonderly From Paul.Klissner at Sun.COM Mon Jul 24 11:41:51 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Mon, 24 Jul 2006 10:41:51 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153761294.44c5000ec1360@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> Message-ID: <44C5065F.3060802@sun.com> Guillermo Rodriguez wrote: > Quoting Paul Klissner : > >>>> None of this is of any particular relevance to the basic underlying >>>> question: >>>> >>>> Should the next JSR attempt to address the multi-drop abilities of >> RS-485? >>> What I would suggest is to just add a new 'ioctlex'-like method >>> to the SerialPort API: A method that you'd use to pass platform- >>> or implementation-specific info to the underlying driver or OS >>> to do things such as "enabling RS485 mode" or "disable FIFOs" or >>> "poll the TSR register". >>> >>> No need to define any function codes. This is for stuff that is >>> platform- or implementation-specific and as such cannot be easily >>> abstracted anyway. >> Detrimental to platform independence. > > Yes, it is. But as you go closer and closer to the hardware level some > things are by nature platform-dependent, and sometimes just cannot be > solved in a platform-independent way. In these cases, is it better to > have no solution at all than having one that is less than perfect? > > Put it another way, would you prefer having people say "I just cannot > do this in Java; I'll go somewhere else" rather than "I can do this > in Java -- only not in a platform-independent way" ? If there isn't a reasonable way to abstract it out, then why use Java? The whole idea is platform neutrality, otherwise, what is the huge advantage of adopting a standardized Java API? I think it is wrong to subvert the API. I think we have to arrive at some sort of consensus about the scope of the API and do our best to engineer a robust API in terms of that scope using abstraction. There may be outliers, but the outliers probably aren't portable, and probably would do just as well to not use java for that particular application. If this was a JSR, if we found some compelling problem that kept cropping up the API could be reved so as not to just orphan cases with legitimate requests. If someone really needs to do funky things with the hardware, why wouldn't that be put in the native back end? Couldn't some of this be addressed by the multiple SPI layer that I recommended as one of the two changes I'd like to see made to javax.comm (the other being a port mapping plugin layer)? Paul From jredman at ergotech.com Mon Jul 24 11:49:46 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 11:49:46 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> Message-ID: <44C5083A.6090902@ergotech.com> A thought for later since we haven't really reached this level of detail, but since this type of approach seems likely... If a configuration file is mandatory, can we specify what the file is called and what the format of the options are (mandatory?, and optional) without limiting extensions. This just adds consistency across platforms/implementations. Jim Doug Berkland wrote: > Gregg Wonderly wrote: > > That there could be a low level port/device SPI > > that could be put in place once, and then overtime > > we could layer other APIs, including an updated > > javax.comm which would make use of this SPI. > > I think there is great merit in this suggestion. I would like to see > the ability to register a new "port" along with a custom handler in the > Java client code before attempting to access the port. > e.g . > CommManager.getInstance().registerPortImpl("USB1:", new > HidPortAdapter(/*vendorId=*/ "1234", /*deviceId=*/ "4321"); > CommManager.getInstance().registerPortImpl("Ether1:", new > InetPortAdapter(/*ipAndPort=*/ " 192.168.1.101:8088 > "); > > It would allow other protocols that this group doesn't have depth in to > be developed by someone who does on an "as needed" basis. > > Additionally, the value of this would be with some devices that > implement basically the same protocol that was initially used over RS232 > for a USB (via an HID) or Ethernet interface. There are a number of > these in POS hardware. The existing JavaPOS driver written against > JavaCOMM 2.0 could be reused by plugging in an HID or IP adapter before > attempting to access the device. > > It might also be valuable to use something like an extended version of > the portmapping file found in JavaCOMM 3.0. A configuration file could > allow this definition to take place outside of any Java client code. > Such a mapping file wouldn't even need to be part of the JSR API or > reference implementation. It could be handled in a specific > implementation. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From mtnvega at yahoo.com.br Mon Jul 24 11:51:40 2006 From: mtnvega at yahoo.com.br (mtnvega) Date: Mon, 24 Jul 2006 14:51:40 -0300 Subject: [Rxtx] Serial Read/Write Details Message-ID: <44C508AC.7060103@yahoo.com.br> Hello, I'm have being flirting with RXTX for a while since I'm working on a college project where I will need to communicate with a microcontroller using USART. Now is the time to start using it! But I have some doubts and I hope you can help-me. I will need to both send and receive data from the serial port. First I will need to send some command bytes then wait for some data that will be returned from the microcontroller. And I would like to know which is the best way to do that. I'm mean, of course send and receive data is the purpose of the serial port and RXTX but I'm looking for some details since there will be no package control but just a fixed command format and confirmation messages from the microcontroller side. I would like to know if I should open and close the port or if I can just open it once. I read that upon writing to output the input buffer are filled with the same data, is it right? If yes, isn't it a problem since I'm waiting for data back in a very small time? Thank you, Luiz _______________________________________________________ Voc? quer respostas para suas perguntas? Ou voc? sabe muito e quer compartilhar seu conhecimento? Experimente o Yahoo! Respostas ! http://br.answers.yahoo.com/ From jredman at ergotech.com Mon Jul 24 12:45:50 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 12:45:50 -0600 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C50488.1040508@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> Message-ID: <44C5155E.7080105@ergotech.com> Gregg, Is SPI applicable to a SerialPort interface over Ethernet (or Bluetooth)? I've assumed that it's specific to directly-connected-UART-based serial ports - something similar to I2C. I'm starting to think that I'm opposed to having hardware definitions (transport layer?) in the JavaComm spec., but then what's left? Jim Gregg Wonderly wrote: > Guillermo Rodriguez wrote: >> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the >> value of standardized APIs to talk to different types of communication >> buses including SPI, I2C, 1-Wire, etc., for embedded applications. >> However we think this has nothing to do with javax.comm. > > I don't think this is only about javax.comm. Certainly that's important. I'm > just wading into this conversation mainstream and trying to say: > > If you are going to do anything about "fixing" javax.comm to work on all > platforms, please, please, please start with a hardware port SPI definition that > lets you get to serial ports, and then provide the existing javax.com API and > whatever new API you think is necessary (I don't have any really issues with the > existing API directly). > > Then, there will be a place for others interesting in SPI, i2C, USB and other > things to get started with providing access to devices that are also interesting > in Java applications, and directly, in embedded Java applications. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Mon Jul 24 13:15:19 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 14:15:19 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C5155E.7080105@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <44C5155E.7080105@ergotech.com> Message-ID: <44C51C47.90409@cox.net> Jim Redman wrote: > Is SPI applicable to a SerialPort interface over Ethernet (or > Bluetooth)? I've assumed that it's specific to > directly-connected-UART-based serial ports - something similar to I2C. SPI is a simple 2 line (clock and data) plus slave select bi-directional, full duplex data transfer mechanism. It has nothing to do, directly with serial ports, but could be implemented using serial port signalling lines. > I'm starting to think that I'm opposed to having hardware definitions > (transport layer?) in the JavaComm spec., but then what's left? Jim, there are multiple conversations going on, on the list. There is a group of people that just want a standard serial port mechanism in Java, apparently NOW! They are going back and forth about that. There is another conversation about doing a JSR to make the serial port interfaces a standard, since Sun's original implementation was never a Java standard. There is a small group saying if you're going to do a JSR for serial ports, why not provide a nice foundation for serial ports which might also support other kinds of "ports" and associated protocols. And there are a couple of other conversations about Pascal's stuff. It's this last group that I am the most interested in. I think that it is possible to create a simple Service Provider Interface for 'hardware interfacing' that covers serial ports and also includes expandability to cover other types of hardware. We want to find the level of abstraction that the most number of OSes provide in their user level APIs, and create a matching SPI at that level which will allow a JVM vendor to provide access to the types of hardware that is common on their OSes/hardware. Then, third parties might add some value by providing some good abstrations for particular types of protocols or particular vendors' hardware (ports which can be switched between RS232 and RS485 for example). Finally, we can create an implementation of the javax.comm API which uses this SPI to provide exactly the same API as today, but with an approved foundation for hardware access from java using 100% java code. Gregg Wonderly From mark at mdsh.com Mon Jul 24 16:03:38 2006 From: mark at mdsh.com (Mark Himsley) Date: Mon, 24 Jul 2006 23:03:38 +0100 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: I don't see how any Java app is going to know the difference between an RS232, RS422, or RS485 port. I regularly use RXTX controlling RS422 devices (controlling VTRs) and I can use an RS232 port with bodged wiring (for short distances) or RS232 port with a media converted - either of which may be built into the PC or may be a USB device - or an RS422 USB device. They are just 'serial port' devices. Please don't get hung up on higher layer stuff - that's for application developers to add on top of a rock-solid multi platform 'serial port' driver implementations. On 24 July 2006 08:44 -0600 Trent Jarvi wrote: > > A JSR/JCP would not just involve RXTX. In fact it would be very nice to > have others with expertise in various areas like I2C, IrDA, RS485, RS422, > ... involved. > > Within the RXTX community, I do not think we have enough depth to tackle > RS485 alone. I'm aware of some of the low level issues but to be honest, > I've never actually used it. The RS485 classes in RXTX are more like > notes to myself about the issues involved without hardware solutions. In > operating systems like Linux, this may be much less of an issue in the > future. Linux is putting realtime patches now in the kernels which could > make RS485 over EIA232 possible. > > This is probably the last chance RS485 has to get into a published spec > for a long time though. Right now, I do not think its reasonable to > include it in the process. Others could make that less of a problem. > > On Mon, 24 Jul 2006, Christo Malan wrote: > > > Hi > > > > I don't think RS-485 belong in rxtx, the scope of the spec is not wide > > enough as it only specify the electrical layer. Their is no data > > protocol recommended or defined. This mean that we have no idea when to > > sample for a bit, how long is a bit and how many bits before we can say > > new data is available. > > > > Christo > > > > Dr. Douglas Lyon wrote: > >> Hi All, > >> There has been a lot of discussion regarding RS485. > >> > >> Let me see if I can summarize this, please correct me if I am wrong; > >> I am deliberately ignoring connector and electrical issues, focusing, > >> instead, on protocol and software issues. Also, I have never used > >> RS485, and I don't know much about it. > >> > >> 1. Serial ports that claim RS232 are typically used in > >> the data link layer of the OSI model of networking. Basically, this > >> means that they work with a point-to-point protocol and are meant to > >> connect two devices. > >> > >> 2. Within the RS232 standard there are framing bits (start and stop > >> bits) and error control bits (parity). The flow control is xon-xoff or > >> DTR, CTS, RTS. Thats' it. > >> > >> 3. If you want more than that from RS232 (forward error correction, > >> ARQ, etc.) you do it in software, not in the RS232 standard. > >> > >> 4. RS485 is different from RS232 in that it is in the Network Layer of > >> the OSI model of networking. > >> > >> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > >> a factory). > >> RS-485 is similar to RS-422, but RS-422 allows just one driver with > >> multiple receivers whereas RS-485 supports multiple drivers and > >> receivers. > >> > >> 6. RS-485 is a serial bus with multiple nodes and thus must handle > >> network link layer protocols. By using high-impedance receivers, you > >> can have as many as 256 nodes. > >> > >> 7. The RS-485 can be implemented with RXTX in the core and a layer of > >> software on top to handle media access control (MAC sublayer). There > >> are also hardware converters. > >> http://www.rs485.com/pconverters.html for example. However, some of > >> these require software control. There is some support in the form of > >> the Rs485.java class, > >> in RXTX. > >> > >> 8. The RS-485 specification will add to the size of the JSR > >> > >> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > >> This version of the Java communications API contains support for > >> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > >> mentioned. > >> > >> 10. DO people want to add RS485 to a new JSR? > >> > >> Would it make sense for the RS-485 people to speak up now? > >> Please let me know if you think my summary is wrong. > >> > >> Thanks! > >> - Doug > >> > >> > >> > >> > >> > >> > >>> At 18:31 20/07/2006, Trent Jarvi wrote: > >>> > >>>> > PROJECT SCOPE: > >>>> > ------------- > >>>> > > >>>> > Also, we should think carefully about what the scope of > >>>> > this project would be. Should it be javax."comm" which > >>>> > handles both serial and parallel (is parallel going by the > >>>> > wayside). Should it be split into two project: > >>>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > >>>> > > >>>> > Should we differentiate between single-ended serial > >>>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > >>>> > quasi-multidrop and full multidrop busses such as > >>>> > EIA422, EIA432 and EIA485? If we really were to > >>>> > add I2C support to the API, we'd have to delve into > >>>> > the semantics more, because there could be some > >>>> > implicit decoding of the bus the API users would > >>>> > want to see. > >>>> > > >>>> > >>>> Hi Paul > >>>> > >>>> The way RXTX works, which is a fair representation of the people > >>>> using the API, is complete support for RIA232, minimal support for > >>>> IEEE1284. From what I understand, Sun was going along the same > >>>> lines. If we combined both projects, we would have half a parallel > >>>> port implementation. I see maybe 4 requests for features not in the > >>>> parallel support a year. > >>>> > >>>> The other protocols should not be limited by a JSR which is going to > >>>> be focused upon serial port interests. The IEA485 hacks in RXTX > >>>> along with I2C and Raw should _not_ be considered a strong basis for > >>>> extending the API to cover these protocols. If people want to do > >>>> real implementations, they should not face a 'standard' which wasnt > >>>> really focused upon their interests. I think we understand the > >>>> parallel port issues fairly well but have not implemented many > >>>> features and I don't know if we would. > >>>> > >>> I agree with all of this. API requirements for I2C, SPI, etc. are very > >>> different from those for RS232/485/422. Our embedded Java platform has > >>> APIs for all of these and more and they don't share a lot apart from > >>> the fact that they all use Input/OutputStreams (and in the case of > >>> SPI you still need to cater with the fact that every time you want to > >>> read you must also write to the device.) > >>> > >>> If I was to design javax.comm from scratch, I think I would focus on > >>> serial ports exclusively (== whatever the underlying OS represents as > >>> serial ports). Even parallel is a bit out of place IMHO, although I > >>> understand it needs to stay for backwards compatibility. > >>> > >>> > >>> > >>>> So a versatile API is favorable but I do not think we have the proper > >>>> community to represent much more than Serial. > >>>> > >>> Yes, I think the same. > >>> > >>> Guillermo > >>> -- > >>> Guillermo Rodriguez Garcia > >>> > >>> Snijder Micro Systems phone +31-493-351020 > >>> G. Rodriguez Garcia fax +31-493-351530 > >>> Visser 25 email guille at sms.nl > >>> NL5751 BL Deurne > >>> The Netherlands http://www.snijder.com > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> > >> > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Mark Himsley From berkland at spamcop.net Mon Jul 24 16:55:18 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 24 Jul 2006 18:55:18 -0400 Subject: [Rxtx] jcp and jsr In-Reply-To: <44C5083A.6090902@ergotech.com> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> <44C5083A.6090902@ergotech.com> Message-ID: <269e40090607241555g281c7f24s5577b86e35d27eab@mail.gmail.com> I'm sorry, I keep reading SPI as "Service Provider Interface" instead of "Serial Peripheral Interface". (See http://en.wikipedia.org/wiki/Serial_Peripheral_Interface.) What I thought was being suggested was a pluggable implementation like that found in javax.security. (The SPI there actually stands for "Security Provider Interface" not "Service Provider Interface" like I had thought.) I guess that might be a CPI (Comm Provider Interface) or PPI (Port Provider Interface.) At any rate what I would like to see is a JSR with (in order of priority) - compatible API for code written against current javax.comm 2.0 classes - ability to register or "force" a port by providing a name and implementation (not have to rely completely on the "auto-discovery") - nothing precluding the use of a portmapping in a given implementation - ability to register port implementations On 7/24/06, Jim Redman wrote: > > A thought for later since we haven't really reached this level of > detail, but since this type of approach seems likely... > > If a configuration file is mandatory, can we specify what the file is > called and what the format of the options are (mandatory?, and optional) > without limiting extensions. > > This just adds consistency across platforms/implementations. > > Jim > > Doug Berkland wrote: > > Gregg Wonderly wrote: > > > That there could be a low level port/device SPI > > > that could be put in place once, and then overtime > > > we could layer other APIs, including an updated > > > javax.comm which would make use of this SPI. > > > > I think there is great merit in this suggestion. I would like to see > > the ability to register a new "port" along with a custom handler in the > > Java client code before attempting to access the port. > > e.g . > > CommManager.getInstance().registerPortImpl("USB1:", new > > HidPortAdapter(/*vendorId=*/ "1234", /*deviceId=*/ "4321"); > > CommManager.getInstance().registerPortImpl("Ether1:", new > > InetPortAdapter(/*ipAndPort=*/ " 192.168.1.101:8088 > > "); > > > > It would allow other protocols that this group doesn't have depth in to > > be developed by someone who does on an "as needed" basis. > > > > Additionally, the value of this would be with some devices that > > implement basically the same protocol that was initially used over RS232 > > for a USB (via an HID) or Ethernet interface. There are a number of > > these in POS hardware. The existing JavaPOS driver written against > > JavaCOMM 2.0 could be reused by plugging in an HID or IP adapter before > > attempting to access the device. > > > > It might also be valuable to use something like an extended version of > > the portmapping file found in JavaCOMM 3.0. A configuration file could > > allow this definition to take place outside of any Java client code. > > Such a mapping file wouldn't even need to be part of the JSR API or > > reference implementation. It could be handled in a specific > > implementation. > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060724/02c50e6a/attachment-0340.html From tjarvi at qbang.org Mon Jul 24 18:44:54 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 24 Jul 2006 18:44:54 -0600 (MDT) Subject: [Rxtx] Serial Read/Write Details In-Reply-To: <44C508AC.7060103@yahoo.com.br> References: <44C508AC.7060103@yahoo.com.br> Message-ID: On Mon, 24 Jul 2006, mtnvega wrote: > Hello, > > I'm have being flirting with RXTX for a while since I'm working on a > college project where I will > need to communicate with a microcontroller using USART. > > Now is the time to start using it! But I have some doubts and I hope you > can help-me. > > I will need to both send and receive data from the serial port. First I > will need to send some command > bytes then wait for some data that will be returned from the > microcontroller. And I would like > to know which is the best way to do that. I'm mean, of course send and > receive data is the purpose > of the serial port and RXTX but I'm looking for some details since there > will be no package control > but just a fixed command format and confirmation messages from the > microcontroller side. > > I would like to know if I should open and close the port or if I can > just open it once. > I read that upon writing to output the input buffer are filled with the > same data, is it right? > If yes, isn't it a problem since I'm waiting for data back in a very > small time? > Hi Luiz Unless you want to use the port with a second application, just open the port once and close it when you exit the application. The input will not be filled with the data you write. The API has events to let you know when data is available and when your data has gone out the port. You can look in the contrib directory that comes with the source for crude examples of event notification. I think there is an example on the wiki too. I don't think you will have any problems. -- Trent Jarvi tjarvi at qbang.org From guille at sms.nl Tue Jul 25 00:26:12 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 08:26:12 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C50488.1040508@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> Message-ID: <7.0.1.0.0.20060725082124.036309e0@sms.nl> At 19:34 24/07/2006, Gregg Wonderly wrote: >Guillermo Rodriguez wrote: > > As an embedded Java vendor, SNIJDER Micro Systems certainly sees the > > value of standardized APIs to talk to different types of communication > > buses including SPI, I2C, 1-Wire, etc., for embedded applications. > > However we think this has nothing to do with javax.comm. > >I don't think this is only about javax.comm. Certainly that's >important. I'm >just wading into this conversation mainstream and trying to say: > >If you are going to do anything about "fixing" javax.comm to work on all >platforms, please, please, please start with a hardware port SPI >definition that >lets you get to serial ports, and then provide the existing javax.com API and >whatever new API you think is necessary (I don't have any really >issues with the >existing API directly). > >Then, there will be a place for others interesting in SPI, i2C, USB and other >things to get started with providing access to devices that are also >interesting >in Java applications, and directly, in embedded Java applications. I do agree that the best a hardware port SPI definition (where SPI = Service Provider Interface, not the SPI protocol) is a good thing to have to support serial ports layered over other transports. However these are still serial ports at the end. I still don't think the javax.comm API is well suited to "any" serial bus such as I2C, SPI, etc. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 00:41:46 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 08:41:46 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C5065F.3060802@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> Message-ID: <7.0.1.0.0.20060725082630.036d2d10@sms.nl> At 19:41 24/07/2006, Paul Klissner wrote: >Guillermo Rodriguez wrote: >>Quoting Paul Klissner : >> >>>>>None of this is of any particular relevance to the basic underlying >>>>>question: >>>>> >>>>>Should the next JSR attempt to address the multi-drop abilities of >>>RS-485? >>>>What I would suggest is to just add a new 'ioctlex'-like method >>>>to the SerialPort API: A method that you'd use to pass platform- >>>>or implementation-specific info to the underlying driver or OS >>>>to do things such as "enabling RS485 mode" or "disable FIFOs" or >>>>"poll the TSR register". >>>> >>>>No need to define any function codes. This is for stuff that is >>>>platform- or implementation-specific and as such cannot be easily >>>>abstracted anyway. >>>Detrimental to platform independence. >>Yes, it is. But as you go closer and closer to the hardware level some >>things are by nature platform-dependent, and sometimes just cannot be >>solved in a platform-independent way. In these cases, is it better to >>have no solution at all than having one that is less than perfect? >>Put it another way, would you prefer having people say "I just cannot >>do this in Java; I'll go somewhere else" rather than "I can do this >>in Java -- only not in a platform-independent way" ? > >If there isn't a reasonable way to abstract it out, then >why use Java? If an application can be 99% platform independent with small bits being not portable, why *not* use Java? I'd prefer to see people using Java to write non-portable applications than having them use C instead. I believe that Java should promote platform neutrality, but that does not necessarily mean precluding the use of anything that is NOT platform independent. And let's face it, if you are using javax.comm to talk to some serial device directly, then chances are you are already tied to some specific hardware anyway. Also, some people (myself included) think that Java can also be used as a systems programming language, not only for applications. For many embedded platforms this is certainly the case. In our platform we even write device drivers directly in Java. I would imagine the Sun SPOT team (www.sunspotworld.com) supports a similar view. If people needs to do non-portable stuff and wants to do it in Java I'd rather have them do it in Java than tell them to do it in C instead. >The whole idea is platform neutrality, otherwise, what is the >huge advantage of adopting a standardized Java API? I think >it is wrong to subvert the API. I think we have to arrive at >some sort of consensus about the scope of the API and do our >best to engineer a robust API in terms of that scope using >abstraction. > >There may be outliers, but the outliers probably aren't portable, >and probably would do just as well to not use java for that >particular application. The cases I have in mind is more like portable applications with very small bits of non portable code. I can imagine lots of portable applications that need access to RS485, specially in the industrial process control and factory automation fields. As I said in an earlier mail RS485 is half- duplex, but there is standard way to do RS485 direction control from software. Does it mean that the whole application should not be written in Java, only because some small bits of code related to RS485 direction control are not completely portable? > If this was a JSR, if we found some >compelling problem that kept cropping up the API could be >reved so as not to just orphan cases with legitimate requests. > >If someone really needs to do funky things with the hardware, >why wouldn't that be put in the native back end? But nobody said the functionality can't be implemented in the native back end. However you still need an application level API to enable/disable it. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 00:44:43 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 08:44:43 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <269e40090607241555g281c7f24s5577b86e35d27eab@mail.gmail.co m> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> <44C5083A.6090902@ergotech.com> <269e40090607241555g281c7f24s5577b86e35d27eab@mail.gmail.com> Message-ID: <7.0.1.0.0.20060725084431.036d0700@sms.nl> At 00:55 25/07/2006, Doug Berkland wrote: >I'm sorry, I keep reading SPI as "Service Provider Interface" >instead of "Serial Peripheral Interface". (See >http://en.wikipedia.org/wiki/Serial_Peripheral_Interface. >) > >What I thought was being suggested was a pluggable implementation >like that found in javax.security. (The SPI there actually stands >for "Security Provider Interface" not "Service Provider Interface" >like I had thought.) I guess that might be a CPI (Comm Provider >Interface) or PPI (Port Provider Interface.) > >At any rate what I would like to see is a JSR with (in order of priority) >- compatible API for code written against current javax.comm 2.0 classes >- ability to register or "force" a port by providing a name and >implementation (not have to rely completely on the "auto-discovery") >- nothing precluding the use of a portmapping in a given implementation >- ability to register port implementations That sounds very good to me. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From tjarvi at qbang.org Tue Jul 25 01:21:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 01:21:53 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725082124.036309e0@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> Message-ID: On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: > At 19:34 24/07/2006, Gregg Wonderly wrote: >> Guillermo Rodriguez wrote: >>> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the >>> value of standardized APIs to talk to different types of communication >>> buses including SPI, I2C, 1-Wire, etc., for embedded applications. >>> However we think this has nothing to do with javax.comm. >> >> I don't think this is only about javax.comm. Certainly that's >> important. I'm >> just wading into this conversation mainstream and trying to say: >> >> If you are going to do anything about "fixing" javax.comm to work on all >> platforms, please, please, please start with a hardware port SPI >> definition that >> lets you get to serial ports, and then provide the existing javax.com API and >> whatever new API you think is necessary (I don't have any really >> issues with the >> existing API directly). >> >> Then, there will be a place for others interesting in SPI, i2C, USB and other >> things to get started with providing access to devices that are also >> interesting >> in Java applications, and directly, in embedded Java applications. > > I do agree that the best a hardware port SPI definition (where SPI = Service > Provider Interface, not the SPI protocol) is a good thing to have to support > serial ports layered over other transports. However these are still serial > ports at the end. I still don't think the javax.comm API is well suited to > "any" serial bus such as I2C, SPI, etc. > Perhaps the javax.com namespace is just wrong. I think thats a larger issue we are not well prepared to answer. We do have a larger group participating so there is interest beyond our current solution. My concern is getting into blue sky efforts that never materialize. We have a very concrete solution that just needs a few modifications to make current java users happy. This solution is more or less supporting POSIX termios on all platforms including windows. This solution does not ask deep questions like is it USB or RS485 or IrDA. Smart kernel people worry about that. Thats what works. When the fun goes away and I'm fixing spam on slow mail-lists, thats what will continue to work. Thats what will be tested on hundreds of machines every six months. I don't want to remind people of JSR80 windows support but you should keep that in mind while getting too far from the crusty roman roads. I'd love to move off to the side in the namespace and leave javax.com for a great effort unifying the time space continuum to be announced at a later date. Beyond that, we would need serious commitment from people in the community to get more working. Both rxtx.org and Sun are about maxed out right now. -- Trent Jarvi tjarvi at qbang.org From martin at jopdesign.com Tue Jul 25 01:32:22 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 09:32:22 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> Message-ID: <005b01c6afbc$794fc060$0202a8c0@luna> >>> None of this is of any particular relevance to the basic underlying >>> question: >>> >>> Should the next JSR attempt to address the multi-drop abilities of RS-485? I would vote for a strong yes. >> >> What I would suggest is to just add a new 'ioctlex'-like method >> to the SerialPort API: A method that you'd use to pass platform- >> or implementation-specific info to the underlying driver or OS >> to do things such as "enabling RS485 mode" or "disable FIFOs" or >> "poll the TSR register". >> >> No need to define any function codes. This is for stuff that is >> platform- or implementation-specific and as such cannot be easily >> abstracted anyway. > > Detrimental to platform independence. We can model it platform independent with two methods: enterTransmit() and extiTransmit() to do whatever is necessary on the underlying platform to switch to RS485 transmit mode and back. Martin From guille at sms.nl Tue Jul 25 01:45:53 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 09:45:53 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <005b01c6afbc$794fc060$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> Message-ID: <7.0.1.0.0.20060725094317.0363b390@sms.nl> Hi Martin, At 09:32 25/07/2006, Martin Schoeberl wrote: > >>> None of this is of any particular relevance to the basic underlying > >>> question: > >>> > >>> Should the next JSR attempt to address the multi-drop abilities > of RS-485? > >I would vote for a strong yes. > > >> > >> What I would suggest is to just add a new 'ioctlex'-like method > >> to the SerialPort API: A method that you'd use to pass platform- > >> or implementation-specific info to the underlying driver or OS > >> to do things such as "enabling RS485 mode" or "disable FIFOs" or > >> "poll the TSR register". > >> > >> No need to define any function codes. This is for stuff that is > >> platform- or implementation-specific and as such cannot be easily > >> abstracted anyway. > > > > Detrimental to platform independence. > >We can model it platform independent with two methods: > >enterTransmit() and extiTransmit() to do whatever is necessary >on the underlying platform to switch to RS485 transmit mode and >back. Tempting as it is, I don't think this covers all cases. For example, in those cases where RS485 direction control must be done 100% in software, the software needs to have a way to flush (sync) software buffers, poll the hardware FIFOs and TSR (not THR), etc. Or, for example, for those UARTs that do automatic RS485 direction control with a configurable turnaround delay, how would you configure this turnaround delay from the application? Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 01:48:10 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 09:48:10 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> Message-ID: <7.0.1.0.0.20060725094602.036cec00@sms.nl> Hi Trent, At 09:21 25/07/2006, Trent Jarvi wrote: >On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: > > > At 19:34 24/07/2006, Gregg Wonderly wrote: > >> Guillermo Rodriguez wrote: > >>> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the > >>> value of standardized APIs to talk to different types of communication > >>> buses including SPI, I2C, 1-Wire, etc., for embedded applications. > >>> However we think this has nothing to do with javax.comm. > >> > >> I don't think this is only about javax.comm. Certainly that's > >> important. I'm > >> just wading into this conversation mainstream and trying to say: > >> > >> If you are going to do anything about "fixing" javax.comm to work on all > >> platforms, please, please, please start with a hardware port SPI > >> definition that > >> lets you get to serial ports, and then provide the existing > javax.com API and > >> whatever new API you think is necessary (I don't have any really > >> issues with the > >> existing API directly). > >> > >> Then, there will be a place for others interesting in SPI, i2C, > USB and other > >> things to get started with providing access to devices that are also > >> interesting > >> in Java applications, and directly, in embedded Java applications. > > > > I do agree that the best a hardware port SPI definition (where > SPI = Service > > Provider Interface, not the SPI protocol) is a good thing to have > to support > > serial ports layered over other transports. However these are still serial > > ports at the end. I still don't think the javax.comm API is well suited to > > "any" serial bus such as I2C, SPI, etc. > > > >Perhaps the javax.com namespace is just wrong. I think thats a larger >issue we are not well prepared to answer. We do have a larger group >participating so there is interest beyond our current solution. My concern was not about the name specifically, but about the idea that a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, IrDA, etc. Looking from a distance all of these may look similar but the fact is, they have little to do with each other (apart from being 'communication protocols' or 'buses') Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From Paul.Klissner at Sun.COM Tue Jul 25 01:51:26 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Tue, 25 Jul 2006 00:51:26 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725082630.036d2d10@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> Message-ID: <44C5CD7E.9030903@sun.com> Guillermo Rodriguez Garcia wrote: > At 19:41 24/07/2006, Paul Klissner wrote: >> Guillermo Rodriguez wrote: >>> Quoting Paul Klissner : >>> >>>>>> None of this is of any particular relevance to the basic underlying >>>>>> question: >>>>>> >>>>>> Should the next JSR attempt to address the multi-drop abilities of >>>> RS-485? >>>>> What I would suggest is to just add a new 'ioctlex'-like method >>>>> to the SerialPort API: A method that you'd use to pass platform- >>>>> or implementation-specific info to the underlying driver or OS >>>>> to do things such as "enabling RS485 mode" or "disable FIFOs" or >>>>> "poll the TSR register". >>>>> >>>>> No need to define any function codes. This is for stuff that is >>>>> platform- or implementation-specific and as such cannot be easily >>>>> abstracted anyway. >>>> Detrimental to platform independence. >>> Yes, it is. But as you go closer and closer to the hardware level some >>> things are by nature platform-dependent, and sometimes just cannot be >>> solved in a platform-independent way. In these cases, is it better to >>> have no solution at all than having one that is less than perfect? >>> Put it another way, would you prefer having people say "I just cannot >>> do this in Java; I'll go somewhere else" rather than "I can do this >>> in Java -- only not in a platform-independent way" ? >> If there isn't a reasonable way to abstract it out, then >> why use Java? > > If an application can be 99% platform independent with small bits > being not portable, why *not* use Java? I'd prefer to see people > using Java to write non-portable applications than having them > use C instead. > > I believe that Java should promote platform neutrality, but that > does not necessarily mean precluding the use of anything that is > NOT platform independent. And let's face it, if you are using > javax.comm to talk to some serial device directly, then chances > are you are already tied to some specific hardware anyway. > > Also, some people (myself included) think that Java can also be > used as a systems programming language, not only for applications. > For many embedded platforms this is certainly the case. In our > platform we even write device drivers directly in Java. I would > imagine the Sun SPOT team (www.sunspotworld.com) supports a > similar view. > > If people needs to do non-portable stuff and wants to do it in > Java I'd rather have them do it in Java than tell them to do it > in C instead. That sounds a bit evangelizing. I think C is perfectly viable for some jobs, and might even be preferable in some cases, for example in some cases where performance or space is a factor. I feel it isn't right to corrupt an API with hacks for the goal of enticing users to Java, even for all the 'right' reasons. >> If someone really needs to do funky things with the hardware, >> why wouldn't that be put in the native back end? > > But nobody said the functionality can't be implemented in the > native back end. However you still need an application level API > to enable/disable it. Sure, but the functions, if really along the lines of the defined standard, can be abstracted, rather than cheat with a general purpose hack-all ioctl-like interface that just begs to be abused, lending itself to a litany of non-portable applications. I maintain we should scope the project appropriately, then take our best shot at a reasonably complete set of abstract functions, and improve it if necessary over time (alpha and beta, release candidates? And then update the API in a backward-compatible way based on feedback after FCS if necessary), rather than add an everything-but-the-kitchen-sink escape clause method. A determined programmer facing a corner case can figure out a way to accomplish the goal in most cases. Even if the API doesn't provide an ioctl call, it is possible to create implementation classes that mak methods visible outsidethe scope of the API-defined methods. For example, if I am implementing class Foo in FooImpl.java, And Foo.java defines interface methods a(), b() and c(), FooImpl.java can also have public methods d(), e() and f(), which can be accessed from the application by casting a Foo object into a FooImpl object. This is one way to provide a back door without compromising the core API itself to do it. This puts the responsibility of breaking platform independence on the developers and not on the designers. Paul From tjarvi at qbang.org Tue Jul 25 02:57:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 02:57:28 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725094602.036cec00@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> Message-ID: On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: > Hi Trent, > > At 09:21 25/07/2006, Trent Jarvi wrote: >> On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: >> >>> At 19:34 24/07/2006, Gregg Wonderly wrote: >>>> Guillermo Rodriguez wrote: >>>>> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the >>>>> value of standardized APIs to talk to different types of communication >>>>> buses including SPI, I2C, 1-Wire, etc., for embedded applications. >>>>> However we think this has nothing to do with javax.comm. >>>> >>>> I don't think this is only about javax.comm. Certainly that's >>>> important. I'm >>>> just wading into this conversation mainstream and trying to say: >>>> >>>> If you are going to do anything about "fixing" javax.comm to work on all >>>> platforms, please, please, please start with a hardware port SPI >>>> definition that >>>> lets you get to serial ports, and then provide the existing >> javax.com API and >>>> whatever new API you think is necessary (I don't have any really >>>> issues with the >>>> existing API directly). >>>> >>>> Then, there will be a place for others interesting in SPI, i2C, >> USB and other >>>> things to get started with providing access to devices that are also >>>> interesting >>>> in Java applications, and directly, in embedded Java applications. >>> >>> I do agree that the best a hardware port SPI definition (where >> SPI = Service >>> Provider Interface, not the SPI protocol) is a good thing to have >> to support >>> serial ports layered over other transports. However these are still serial >>> ports at the end. I still don't think the javax.comm API is well suited to >>> "any" serial bus such as I2C, SPI, etc. >>> >> >> Perhaps the javax.com namespace is just wrong. I think thats a larger >> issue we are not well prepared to answer. We do have a larger group >> participating so there is interest beyond our current solution. > > My concern was not about the name specifically, but about the idea that > a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, > IrDA, etc. Looking from a distance all of these may look similar but > the fact is, they have little to do with each other (apart from being > 'communication protocols' or 'buses') > Hi Guillermo Interesting name. Fair enough. My thoughts are that if it can't be unified in the kernel we are out of our skulls trying to do it in user space. Hacks trying to do such will sure to be in open solaris or linux symposiums about why user space sucks. But there is a minimal bit that overlapps that is what most users want. If we limit the scope, it isnt that hard of a problem. By limiting the scope we also limit our deliverables. If you have an interest in a specific area it will probably not be enough. -- Trent Jarvi tjarvi at qbang.org From martin at jopdesign.com Tue Jul 25 03:25:38 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 11:25:38 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> Message-ID: <001901c6afcc$4bcf64f0$0c28a8c0@luna> >> >> >> >> What I would suggest is to just add a new 'ioctlex'-like method >> >> to the SerialPort API: A method that you'd use to pass platform- >> >> or implementation-specific info to the underlying driver or OS >> >> to do things such as "enabling RS485 mode" or "disable FIFOs" or >> >> "poll the TSR register". >> >> >> >> No need to define any function codes. This is for stuff that is >> >> platform- or implementation-specific and as such cannot be easily >> >> abstracted anyway. >> > >> > Detrimental to platform independence. >> >>We can model it platform independent with two methods: >> >>enterTransmit() and extiTransmit() to do whatever is necessary >>on the underlying platform to switch to RS485 transmit mode and >>back. > > Tempting as it is, I don't think this covers all cases. For example, > in those cases where RS485 direction control must be done 100% in > software, the software needs to have a way to flush (sync) software > buffers, poll the hardware FIFOs and TSR (not THR), etc. I just meant to hide those low-level issues you mention in the enter/exitTransmit modes. > > Or, for example, for those UARTs that do automatic RS485 direction > control with a configurable turnaround delay, how would you configure > this turnaround delay from the application? Mmh, perhaps in a similar way as you configure timeouts? Isn't this 'just' a timeout value? Martin From guille at sms.nl Tue Jul 25 04:05:29 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 12:05:29 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <001901c6afcc$4bcf64f0$0c28a8c0@luna> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> Message-ID: <7.0.1.0.0.20060725115736.03706a38@sms.nl> At 11:25 25/07/2006, Martin Schoeberl wrote: > >> >> > >> >> What I would suggest is to just add a new 'ioctlex'-like method > >> >> to the SerialPort API: A method that you'd use to pass platform- > >> >> or implementation-specific info to the underlying driver or OS > >> >> to do things such as "enabling RS485 mode" or "disable FIFOs" or > >> >> "poll the TSR register". > >> >> > >> >> No need to define any function codes. This is for stuff that is > >> >> platform- or implementation-specific and as such cannot be easily > >> >> abstracted anyway. > >> > > >> > Detrimental to platform independence. > >> > >>We can model it platform independent with two methods: > >> > >>enterTransmit() and extiTransmit() to do whatever is necessary > >>on the underlying platform to switch to RS485 transmit mode and > >>back. > > > > Tempting as it is, I don't think this covers all cases. For example, > > in those cases where RS485 direction control must be done 100% in > > software, the software needs to have a way to flush (sync) software > > buffers, poll the hardware FIFOs and TSR (not THR), etc. > >I just meant to hide those low-level issues you mention in the >enter/exitTransmit modes. If the system has dedicated RS485 hardware then the underlying kernel or device driver may know about it and all of the hassle can be conveniently encapsulated in some enter/exitTransmit methods -- but in this case you can also skip these and just have the driver enable transmit mode as long as it has data to transmit, and stay in receive mode otherwise. If the system has a UART that can be configured as RS232 or RS485 then you may need to tell the kernel or device driver to enter RS485 mode explicitly. Your approach may work there as well. If the system does not have dedicated RS485 hardware and you are using an external RS232-RS485 protocol converter (a very common case) then the driver and kernel probably don't know about that and you have to take care at the application level (javax.comm doesn't even need to know this converter exists), and in order to that you may need to do different things depending on the specific converter you're using. > > > > Or, for example, for those UARTs that do automatic RS485 direction > > control with a configurable turnaround delay, how would you configure > > this turnaround delay from the application? > >Mmh, perhaps in a similar way as you configure timeouts? >Isn't this 'just' a timeout value? Yes, but this is just a specific parameter that you can configure in a specific type of UART (an EXAR UART). Other UARTs might be different. The point I'm trying to make is that there are just too many parameters to have an API for each specific case. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 04:12:31 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 12:12:31 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C5CD7E.9030903@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> <44C5CD7E.9030903@sun.com> Message-ID: <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> At 09:51 25/07/2006, Paul Klissner wrote: >Guillermo Rodriguez Garcia wrote: > > At 19:41 24/07/2006, Paul Klissner wrote: > >> Guillermo Rodriguez wrote: > >>> Quoting Paul Klissner : > >>> > >>>>>> None of this is of any particular relevance to the basic underlying > >>>>>> question: > >>>>>> > >>>>>> Should the next JSR attempt to address the multi-drop abilities of > >>>> RS-485? > >>>>> What I would suggest is to just add a new 'ioctlex'-like method > >>>>> to the SerialPort API: A method that you'd use to pass platform- > >>>>> or implementation-specific info to the underlying driver or OS > >>>>> to do things such as "enabling RS485 mode" or "disable FIFOs" or > >>>>> "poll the TSR register". > >>>>> > >>>>> No need to define any function codes. This is for stuff that is > >>>>> platform- or implementation-specific and as such cannot be easily > >>>>> abstracted anyway. > >>>> Detrimental to platform independence. > >>> Yes, it is. But as you go closer and closer to the hardware level some > >>> things are by nature platform-dependent, and sometimes just cannot be > >>> solved in a platform-independent way. In these cases, is it better to > >>> have no solution at all than having one that is less than perfect? > >>> Put it another way, would you prefer having people say "I just cannot > >>> do this in Java; I'll go somewhere else" rather than "I can do this > >>> in Java -- only not in a platform-independent way" ? > >> If there isn't a reasonable way to abstract it out, then > >> why use Java? > > > > If an application can be 99% platform independent with small bits > > being not portable, why *not* use Java? I'd prefer to see people > > using Java to write non-portable applications than having them > > use C instead. > > > > I believe that Java should promote platform neutrality, but that > > does not necessarily mean precluding the use of anything that is > > NOT platform independent. And let's face it, if you are using > > javax.comm to talk to some serial device directly, then chances > > are you are already tied to some specific hardware anyway. > > > > Also, some people (myself included) think that Java can also be > > used as a systems programming language, not only for applications. > > For many embedded platforms this is certainly the case. In our > > platform we even write device drivers directly in Java. I would > > imagine the Sun SPOT team (www.sunspotworld.com) supports a > > similar view. > > > > If people needs to do non-portable stuff and wants to do it in > > Java I'd rather have them do it in Java than tell them to do it > > in C instead. > >That sounds a bit evangelizing. Could be, but then what's wrong with that? As I said there is people that thinks that Java can be perfectly adequate for system level programming -- especially for embedded platforms. I guess the whole issue is whether it is better to have no solution at all for a specific problem than a solution that is not perfect (in this context a "perfect" solution is one that is portable and platform-independent). I think a solution that is not perfect is better than no solution. If I understand correctly you say that you prefer to have no Java solution (and have people use C) rather than one that is not portable. >I think C is perfectly viable >for some jobs, and might even be preferable in some cases, for example >in some cases where performance or space is a factor. I feel it isn't >right to corrupt an API with hacks for the goal of enticing users >to Java, even for all the 'right' reasons. > > >> If someone really needs to do funky things with the hardware, > >> why wouldn't that be put in the native back end? > > > > But nobody said the functionality can't be implemented in the > > native back end. However you still need an application level API > > to enable/disable it. > >Sure, but the functions, if really along the lines of the defined >standard, can be abstracted, rather than cheat with a general >purpose hack-all ioctl-like interface that just begs to be abused, >lending itself to a litany of non-portable applications. Well, I didn't specifically say there's no way to abstract these functions. I only said that it is not easy, and that I don't know of any reasonable way to do it. But if others can find a way, that is fine of course. >I maintain we should scope the project appropriately, then take >our best shot at a reasonably complete set of abstract functions, >and improve it if necessary over time (alpha and beta, release >candidates? And then update the API in a backward-compatible way >based on feedback after FCS if necessary), rather than add an >everything-but-the-kitchen-sink escape clause method. > >A determined programmer facing a corner case can figure out a way >to accomplish the goal in most cases. Even if the API doesn't provide >an ioctl call, it is possible to create implementation classes that >mak methods visible outsidethe scope of the API-defined methods. > >For example, if I am implementing class Foo in FooImpl.java, >And Foo.java defines interface methods a(), b() and c(), >FooImpl.java can also have public methods d(), e() and f(), which can >be accessed from the application by casting a Foo object into >a FooImpl object. This is one way to provide a back door without >compromising the core API itself to do it. This puts the >responsibility of breaking platform independence on the developers >and not on the designers. Yes, that may be a good way to do it. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 04:21:31 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 12:21:31 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> Message-ID: <7.0.1.0.0.20060725121958.03714668@sms.nl> Hi Trent, At 10:57 25/07/2006, Trent Jarvi wrote: > >> Perhaps the javax.com namespace is just wrong. I think thats a larger > >> issue we are not well prepared to answer. We do have a larger group > >> participating so there is interest beyond our current solution. > > > > My concern was not about the name specifically, but about the idea that > > a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, > > IrDA, etc. Looking from a distance all of these may look similar but > > the fact is, they have little to do with each other (apart from being > > 'communication protocols' or 'buses') > > > >Hi Guillermo > >Interesting name. > >Fair enough. My thoughts are that if it can't be unified in the kernel we >are out of our skulls trying to do it in user space. Hacks trying to do >such will sure to be in open solaris or linux symposiums about why user >space sucks. > >But there is a minimal bit that overlapps that is what most users want. >If we limit the scope, it isnt that hard of a problem. By limiting the >scope we also limit our deliverables. If you have an interest in a >specific area it will probably not be enough. Yes, you are right. But isn't this 'minimal bit that overlaps' what we have already? (basically support for UART-based serial ports plus minimal support for parallel ports) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From lyon at docjava.com Tue Jul 25 05:44:43 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 25 Jul 2006 07:44:43 -0400 Subject: [Rxtx] 7 RS485 questions... In-Reply-To: <7.0.1.0.0.20060725115736.03706a38@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: Hi All, 1. Does anyone have a sense for how much larger the JSR would be if it embraced a multi-drop protocol, like RS485? 2. Do we address collision detection and addressing in RS485? 3. How would collision detection and addressing impact the size of the specification? 4. Would JSR80 (and, perhaps a RS485-USB converter) be the more appropriate place for RS485 support? 5. Is RS485 Transmission controlled by RTS, and the TxD line? 6. How tight is the windows timing on control of the RTS line? 7. Does an RTS controlled RS485 converter work well at high baud rates under windows? Thanks! - Doug From naranjo.manuel at gmail.com Tue Jul 25 06:29:45 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Tue, 25 Jul 2006 09:29:45 -0300 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725094602.036cec00@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> Message-ID: <44C60EB9.5000803@gmail.com> Guillermo Rodriguez Garcia escribi?: > My concern was not about the name specifically, but about the idea that > a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, > IrDA, etc. Looking from a distance all of these may look similar but > the fact is, they have little to do with each other (apart from being > 'communication protocols' or 'buses') > I think Guillermo is right, all ports has in common that they are buses. A stupid idea but why don't declarate the package javax.bus and make javax.comm a dedicated namespace to rs232 and parallell to mantain backward compatibility, obviously the classes at javax.comm should extend classes from javax.bus. Regards, Manuel From j.a.horsmeier at wanadoo.nl Tue Jul 25 07:00:17 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Tue, 25 Jul 2006 15:00:17 +0200 Subject: [Rxtx] 7 RS485 questions... In-Reply-To: Message-ID: <05a701c6afea$47002e00$0a01a8c0@CALVIN> Douglas Lyon wrote: > 1. Does anyone have a sense for how much larger the JSR would > be if it embraced a multi-drop protocol, like RS485? The RS485 multidrop capability all resides on top of the communication layer, i.e. all transmitters but one are disabled (all devices are just listening). When the message has been sent at most one device answers (see 2) > 2. Do we address collision detection and addressing in RS485? Addressing a device is also implemented on top of the communication layer. If/when two devices happen to have the same address it would be disastrous. An address is defined by the protocol, e.g. modbus allows for 250 or so different addresses but another protocol might allow for 2^32 different devices hooked up on one two wire cable. > 3. How would collision detection and addressing impact the size of > the specification? IMHO it's none of rxtx's business, it's a configuration error on the devices if that happens. > 4. Would JSR80 (and, perhaps a RS485-USB converter) be the > more appropriate place for RS485 support? Don't know. > 5. Is RS485 Transmission controlled by RTS, and the TxD line? Two wire RS485 doesn't have a RTS line. It's all in the timing. The half duplex protocol is extremely simple: one master sends, all devices listen, after that at most one device enables its transmitter and sends something back. > 6. How tight is the windows timing on control of the RTS line? Before a device enables its transmitter it should wait a bit because of cable lengths and the other device that must *disable* its transmitter. It's all up to the devices and rxtx can do nothing about it. > 7. Does an RTS controlled RS485 converter work well at high baud > rates under windows? Baud rates aren't the problem; cable lengths are the problem, sensitivity for distortion are the problem. The wait time between en/disabling transmitters can be configured in the devices and can be software controlled on the pc. kind regards, Jos From tjarvi at qbang.org Tue Jul 25 07:08:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 07:08:53 -0600 (MDT) Subject: [Rxtx] 7 RS485 questions... In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: > 5. Is RS485 Transmission controlled by RTS, and the TxD line? This is done when using EIA232 to drive RS485 with no adaptor. This is the RS485 hack that is in RXTX 2.1 that never went anyplace. I discovered no typical kernel will openly support this line of thought. It is not maintainable. There are hardware solutions. Off the top of my head it required < 10 ms responses and typical kernels + java do 10 ms responses. Realtime kernels or special kernel drivers are required. It is possible but not supportable. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Tue Jul 25 07:46:52 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 08:46:52 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <005b01c6afbc$794fc060$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> Message-ID: <44C620CC.6090901@cox.net> Martin Schoeberl wrote: > We can model it platform independent with two methods: > > enterTransmit() and extiTransmit() to do whatever is necessary > on the underlying platform to switch to RS485 transmit mode and > back. Or, do what is typically done, and use a single write operation as the indication of a 'packet' that will let the underlying RS-485/422 driver assert the appropriate signalling. Gregg Wonderly From guille at sms.nl Tue Jul 25 07:48:04 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 15:48:04 +0200 Subject: [Rxtx] 7 RS485 questions... In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: <7.0.1.0.0.20060725154329.036deb18@sms.nl> Hi Doug, Some answers below. At 13:44 25/07/2006, Dr. Douglas Lyon wrote: >Hi All, > >1. Does anyone have a sense for how much larger the JSR would be >if it embraced a multi-drop protocol, like RS485? As I've said in other mails RS485 is in essence just a UART-based serial port interface just like RS232. The only functional difference is that it is multi-drop and half-duplex so there must be a way for nodes to switch between transmit and receive modes but then the RS485 standard does not tell you when or how you should do that -- this depends on the upper layer protocols (for example Modbus) >2. Do we address collision detection and addressing in RS485? Collision detection and addressing are not defined by the RS485 standard. Upper layer protocols such as Modbus take care of that. >3. How would collision detection and addressing impact the size of >the specification? See above. >4. Would JSR80 (and, perhaps a RS485-USB converter) be the more appropriate >place for RS485 support? I don't think so. As I said RS485 is just a serial port like RS232 is. >5. Is RS485 Transmission controlled by RTS, and the TxD line? Some RS232-RS485 protocol converters use the RTS line as a control signal to switch between transmit and receive modes. Others use DTR. Others do not use any of them. >6. How tight is the windows timing on control of the RTS line? Depends on the upper layer protocols, e.g. Modbus. Not defined by RS485. >7. Does an RTS controlled RS485 converter work well at high baud >rates under windows? Depends on how tight the timing is. For some applications it may work well but for many probably won't. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 09:22:09 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Tue, 25 Jul 2006 17:22:09 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C620CC.6090901@cox.net> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> Message-ID: <1153840929.44c6372186f67@webmail.eatserver.nl> Hi Gregg, Quoting Gregg Wonderly : > Martin Schoeberl wrote: > > We can model it platform independent with two methods: > > > > enterTransmit() and extiTransmit() to do whatever is necessary > > on the underlying platform to switch to RS485 transmit mode and > > back. > > Or, do what is typically done, and use a single write operation as the > indication of a 'packet' that will let the underlying RS-485/422 driver > assert > the appropriate signalling. The problem with this is that there is no guarantee that a single call to the write method of the OutputStream associated with a javax.comm SerialPort will translate to a single write to the underlying device driver -- this depends on the javax.comm implementation. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From Paul.Klissner at Sun.COM Tue Jul 25 09:35:19 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Tue, 25 Jul 2006 08:35:19 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C60EB9.5000803@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> <44C60EB9.5000803@gmail.com> Message-ID: <44C63A37.8080406@sun.com> Manuel Francisco Naranjo wrote: > Guillermo Rodriguez Garcia escribi?: >> My concern was not about the name specifically, but about the idea that >> a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, >> IrDA, etc. Looking from a distance all of these may look similar but >> the fact is, they have little to do with each other (apart from being >> 'communication protocols' or 'buses') >> > I think Guillermo is right, all ports has in common that they are buses. > A stupid idea but why don't declarate the package javax.bus and make > javax.comm a dedicated namespace to rs232 and parallell to mantain > backward compatibility, obviously the classes at javax.comm should > extend classes from javax.bus. I like the initial sound of that idea too and was starting to think along those lines myself. But what would be the points of commonality to extend? Device mapping, ownership? Read, write, type, status? Too late for javax.usb (JSR80) very complex Bus and for the most part cast in stone. And 'bus' has such a wide scope. Also that would imply two downloads to install any given bus support, which might not be the end of the world. And maybe two JSRs? Paul From martin at jopdesign.com Tue Jul 25 09:37:12 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 17:37:12 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> Message-ID: <00c801c6b000$33a68f00$0c28a8c0@luna> >> Martin Schoeberl wrote: >> > We can model it platform independent with two methods: >> > >> > enterTransmit() and extiTransmit() to do whatever is necessary >> > on the underlying platform to switch to RS485 transmit mode and >> > back. >> >> Or, do what is typically done, and use a single write operation as the >> indication of a 'packet' that will let the underlying RS-485/422 driver >> assert >> the appropriate signalling. > > The problem with this is that there is no guarantee that a single call > to the write method of the OutputStream associated with a javax.comm > SerialPort will translate to a single write to the underlying device > driver -- this depends on the javax.comm implementation. > I completely agree - it's still a stream and not a packet. This is similar to a single write to a TCP/IP socket. There is no guarantee that you get this data as a single packet/single read on the other side. However, I've seen a lot of programs assuming that this happens ;-) Martin From gergg at cox.net Tue Jul 25 10:15:41 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 11:15:41 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725082124.036309e0@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> Message-ID: <44C643AD.6020604@cox.net> Guillermo Rodriguez Garcia wrote: > At 19:34 24/07/2006, Gregg Wonderly wrote: >>Then, there will be a place for others interesting in SPI, i2C, USB and other >>things to get started with providing access to devices that are also >>interesting >>in Java applications, and directly, in embedded Java applications. > > I do agree that the best a hardware port SPI definition (where SPI = Service > Provider Interface, not the SPI protocol) is a good thing to have to support > serial ports layered over other transports. However these are still serial > ports at the end. I still don't think the javax.comm API is well suited to > "any" serial bus such as I2C, SPI, etc. Yes, absolutely these other wire protocols are different. As I tried to say before, I think that the javax.comm API works fine for my needs. I think that we need to keep it around, no matter what else happens. So, for me, there are a few choices. 1. Create a new JSR to formalize the existing API and include some hardwired JNI code to provide port enumeration and access. 2. Create a new JSR to create a port abstraction SPI to allow JVM providers to enumerate all kinds of port/circuit based hardware to the JVM. Create an implementation of the existing javax.comm API that uses this SPI. 3. Just implement some JNI and Java libraries post them on sourceforge/java.net and let people have at them. For 1 and 2, you'll have to get the JCP to approve that the JSR is worth making a standard. Option 3 doesn't really solve a problem as much as it creates a new way to deal with an existing problem. I think 2 is the most desireable way to go. It really will open the door for more access to hardware from Java! Gregg Wonderly From joachim at buechse.de Tue Jul 25 10:17:07 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 25 Jul 2006 18:17:07 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <00c801c6b000$33a68f00$0c28a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: Just trigger writing on flush(). It is perfectly legal for an Outputstream implementation to do do nothing until flush is called and the documentation of OutputStream.flush reads: "Flushes this output stream and forces any buffered output bytes to be written out. The general contract of flush is that calling it is an indication that, if any bytes previously written have been buffered by the implementation of the output stream, such bytes should immediately be written to their intended destination." As RS485 is a "dont speak up unless requested" protocol, a mandatory flush after write seems like the way to go to me No client can prevent another client from writing, so there is no point in keeping the output-drivers enabled after all data currently buffered has been written. So flush() should trigger "enterTransmit, writePacket[s], exitTransmit". If the service provider (ie concrete implementation of the flush method) decides that the write is inapropriate at the moment (ie because of a higher level arbitration protocol that might be implemented by the service provider) it will simply block the flush or throw an IOException (preferably after some sort of timeout). Regards, Joachim PS: It is great to see all the motivation that is brought forward on this list regarding the future. It would be great if only 10% of that motivation could be transformed into a cleanup and extension of the existing code. The current code access model seems rather inappropriate for the prototyping of the ideas beeing presented. Trent can we get a "contributions" branch with "free" access. On 25.07.2006, at 17:37, Martin Schoeberl wrote: >>> Martin Schoeberl wrote: >>>> We can model it platform independent with two methods: >>>> >>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>> on the underlying platform to switch to RS485 transmit mode and >>>> back. >>> >>> Or, do what is typically done, and use a single write operation >>> as the >>> indication of a 'packet' that will let the underlying RS-485/422 >>> driver >>> assert >>> the appropriate signalling. >> >> The problem with this is that there is no guarantee that a single >> call >> to the write method of the OutputStream associated with a javax.comm >> SerialPort will translate to a single write to the underlying device >> driver -- this depends on the javax.comm implementation. >> > I completely agree - it's still a stream and not a packet. > > This is similar to a single write to a TCP/IP socket. There > is no guarantee that you get this data as a single packet/single > read on the other side. However, I've seen a lot of programs > assuming that this happens ;-) > > Martin > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Tue Jul 25 10:34:59 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Tue, 25 Jul 2006 18:34:59 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <1153845299.44c64833920bd@webmail.eatserver.nl> Hi Joachim, That is a very nice approach which I think would work well as far as the underlying device driver knows about RS485. However it still does not solve the problem with external protocol converters where the device driver only knows about regular UARTs and RTS or DTR must be used to toggle direction of the converter. Guillermo Quoting Joachim Buechse : > Just trigger writing on flush(). It is perfectly legal for an > Outputstream implementation to do do nothing until flush is called > and the documentation of OutputStream.flush reads: > > "Flushes this output stream and forces any buffered output bytes to > be written out. The general contract of flush is that calling it is > an indication that, if any bytes previously written have been > buffered by the implementation of the output stream, such bytes > should immediately be written to their intended destination." > > As RS485 is a "dont speak up unless requested" protocol, a mandatory > flush after write seems like the way to go to me > > No client can prevent another client from writing, so there is no > point in keeping the output-drivers enabled after all data currently > buffered has been written. So flush() should trigger "enterTransmit, > writePacket[s], exitTransmit". If the service provider (ie concrete > implementation of the flush method) decides that the write is > inapropriate at the moment (ie because of a higher level arbitration > protocol that might be implemented by the service provider) it will > simply block the flush or throw an IOException (preferably after some > sort of timeout). > > Regards, > Joachim > > PS: It is great to see all the motivation that is brought forward on > this list regarding the future. It would be great if only 10% of that > motivation could be transformed into a cleanup and extension of the > existing code. The current code access model seems rather > inappropriate for the prototyping of the ideas beeing presented. > Trent can we get a "contributions" branch with "free" access. > > > On 25.07.2006, at 17:37, Martin Schoeberl wrote: > > >>> Martin Schoeberl wrote: > >>>> We can model it platform independent with two methods: > >>>> > >>>> enterTransmit() and extiTransmit() to do whatever is necessary > >>>> on the underlying platform to switch to RS485 transmit mode and > >>>> back. > >>> > >>> Or, do what is typically done, and use a single write operation > >>> as the > >>> indication of a 'packet' that will let the underlying RS-485/422 > >>> driver > >>> assert > >>> the appropriate signalling. > >> > >> The problem with this is that there is no guarantee that a single > >> call > >> to the write method of the OutputStream associated with a javax.comm > >> SerialPort will translate to a single write to the underlying device > >> driver -- this depends on the javax.comm implementation. > >> > > I completely agree - it's still a stream and not a packet. > > > > This is similar to a single write to a TCP/IP socket. There > > is no guarantee that you get this data as a single packet/single > > read on the other side. However, I've seen a lot of programs > > assuming that this happens ;-) > > > > Martin > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- http://www.snijder.com/ SNIJDER Micro Systems From guille at sms.nl Tue Jul 25 10:44:56 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Tue, 25 Jul 2006 18:44:56 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C643AD.6020604@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <44C643AD.6020604@cox.net> Message-ID: <1153845896.44c64a8890968@webmail.eatserver.nl> Hi Gregg, Quoting Gregg Wonderly : > Guillermo Rodriguez Garcia wrote: > > At 19:34 24/07/2006, Gregg Wonderly wrote: > >>Then, there will be a place for others interesting in SPI, i2C, USB and > other > >>things to get started with providing access to devices that are also > >>interesting > >>in Java applications, and directly, in embedded Java applications. > > > > I do agree that the best a hardware port SPI definition (where SPI = > Service > > Provider Interface, not the SPI protocol) is a good thing to have to > support > > serial ports layered over other transports. However these are still serial > > ports at the end. I still don't think the javax.comm API is well suited to > > "any" serial bus such as I2C, SPI, etc. > > Yes, absolutely these other wire protocols are different. As I tried to say > > before, I think that the javax.comm API works fine for my needs. I think > that > we need to keep it around, no matter what else happens. So, for me, there > are a > few choices. > > 1. Create a new JSR to formalize the existing API and include some hardwired > JNI > code to provide port enumeration and access. > > 2. Create a new JSR to create a port abstraction SPI to allow JVM providers > to > enumerate all kinds of port/circuit based hardware to the JVM. Create an > implementation of the existing javax.comm API that uses this SPI. As an embedded Java vendor we work very close to the hardware level and have to deal daily with dozens of different types of ports and communication buses and protocols. Based on our experience I think that a SPI for "all kinds of port/circuit based hardware" is just too generic and not really practical. I think having a Service Provider Interface within javax.comm so that custom serial port implementations can be plugged in is a very good idea. However I don't think it is convenient to have it as a separate JSR and then with such a broad scope. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From joachim at buechse.de Tue Jul 25 10:56:12 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 25 Jul 2006 18:56:12 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <1153845299.44c64833920bd@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> <1153845299.44c64833920bd@webmail.eatserver.nl> Message-ID: In this case you need to configure your port with a different device driver. You may optionally take an existing port, wrap it up in a "wrapping device driver" implemented in Java and add it to the list of ports as a new port... In any case the core application should not care. On 25.07.2006, at 18:34, Guillermo Rodriguez wrote: > Hi Joachim, > > That is a very nice approach which I think would work well as far > as the underlying device driver knows about RS485. > > However it still does not solve the problem with external protocol > converters where the device driver only knows about regular UARTs > and RTS or DTR must be used to toggle direction of the converter. > > Guillermo > > Quoting Joachim Buechse : > >> Just trigger writing on flush(). It is perfectly legal for an >> Outputstream implementation to do do nothing until flush is called >> and the documentation of OutputStream.flush reads: >> >> "Flushes this output stream and forces any buffered output bytes to >> be written out. The general contract of flush is that calling it is >> an indication that, if any bytes previously written have been >> buffered by the implementation of the output stream, such bytes >> should immediately be written to their intended destination." >> >> As RS485 is a "dont speak up unless requested" protocol, a mandatory >> flush after write seems like the way to go to me >> >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). >> >> Regards, >> Joachim >> >> PS: It is great to see all the motivation that is brought forward on >> this list regarding the future. It would be great if only 10% of that >> motivation could be transformed into a cleanup and extension of the >> existing code. The current code access model seems rather >> inappropriate for the prototyping of the ideas beeing presented. >> Trent can we get a "contributions" branch with "free" access. >> >> >> On 25.07.2006, at 17:37, Martin Schoeberl wrote: >> >>>>> Martin Schoeberl wrote: >>>>>> We can model it platform independent with two methods: >>>>>> >>>>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>>>> on the underlying platform to switch to RS485 transmit mode and >>>>>> back. >>>>> >>>>> Or, do what is typically done, and use a single write operation >>>>> as the >>>>> indication of a 'packet' that will let the underlying RS-485/422 >>>>> driver >>>>> assert >>>>> the appropriate signalling. >>>> >>>> The problem with this is that there is no guarantee that a single >>>> call >>>> to the write method of the OutputStream associated with a >>>> javax.comm >>>> SerialPort will translate to a single write to the underlying >>>> device >>>> driver -- this depends on the javax.comm implementation. >>>> >>> I completely agree - it's still a stream and not a packet. >>> >>> This is similar to a single write to a TCP/IP socket. There >>> is no guarantee that you get this data as a single packet/single >>> read on the other side. However, I've seen a lot of programs >>> assuming that this happens ;-) >>> >>> Martin >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > > -- > http://www.snijder.com/ > SNIJDER Micro Systems > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From martin at jopdesign.com Tue Jul 25 11:13:10 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 19:13:10 +0200 Subject: [Rxtx] JSR Direction; packetizing writes References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com><005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net><1153840929.44c6372186f67@webmail.eatserver.nl><00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <000f01c6b00d$9bcc51c0$0202a8c0@luna> > No client can prevent another client from writing, so there is no > point in keeping the output-drivers enabled after all data currently > buffered has been written. So flush() should trigger "enterTransmit, > writePacket[s], exitTransmit". If the service provider (ie concrete > implementation of the flush method) decides that the write is > inapropriate at the moment (ie because of a higher level arbitration > protocol that might be implemented by the service provider) it will > simply block the flush or throw an IOException (preferably after some > sort of timeout). Not only flush() would mean enterTransmit(). With your idea each write should enable the driver, but only flush() can disable the driver after the last byte is written. RS485 is a beast. E.g. some driver chips need a few us (100us for a Maxim 1480B!) from output enable till output low/high. On a different application we had to wait a little bit before disabling the output driver to have a clear '1' on the bus as it took too long for the termination resistors to force the bus to 1. I can imagine that this is not really funny with general RS232/RS485 converters. Martin From joachim at buechse.de Tue Jul 25 11:42:18 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 25 Jul 2006 19:42:18 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <000f01c6b00d$9bcc51c0$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com><005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net><1153840929.44c6372186f67@webmail.eatserver.nl><00c801c6b000$33a68f00$0c28a8c0@luna> <000f01c6b00d$9bcc51c0$0202a8c0@luna> Message-ID: Simple answer: NO. You can not control the timing of the Java VM (especially not on ME) and hence you do not want to enable the outputs before you have all data collected. The timings you mention are all in the implementation space of the device driver. The core application should not care, neither should the javax.comm api in my opinion. Should I happen to be the pour soul that tries to implement an RS485 device driver reference implementation I will try to remember your email and add appropriate properties. Regards, Joachim On 25.07.2006, at 19:13, Martin Schoeberl wrote: >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). > > Not only flush() would mean enterTransmit(). With your idea each > write should enable the driver, but only flush() can disable > the driver after the last byte is written. > > RS485 is a beast. E.g. some driver chips need a few us (100us > for a Maxim 1480B!) from output enable till output low/high. > > On a different application we had to wait a little bit before > disabling the output driver to have a clear '1' on the bus as it took > too long for the termination resistors to force the bus to 1. > > I can imagine that this is not really funny with general > RS232/RS485 converters. > > Martin > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Tue Jul 25 12:50:20 2006 From: jredman at ergotech.com (Jim Redman) Date: Tue, 25 Jul 2006 12:50:20 -0600 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <44C667EC.2070602@ergotech.com> The horror! This would be terribly inefficient. Especially in serial protocols you need to start getting bits on the wire as soon as possible. It could also have some timeout implications. Jim Joachim Buechse wrote: > Just trigger writing on flush(). It is perfectly legal for an > Outputstream implementation to do do nothing until flush is called > and the documentation of OutputStream.flush reads: > > "Flushes this output stream and forces any buffered output bytes to > be written out. The general contract of flush is that calling it is > an indication that, if any bytes previously written have been > buffered by the implementation of the output stream, such bytes > should immediately be written to their intended destination." > > As RS485 is a "dont speak up unless requested" protocol, a mandatory > flush after write seems like the way to go to me > > No client can prevent another client from writing, so there is no > point in keeping the output-drivers enabled after all data currently > buffered has been written. So flush() should trigger "enterTransmit, > writePacket[s], exitTransmit". If the service provider (ie concrete > implementation of the flush method) decides that the write is > inapropriate at the moment (ie because of a higher level arbitration > protocol that might be implemented by the service provider) it will > simply block the flush or throw an IOException (preferably after some > sort of timeout). > > Regards, > Joachim > > PS: It is great to see all the motivation that is brought forward on > this list regarding the future. It would be great if only 10% of that > motivation could be transformed into a cleanup and extension of the > existing code. The current code access model seems rather > inappropriate for the prototyping of the ideas beeing presented. > Trent can we get a "contributions" branch with "free" access. > > > On 25.07.2006, at 17:37, Martin Schoeberl wrote: > >>>> Martin Schoeberl wrote: >>>>> We can model it platform independent with two methods: >>>>> >>>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>>> on the underlying platform to switch to RS485 transmit mode and >>>>> back. >>>> Or, do what is typically done, and use a single write operation >>>> as the >>>> indication of a 'packet' that will let the underlying RS-485/422 >>>> driver >>>> assert >>>> the appropriate signalling. >>> The problem with this is that there is no guarantee that a single >>> call >>> to the write method of the OutputStream associated with a javax.comm >>> SerialPort will translate to a single write to the underlying device >>> driver -- this depends on the javax.comm implementation. >>> >> I completely agree - it's still a stream and not a packet. >> >> This is similar to a single write to a TCP/IP socket. There >> is no guarantee that you get this data as a single packet/single >> read on the other side. However, I've seen a lot of programs >> assuming that this happens ;-) >> >> Martin >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From jredman at ergotech.com Tue Jul 25 12:53:02 2006 From: jredman at ergotech.com (Jim Redman) Date: Tue, 25 Jul 2006 12:53:02 -0600 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <000f01c6b00d$9bcc51c0$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com><005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net><1153840929.44c6372186f67@webmail.eatserver.nl><00c801c6b000$33a68f00$0c28a8c0@luna> <000f01c6b00d$9bcc51c0$0202a8c0@luna> Message-ID: <44C6688E.8040202@ergotech.com> Since we now seem to have entered a discussion of how to switch receive/transmit on 485 lines, I can tell you from experience that you cannot reliably do this from Java. Java just is not fast enough. I spend some time trying to get this to work with RXTX and it would work _most_ of the time, but you need to be able to guarantee ms level response which you can't do in any system that doesn't have real-time capabilities. Jim Martin Schoeberl wrote: >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). > > Not only flush() would mean enterTransmit(). With your idea each > write should enable the driver, but only flush() can disable > the driver after the last byte is written. > > RS485 is a beast. E.g. some driver chips need a few us (100us > for a Maxim 1480B!) from output enable till output low/high. > > On a different application we had to wait a little bit before > disabling the output driver to have a clear '1' on the bus as it took > too long for the termination resistors to force the bus to 1. > > I can imagine that this is not really funny with general > RS232/RS485 converters. > > Martin > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Tue Jul 25 13:37:14 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 14:37:14 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725115736.03706a38@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: <44C672EA.1080604@cox.net> Guillermo Rodriguez Garcia wrote: > At 11:25 25/07/2006, Martin Schoeberl wrote: >>Mmh, perhaps in a similar way as you configure timeouts? >>Isn't this 'just' a timeout value? > > Yes, but this is just a specific parameter that you can configure in a > specific type of UART (an EXAR UART). Other UARTs might be different. The > point I'm trying to make is that there are just too many parameters to > have an API for each specific case. In my earlier example/proposal, I included the ability for attributes of a port to be expressed as a collection of enumeration values for standard things. That would be fine for simple things like Input, Output, Sync, Async etc. When there are specific attributes of specific hardware, the vendor is going to have to provide a way to configure those attributes. One of the primary mechanisms in Java to do this is the JavaBean pattern that can be manifested in a Map type object when an API needs to preexist. So, we can provide an mechanism for propagating random attributes using a Map argument to a method such as public void setConfig( Map params ) throws IOException; public Map getConfig() throws IOException; Then, there is a conduit in and out of the driver that the user can use without needing more standards/spec'd code/API. This isn't much different than an ioctl(2) like mechanism, but it feels more Java like. A URL like mechanism, such as that which JDBC drivers use, could also be attractive. I've also wanted to replace java.net with the J2ME connection based mechanism as well. We might consider looking at the J2ME connector architecture to see if there is any gain in using some of that experience. Gregg Wonderly From gergg at cox.net Tue Jul 25 13:38:42 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 14:38:42 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> <44C5CD7E.9030903@sun.com> <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> Message-ID: <44C67342.9020402@cox.net> Guillermo Rodriguez Garcia wrote: > At 09:51 25/07/2006, Paul Klissner wrote: >>For example, if I am implementing class Foo in FooImpl.java, >>And Foo.java defines interface methods a(), b() and c(), >>FooImpl.java can also have public methods d(), e() and f(), which can >>be accessed from the application by casting a Foo object into >>a FooImpl object. This is one way to provide a back door without >>compromising the core API itself to do it. This puts the >>responsibility of breaking platform independence on the developers >>and not on the designers. > > Yes, that may be a good way to do it. The J2ME connector architecture is an example of a place where this is done. Gregg Wonderly From Paul.Klissner at Sun.COM Tue Jul 25 14:02:40 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Tue, 25 Jul 2006 13:02:40 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C67342.9020402@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> <44C5CD7E.9030903@sun.com> <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> <44C67342.9020402@cox.net> Message-ID: <44C678E0.90209@sun.com> Gregg Wonderly wrote: > Guillermo Rodriguez Garcia wrote: >> At 09:51 25/07/2006, Paul Klissner wrote: >>> For example, if I am implementing class Foo in FooImpl.java, >>> And Foo.java defines interface methods a(), b() and c(), >>> FooImpl.java can also have public methods d(), e() and f(), which can >>> be accessed from the application by casting a Foo object into >>> a FooImpl object. This is one way to provide a back door without >>> compromising the core API itself to do it. This puts the >>> responsibility of breaking platform independence on the developers >>> and not on the designers. >> Yes, that may be a good way to do it. > > The J2ME connector architecture is an example of a place where this is done. It's how I debugged my javax.usb implementations. Paul From Pawan.Kharbanda at dot.state.co.us Tue Jul 25 14:02:53 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 25 Jul 2006 14:02:53 -0600 Subject: [Rxtx] Strange error (show stopper) Message-ID: <939A619A756047469C41EE9BA51890FB0429DFA4@hqexchange3.dot.state.co.us> Joachim, I believe it's the same problem that I reported earlier (Thread deadlocks/Locked Ports), I am not a C person so don't know exactly whatz going in the native code but was able to find a workaround for right now by synchronizing the "interruptEventLoop" and "eventLoop" methods in the RXTXPort class. It helped but is not the right solution, I still find the deadlocks but not as often as I used too. A fix for this will be highly appreciated. I have some Test Classes that I have posted earlier to simulate the problem. ~pk -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Joachim Buechse Sent: Monday, July 24, 2006 2:13 AM To: RXTX Developers and Users Subject: Re: [Rxtx] Strange error (show stopper) The pthread_kill is followed by a sleep. When the sleep returns the structure is damaged. I did not find the source that overwrites the closing field - it is correctly set by the exiting drain thread. But something overwrites it afterwards. I currently believe that this existed for some time but was never seen because the previous versions did not rely on the structure to be in good shape when tearing down connections. However I may be completely wrong and it is an OSX problem. To help me find the source, it would be nice to get some indications what the 2 debug lines I suggested return on other platforms. Joachim On 24.07.2006, at 05:27, Trent Jarvi wrote: > On Sat, 22 Jul 2006, Joachim Buechse wrote: > >> I just discovered a strange error in RXTX on OSX. SerialDemo.java >> manages to corrupt the event_info_structure by a simple >> OpenPort,ClosePort - this could be in relation to the deadlock >> problem that was reported recently. >> >> Could anyone try to reproduce this on Solaris or some other system >> which is neither WIN32 nor Linux (ie which uses a drain thread). >> >> In SerialImp.c : RXTXPort(interruptEventLoop) >> >> Apparently the event_info_structure gets corrupted shortly after >> >> pthread_kill(index->drain_tid, SIGABRT); >> >> In particular, the index->closing flag gets overwritten by a pointer >> value. > > Hi Joachim > > Interesting. I did run many tests with that code on may OSs. To be > fair, the tests are just starting to get into good shape again. I'm > still tagging releases with a bit of feel and not enough process. > I'll look at this some more tomorrow night. > > The SIGABRT was added recently as part of the close speedups. > Thats from > memory. I can provide the exact patch that introduced that tomorrow. > > -- > Trent Jarvi > tjarvi at qbang.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Jul 25 17:42:23 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 18:42:23 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153840929.44c6372186f67@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> Message-ID: <44C6AC5F.3060107@cox.net> Guillermo Rodriguez wrote: > The problem with this is that there is no guarantee that a single call > to the write method of the OutputStream associated with a javax.comm > SerialPort will translate to a single write to the underlying device > driver -- this depends on the javax.comm implementation. More specifically, it depends on a software layer that would targeted specifically at solving this problem for RS-485 and other transports which have blocking or packetizing issues. There are many. In amatuer radio, we have TNCs (radio modems) which will block things using newline separators in some modes, and 0xc0 in others. Gregg Wonderly From gergg at cox.net Tue Jul 25 17:46:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 18:46:11 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C63A37.8080406@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> <44C60EB9.5000803@gmail.com> <44C63A37.8080406@sun.com> Message-ID: <44C6AD43.1090302@cox.net> Paul Klissner wrote: > Also that would imply two downloads to install any given > bus support, which might not be the end of the world. > And maybe two JSRs? Why are we hovering around this "downloads" issue? If we create a JSR that covers everything needed for javax.comm compatibility, does that still imply that it would be an unincluded, optional part of the JVM? If that is still something that people will tolerate, I'm a little lost for words. Still today, I can use the old javax.comm support. If we're just going to recreate the same concerns, issues and limitations, then what's the point? Gregg Wonderly From gergg at cox.net Tue Jul 25 17:48:42 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 18:48:42 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <00c801c6b000$33a68f00$0c28a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <44C6ADDA.5040208@cox.net> Martin Schoeberl wrote: > I completely agree - it's still a stream and not a packet. > > This is similar to a single write to a TCP/IP socket. There > is no guarantee that you get this data as a single packet/single > read on the other side. However, I've seen a lot of programs > assuming that this happens ;-) For nearly forever, serialport drivers have operated in the mode that they send either everything up to the divider char, or a single char. This was specifically done for protocols such as modbus which have 1 1/2 bit time delays indicating end of packet. This kind of thing is something that needs to be maintained for serial protocols to work. A user has to have a way to send a single "packet" of data and make sure that it flows out of the uart uninterrupted. Gregg Wonderly From gergg at cox.net Tue Jul 25 18:03:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 19:03:11 -0500 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <939A619A756047469C41EE9BA51890FB0429DFA4@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB0429DFA4@hqexchange3.dot.state.co.us> Message-ID: <44C6B13F.1000306@cox.net> Kharbanda, Pawan wrote: > Joachim, > I believe it's the same problem that I reported earlier (Thread > deadlocks/Locked Ports), I am not a C person so don't know exactly whatz > going in the native code but was able to find a workaround for right now > by synchronizing the "interruptEventLoop" and "eventLoop" methods in the > RXTXPort class. It helped but is not the right solution, I still find > the deadlocks but not as often as I used too. > > A fix for this will be highly appreciated. I have some Test Classes that > I have posted earlier to simulate the problem. You can send SIGQUIT (signal #3) to unix JVMs to get a stacktrace of where all the threads are at and who owns what locks. Also, on windows, you can run the JVM in a DOS window and use CTRL-BREAK to get the stack trace. This won't go beyond the native level, but it might expose what you need to know. Gregg Wonderly From tjarvi at qbang.org Tue Jul 25 22:21:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 22:21:22 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6AC5F.3060107@cox.net> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: On Tue, 25 Jul 2006, Gregg Wonderly wrote: > Guillermo Rodriguez wrote: >> The problem with this is that there is no guarantee that a single call >> to the write method of the OutputStream associated with a javax.comm >> SerialPort will translate to a single write to the underlying device >> driver -- this depends on the javax.comm implementation. > > More specifically, it depends on a software layer that would targeted > specifically at solving this problem for RS-485 and other transports which have > blocking or packetizing issues. There are many. In amatuer radio, we have TNCs > (radio modems) which will block things using newline separators in some modes, > and 0xc0 in others. > I had looked into RS-485 some. It is daunting without proper hardware. One option is to do a native local tcpip/udp server to remove most of the the 'java issues.' Realtime patches comming down the pipe make it tempting to jump into the tarpit of failures. Beyond that, we should be very explicit about what type of RS-485 hardware we do support and it should not involve things that we have to control DTR/RTS in almost realtime (<20 ms). There are going to be people wanting < $5/EURO winmodem type solutions that will be nothing but problems. Thats doable by hacking kernel drivers but it will never get into mainstream kernels. I do not think thats reasonable from java and is even questionable in typical C. It will work fine until you start oracle... It would be nice to get RS-485 support in. Things like controlling low cost devices in houses, ... But cutting out the hardware isn't a viable solution in java. -- Trent Jarvi tjarvi From tjarvi at qbang.org Tue Jul 25 22:40:36 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 22:40:36 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6AD43.1090302@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> <44C60EB9.5000803@gmail.com> <44C63A37.8080406@sun.com> <44C6AD43.1090302@cox.net> Message-ID: On Tue, 25 Jul 2006, Gregg Wonderly wrote: > Paul Klissner wrote: >> Also that would imply two downloads to install any given >> bus support, which might not be the end of the world. >> And maybe two JSRs? > > Why are we hovering around this "downloads" issue? If we create a JSR that > covers everything needed for javax.comm compatibility, does that still imply > that it would be an unincluded, optional part of the JVM? If that is still > something that people will tolerate, I'm a little lost for words. Still today, > I can use the old javax.comm support. If we're just going to recreate the same > concerns, issues and limitations, then what's the point? > I don't have a problem with Sun shipping rxtx or whatever it becomes. They may have some legacy issues :) Just poking fun. The current state does not work for java users. Not having w32 support means about 80+% of the users do not have support. The rxtx w32 support is heavily influenced by cygwin so it wont change license out of respect for that project. If you really hate life and the LGPL, you can do a w32 port and the rest will just fall into place while you chase windows bugs for 5 years. Anything that dances around w32 support is just an academic waste of time. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Tue Jul 25 22:41:21 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 23:41:21 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: <44C6F271.2020604@cox.net> Trent Jarvi wrote: > I had looked into RS-485 some. It is daunting without proper hardware. > One option is to do a native local tcpip/udp server to remove most of the > the 'java issues.' Realtime patches comming down the pipe make it tempting > to jump into the tarpit of failures. Trent, there is not a way for a non-realtime OS to drive 485 hardware without the hardware taking care of the timing issues. But, a non-realtime OS can support software APIs which let the developer express in an API the types of things that a piece of hardware is capable of. Then we can have an API, and the hardware people and the OS people will provide the solutions where possible. > It would be nice to get RS-485 support in. Things like controlling > low cost devices in houses, ... But cutting out the hardware isn't a > viable solution in java. The 485 hardware devices will have to have non-realtime requirements associated with the controlling mechanisms. There are some of those. I'm mostly interested in having a 485 API for realtime java and/or the aJile and other uC environments which can provide realtime environments. Gregg Wonderly From tjarvi at qbang.org Tue Jul 25 22:54:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 22:54:44 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6F271.2020604@cox.net> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <44C6F271.2020604@cox.net> Message-ID: On Tue, 25 Jul 2006, Gregg Wonderly wrote: > Trent Jarvi wrote: >> I had looked into RS-485 some. It is daunting without proper hardware. >> One option is to do a native local tcpip/udp server to remove most of the >> the 'java issues.' Realtime patches comming down the pipe make it tempting >> to jump into the tarpit of failures. > > Trent, there is not a way for a non-realtime OS to drive 485 hardware without > the hardware taking care of the timing issues. But, a non-realtime OS can > support software APIs which let the developer express in an API the types of > things that a piece of hardware is capable of. Then we can have an API, and the > hardware people and the OS people will provide the solutions where possible. > >> It would be nice to get RS-485 support in. Things like controlling >> low cost devices in houses, ... But cutting out the hardware isn't a >> viable solution in java. > > The 485 hardware devices will have to have non-realtime requirements associated > with the controlling mechanisms. There are some of those. I'm mostly > interested in having a 485 API for realtime java and/or the aJile and other uC > environments which can provide realtime environments. > Hi Gregg I do not disagree with you but I have a problem with this (realtime java and/or the aJile and other Uc environements) being something I may be hearing bugs about 5 years from now. Is this really something that should be in the API or is it something that would make a nice niche market for support and services? Do the two really go together? If you like that market and I think there is a niche market there, great. This is a good area for SPI type interfaces where you could support it but it was not provided by default. -- Trent Jarvi tjarvi at qbang.org From guille at sms.nl Wed Jul 26 00:39:47 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 08:39:47 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C672EA.1080604@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> Message-ID: <7.0.1.0.0.20060726083751.03633188@sms.nl> At 21:37 25/07/2006, Gregg Wonderly wrote: >Guillermo Rodriguez Garcia wrote: > > At 11:25 25/07/2006, Martin Schoeberl wrote: > >>Mmh, perhaps in a similar way as you configure timeouts? > >>Isn't this 'just' a timeout value? > > > > Yes, but this is just a specific parameter that you can configure in a > > specific type of UART (an EXAR UART). Other UARTs might be different. The > > point I'm trying to make is that there are just too many parameters to > > have an API for each specific case. > >In my earlier example/proposal, I included the ability for >attributes of a port >to be expressed as a collection of enumeration values for standard >things. That >would be fine for simple things like Input, Output, Sync, Async >etc. When there >are specific attributes of specific hardware, the vendor is going to have to >provide a way to configure those attributes. One of the primary >mechanisms in >Java to do this is the JavaBean pattern that can be manifested in a Map type >object when an API needs to preexist. So, we can provide an mechanism for >propagating random attributes using a Map argument to a method such as > >public void setConfig( Map params ) throws IOException; >public Map getConfig() throws IOException; > >Then, there is a conduit in and out of the driver that the user can >use without >needing more standards/spec'd code/API. > >This isn't much different than an ioctl(2) like mechanism, This is exactly what I was thinking while reading your mail :) >but it feels more Java like. It would do the job as well and I would be happy with that. However Paul's proposal where implementation classes extend the core API as necessary might be more elegant (for the same reason that it is more elegant than ioctl) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Wed Jul 26 00:41:40 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 08:41:40 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6AC5F.3060107@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: <7.0.1.0.0.20060726084016.03633040@sms.nl> At 01:42 26/07/2006, Gregg Wonderly wrote: >Guillermo Rodriguez wrote: > > The problem with this is that there is no guarantee that a single call > > to the write method of the OutputStream associated with a javax.comm > > SerialPort will translate to a single write to the underlying device > > driver -- this depends on the javax.comm implementation. > >More specifically, it depends on a software layer that would targeted >specifically at solving this problem for RS-485 and other transports >which have >blocking or packetizing issues. There are many. In amatuer radio, >we have TNCs >(radio modems) which will block things using newline separators in >some modes, >and 0xc0 in others. Right. I meant that in general one cannot assume that writes to a stream will translate 1:1 to writes in every layer of the protocol stack (this is most often not the case.) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Wed Jul 26 00:44:57 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 08:44:57 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6ADDA.5040208@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> <44C6ADDA.5040208@cox.net> Message-ID: <7.0.1.0.0.20060726084203.036cd2b8@sms.nl> At 01:48 26/07/2006, Gregg Wonderly wrote: >Martin Schoeberl wrote: > > I completely agree - it's still a stream and not a packet. > > > > This is similar to a single write to a TCP/IP socket. There > > is no guarantee that you get this data as a single packet/single > > read on the other side. However, I've seen a lot of programs > > assuming that this happens ;-) > >For nearly forever, serialport drivers have operated in the mode >that they send >either everything up to the divider char, or a single char. This was >specifically done for protocols such as modbus which have 1 1/2 bit >time delays >indicating end of packet. This kind of thing is something that needs to be >maintained for serial protocols to work. A user has to have a way to send a >single "packet" of data and make sure that it flows out of the uart >uninterrupted. Even that is sometimes difficult to achieve. If the whole packet does not fit in the UART FIFOs, then the driver may have a hard time making sure that all of the data flows out uninterrupted, unless 1/ you have a RTOS with a response time that is fast enough to refill the FIFO before it empties, and/or 2/ you can tolerate a 'stop the world' approach where ints are globally disabled while the packet is being sent (not nice) (just a side comment) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From tjarvi at qbang.org Wed Jul 26 00:48:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 26 Jul 2006 00:48:29 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060726084016.03633040@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <7.0.1.0.0.20060726084016.03633040@sms.nl> Message-ID: On Wed, 26 Jul 2006, Guillermo Rodriguez Garcia wrote: > At 01:42 26/07/2006, Gregg Wonderly wrote: >> Guillermo Rodriguez wrote: >>> The problem with this is that there is no guarantee that a single call >>> to the write method of the OutputStream associated with a javax.comm >>> SerialPort will translate to a single write to the underlying device >>> driver -- this depends on the javax.comm implementation. >> >> More specifically, it depends on a software layer that would targeted >> specifically at solving this problem for RS-485 and other transports >> which have >> blocking or packetizing issues. There are many. In amatuer radio, >> we have TNCs >> (radio modems) which will block things using newline separators in >> some modes, >> and 0xc0 in others. > > Right. I meant that in general one cannot assume that writes to a stream > will translate 1:1 to writes in every layer of the protocol stack (this is > most often not the case.) > Hi Guillermo This sounds like a dead end to me. People using commapi want a a write, an interrupt and data. The kernel being a big problem these days. There are _much_ better ways to do things like protocol stacks. This is not how EIA232 works in the real world. -- Trent Jarvi tjarvi From guille at sms.nl Wed Jul 26 01:02:09 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 09:02:09 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <7.0.1.0.0.20060726084016.03633040@sms.nl> Message-ID: <7.0.1.0.0.20060726090154.036dd708@sms.nl> At 08:48 26/07/2006, Trent Jarvi wrote: >On Wed, 26 Jul 2006, Guillermo Rodriguez Garcia wrote: > > > At 01:42 26/07/2006, Gregg Wonderly wrote: > >> Guillermo Rodriguez wrote: > >>> The problem with this is that there is no guarantee that a single call > >>> to the write method of the OutputStream associated with a javax.comm > >>> SerialPort will translate to a single write to the underlying device > >>> driver -- this depends on the javax.comm implementation. > >> > >> More specifically, it depends on a software layer that would targeted > >> specifically at solving this problem for RS-485 and other transports > >> which have > >> blocking or packetizing issues. There are many. In amatuer radio, > >> we have TNCs > >> (radio modems) which will block things using newline separators in > >> some modes, > >> and 0xc0 in others. > > > > Right. I meant that in general one cannot assume that writes to a stream > > will translate 1:1 to writes in every layer of the protocol stack (this is > > most often not the case.) > > > >Hi Guillermo > >This sounds like a dead end to me. People using commapi want a a write, >an interrupt and data. The kernel being a big problem these days. > >There are _much_ better ways to do things like protocol stacks. This is >not how EIA232 works in the real world. Yes, this is exactly what I'm saying. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From Luis.Moreira at jet.uk Wed Jul 26 01:34:42 2006 From: Luis.Moreira at jet.uk (Luis Moreira) Date: Wed, 26 Jul 2006 08:34:42 +0100 Subject: [Rxtx] Portability Message-ID: Hi Guys, I managed to get the RXTX package to work on my PC, but the question is, if I need to distribute my program to someone that does not know much about java how do I get the program to work on their System? Best regards Luis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/3e3c2058/attachment-0339.html From joachim at buechse.de Wed Jul 26 02:18:19 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 26 Jul 2006 10:18:19 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <44C667EC.2070602@ergotech.com> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> <44C667EC.2070602@ergotech.com> Message-ID: I may not have been very clear with my suggestion: The "mandatory" flush after write was only regarding RS485. If an application does not use flush after write (today), it is damned to fail anyway. The Outputstream interface makes no guarentee what so ever, that any data will be writen before you call flush. So in fact flush is already mandatory unless you dont care if your data is ever transmitted. I don't see how sending on flush for RS485 would be less efficient. If you are concerned about the additional function call you may want to specify on which platform/VM you are working. A function call in java even on slow PCs is in the microsecond range. So if your concern is, that writes should be forwarded as soon as possible, well then follow any write by a flush. I haven't done any JavaME serial programming, but from my experience with implementing Ymodem over RS232+USB, all I can say is this: Either you have your data ready when it is demanded and you can write it with a single write(+flush) or your application will be slow. So yes, you need to get data on the wire as quick as possible, the solutions are manyfold but an additional (flush) function call will hardly make your application slower. Regards, Joachim On 25.07.2006, at 20:50, Jim Redman wrote: > The horror! This would be terribly inefficient. Especially in serial > protocols you need to start getting bits on the wire as soon as > possible. It could also have some timeout implications. > > Jim > > Joachim Buechse wrote: >> Just trigger writing on flush(). It is perfectly legal for an >> Outputstream implementation to do do nothing until flush is called >> and the documentation of OutputStream.flush reads: >> >> "Flushes this output stream and forces any buffered output bytes to >> be written out. The general contract of flush is that calling it is >> an indication that, if any bytes previously written have been >> buffered by the implementation of the output stream, such bytes >> should immediately be written to their intended destination." >> >> As RS485 is a "dont speak up unless requested" protocol, a mandatory >> flush after write seems like the way to go to me >> >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). >> >> Regards, >> Joachim >> >> PS: It is great to see all the motivation that is brought forward on >> this list regarding the future. It would be great if only 10% of that >> motivation could be transformed into a cleanup and extension of the >> existing code. The current code access model seems rather >> inappropriate for the prototyping of the ideas beeing presented. >> Trent can we get a "contributions" branch with "free" access. >> >> >> On 25.07.2006, at 17:37, Martin Schoeberl wrote: >> >>>>> Martin Schoeberl wrote: >>>>>> We can model it platform independent with two methods: >>>>>> >>>>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>>>> on the underlying platform to switch to RS485 transmit mode and >>>>>> back. >>>>> Or, do what is typically done, and use a single write operation >>>>> as the >>>>> indication of a 'packet' that will let the underlying RS-485/422 >>>>> driver >>>>> assert >>>>> the appropriate signalling. >>>> The problem with this is that there is no guarantee that a single >>>> call >>>> to the write method of the OutputStream associated with a >>>> javax.comm >>>> SerialPort will translate to a single write to the underlying >>>> device >>>> driver -- this depends on the javax.comm implementation. >>>> >>> I completely agree - it's still a stream and not a packet. >>> >>> This is similar to a single write to a TCP/IP socket. There >>> is no guarantee that you get this data as a single packet/single >>> read on the other side. However, I've seen a lot of programs >>> assuming that this happens ;-) >>> >>> Martin >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Jul 26 04:28:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 26 Jul 2006 06:28:33 -0400 Subject: [Rxtx] Should we defer JSR support of RS485? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: Hi All, Would it make sense to focus the JSR on rock solid serial and parallel port support? Can the RS485 people live with unofficial support, at least until we get the JSR accepted and the implementation rock solid? Thanks! - Doug From gergg at cox.net Wed Jul 26 08:49:21 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 26 Jul 2006 09:49:21 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <44C6F271.2020604@cox.net> Message-ID: <44C780F1.8020506@cox.net> Trent Jarvi wrote: > I do not disagree with you but I have a problem with this (realtime java > and/or the aJile and other Uc environements) being something I may be > hearing bugs about 5 years from now. Is this really something that should > be in the API or is it something that would make a nice niche market for > support and services? Do the two really go together? The question is whether there needs to be two, three or five ways to do the same thing, or can we distill it down to one so that software working in one environment can work in all. > If you like that market and I think there is a niche market there, great. > This is a good area for SPI type interfaces where you could support it but > it was not provided by default. SPI is supported natively on the aJile processors. Systronix provides an API for using the SPI lines defined for that use. Adding extra slave selects is not part of their API. There are plenty of places where this stuff is getting used. In the C world of uC, there are 500 ways to do the same thing because everyone wants to be as close to the hardware as possible. The trumpet of the Java platform proclaims write once, run anywhere. Thats been a powerful impetus to me and others to use the language. I really do appreciate that I don't have to think about non-application related programming tasks as much as I did in C and C++. It's possible to pick a reasonable level of abstraction that provide opportunity to expand in the future while accounting for the small in the present. But, we have to all get together with a desire to accomplish this, have good constructive conversation and feedback, and get it done. Gregg Wonderly From gergg at cox.net Wed Jul 26 08:56:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 26 Jul 2006 09:56:11 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060726083751.03633188@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> Message-ID: <44C7828B.7040904@cox.net> Guillermo Rodriguez Garcia wrote: > It would do the job as well and I would be happy with that. However > Paul's proposal where implementation classes extend the core API as > necessary might be more elegant (for the same reason that it is more > elegant than ioctl) Right, but my argument was that this demanded that the classes preexist at the time I am writing the software. I have to be able to compile against them. The Map mechanism would allow me to write software that worked with any hardware. The person deploying my software into their environment with their hardware would then just provide a set of configuration values that my software would pass into the API. That's the point I'm trying to make. I'm on the fence about a Map vs a subclass with methods. I can see it both ways. But, as a JDBC user, I've learned to appreciate a single API with Properties passed in. As a Jini user I've learned to appreciate the Configuration mechanisms that Jini 2.x has. I can write code in my configuration file to instantiate and configure the system at deployment time! Gregg Wonderly From joachim at buechse.de Wed Jul 26 09:37:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 26 Jul 2006 17:37:27 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C7828B.7040904@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> <44C7828B.7040904@cox.net> Message-ID: <08E356DB-AC3F-46FC-952B-82D5ABB15926@buechse.de> Unless you are working with J2ME, you can just as well do what you describe using reflection (ie a JavaBean strategy). A Map can change at runtime, an interface can not. Regards, Joachim On 26.07.2006, at 16:56, Gregg Wonderly wrote: > Guillermo Rodriguez Garcia wrote: >> It would do the job as well and I would be happy with that. However >> Paul's proposal where implementation classes extend the core API as >> necessary might be more elegant (for the same reason that it is more >> elegant than ioctl) > > Right, but my argument was that this demanded that the classes > preexist at the > time I am writing the software. I have to be able to compile > against them. > > The Map mechanism would allow me to write software that worked with > any > hardware. The person deploying my software into their environment > with their > hardware would then just provide a set of configuration values that > my software > would pass into the API. > > That's the point I'm trying to make. I'm on the fence about a Map > vs a subclass > with methods. I can see it both ways. But, as a JDBC user, I've > learned to > appreciate a single API with Properties passed in. As a Jini user > I've learned > to appreciate the Configuration mechanisms that Jini 2.x has. I > can write code > in my configuration file to instantiate and configure the system at > deployment > time! > > config/ConfigurationFile.html> > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Paul.Klissner at Sun.COM Wed Jul 26 12:11:37 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 26 Jul 2006 11:11:37 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C780F1.8020506@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <44C6F271.2020604@cox.net> <44C780F1.8020506@cox.net> Message-ID: <44C7B059.1060302@sun.com> Gregg Wonderly wrote: > Trent Jarvi wrote: >> I do not disagree with you but I have a problem with this (realtime java >> and/or the aJile and other Uc environements) being something I may be >> hearing bugs about 5 years from now. Is this really something that should >> be in the API or is it something that would make a nice niche market for >> support and services? Do the two really go together? > > The question is whether there needs to be two, three or five ways to do the same > thing, or can we distill it down to one so that software working in one > environment can work in all. > >> If you like that market and I think there is a niche market there, great. >> This is a good area for SPI type interfaces where you could support it but >> it was not provided by default. > > SPI is supported natively on the aJile processors. Systronix provides an API > for using the SPI lines defined for that use. Adding extra slave selects is not > part of their API. > > There are plenty of places where this stuff is getting used. In the C world of > uC, there are 500 ways to do the same thing because everyone wants to be as > close to the hardware as possible. > > The trumpet of the Java platform proclaims write once, run anywhere. Thats been > a powerful impetus to me and others to use the language. I really do appreciate > that I don't have to think about non-application related programming tasks as > much as I did in C and C++. > > It's possible to pick a reasonable level of abstraction that provide opportunity > to expand in the future while accounting for the small in the present. > > But, we have to all get together with a desire to accomplish this, have good > constructive conversation and feedback, and get it done. I agree that whatever approach we take should involve settling on the scope and then seeking to create a reasonably complete set of abstractions to generalize and make platform independent, and then refine that list as corner cases appear. For whichever bus(ses) we support, it will be standards-based functionality we're trying to support, with device-specific functionality hidden in the driver and not passed through as direct driver-oriented commands via the API. Paul > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Paul.Klissner at Sun.COM Wed Jul 26 12:23:56 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 26 Jul 2006 11:23:56 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C7828B.7040904@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> <44C7828B.7040904@cox.net> Message-ID: <44C7B33C.8090005@sun.com> Gregg Wonderly wrote: > Guillermo Rodriguez Garcia wrote: >> It would do the job as well and I would be happy with that. However >> Paul's proposal where implementation classes extend the core API as >> necessary might be more elegant (for the same reason that it is more >> elegant than ioctl) > > Right, but my argument was that this demanded that the classes preexist at the > time I am writing the software. I have to be able to compile against them. > > The Map mechanism would allow me to write software that worked with any > hardware. The person deploying my software into their environment with their > hardware would then just provide a set of configuration values that my software > would pass into the API. > > That's the point I'm trying to make. I'm on the fence about a Map vs a subclass > with methods. I can see it both ways. But, as a JDBC user, I've learned to > appreciate a single API with Properties passed in. As a Jini user I've learned > to appreciate the Configuration mechanisms that Jini 2.x has. I can write code > in my configuration file to instantiate and configure the system at deployment > time! I don't think this is a problem as long as the implementation specific stuff is handled by controlling through vehicles outside the API. The application code layered over the API should be written such that it can run on any platform and with any generic device of the class the API claims to support. The problem with the ioctl is it's proneness for abuse and invitation to proliferate the space with non-portable applications. If the implementation requires a configuration file to be passed through the API then the application can run on platform A, B and C, which all have the same type of device, fine, and then with a different configuration file, could run on D, E and F with other hardware, that seems reasonable. What if there are multiple devices on a system of different types? There needs to be a way to get the right configuration file to associate with the right device, and the application should seamlessly work with either. The application code layered over the API should not have to be aware of the configuration file or the programmatic peculiarities of the underlying hardware. Paul From joachim at buechse.de Wed Jul 26 12:59:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 26 Jul 2006 20:59:06 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C7B33C.8090005@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> <44C7828B.7040904@cox.net> <44C7B33C.8090005@sun.com> Message-ID: <1A34B6D0-43B2-4F73-A39F-004B3D100CE9@buechse.de> Paul honestly I think you are to extreme - Often enough a USER is very well capable of indentifying which "config file" needs to be choosen to set up the device he owns. This file can be accepted from the application as a "configuration parameter" and passed on to the driver. One very typical example are AT-command sequences. Terminal programs know nothing about their meaning - still they happily pass them on to do their magic. Best regards, Joachim On 26.07.2006, at 20:23, Paul Klissner wrote: > Gregg Wonderly wrote: >> Guillermo Rodriguez Garcia wrote: >>> It would do the job as well and I would be happy with that. However >>> Paul's proposal where implementation classes extend the core API as >>> necessary might be more elegant (for the same reason that it is more >>> elegant than ioctl) >> >> Right, but my argument was that this demanded that the classes >> preexist at the >> time I am writing the software. I have to be able to compile >> against them. >> >> The Map mechanism would allow me to write software that worked >> with any >> hardware. The person deploying my software into their environment >> with their >> hardware would then just provide a set of configuration values >> that my software >> would pass into the API. >> >> That's the point I'm trying to make. I'm on the fence about a Map >> vs a subclass >> with methods. I can see it both ways. But, as a JDBC user, I've >> learned to >> appreciate a single API with Properties passed in. As a Jini user >> I've learned >> to appreciate the Configuration mechanisms that Jini 2.x has. I >> can write code >> in my configuration file to instantiate and configure the system >> at deployment >> time! > > I don't think this is a problem as long as the implementation specific > stuff is handled by controlling through vehicles outside the API. > The application code layered over the API should be written such that > it can run on any platform and with any generic device of the class > the API claims to support. > > The problem with the ioctl is it's proneness for abuse and invitation > to proliferate the space with non-portable applications. > > If the implementation requires a configuration file to be passed > through > the API then the application can run on platform A, B and C, which all > have the same type of device, fine, and then with a different > configuration > file, could run on D, E and F with other hardware, that seems > reasonable. > > What if there are multiple devices on a system of different types? > There needs to be a way to get the right configuration file to > associate > with the right device, and the application should seamlessly work > with either. > The application code layered over the API should not have to be aware > of the configuration file or the programmatic peculiarities of the > underlying hardware. > > Paul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From savagobr at yahoo.com Wed Jul 26 13:15:13 2006 From: savagobr at yahoo.com (Adenilson Cavalcanti) Date: Wed, 26 Jul 2006 12:15:13 -0700 (PDT) Subject: [Rxtx] Strange error (show stopper) - Fedora Core 5 is ok! Message-ID: <20060726191513.28407.qmail@web53802.mail.yahoo.com> Dear Joachim Buechse I'm pretty new to this list (actually, first post) but got curious about the issue that you reported. If a undertood the code correctly, SerialImp.c -> interruptEventLoop only calls pthread_kill when compiled for MacOSX. Anyway, I changed the code to print field values of structure object 'index' and got this results: 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 CLOSING=0 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 CLOSING=1 Which I think seems to be o.k. (I must also comment that I'm running FC5, kernel 2.6.15, gcc 4.1.1, jdk 1.5.0_06). Bellow you will find where in source code I printed the debug information. I was wondering why in Linux is not necessary to call pthread_kill (of course I did read the comments about "output buffer empty" but don't get it...). Any comments? Best regards Savago //---------------------------------------------------------------------------------------------- Changed code. //---------------------------------------------------------------------------------------------- /** XXX: DEBUG INFO*/ snprintf(message, sizeof(message), "1 interrupted thread for FD=%i PTR=%i CLOSING=%i\n", index->fd, index, index->closing ); report(message); #ifdef TIOCSERGETLSR index->closing=1; #endif /* TIOCSERGETLSR */ #ifdef WIN32 termios_interrupt_event_loop( index->fd, 1 ); #endif /* WIN32 */ #if !defined(TIOCSERGETLSR) && !defined(WIN32) . . . #endif /** XXX: DEBUG INFO*/ snprintf(message, sizeof(message), "2 interrupted thread for FD=%i PTR=%i CLOSING=%i\n", index->fd, index, index->closing ); report(message); report("interruptEventLoop: interrupted\n"); //---------------------------------------------------------------------------------------------- OUTPUT: 15:00:24:******* report_serial_events: sending DATA_AVAILABLE 15:00:24:******* reporting data available 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 CLOSING=0 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 CLOSING=1 15:00:24:******* interruptEventLoop: interrupted 15:00:24:******* eventLoop: got interrupt 15:00:24:******* setDTR( 0 ) 15:00:24:******* setDSR( 0 ) 15:00:24:******* >nativeClose pid 15:00:24:******* nativeClose: pid 15:00:24:******* nativeClose: discarding remaining datai (tcflush) 15:00:24:******* nativeClose: calling close 15:00:24:******* fhs_unlock: Removing LockFile 15:00:24:******* nativeClose: Delete jclazz 15:00:24:******* nativeClose: release filename 15:00:24:******* fhs_unlock: Removing LockFile //---------------------------------------------------------------------------------------------- --------------------------------- How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone call rates. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/ad116f14/attachment-0338.html From savagobr at yahoo.com Wed Jul 26 13:23:05 2006 From: savagobr at yahoo.com (Adenilson Cavalcanti) Date: Wed, 26 Jul 2006 12:23:05 -0700 (PDT) Subject: [Rxtx] Locked ports - to Kharbanda Message-ID: <20060726192305.23957.qmail@web53807.mail.yahoo.com> Dear Kharbanda I'm trying to reproduce the bug that you reported (the deadlock one) but dont get it. What I did was write a java app that continuously open/close a port (/dev/ttyS0) within 1 second for this operation. The program keeps running fine, no lock until now. I'm wondering if you could send me a sample app that could help me to reproduce this bug? Best regards Savago --------------------------------- Yahoo! Music Unlimited - Access over 1 million songs.Try it free. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/c56bc64a/attachment-0338.html From Pawan.Kharbanda at dot.state.co.us Wed Jul 26 13:41:13 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Wed, 26 Jul 2006 13:41:13 -0600 Subject: [Rxtx] Locked ports - to Kharbanda Message-ID: <939A619A756047469C41EE9BA51890FB0429E08B@hqexchange3.dot.state.co.us> Savago, I have attached the Test class that i wrote to replicate the locking/threading problem with RXTX in Redhat Linux. Please follow the following instructions to replicate the problem. I don't know if you will be able to replicate using one Serial port or not, i was able to reproduced it using 3 or 4 ports constantly. Instructions: In the TestOpenClosePort.java please change the Serial Ports names(Add the ports installed on your machine). Then compile your java file and run as "java TestOpenClosePort 100" (100 is the no of times you want to open and close the port in one single thread). I have tested this with the Digi Boxes and able to replicate this over and over in Single JVM. Thanks ~pk ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Adenilson Cavalcanti Sent: Wednesday, July 26, 2006 1:23 PM To: rxtx at qbang.org Subject: [Rxtx] Locked ports - to Kharbanda Dear Kharbanda I'm trying to reproduce the bug that you reported (the deadlock one) but dont get it. What I did was write a java app that continuously open/close a port (/dev/ttyS0) within 1 second for this operation. The program keeps running fine, no lock until now. I'm wondering if you could send me a sample app that could help me to reproduce this bug? Best regards Savago ________________________________ Yahoo! Music Unlimited - Access over 1 million songs. Try it free. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/c581de54/attachment-0338.html -------------- next part -------------- A non-text attachment was scrubbed... Name: TestOpenClosePort.java Type: application/octet-stream Size: 6038 bytes Desc: TestOpenClosePort.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/c581de54/TestOpenClosePort-0338.obj From joachim at buechse.de Wed Jul 26 16:01:31 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 27 Jul 2006 00:01:31 +0200 Subject: [Rxtx] Strange error (show stopper) - Fedora Core 5 is ok! In-Reply-To: <20060726191513.28407.qmail@web53802.mail.yahoo.com> References: <20060726191513.28407.qmail@web53802.mail.yahoo.com> Message-ID: Linux offers a feature (TIOCSERGETLSR) that allows to check if all data has been sent. This feature does not exist on OSX, BSD, Solaris and probably some other systems. For these systems RXTX uses a separate thread that calls tc_drain() - on return of this call all data has been written. The pthread_kill is used to guarantee that the drain thread has been canceled. On Linux there is no forced "wait" between the setting of the "closing" flag and the end of the procedure. The test should to be done on a BSD or Solaris system. But maybe you could add a usleep (50000) just before the second sprintf. This might in fact be helpful to see if the problem exists on Linux as well. Thanks, Joachim On 26.07.2006, at 21:15, Adenilson Cavalcanti wrote: > Dear Joachim Buechse > > I'm pretty new to this list (actually, first post) but got curious > about the issue that you reported. > > If a undertood the code correctly, SerialImp.c -> > interruptEventLoop only calls pthread_kill when compiled for MacOSX. > > Anyway, I changed the code to print field values of structure > object 'index' and got this results: > > 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 > CLOSING=0 > 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 > CLOSING=1 > > Which I think seems to be o.k. (I must also comment that I'm > running FC5, kernel 2.6.15, gcc 4.1.1, jdk 1.5.0_06). > > Bellow you will find where in source code I printed the debug > information. > > I was wondering why in Linux is not necessary to call pthread_kill > (of course I did read the comments about "output buffer empty" but > don't get it...). Any comments? > > Best regards > > Savago > > //-------------------------------------------------------------------- > -------------------------- > Changed code. > //-------------------------------------------------------------------- > -------------------------- > /** XXX: DEBUG INFO*/ > snprintf(message, sizeof(message), "1 interrupted thread for FD= > %i PTR=%i CLOSING=%i\n", > index->fd, index, index->closing ); > report(message); > > #ifdef TIOCSERGETLSR > index->closing=1; > #endif /* TIOCSERGETLSR */ > #ifdef WIN32 > termios_interrupt_event_loop( index->fd, 1 ); > #endif /* WIN32 */ > #if !defined(TIOCSERGETLSR) && !defined(WIN32) > . > . > . > #endif > /** XXX: DEBUG INFO*/ > snprintf(message, sizeof(message), "2 interrupted thread for FD= > %i PTR=%i CLOSING=%i\n", > index->fd, index, index->closing ); > report(message); > > report("interruptEventLoop: interrupted\n"); > > //-------------------------------------------------------------------- > -------------------------- > OUTPUT: > > 15:00:24:******* report_serial_events: sending DATA_AVAILABLE > 15:00:24:******* reporting data available > 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 > CLOSING=0 > 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 > CLOSING=1 > 15:00:24:******* interruptEventLoop: interrupted > 15:00:24:******* eventLoop: got interrupt > 15:00:24:******* setDTR( 0 ) > 15:00:24:******* setDSR( 0 ) > 15:00:24:******* >nativeClose pid > 15:00:24:******* nativeClose: pid > 15:00:24:******* nativeClose: discarding remaining datai (tcflush) > 15:00:24:******* nativeClose: calling close > 15:00:24:******* fhs_unlock: Removing LockFile > 15:00:24:******* nativeClose: Delete jclazz > 15:00:24:******* nativeClose: release filename > 15:00:24:******* fhs_unlock: Removing LockFile > //-------------------------------------------------------------------- > -------------------------- > > How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone > call rates. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jul 26 19:34:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 26 Jul 2006 19:34:11 -0600 (MDT) Subject: [Rxtx] Strange error (show stopper) - Fedora Core 5 is ok! In-Reply-To: References: <20060726191513.28407.qmail@web53802.mail.yahoo.com> Message-ID: It is also possible to undefine TIOCSERGETLSR on Linux. It would be nice if BSD and Solaris made the line status register available but it isn't really a standard. On Thu, 27 Jul 2006, Joachim Buechse wrote: > Linux offers a feature (TIOCSERGETLSR) that allows to check if all > data has been sent. This feature does not exist on OSX, BSD, Solaris > and probably some other systems. For these systems RXTX uses a > separate thread that calls tc_drain() - on return of this call all > data has been written. The pthread_kill is used to guarantee that the > drain thread has been canceled. > > On Linux there is no forced "wait" between the setting of the > "closing" flag and the end of the procedure. The test should to be > done on a BSD or Solaris system. But maybe you could add a usleep > (50000) just before the second sprintf. This might in fact be helpful > to see if the problem exists on Linux as well. > > Thanks, > Joachim > > > On 26.07.2006, at 21:15, Adenilson Cavalcanti wrote: > >> Dear Joachim Buechse >> >> I'm pretty new to this list (actually, first post) but got curious >> about the issue that you reported. >> >> If a undertood the code correctly, SerialImp.c -> >> interruptEventLoop only calls pthread_kill when compiled for MacOSX. >> >> Anyway, I changed the code to print field values of structure >> object 'index' and got this results: >> >> 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 >> CLOSING=0 >> 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 >> CLOSING=1 >> >> Which I think seems to be o.k. (I must also comment that I'm >> running FC5, kernel 2.6.15, gcc 4.1.1, jdk 1.5.0_06). >> >> Bellow you will find where in source code I printed the debug >> information. >> >> I was wondering why in Linux is not necessary to call pthread_kill >> (of course I did read the comments about "output buffer empty" but >> don't get it...). Any comments? >> >> Best regards >> >> Savago >> >> //-------------------------------------------------------------------- >> -------------------------- >> Changed code. >> //-------------------------------------------------------------------- >> -------------------------- >> /** XXX: DEBUG INFO*/ >> snprintf(message, sizeof(message), "1 interrupted thread for FD= >> %i PTR=%i CLOSING=%i\n", >> index->fd, index, index->closing ); >> report(message); >> >> #ifdef TIOCSERGETLSR >> index->closing=1; >> #endif /* TIOCSERGETLSR */ >> #ifdef WIN32 >> termios_interrupt_event_loop( index->fd, 1 ); >> #endif /* WIN32 */ >> #if !defined(TIOCSERGETLSR) && !defined(WIN32) >> . >> . >> . >> #endif >> /** XXX: DEBUG INFO*/ >> snprintf(message, sizeof(message), "2 interrupted thread for FD= >> %i PTR=%i CLOSING=%i\n", >> index->fd, index, index->closing ); >> report(message); >> >> report("interruptEventLoop: interrupted\n"); >> >> //-------------------------------------------------------------------- >> -------------------------- >> OUTPUT: >> >> 15:00:24:******* report_serial_events: sending DATA_AVAILABLE >> 15:00:24:******* reporting data available >> 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 >> CLOSING=0 >> 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 >> CLOSING=1 >> 15:00:24:******* interruptEventLoop: interrupted >> 15:00:24:******* eventLoop: got interrupt >> 15:00:24:******* setDTR( 0 ) >> 15:00:24:******* setDSR( 0 ) >> 15:00:24:******* >nativeClose pid >> 15:00:24:******* nativeClose: pid >> 15:00:24:******* nativeClose: discarding remaining datai (tcflush) >> 15:00:24:******* nativeClose: calling close >> 15:00:24:******* fhs_unlock: Removing LockFile >> 15:00:24:******* nativeClose: Delete jclazz >> 15:00:24:******* nativeClose: release filename >> 15:00:24:******* fhs_unlock: Removing LockFile >> //-------------------------------------------------------------------- >> -------------------------- >> >> How low will we go? Check out Yahoo! Messengers low PC-to-Phone >> call rates. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From guille at sms.nl Thu Jul 27 00:30:47 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 27 Jul 2006 08:30:47 +0200 Subject: [Rxtx] more RS485 (was: Strange error (show stopper) - Fedora Core 5 is ok!) In-Reply-To: References: <20060726191513.28407.qmail@web53802.mail.yahoo.com> Message-ID: <7.0.1.0.0.20060727082321.036f10d0@sms.nl> At 00:01 27/07/2006, Joachim Buechse wrote: >Linux offers a feature (TIOCSERGETLSR) that allows to check if all >data has been sent. Just a side note: This is one of the things that is useful when one needs to control external RS232 to RS485 converters with the RTS or DTR lines. The above lets you look at the transmit shift register to know if/when the last character has been completely shifted out ('transmit shift register empty' is a different thing than 'output FIFO empty' and than 'software output buffer empty'). This is something you currently cannot do from your application using rxtx. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From gergg at cox.net Thu Jul 27 11:08:32 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 27 Jul 2006 12:08:32 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C7B33C.8090005@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> <44C7828B.7040904@cox.net> <44C7B33C.8090005@sun.com> Message-ID: <44C8F310.2040107@cox.net> Paul Klissner wrote: > What if there are multiple devices on a system of different types? > There needs to be a way to get the right configuration file to associate > with the right device, and the application should seamlessly work with either. > The application code layered over the API should not have to be aware > of the configuration file or the programmatic peculiarities of the > underlying hardware. If the configuration mechanism is the standard and must be supported, then every device will have to have such a configuration object. The configuration object would be the per device mechanism with a real API on that object. I'll use the Jini ConfigurationFile syntax here as an example: com2 { driver = "name.of.device.driver.class"; config = new com.deviceco.rs485.Parameters( ... arguments to parameter construction ... ); } then the API would ask for the driver and configuration for device com2, and have all the things needed to make the correct device used with the correct configuration. Gregg Wonderly From fredm at alum.mit.edu Fri Jul 28 04:32:56 2006 From: fredm at alum.mit.edu (Fred G. Martin) Date: Fri, 28 Jul 2006 06:32:56 -0400 Subject: [Rxtx] precompiled for Intel Mac? Message-ID: Dear RXTX'ers, Would there be a precompiled binary of the older 2.0-7pre1 version (javax.comm namespace) rxtx for the Intel Mac platform? Would I just need the libSerial.jnilib file? Thank you, Fred From savagobr at yahoo.com Fri Jul 28 09:34:35 2006 From: savagobr at yahoo.com (Adenilson Cavalcanti) Date: Fri, 28 Jul 2006 08:34:35 -0700 (PDT) Subject: [Rxtx] Strange error (show stopper) - FC5 still ok! Message-ID: <20060728153435.41645.qmail@web53815.mail.yahoo.com> Friends I repeated the test, both undefining TIOCSERGETLSR in SerialImp.h as also adding a sleep in function 'interruptEventLoop' and it still is working fine. Later I can test it in pcbsd (based on FreeBSD 6) on my notebook. So far, I think that we can say that in Linux this error doesn't happen. Best regards Savago //------------------------------------------------------------------------ Result with #undef TIOCSERGETLSR 11:08:11:******* 1 interrupted thread for FD=51 PTR=-1321354040 CLOSING=0 11:08:11:******* 2 interrupted thread for FD=51 PTR=-1321354040 CLOSING=1 Result with usleep(50000) 11:14:57:******* 1 interrupted thread for FD=51 PTR=-1322914604 CLOSING=0 11:14:57:******* 2 interrupted thread for FD=51 PTR=-1322914604 CLOSING=1 --------------------------------- How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone call rates. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060728/acd6aec1/attachment-0336.html From joachim at buechse.de Fri Jul 28 12:48:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 28 Jul 2006 20:48:33 +0200 Subject: [Rxtx] precompiled for Intel Mac? In-Reply-To: References: Message-ID: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> There will be. However not before we have figured out some remaining issues. Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 28.07.2006, at 12:32, Fred G. Martin wrote: > Dear RXTX'ers, > > Would there be a precompiled binary of the older 2.0-7pre1 version > (javax.comm namespace) rxtx for the Intel Mac platform? > > Would I just need the libSerial.jnilib file? > > Thank you, > Fred > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From fredm at alum.mit.edu Fri Jul 28 15:30:38 2006 From: fredm at alum.mit.edu (Fred G. Martin) Date: Fri, 28 Jul 2006 17:30:38 -0400 Subject: [Rxtx] precompiled for Intel Mac? In-Reply-To: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> References: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> Message-ID: <4616ED35-24BC-4FD3-90FB-81CAA851FB08@alum.mit.edu> May I ask another way--- can it [easily] be built from the 2.0-7pre1 sources? Fred On Jul 28, 2006, at 2:48 PM, Joachim Buechse wrote: > There will be. However not before we have figured out some remaining > issues. > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 28.07.2006, at 12:32, Fred G. Martin wrote: > >> Dear RXTX'ers, >> >> Would there be a precompiled binary of the older 2.0-7pre1 version >> (javax.comm namespace) rxtx for the Intel Mac platform? >> >> Would I just need the libSerial.jnilib file? >> >> Thank you, >> Fred >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Fri Jul 28 21:04:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 28 Jul 2006 21:04:45 -0600 (MDT) Subject: [Rxtx] precompiled for Intel Mac? In-Reply-To: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> References: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> Message-ID: On Fri, 28 Jul 2006, Joachim Buechse wrote: > There will be. However not before we have figured out some remaining > issues. > Joachim > Joachim and I are trying to get together to work out the remaining issues. I'll be looking at some w32 issues this weekend - a lovely job everyone should do exactly once. There are a few details that need attention. The summer vacation schedual is keeping things at a slow pace. This will be the first free weekend I've had in a while. I'm also gathering a list of things to do on Linux and Solaris which so far isn't too big but there are some that can be problems depending upon your use. Bugzilla is also your friend for bugs that are not getting attention right away. All bugs are interesting but sometimes forgotten on the mail list. I do go through all the bugs in bugzilla one by one now and then. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jul 29 05:18:25 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 29 Jul 2006 07:18:25 -0400 Subject: [Rxtx] The new JSR and RS485 - Moderator Ruling In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: Hi All, It has been several days since I asked the below question. There has not been much in the way of response. Therefore, I am using my new-age radioactive mutant moderator super-powers to make a (non-final) decision that: 1. We can live with unofficial RS485 support for a while, 2. The JSR specification that we embark upon will focus on serial and parallel ports and 3. We may revisit the RS485 question, in the future. Thanks! - Doug Date: Wed, 26 Jul 2006 06:28:33 -0400 From: "Dr. Douglas Lyon" Subject: Should we defer JSR support of RS485? To: RXTX Developers and Users , lyon at docjava.com Original-recipient: rfc822;dlyon at optonline.net Hi All, Would it make sense to focus the JSR on rock solid serial and parallel port support? Can the RS485 people live with unofficial support, at least until we get the JSR accepted and the implementation rock solid? Thanks! - Doug From naranjo.manuel at gmail.com Sat Jul 29 07:59:10 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Sat, 29 Jul 2006 10:59:10 -0300 Subject: [Rxtx] The new JSR and RS485 - Moderator Ruling In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: <44CB69AE.8030104@gmail.com> +1 Totally agree, Manuel > Hi All, > > It has been several days since I asked the below question. > There has not been much in the way of response. > Therefore, I am using my new-age radioactive > mutant moderator super-powers to > make a (non-final) decision that: > 1. We can live with unofficial RS485 support for a while, > 2. The JSR specification that we embark upon will focus on > serial and parallel ports and > 3. We may revisit the RS485 question, in the future. > > Thanks! > - Doug > > > Date: Wed, 26 Jul 2006 06:28:33 -0400 > From: "Dr. Douglas Lyon" > Subject: Should we defer JSR support of RS485? > To: RXTX Developers and Users , lyon at docjava.com > Original-recipient: rfc822;dlyon at optonline.net > > Hi All, > > Would it make sense to focus the JSR on rock solid > serial and parallel port support? > > Can the RS485 people live with unofficial support, at least until > we get the JSR accepted and the implementation rock solid? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Sat Jul 29 14:21:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 29 Jul 2006 14:21:32 -0600 (MDT) Subject: [Rxtx] The new JSR and RS485 - Moderator Ruling In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: Hi Doug At this time, I agree. RS485 is interesting and I would be intested in participating in future discussions/plans with RS485. On Sat, 29 Jul 2006, Dr. Douglas Lyon wrote: > Hi All, > > It has been several days since I asked the below question. > There has not been much in the way of response. > Therefore, I am using my new-age radioactive > mutant moderator super-powers to > make a (non-final) decision that: > 1. We can live with unofficial RS485 support for a while, > 2. The JSR specification that we embark upon will focus on > serial and parallel ports and > 3. We may revisit the RS485 question, in the future. > > Thanks! > - Doug > > > Date: Wed, 26 Jul 2006 06:28:33 -0400 > From: "Dr. Douglas Lyon" > Subject: Should we defer JSR support of RS485? > To: RXTX Developers and Users , lyon at docjava.com > Original-recipient: rfc822;dlyon at optonline.net > > Hi All, > > Would it make sense to focus the JSR on rock solid > serial and parallel port support? > > Can the RS485 people live with unofficial support, at least until > we get the JSR accepted and the implementation rock solid? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Sun Jul 30 04:28:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 30 Jul 2006 06:28:49 -0400 Subject: [Rxtx] interfaces vs. abstract classes Message-ID: Hi All, I was thinking that the new JSR might be more interface oriented and less abstract class oriented. For example, instead of subclassing CommPort, perhaps we should implement a CommPortInterface. How would this look? I don't know. But, perhaps, it would look something like this: package gnu.io; import java.io.InputStream; import java.io.IOException; import java.io.OutputStream; /** * User: lyon * Date: Jul 30, 2006 * Time: 5:19:55 AM * Copyright DocJava, Inc. 2005. */ public interface CommPortInterface { void enableReceiveFraming(int f) throws UnsupportedCommOperationException; void disableReceiveFraming(); boolean isReceiveFramingEnabled(); int getReceiveFramingByte(); void disableReceiveTimeout(); void enableReceiveTimeout(int time) throws UnsupportedCommOperationException; boolean isReceiveTimeoutEnabled(); int getReceiveTimeout(); void enableReceiveThreshold(int thresh) throws UnsupportedCommOperationException; void disableReceiveThreshold(); int getReceiveThreshold(); boolean isReceiveThresholdEnabled(); void setInputBufferSize(int size); int getInputBufferSize(); void setOutputBufferSize(int size); int getOutputBufferSize(); void close(); InputStream getInputStream() throws IOException; OutputStream getOutputStream() throws IOException; String getName(); } Then, we can use: /** * CommPort */ public abstract class CommPort implements CommPortInterface And replace uses of CommPort with uses of CommPortInterface.... package gnu.io; import java.io.FileDescriptor; /** * User: lyon * Date: Jul 30, 2006 * Time: 5:40:20 AM * Copyright DocJava, Inc. 2005. */ public interface CommPortIdentifierInterface { int PORT_SERIAL = 1; int PORT_PARALLEL = 2; int PORT_I2C = 3; int PORT_RS485 = 4; int PORT_RAW = 5; void addPortOwnershipListener(CommPortOwnershipListener c); String getCurrentOwner(); String getName(); int getPortType(); boolean isCurrentlyOwned(); CommPortInterface open(FileDescriptor f) throws UnsupportedCommOperationExce ption; CommPortInterface open(String TheOwner, int i) throws PortInUseException; void removePortOwnershipListener(CommPortOwnershipListener c); } If we continue in this vain, the SerialPort should have an interface that it implements, called (due to my lack of imagination) the SerialPortInterface package gnu.io; import java.util.TooManyListenersException; /** * User: lyon * Date: Jul 30, 2006 * Time: 5:56:35 AM * Copyright DocJava, Inc. 2005. */ public interface SerialPortInterface extends CommPortInterface { int DATABITS_5 = 5; int DATABITS_6 = 6; int DATABITS_7 = 7; int DATABITS_8 = 8; int PARITY_NONE = 0; int PARITY_ODD = 1; int PARITY_EVEN = 2; int PARITY_MARK = 3; int PARITY_SPACE = 4; int STOPBITS_1 = 1; int STOPBITS_2 = 2; int STOPBITS_1_5 = 3; int FLOWCONTROL_NONE = 0; int FLOWCONTROL_RTSCTS_IN = 1; int FLOWCONTROL_RTSCTS_OUT = 2; int FLOWCONTROL_XONXOFF_IN = 4; int FLOWCONTROL_XONXOFF_OUT = 8; void setSerialPortParams(int b, int d, int s, int p) throws UnsupportedCommOperationException; int getBaudRate(); int getDataBits(); int getStopBits(); int getParity(); void setFlowControlMode(int flowcontrol) throws UnsupportedCommOperationException; int getFlowControlMode(); boolean isDTR(); void setDTR(boolean state); void setRTS(boolean state); boolean isCTS(); boolean isDSR(); boolean isCD(); boolean isRI(); boolean isRTS(); void sendBreak(int duration); void addEventListener(SerialPortEventListener lsnr) throws TooManyListenersException; void removeEventListener(); void notifyOnDataAvailable(boolean enable); void notifyOnOutputEmpty(boolean enable); void notifyOnCTS(boolean enable); void notifyOnDSR(boolean enable); void notifyOnRingIndicator(boolean enable); void notifyOnCarrierDetect(boolean enable); void notifyOnOverrunError(boolean enable); void notifyOnParityError(boolean enable); void notifyOnFramingError(boolean enable); void notifyOnBreakInterrupt(boolean enable); byte getParityErrorChar() throws UnsupportedCommOperationException; boolean setParityErrorChar(byte b) throws UnsupportedCommOperationException; byte getEndOfInputChar() throws UnsupportedCommOperationException; boolean setEndOfInputChar(byte b) throws UnsupportedCommOperationException; boolean setUARTType(String type, boolean test) throws UnsupportedCommOperationException; String getUARTType() throws UnsupportedCommOperationException; boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException; int getBaudBase() throws UnsupportedCommOperationException; boolean setDivisor(int Divisor) throws UnsupportedCommOperationException; int getDivisor() throws UnsupportedCommOperationException; boolean setLowLatency() throws UnsupportedCommOperationException; boolean getLowLatency() throws UnsupportedCommOperationException; boolean setCallOutHangup(boolean NoHup) throws UnsupportedCommOperationException; boolean getCallOutHangup() throws UnsupportedCommOperationException; } And, of course, you need a parallel port: package gnu.io; import java.util.TooManyListenersException; /** * User: lyon * Date: Jul 30, 2006 * Time: 6:14:02 AM * Copyright DocJava, Inc. 2005. */ public interface ParallelPortInterface extends CommPortInterface { int LPT_MODE_ANY = 0; int LPT_MODE_SPP = 1; int LPT_MODE_PS2 = 2; int LPT_MODE_EPP = 3; int LPT_MODE_ECP = 4; int LPT_MODE_NIBBLE = 5; int getMode(); int setMode(int mode) throws UnsupportedCommOperationException; void restart(); void suspend(); boolean isPaperOut(); boolean isPrinterBusy(); boolean isPrinterError(); boolean isPrinterSelected(); boolean isPrinterTimedOut(); int getOutputBufferFree(); void addEventListener(ParallelPortEventListener lsnr) throws TooManyListenersException; void removeEventListener(); void notifyOnError(boolean enable); void notifyOnBuffer(boolean enable); } Now, I have refactored my code to take advantage of these interfaces. And have done very limited testing. The problem is that we have some static methods in classes like CommPortIdentifier that don't refactor into interfaces cleanly. I don't know what to do about that... What do people think about the idea of using interfaces rather than abstract classes for making the system a little more component oriented? Thanks! - Doug From tjarvi at qbang.org Sun Jul 30 10:13:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 30 Jul 2006 10:13:06 -0600 (MDT) Subject: [Rxtx] interfaces vs. abstract classes In-Reply-To: References: Message-ID: Hi Doug, I don't see a big advantage one way or another for the interfaces. One thing that should be added but not supported initially on all platforms is event notification of devices becomming physically available and vanishing. This is not the same as digging into USB. If the OS can provide a clean event driven method and provides a proper interface, it is of great use to people dealing with USB and Serial and Parallel Dongles. On Sun, 30 Jul 2006, Dr. Douglas Lyon wrote: > Hi All, > I was thinking that the new JSR might be more > interface oriented and less abstract class oriented. > > For example, instead of subclassing CommPort, perhaps > we should implement a CommPortInterface. > > How would this look? > > I don't know. But, perhaps, it would look something like this: > package gnu.io; > > import java.io.InputStream; > import java.io.IOException; > import java.io.OutputStream; > > /** > * User: lyon > * Date: Jul 30, 2006 > * Time: 5:19:55 AM > * Copyright DocJava, Inc. 2005. > */ > public interface CommPortInterface { > void enableReceiveFraming(int f) > throws UnsupportedCommOperationException; > > void disableReceiveFraming(); > > boolean isReceiveFramingEnabled(); > > int getReceiveFramingByte(); > > void disableReceiveTimeout(); > > void enableReceiveTimeout(int time) > throws UnsupportedCommOperationException; > > boolean isReceiveTimeoutEnabled(); > > int getReceiveTimeout(); > > void enableReceiveThreshold(int thresh) > throws UnsupportedCommOperationException; > > void disableReceiveThreshold(); > > int getReceiveThreshold(); > > boolean isReceiveThresholdEnabled(); > > void setInputBufferSize(int size); > > int getInputBufferSize(); > > void setOutputBufferSize(int size); > > int getOutputBufferSize(); > > void close(); > > InputStream getInputStream() throws IOException; > > OutputStream getOutputStream() throws IOException; > > String getName(); > } > > Then, we can use: > /** > * CommPort > */ > public abstract class CommPort implements CommPortInterface > > And replace uses of CommPort with uses of CommPortInterface.... > package gnu.io; > > import java.io.FileDescriptor; > > /** > * User: lyon > * Date: Jul 30, 2006 > * Time: 5:40:20 AM > * Copyright DocJava, Inc. 2005. > */ > public interface CommPortIdentifierInterface { > int PORT_SERIAL = 1; > int PORT_PARALLEL = 2; > int PORT_I2C = 3; > int PORT_RS485 = 4; > int PORT_RAW = 5; > > void addPortOwnershipListener(CommPortOwnershipListener c); > > String getCurrentOwner(); > > String getName(); > > int getPortType(); > > boolean isCurrentlyOwned(); > > CommPortInterface open(FileDescriptor f) throws > UnsupportedCommOperationExce > ption; > > CommPortInterface open(String TheOwner, int i) > throws PortInUseException; > > void removePortOwnershipListener(CommPortOwnershipListener c); > } > > If we continue in this vain, the SerialPort should have an interface that > it implements, called (due to my lack of imagination) the SerialPortInterface > > package gnu.io; > > import java.util.TooManyListenersException; > > /** > * User: lyon > * Date: Jul 30, 2006 > * Time: 5:56:35 AM > * Copyright DocJava, Inc. 2005. > */ > public interface SerialPortInterface extends CommPortInterface { > int DATABITS_5 = 5; > int DATABITS_6 = 6; > int DATABITS_7 = 7; > int DATABITS_8 = 8; > int PARITY_NONE = 0; > int PARITY_ODD = 1; > int PARITY_EVEN = 2; > int PARITY_MARK = 3; > int PARITY_SPACE = 4; > int STOPBITS_1 = 1; > int STOPBITS_2 = 2; > int STOPBITS_1_5 = 3; > int FLOWCONTROL_NONE = 0; > int FLOWCONTROL_RTSCTS_IN = 1; > int FLOWCONTROL_RTSCTS_OUT = 2; > int FLOWCONTROL_XONXOFF_IN = 4; > int FLOWCONTROL_XONXOFF_OUT = 8; > > void setSerialPortParams(int b, int d, int s, int p) > throws UnsupportedCommOperationException; > > int getBaudRate(); > > int getDataBits(); > > int getStopBits(); > > int getParity(); > > void setFlowControlMode(int flowcontrol) > throws UnsupportedCommOperationException; > > int getFlowControlMode(); > > boolean isDTR(); > > void setDTR(boolean state); > > void setRTS(boolean state); > > boolean isCTS(); > > boolean isDSR(); > > boolean isCD(); > > boolean isRI(); > > boolean isRTS(); > > void sendBreak(int duration); > > void addEventListener(SerialPortEventListener lsnr) > throws TooManyListenersException; > > void removeEventListener(); > > void notifyOnDataAvailable(boolean enable); > > void notifyOnOutputEmpty(boolean enable); > > void notifyOnCTS(boolean enable); > > void notifyOnDSR(boolean enable); > > void notifyOnRingIndicator(boolean enable); > > void notifyOnCarrierDetect(boolean enable); > > void notifyOnOverrunError(boolean enable); > > void notifyOnParityError(boolean enable); > > void notifyOnFramingError(boolean enable); > > void notifyOnBreakInterrupt(boolean enable); > > byte getParityErrorChar() > throws UnsupportedCommOperationException; > > boolean setParityErrorChar(byte b) > throws UnsupportedCommOperationException; > > byte getEndOfInputChar() > throws UnsupportedCommOperationException; > > boolean setEndOfInputChar(byte b) > throws UnsupportedCommOperationException; > > boolean setUARTType(String type, boolean test) > throws UnsupportedCommOperationException; > > String getUARTType() > throws UnsupportedCommOperationException; > > boolean setBaudBase(int BaudBase) > throws UnsupportedCommOperationException; > > int getBaudBase() > throws UnsupportedCommOperationException; > > boolean setDivisor(int Divisor) > throws UnsupportedCommOperationException; > > int getDivisor() > throws UnsupportedCommOperationException; > > boolean setLowLatency() > throws UnsupportedCommOperationException; > > boolean getLowLatency() > throws UnsupportedCommOperationException; > > boolean setCallOutHangup(boolean NoHup) > throws UnsupportedCommOperationException; > > boolean getCallOutHangup() > throws UnsupportedCommOperationException; > } > > And, of course, you need a parallel port: > package gnu.io; > > import java.util.TooManyListenersException; > > /** > * User: lyon > * Date: Jul 30, 2006 > * Time: 6:14:02 AM > * Copyright DocJava, Inc. 2005. > */ > public interface ParallelPortInterface extends CommPortInterface { > int LPT_MODE_ANY = 0; > int LPT_MODE_SPP = 1; > int LPT_MODE_PS2 = 2; > int LPT_MODE_EPP = 3; > int LPT_MODE_ECP = 4; > int LPT_MODE_NIBBLE = 5; > > int getMode(); > > int setMode(int mode) > throws UnsupportedCommOperationException; > > void restart(); > > void suspend(); > > boolean isPaperOut(); > > boolean isPrinterBusy(); > > boolean isPrinterError(); > > boolean isPrinterSelected(); > > boolean isPrinterTimedOut(); > > int getOutputBufferFree(); > > void addEventListener(ParallelPortEventListener lsnr) > throws TooManyListenersException; > > void removeEventListener(); > > void notifyOnError(boolean enable); > > void notifyOnBuffer(boolean enable); > } > > Now, I have refactored my code to take advantage of these interfaces. > And have done very limited testing. The problem is that we have some > static methods in > classes like CommPortIdentifier that don't refactor into interfaces cleanly. > > I don't know what to do about that... > > What do people think about the idea of using interfaces rather than > abstract classes for making the system a little more component oriented? > > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From berkland at spamcop.net Sun Jul 30 15:15:59 2006 From: berkland at spamcop.net (Doug Berkland) Date: Sun, 30 Jul 2006 17:15:59 -0400 Subject: [Rxtx] interfaces vs. abstract classes In-Reply-To: <269e40090607301408q41759906k6e45f0dd33618655@mail.gmail.com> References: <269e40090607301408q41759906k6e45f0dd33618655@mail.gmail.com> Message-ID: <269e40090607301415p3238e51eyce4b124f385c1918@mail.gmail.com> I think the interfaces are a good idea. They will allow more flexibility if someone needs to create a modified implementation. I just hope that all of this will end up in the javax.comm package instead of gnu.io. From gergg at cox.net Sun Jul 30 16:30:37 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 30 Jul 2006 17:30:37 -0500 Subject: [Rxtx] interfaces vs. abstract classes In-Reply-To: <269e40090607301415p3238e51eyce4b124f385c1918@mail.gmail.com> References: <269e40090607301408q41759906k6e45f0dd33618655@mail.gmail.com> <269e40090607301415p3238e51eyce4b124f385c1918@mail.gmail.com> Message-ID: <44CD330D.20608@cox.net> Doug Berkland wrote: > I think the interfaces are a good idea. They will allow more > flexibility if someone needs to create a modified implementation. I > just hope that all of this will end up in the javax.comm package > instead of gnu.io. You can provide an abstract class that implements the interface, but defers on the implementation details to allow porting parties the ability to reuse common code with less variations on the behavior that users experience. Please don't include anything in the interface that can't be described in 100% accuracy and perform identically on all possible ports, or throw a well described compatibility exception. Gregg Wonderly From lyon at docjava.com Sun Jul 30 17:27:13 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 30 Jul 2006 19:27:13 -0400 Subject: [Rxtx] interfaces vs abstract classes Message-ID: Hi All, If you ever want to use serial ports with RMI, a nice set of interfaces will be required. On the other hand, perhaps nobody wants that. On the other, other hand, there are some areas where we could really use some API clean-up. This could be a chance to shape the JSR with really clean interfaces with well defined semantics and some good Javadoc. For example: I2CPort, RS485Port and SerialPort all begin with duplicate code. We can put all the constants in a nice interface, as appears below. I have added a little Javadoc. Would someone like to finish it up? So far, I have not added any new features, other than documentation and refactoring. >More importantly is the philosophical start point for a >specification in a JSR; >that is speaking to the future: >Interfaces describe capabilities; >Classes implement capabilities; Methods execute capabilities. >In the long run, a plug-in based system can be used to substitute >implementation >but retain the use of the interface. > >So, use inheritance for internal code reuse and interfaces for >contract definition. > >As the famous GoF book says: > >Prefer interfaces over inheritance. > >Use interfaces as a design-time resource when you are planning your system. >It is almost always useful to define a contract of functionality for >a given set of features. Clients of such a contract should never >have to bother with details of actual implementations. - DL public interface SerialPortInterface extends CommPortInterface { int DATABITS_5 = 5; int DATABITS_6 = 6; int DATABITS_7 = 7; int DATABITS_8 = 8; int PARITY_NONE = 0; int PARITY_ODD = 1; int PARITY_EVEN = 2; int PARITY_MARK = 3; int PARITY_SPACE = 4; int STOPBITS_1 = 1; int STOPBITS_2 = 2; int STOPBITS_1_5 = 3; int FLOWCONTROL_NONE = 0; int FLOWCONTROL_RTSCTS_IN = 1; int FLOWCONTROL_RTSCTS_OUT = 2; int FLOWCONTROL_XONXOFF_IN = 4; int FLOWCONTROL_XONXOFF_OUT = 8; /** * @return true if the DTR bit is set. * * @see #setDTR */ boolean isCTS(); /** * @return true if the DTR bit is set. * */ boolean isDSR(); /** * @return true if the CD bit is set. * */ boolean isCD(); /** * @return true if the RI bit is set. * */ boolean isRI(); /** * @return true if the RTS bit is set. * * @see #setRTS */ boolean isRTS(); /** would someone like to write some nice javadoc for the following? */ void addEventListener(SerialPortEventListener lsnr) throws TooManyListenersException; void removeEventListener(); void notifyOnDataAvailable(boolean enable); void notifyOnOutputEmpty(boolean enable); void notifyOnCTS(boolean enable); void notifyOnDSR(boolean enable); void notifyOnRingIndicator(boolean enable); void notifyOnCarrierDetect(boolean enable); void notifyOnOverrunError(boolean enable); void notifyOnParityError(boolean enable); void notifyOnFramingError(boolean enable); void notifyOnBreakInterrupt(boolean enable); byte getParityErrorChar() throws UnsupportedCommOperationException; boolean setParityErrorChar(byte b) throws UnsupportedCommOperationException; byte getEndOfInputChar() throws UnsupportedCommOperationException; boolean setEndOfInputChar(byte b) throws UnsupportedCommOperationException; boolean setUARTType(String type, boolean test) throws UnsupportedCommOperationException; String getUARTType() throws UnsupportedCommOperationException; boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException; int getBaudBase() throws UnsupportedCommOperationException; boolean setDivisor(int Divisor) throws UnsupportedCommOperationException; int getDivisor() throws UnsupportedCommOperationException; boolean setLowLatency() throws UnsupportedCommOperationException; boolean getLowLatency() throws UnsupportedCommOperationException; boolean setCallOutHangup(boolean NoHup) throws UnsupportedCommOperationException; boolean getCallOutHangup() throws UnsupportedCommOperationException; /** * @return the current baud rate */ int getBaudRate(); /** * @return the current number of data bits: DATABITS_5, DATABITS_6, * DATABITS_7, or DATABITS_8. */ int getDataBits(); /** * @return the current number of stop bits: STOPBITS_1, STOPBITS_2, or * STOPBITS_1_5. */ int getStopBits(); /** * @return the current parity scheme: PARITY_NONE, PARITY_ODD, * PARITY_EVEN, PARITY_MARK or PARITY_SPACE. */ int getParity(); /** * Sends a break of the specified duration. * * @param millis the duration in milliseconds */ void sendBreak(int millis); /** * Sets the flow control mode. * * @param flowcontrol a bitmask combination of FLOWCONTROL_NONE, * FLOWCONTROL_RTSCTS_IN, FLOWCONTROL_RTSCTS_OUT, * FLOWCONTROL_XONXOFF_IN, and/or FLOWCONTROL_XONXOFF_OUT. */ void setFlowControlMode(int flowcontrol); /** * @return the current flow control mode as a bitmask of * FLOWCONTROL_NONE, FLOWCONTROL_RTSCTS_IN, FLOWCONTROL_RTSCTS_OUT, * FLOWCONTROL_XONXOFF_IN, and/or FLOWCONTROL_XONXOFF_OUT. */ int getFlowControlMode(); /** * Set the Receive Fifo trigger level. * If the UART has a FIFO and if it can have programmable trigger * levels, then this method will cause the UART to raise an interrupt * after trigger bytes have been received. * * @param trigger the trigger level * @deprecated */ void setRcvFifoTrigger(int trigger); /** * Sets the serial port parameters. * * @param baudRate the baud rate * @param dataBits the number of data bits: DATABITS_5, * DATABITS_6, DATABITS_7, or DATABITS_8 * @param stopBits the number of stop bits: STOPBITS_1, * STOPBITS_2, or STOPBITS_1_5 * @param parity the parity schema: PARITY_NONE, PARITY_ODD, * PARITY_EVEN, PARITY_MARK or PARITY_SPACE * @throws UnsupportedCommOperationException */ void setSerialPortParams(int baudRate, int dataBits, int stopBits, int parity) throws UnsupportedCommOperationException; /** * Sets or clears the DTR bit in the UART. * * @param dtr the Data Terminal Ready bit value * @see #isDTR */ void setDTR(boolean dtr); /** * @return true if the DTR bit is set. * * @see #setDTR */ boolean isDTR(); /** * Sets or clears the RTS bit in the UART. * * @param rts the Request To Send bit value */ void setRTS(boolean rts); } Here is the CommPortInterface: public interface CommPortInterface { /** * @return the name of this port. * */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is disabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } From tjarvi at qbang.org Sun Jul 30 17:43:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 30 Jul 2006 17:43:13 -0600 (MDT) Subject: [Rxtx] RMI In-Reply-To: References: Message-ID: On Sun, 30 Jul 2006, Dr. Douglas Lyon wrote: > Hi All, > > If you ever want to use serial ports with RMI, > a nice set of interfaces will be required. > So this would eventually lead to j2ee beans and such. The security model would have to be examined for this. Often there are tens of thousands of dollars in instrumentation or even cash drawers/POS sitting on the other end of the cable. A serial port should be no less secure than a hard drive. I think security is going to be OK but then we are opening up for a bunch of questions about how to get it working. That puts us in a position of answering how to bypass security with RMI to access hard drives [or serial ports]. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Jul 30 21:48:01 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 30 Jul 2006 22:48:01 -0500 Subject: [Rxtx] RMI In-Reply-To: References: Message-ID: <44CD7D71.2080306@cox.net> Trent Jarvi wrote: > On Sun, 30 Jul 2006, Dr. Douglas Lyon wrote: >>If you ever want to use serial ports with RMI, >>a nice set of interfaces will be required. > > So this would eventually lead to j2ee beans and such. > > The security model would have to be examined for this. Often there are > tens of thousands of dollars in instrumentation or even cash drawers/POS > sitting on the other end of the cable. > > A serial port should be no less secure than a hard drive. I think > security is going to be OK but then we are opening up for a bunch of > questions about how to get it working. > > That puts us in a position of answering how to bypass security with RMI to > access hard drives [or serial ports]. This really depends on whether you want those streams to be visible remotely, directly or not. I think that it is poor engineering practice for any Remote access to directly expose the raw hardware/stream/data. You need to have choices on how to transport and encapsulate data streams. This is the power of the RMI programming model. Mobile code can put computational activities on the client instead of the server. The next generation of RMI, with all of the security features you need was developed by the original RMI team and some others, and is the Jini Extensible Remote Invocation (JERI) stack that is available in Jini 2.0 and later versions (http://www.jini.org and http://starterkit.dev.java.net). One of the primary things that JERI provides is an authentication and authorization mechanism that is activated at deployment time, instead of being coded into the libraries. Gregg Wonderly From guille at sms.nl Mon Jul 31 03:17:29 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Mon, 31 Jul 2006 11:17:29 +0200 Subject: [Rxtx] interfaces vs. abstract classes In-Reply-To: References: Message-ID: <7.0.1.0.0.20060731111659.0363b620@sms.nl> At 12:28 30/07/2006, Dr. Douglas Lyon wrote: >Hi All, >I was thinking that the new JSR might be more >interface oriented and less abstract class oriented. > >For example, instead of subclassing CommPort, perhaps >we should implement a CommPortInterface. > >How would this look? Will it break backwards compatibility? Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From lyon at docjava.com Mon Jul 31 04:57:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 31 Jul 2006 06:57:39 -0400 Subject: [Rxtx] Rxtx RMI/SSL In-Reply-To: <44CD7D71.2080306@cox.net> References: <44CD7D71.2080306@cox.net> Message-ID: Hi All, Networked based serial ports are a nice option for java clients that do not need (or want) native method drivers installed. Applications include web-controlled robotics, network-based modems, auto-dialing addressbooks (remote dialers), remote sensing, etc. If you are behind a firewall, you may not feel the need for RMI/SSL security. After all, hacking into a serial port behind a firewall does seem a bit over-the-top. On the other hand, for those who feel they want to go over the Internet; I have been playing around with RMI over SSL. Here is a paper on the topic: http://show.docjava.com:8086/pub/document/jot/rjs.pdf Remote Job Submission Security by Pawel Krepstzul and Douglas A. Lyon, in Journal of Object Technology, vol. 5, no. 1, Janurary-February 2006, pp. 13-29. From the programmer point-of-view the SSL part is not quite transparent, but, given proper diligence, can be made somewhat secure. Naturally, you can put the exchange in a high-level of abstraction. I guess it really depends on the application. The question of how level-of-abstraction impacts security, remains open. You may observe a trend toward RMI based API's by looking at JAI (Java Advanced Imaging). Cheers! - Doug >Trent Jarvi wrote: >> On Sun, 30 Jul 2006, Dr. Douglas Lyon wrote: >>>If you ever want to use serial ports with RMI, >>>a nice set of interfaces will be required. >> >> So this would eventually lead to j2ee beans and such. >> >> The security model would have to be examined for this. Often there are >> tens of thousands of dollars in instrumentation or even cash drawers/POS >> sitting on the other end of the cable. >> >> A serial port should be no less secure than a hard drive. I think >> security is going to be OK but then we are opening up for a bunch of >> questions about how to get it working. >> >> That puts us in a position of answering how to bypass security with RMI to >> access hard drives [or serial ports]. > >This really depends on whether you want those streams to be visible remotely, >directly or not. I think that it is poor engineering practice for any Remote >access to directly expose the raw hardware/stream/data. You need to have >choices on how to transport and encapsulate data streams. This is >the power of >the RMI programming model. Mobile code can put computational >activities on the >client instead of the server. > >The next generation of RMI, with all of the security features you need was >developed by the original RMI team and some others, and is the Jini Extensible >Remote Invocation (JERI) stack that is available in Jini 2.0 and >later versions >(http://www.jini.org and http://starterkit.dev.java.net). > >One of the primary things that JERI provides is an authentication and >authorization mechanism that is activated at deployment time, instead of being >coded into the libraries. > >Gregg Wonderly >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Mon Jul 31 07:16:51 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 31 Jul 2006 15:16:51 +0200 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> Message-ID: <1154351811.44ce02c3a5539@webmail.eatserver.nl> Hi Doug, I understand. Note that we are not only concerned about source compatibility, but also about binary compatibility (which would be preserved as well with this approach if I understood correctly) Best regards, Guillermo Quoting "Dr. Douglas Lyon" : > Hi All, > At present I have a prototype version of the libraries that I am > testing that contains the Interfaces, with growing Javadoc. > I have been refactoring my code to take advantage of these > interfaces, but, in the interest of backward compatibility, > have left the abstract classes, for those who want to continue > to use and test them. So there is 100% backward compatibility. > > My goal is to identify the features of the class specification and > provide good documentation for them. I think this is seen most clearly in > the below code. This has ZERO impact on existing code that > seeks to make use of the CommPort class. > > I am adding interfaces and documentation to arrive at a specification. > Abstract methods and constants move from the abstract class into the > interface, but then the abstract class implements the interface. > > To the API user, it should have no effect. > > Cheers! > - Doug > > > public interface CommPortIdentifierInterface { > > int PORT_I2C = 3; > int PORT_RS485 = 4; > int PORT_RAW = 5; > /** > * RS-232 serial port. > */ > int PORT_SERIAL = 1; > /** > * IEEE 1284 parallel port. > */ > int PORT_PARALLEL = 2; > > > > /** > * @return the port name, typically an OS-dependent hardware label. > * > */ > String getName(); > > /** > * @return the port type, PORT_SERIAL or PORT_PARALLEL. > */ > int getPortType() > ; > > /** > * @return the current owner of this port. > */ > String getCurrentOwner() > ; > > /** > * @return true if this port is currently owned. > */ > boolean isCurrentlyOwned() ; > > /** > * @return communications port. > * If the port is in use by another application, it will be notified > * with a PORT_OWNERSHIP_REQUESTED event. If the current owner closes > * the port, then this method will succeed. Otherwise a > * PortInUseException will be thrown. > * @param appName the name of the application requesting the port > * @param timeout number of miliseconds to wait for the port to open > * @throws PortInUseException > */ > CommPortInterface open(String appName, int timeout) > throws PortInUseException; > > /** > * @return a port using a file descriptor. > * @param fd the file descriptor > * @exception UnsupportedCommOperationException if the platform does > not > * support this functionality > */ > CommPortInterface open(FileDescriptor fd) > throws UnsupportedCommOperationException; > > /** > * Adds the specified listener to the list of ownership listeners for > * this port. > * @param listener the ownership listener to add > */ > void addPortOwnershipListener(CommPortOwnershipListener listener); > > /** > * Removes the specified listener from the list of ownership listeners > for > * this port. > * @param listener the ownership listener to remove > */ > void removePortOwnershipListener(CommPortOwnershipListener listener); > } > public abstract class CommPort implements CommPortInterface { > protected String name; > private final static boolean debug = false; > > public void close() { > if (debug) System.out.println("CommPort:close()"); > > try { > CommPortIdentifierInterface cp = > CommPortIdentifier.getPortIdentifier(this); > if (cp != null) > > CommPortIdentifier.getPortIdentifier(this).internalClosePort(); > } > catch (NoSuchPortException e) { > e.printStackTrace(); > } > } > > public String getName() { > if (debug) System.out.println("CommPort:getName()"); > return (name); > } > > public String toString() { > if (debug) System.out.println("CommPort:toString()"); > return (name); > } > } > >At 12:28 30/07/2006, Dr. Douglas Lyon wrote: > >>Hi All, > >>I was thinking that the new JSR might be more > >>interface oriented and less abstract class oriented. > >> > >>For example, instead of subclassing CommPort, perhaps > >>we should implement a CommPortInterface. > >> > >>How would this look? > > > >Will it break backwards compatibility? > > > >Guillermo > >-- > >Guillermo Rodriguez Garcia > > > >Snijder Micro Systems phone +31-493-351020 > >G. Rodriguez Garcia fax +31-493-351530 > >Visser 25 email guille at sms.nl > >NL5751 BL Deurne > >The Netherlands http://www.snijder.com > > -- http://www.snijder.com/ SNIJDER Micro Systems From lyon at docjava.com Mon Jul 31 07:44:29 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 31 Jul 2006 09:44:29 -0400 Subject: [Rxtx] Do interfaces break backwards BINARY compatibility? Welcome to the serial ports of tomorrow! In-Reply-To: <1154351811.44ce02c3a5539@webmail.eatserver.nl> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> Message-ID: Hi All, The jar file, comm.jar, will change in the sense that there will be new byte codes for Interfaces and the abstract classes byte codes will change. However, the native methods are left unchanged. The goal is to specify "what is" via interfaces, minimizing the impact on the API. This enables RXTX to be a reference implementation of the interface specification. If the JSR is accepted and the interfaces become a part of the javax.comm package, then rxtx could implement the javax.comm specification. Thus, my VISION of the FUTURE (ta da): javax.comm programmers code to the javax.comm interfaces and use a factory method to get an RXTX-based driver. Does that sort of make sense? Thanks! - Doug >Hi Doug, > >I understand. Note that we are not only concerned about source >compatibility, but also about binary compatibility (which would be >preserved as well with this approach if I understood correctly) > >Best regards, >Guillermo > >Quoting "Dr. Douglas Lyon" : > >> Hi All, >> At present I have a prototype version of the libraries that I am >> testing that contains the Interfaces, with growing Javadoc. >> I have been refactoring my code to take advantage of these >> interfaces, but, in the interest of backward compatibility, >> have left the abstract classes, for those who want to continue >> to use and test them. So there is 100% backward compatibility. >> >> My goal is to identify the features of the class specification and >> provide good documentation for them. I think this is seen most clearly in >> the below code. This has ZERO impact on existing code that >> seeks to make use of the CommPort class. >> >> I am adding interfaces and documentation to arrive at a specification. >> Abstract methods and constants move from the abstract class into the >> interface, but then the abstract class implements the interface. >> >> To the API user, it should have no effect. >> >> Cheers! >> - Doug >> >> >> public interface CommPortIdentifierInterface { >> >> int PORT_I2C = 3; >> int PORT_RS485 = 4; >> int PORT_RAW = 5; >> /** >> * RS-232 serial port. >> */ >> int PORT_SERIAL = 1; >> /** >> * IEEE 1284 parallel port. >> */ >> int PORT_PARALLEL = 2; >> >> >> >> /** >> * @return the port name, typically an OS-dependent hardware label. >> * >> */ >> String getName(); >> >> /** >> * @return the port type, PORT_SERIAL or PORT_PARALLEL. >> */ >> int getPortType() >> ; >> >> /** >> * @return the current owner of this port. >> */ >> String getCurrentOwner() >> ; >> >> /** >> * @return true if this port is currently owned. >> */ >> boolean isCurrentlyOwned() ; >> >> /** >> * @return communications port. >> * If the port is in use by another application, it will be notified >> * with a PORT_OWNERSHIP_REQUESTED event. If the current owner closes >> * the port, then this method will succeed. Otherwise a >> * PortInUseException will be thrown. >> * @param appName the name of the application requesting the port >> * @param timeout number of miliseconds to wait for the port to open >> * @throws PortInUseException >> */ >> CommPortInterface open(String appName, int timeout) >> throws PortInUseException; >> >> /** >> * @return a port using a file descriptor. >> * @param fd the file descriptor >> * @exception UnsupportedCommOperationException if the platform does >> not >> * support this functionality >> */ >> CommPortInterface open(FileDescriptor fd) >> throws UnsupportedCommOperationException; >> >> /** >> * Adds the specified listener to the list of ownership listeners for >> * this port. >> * @param listener the ownership listener to add >> */ >> void addPortOwnershipListener(CommPortOwnershipListener listener); > > >> /** >> * Removes the specified listener from the list of ownership listeners >> for >> * this port. >> * @param listener the ownership listener to remove >> */ >> void removePortOwnershipListener(CommPortOwnershipListener listener); >> } >> public abstract class CommPort implements CommPortInterface { >> protected String name; >> private final static boolean debug = false; >> >> public void close() { >> if (debug) System.out.println("CommPort:close()"); >> >> try { >> CommPortIdentifierInterface cp = >> CommPortIdentifier.getPortIdentifier(this); >> if (cp != null) >>???????????????? >> CommPortIdentifier.getPortIdentifier(this).internalClosePort(); >> } >> catch (NoSuchPortException e) { >> e.printStackTrace(); >> } >> } >> >> public String getName() { >> if (debug) System.out.println("CommPort:getName()"); >> return (name); >> } >> >> public String toString() { >> if (debug) System.out.println("CommPort:toString()"); >> return (name); >> } >> } >> >At 12:28 30/07/2006, Dr. Douglas Lyon wrote: >> >>Hi All, >> >>I was thinking that the new JSR might be more >> >>interface oriented and less abstract class oriented. >> >> >> >>For example, instead of subclassing CommPort, perhaps >> >>we should implement a CommPortInterface. >> >> >> >>How would this look? >> > >> >Will it break backwards compatibility? >> > >> >Guillermo >> >-- >> >Guillermo Rodriguez Garcia >> > >> >Snijder Micro Systems phone +31-493-351020 >> >G. Rodriguez Garcia fax +31-493-351530 >> >Visser 25 email guille at sms.nl >> >NL5751 BL Deurne >> >The Netherlands http://www.snijder.com >> >> > > >-- >http://www.snijder.com/ >SNIJDER Micro Systems From berkland at spamcop.net Mon Jul 31 07:57:50 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 31 Jul 2006 09:57:50 -0400 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <1154351811.44ce02c3a5539@webmail.eatserver.nl> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> Message-ID: <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> Adding interfaces does not break any kind of compatibility. Java is more forgiving when it comes to this kind of change than languages that are compiled into native code. As long as the implementing class has the same name, same package, and all of the same methods (with the same signatures) you can add on anything you wish, including implementing additional interfaces. On 7/31/06, Guillermo Rodriguez wrote: > Hi Doug, > > I understand. Note that we are not only concerned about source > compatibility, but also about binary compatibility (which would be > preserved as well with this approach if I understood correctly) > > Best regards, > Guillermo From gergg at cox.net Mon Jul 31 08:12:20 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 31 Jul 2006 09:12:20 -0500 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> Message-ID: <44CE0FC4.9010307@cox.net> Doug Berkland wrote: > Adding interfaces does not break any kind of compatibility. Java is > more forgiving when it comes to this kind of change than languages > that are compiled into native code. As long as the implementing class > has the same name, same package, and all of the same methods (with the > same signatures) you can add on anything you wish, including > implementing additional interfaces. Check the Serialization compatibility guidelines for more information on exactly what binary compatibility requires, and what things can change in an interface and/or class which won't break things. Gregg Wonderly From berkland at spamcop.net Mon Jul 31 09:13:00 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 31 Jul 2006 11:13:00 -0400 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <44CE0FC4.9010307@cox.net> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> <44CE0FC4.9010307@cox.net> Message-ID: <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> As far as I can tell, nothing in either RXTX or Sun's JavaCOMM implements Serializable. Therefore, there are no worries from that either. (I can't think of a reason anything in JavaCOMM should implement Serializable either.) On 7/31/06, Gregg Wonderly wrote: > Doug Berkland wrote: > > Adding interfaces does not break any kind of compatibility. Java is > > more forgiving when it comes to this kind of change than languages > > that are compiled into native code. As long as the implementing class > > has the same name, same package, and all of the same methods (with the > > same signatures) you can add on anything you wish, including > > implementing additional interfaces. > > Check the Serialization compatibility guidelines for more information on exactly > what binary compatibility requires, and what things can change in an interface > and/or class which won't break things. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From berkland at spamcop.net Mon Jul 31 09:20:48 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 31 Jul 2006 11:20:48 -0400 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> <44CE0FC4.9010307@cox.net> <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> Message-ID: <269e40090607310820s15f2eee8j903e077917d7fc72@mail.gmail.com> Correction: Nothing except the classes extending Exception and Event implement Serializable. On 7/31/06, Doug Berkland wrote: > As far as I can tell, nothing in either RXTX or Sun's JavaCOMM > implements Serializable. Therefore, there are no worries from that > either. (I can't think of a reason anything in JavaCOMM should > implement Serializable either.) > > On 7/31/06, Gregg Wonderly wrote: > > Doug Berkland wrote: > > > Adding interfaces does not break any kind of compatibility. Java is > > > more forgiving when it comes to this kind of change than languages > > > that are compiled into native code. As long as the implementing class > > > has the same name, same package, and all of the same methods (with the > > > same signatures) you can add on anything you wish, including > > > implementing additional interfaces. > > > > Check the Serialization compatibility guidelines for more information on exactly > > what binary compatibility requires, and what things can change in an interface > > and/or class which won't break things. > > > > Gregg Wonderly > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > From gergg at cox.net Mon Jul 31 11:21:19 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 31 Jul 2006 12:21:19 -0500 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> <44CE0FC4.9010307@cox.net> <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> Message-ID: <44CE3C0F.3080408@cox.net> Doug Berkland wrote: > As far as I can tell, nothing in either RXTX or Sun's JavaCOMM > implements Serializable. Therefore, there are no worries from that > either. (I can't think of a reason anything in JavaCOMM should > implement Serializable either.) Any interface in javax.comm can become implemented by a serializable object. Thus, if someone wants to provide remote access to a serial port, then they might (and I think this is not wise) choose to subclass and add Serializable to the interface list. It's that kind of Serialization compatibility that I'm talking about. Gregg Wonderly From rwelty at suespammers.org Mon Jul 31 19:53:12 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 31 Jul 2006 21:53:12 -0400 Subject: [Rxtx] Application Name? Message-ID: <44CEB408.7040407@suespammers.org> trying to get my app running on a Mac OS X powerbook, when the following is executed as the first thing inside the run method of a Thread: try { port = (SerialPort) selectedPort.open( this.getClass().getName(), 2000); } catch ( PortInUseException ex){ ex.printStackTrace(); return; } i get the following: gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at com.krusty_motorsports.scale.monitor.ScaleWatcher.run(ScaleWatcher.java:143) i've not seen any documentation suggesting that rxtx would be finicky about application names... thanks for any suggestions, richard From stevebeemonkey at monkey-media.co.uk Wed Jul 5 05:59:02 2006 From: stevebeemonkey at monkey-media.co.uk (steve@monkey-media.co.uk) Date: Wed, 5 Jul 2006 04:59:02 -0700 Subject: [Rxtx] No output on WinXP Message-ID: <1152100742.44aba986565e7@www.webmail.ezpublishing.com> Hi there, I've installed RXTX 2.1.7 under Win XP, copying the .jar and .dll files according to the instructions given. I've changed the javax.comm import to gnu.io, but when I run the following code the only output I get is: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Then the program ends, without listing any of the ports. What am I doing wrong? Cheers, Steve Here's my code: ---------------------------------------- import gnu.io.*; import java.util.*; public class PortList { public static void main(String [] args) { Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while(portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); if( portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("Serial port: " + portId.getName()); } else if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { System.out.println("Parallel port: " + portId.getName()); } else System.out.println("Other port: " + portId.getName()); } } } ------------------------------- From tjarvi at qbang.org Wed Jul 5 07:57:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 5 Jul 2006 07:57:22 -0600 (MDT) Subject: [Rxtx] No output on WinXP In-Reply-To: <1152100742.44aba986565e7@www.webmail.ezpublishing.com> References: <1152100742.44aba986565e7@www.webmail.ezpublishing.com> Message-ID: On Wed, 5 Jul 2006, steve at monkey-media.co.uk wrote: > > > Hi there, > > I've installed RXTX 2.1.7 under Win XP, copying the .jar and .dll files > according to the instructions given. > > I've changed the javax.comm import to gnu.io, but when I run the following code > the only output I get is: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Then the program ends, without listing any of the ports. > > What am I doing wrong? > > Cheers, > > Steve > > Here's my code: > > ---------------------------------------- > > import gnu.io.*; > import java.util.*; > > public class PortList > { > public static void main(String [] args) > { > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > while(portList.hasMoreElements()) { > CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); > if( portId.getPortType() == > CommPortIdentifier.PORT_SERIAL) > { > System.out.println("Serial port: " + > portId.getName()); > } else if (portId.getPortType() == > CommPortIdentifier.PORT_PARALLEL) > { > System.out.println("Parallel port: " + > portId.getName()); > } else > System.out.println("Other port: " + > portId.getName()); > } > } > } > > ------------------------------- > If you have a port open with another terminal such as hyperterminal or even another copy of your application using rxtx, the port will not be enumerated. rxtx enumerates ports by opening prospective ports and doing a timed out read. If the port is open by another application, the open will fail. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Wed Jul 5 15:44:05 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Wed, 5 Jul 2006 15:44:05 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EA89@hqexchange3.dot.state.co.us> Trent, I did put some debug statements and the "index" returned to me in the while loop is "0" (see the code below) and it gets into the infinite loop, I can put a break statement but don't know the ramifications of it. Can you explain in what scenarios the index can be "0" or are we somehow in the native code loosing refrences to the indexes? Thanks Again Pawan Kharbanda while( searching ) { index = master_index; if( index ) { while( index->fd != fd && index->next ) index = index->next; if ( index->fd == fd ) searching = 0; } else report("Index"+index"x"); <<<<<< The code gets to this statement and index is returned as "0" and I don't see anyway to break out of this looop after. if( searching ) { report("@"); usleep(1000); } } -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, June 29, 2006 6:21 AM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports > Here is how you can test if you have resources/ test environment. > Write a program and try to open/close different ports(I will say have > a minimum of four) randomly and very frequently(may be 30 seconds), I > am pretty sure you will see the deadlocks and it happens in the native > call to interrptEventLoop in RXTXPort.java in removeEventListener() > method call. Hi Pawan I'll try to find a way to reproduce this. One thing to note is that you are using different kernel drivers (digi) to perform this task. So I probably will not be able to reproduce the exact same environment. In general, multiport kernel drivers have been tested far less than typical serial drivers. This may or may not be an issue. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Wed Jul 5 18:50:01 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Wed, 5 Jul 2006 18:50:01 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EA96@hqexchange3.dot.state.co.us> Trent, Sorry for so many emails, but as I mentioned earlier I will write a test to replicate the Locking problem. I am attaching a Java file to replicate the problem. You need atleast 4-5 ports to simulate the problem. Here is how to run the program. In the TestOpenClosePort.java please change the Serial Ports names(Add the ports installed on your machine). Then compile your java file and run as "java TestOpenClosePort 100" (100 is the no of times you want to open and close the port in one single thread). I have tested this with the Digi Boxes and able to replicate this over and over in Single JVM. Hope this test helps track down the problem. Thanks Pawan Kharbanda -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, June 29, 2006 6:21 AM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports > Here is how you can test if you have resources/ test environment. > Write a program and try to open/close different ports(I will say have > a minimum of four) randomly and very frequently(may be 30 seconds), I > am pretty sure you will see the deadlocks and it happens in the native > call to interrptEventLoop in RXTXPort.java in removeEventListener() > method call. Hi Pawan I'll try to find a way to reproduce this. One thing to note is that you are using different kernel drivers (digi) to perform this task. So I probably will not be able to reproduce the exact same environment. In general, multiport kernel drivers have been tested far less than typical serial drivers. This may or may not be an issue. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: TestOpenClosePort.java Type: application/octet-stream Size: 6038 bytes Desc: TestOpenClosePort.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060705/82f8488f/TestOpenClosePort-0360.obj From tjarvi at qbang.org Wed Jul 5 22:48:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 5 Jul 2006 22:48:52 -0600 (MDT) Subject: [Rxtx] Locked Ports In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3EA89@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03F3EA89@hqexchange3.dot.state.co.us> Message-ID: On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did put some debug statements and the "index" returned to me in > the while loop is "0" (see the code below) and it gets into the infinite > loop, I can put a break statement but don't know the ramifications of > it. Can you explain in what scenarios the index can be "0" or are we > somehow in the native code loosing refrences to the indexes? > > Thanks Again > Pawan Kharbanda > > while( searching ) > { > index = master_index; > > if( index ) > { > while( index->fd != fd && > index->next ) index = index->next; > if ( index->fd == fd ) searching = 0; > } > else > report("Index"+index"x"); <<<<<< The code gets > to this statement and index is returned as "0" and I don't see anyway to > break out of this looop after. > if( searching ) > { > report("@"); > usleep(1000); > } > } > Hi Pawan I am reading with interest :) So it sounds like this is a thread safe problem. The thing I don't understand here is open and close are synchronized in RXTXPort.java. I thought that would prevent any thread problems with the linked list. Looking closer, the linked list is actually populated in eventLoop/MonitorThread which is not synchronized. So you may be able to synchronize on an object in RXTXPort.java. A seperate native call would probably be required for the initalization to prevent a deadlock. A solution might involve making finalize_event_info_struct() and initialise_event_info_struct() [uk spelling?] thread safe with glib. http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads.html#id2786034 glib also has more robust linked lists which could be used. Thats the indirectly the problem found in termios.c for windows. The disadvantage is we would require linking to glib which is another step for systems that don't come with it. The advantage would be reduced code size we have to maintain. We could borrow bits of glib as the licenses are the same. Another solution might be to just use pthread_mutex_lock and unlock. http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html I don't think that would work on windows though. It would require linking cygwin.dll which would not work with nonGPL projects in practice. -- Trent Jarvi tjarvi From neville_seed at yahoo.com Thu Jul 6 06:42:29 2006 From: neville_seed at yahoo.com (neville seed) Date: Thu, 6 Jul 2006 05:42:29 -0700 (PDT) Subject: [Rxtx] port to palm OS? Message-ID: <20060706124230.55790.qmail@web51015.mail.yahoo.com> hello. Has rxtx been ported to PalmOS? regards neville __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From neville_seed at yahoo.com Thu Jul 6 06:43:44 2006 From: neville_seed at yahoo.com (neville seed) Date: Thu, 6 Jul 2006 05:43:44 -0700 (PDT) Subject: [Rxtx] example code Message-ID: <20060706124344.5063.qmail@web51013.mail.yahoo.com> hello. Could anyone provide me with example code of how to read from the serial port. regards neville __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From naranjo.manuel at gmail.com Thu Jul 6 06:48:20 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Thu, 06 Jul 2006 09:48:20 -0300 Subject: [Rxtx] port to palm OS? In-Reply-To: <20060706124230.55790.qmail@web51015.mail.yahoo.com> References: <20060706124230.55790.qmail@web51015.mail.yahoo.com> Message-ID: <44AD0694.1090703@gmail.com> neville seed wrote: > hello. > > Has rxtx been ported to PalmOS? > > regards > neville > I'm interested on this. Do you need rxtx ported to J2ME or to Superwaba?. Superwaba has it owns implementation of a serial port, but it is not rxtx. Regards, Manuel From joachim at buechse.de Thu Jul 6 07:20:57 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 6 Jul 2006 15:20:57 +0200 Subject: [Rxtx] port to palm OS? In-Reply-To: <20060706124230.55790.qmail@web51015.mail.yahoo.com> References: <20060706124230.55790.qmail@web51015.mail.yahoo.com> Message-ID: Which version of PalmOS are you targeting? I have been doing some Java on PalmOS programming for the Palm Vx using the JVM from Esmertec. The problem there was, that PalmOS can only process one kernel call at a time (it is (was?) not a multithreading OS). Threads were implemented by the VM. In a situation like this, any kind of "abort" mechanism is very difficult to handle - from what I know about the RXTX code and the way close() would have to be implemented it's the same as rewriting RXTX. Newer versions of PalmOS might have improved in this respect... Best regards, Joachim On 06.07.2006, at 14:42, neville seed wrote: > hello. > > Has rxtx been ported to PalmOS? > > regards > neville > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From neville_seed at yahoo.com Thu Jul 6 08:23:29 2006 From: neville_seed at yahoo.com (neville seed) Date: Thu, 6 Jul 2006 07:23:29 -0700 (PDT) Subject: [Rxtx] port to palm OS? In-Reply-To: Message-ID: <20060706142329.91625.qmail@web51005.mail.yahoo.com> The palmOS would be version 5.x however i am new to both palm and java. As such I would have to find out any questions. --- Joachim Buechse wrote: > Which version of PalmOS are you targeting? > > I have been doing some Java on PalmOS programming > for the Palm Vx > using the JVM from Esmertec. The problem there was, > that PalmOS can > only process one kernel call at a time (it is (was?) > not a > multithreading OS). Threads were implemented by the > VM. In a > situation like this, any kind of "abort" mechanism > is very difficult > to handle - from what I know about the RXTX code and > the way close() > would have to be implemented it's the same as > rewriting RXTX. Newer > versions of PalmOS might have improved in this > respect... > > Best regards, > Joachim > > On 06.07.2006, at 14:42, neville seed wrote: > > > hello. > > > > Has rxtx been ported to PalmOS? > > > > regards > > neville > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From jhaysonn at gmail.com Thu Jul 6 08:58:07 2006 From: jhaysonn at gmail.com (jhaysonn pathak) Date: Thu, 6 Jul 2006 10:58:07 -0400 Subject: [Rxtx] RXTX install (jhaysonn pathak) Message-ID: Thanks for the install tip. I figured out how to do the cvs update, but in my MACOSX_IDE dir I didn't have any Xcode folders and searching my computer, I only have 3 Xcode folders (one for application support, one for Max/MSP and one in developer tools). I have tried building each of the different *.xcodeproj files and in eachone they have little toolbox looking items that are in red (i assume that means it can't find them). Some of them I manage to locate but some of them just aren't on my computer. In any event, I still can't find the libserial.jnilib. After the update I read the README.OSX and it did make it seem a lot easier, but for the future, if I finally create a libserial.jnilib I don't know what the 'JavaVM' is in reference to this line "Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required)." PS - How do I uninstall everything RXTX so that I can try and re-download and re-install everything? From joachim at buechse.de Thu Jul 6 09:12:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 6 Jul 2006 17:12:24 +0200 Subject: [Rxtx] RXTX install (jhaysonn pathak) In-Reply-To: References: Message-ID: <98F15662-544D-41B5-8229-BB1DB6B6FD43@buechse.de> The Java VM ist the Java Virtual Machine. It runs your application. For the rest of your message ... your description is much to unprecise to help. To start, you could describe what IS in the MACOSX_IDE folder and its subfolders. On 06.07.2006, at 16:58, jhaysonn pathak wrote: > Thanks for the install tip. I figured out how to do the cvs update, > but in my MACOSX_IDE dir I didn't have any Xcode folders and searching > my computer, I only have 3 Xcode folders (one for application support, > one for Max/MSP and one in developer tools). I have tried building > each of the different *.xcodeproj files and in eachone they have > little toolbox looking items that are in red (i assume that means it > can't find them). Some of them I manage to locate but some of them > just aren't on my computer. In any event, I still can't find the > libserial.jnilib. > > After the update I read the README.OSX and it did make it seem a lot > easier, but for the future, if I finally create a libserial.jnilib I > don't know what the 'JavaVM' is in reference to this line > > "Put > libSerial.jnilib > in the directory of the application (the JavaVM will find it > there). Add > RXTXComm.jar > to the application classpath or include the classes in the > application jar. > (Some applications already include the RXTX classes in their > application jar, > in which case only the file libSerial.jnilib is required)." > > PS - How do I uninstall everything RXTX so that I can try and > re-download and re-install everything? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jul 6 09:20:16 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 6 Jul 2006 17:20:16 +0200 Subject: [Rxtx] RXTX install (jhaysonn pathak) In-Reply-To: References: Message-ID: <8F03CA0E-44F4-434F-AA7E-3A8B5054AA6F@buechse.de> Rethinking about your problem... I think you should try a cvs up -d Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 06.07.2006, at 16:58, jhaysonn pathak wrote: > Thanks for the install tip. I figured out how to do the cvs update, > but in my MACOSX_IDE dir I didn't have any Xcode folders and searching > my computer, I only have 3 Xcode folders (one for application support, > one for Max/MSP and one in developer tools). I have tried building > each of the different *.xcodeproj files and in eachone they have > little toolbox looking items that are in red (i assume that means it > can't find them). Some of them I manage to locate but some of them > just aren't on my computer. In any event, I still can't find the > libserial.jnilib. > > After the update I read the README.OSX and it did make it seem a lot > easier, but for the future, if I finally create a libserial.jnilib I > don't know what the 'JavaVM' is in reference to this line > > "Put > libSerial.jnilib > in the directory of the application (the JavaVM will find it > there). Add > RXTXComm.jar > to the application classpath or include the classes in the > application jar. > (Some applications already include the RXTX classes in their > application jar, > in which case only the file libSerial.jnilib is required)." > > PS - How do I uninstall everything RXTX so that I can try and > re-download and re-install everything? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Thu Jul 6 10:19:17 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Thu, 06 Jul 2006 13:19:17 -0300 Subject: [Rxtx] port to palm OS? In-Reply-To: <20060706142329.91625.qmail@web51005.mail.yahoo.com> References: <20060706142329.91625.qmail@web51005.mail.yahoo.com> Message-ID: <44AD3805.3010609@gmail.com> neville seed wrote: > The palmOS would be version 5.x however i am new to > both palm and java. As such I would have to find out > any questions. > Hello if you are new you could use Superwaba, url: www.superwaba.com, which is not exactly Java but works great, and has a serial port. If you need any more info please let me know. Manuel From Pawan.Kharbanda at dot.state.co.us Thu Jul 6 12:49:50 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 6 Jul 2006 12:49:50 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EB11@hqexchange3.dot.state.co.us> Trent, I did made the eventLoop() call in the Monitor Thread synchronized, it improved but still see the same problem. Your comment > A solution might involve making finalize_event_info_struct() and > initialise_event_info_struct() [uk spelling?] thread safe with glib. I didn't follow this how I can implement this. I am not a C guy, can you help me understand how I can implement this? Thanks Pawan Kharbanda -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, July 05, 2006 10:49 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did put some debug statements and the "index" returned to me in > the while loop is "0" (see the code below) and it gets into the > infinite loop, I can put a break statement but don't know the > ramifications of it. Can you explain in what scenarios the index can > be "0" or are we somehow in the native code loosing refrences to the indexes? > > Thanks Again > Pawan Kharbanda > > while( searching ) > { > index = master_index; > > if( index ) > { > while( index->fd != fd && > index->next ) index = index->next; > if ( index->fd == fd ) searching = 0; > } > else > report("Index"+index"x"); <<<<<< The code gets to this statement > and index is returned as "0" and I don't see anyway to break out of > this looop after. > if( searching ) > { > report("@"); > usleep(1000); > } > } > Hi Pawan I am reading with interest :) So it sounds like this is a thread safe problem. The thing I don't understand here is open and close are synchronized in RXTXPort.java. I thought that would prevent any thread problems with the linked list. Looking closer, the linked list is actually populated in eventLoop/MonitorThread which is not synchronized. So you may be able to synchronize on an object in RXTXPort.java. A seperate native call would probably be required for the initalization to prevent a deadlock. A solution might involve making finalize_event_info_struct() and initialise_event_info_struct() [uk spelling?] thread safe with glib. http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. html#id2786034 glib also has more robust linked lists which could be used. Thats the indirectly the problem found in termios.c for windows. The disadvantage is we would require linking to glib which is another step for systems that don't come with it. The advantage would be reduced code size we have to maintain. We could borrow bits of glib as the licenses are the same. Another solution might be to just use pthread_mutex_lock and unlock. http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html I don't think that would work on windows though. It would require linking cygwin.dll which would not work with nonGPL projects in practice. -- Trent Jarvi tjarvi _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From zhanglong at adventnet.com Wed Jul 5 20:44:18 2006 From: zhanglong at adventnet.com (zhanglong) Date: Thu, 06 Jul 2006 10:44:18 +0800 Subject: [Rxtx] rxtx can not read data from serialport Message-ID: <44AC7902.8070407@adventnet.com> Dear sir, When I use rxrx2.1-7-bin-r2?I can write data into serialport,But can not read data from serialport on windowsXP. I can not write and read data from serialport on Redhat Linux9.0. I can get serialport list on my machine.And no error with open serialport. I can get and read data from serialport on windowsXP with SUN's javacomm20-win32.zip. How can I read data on windows and write,read data on Linux with rxtx? Best Regards, Zhanglong From tjarvi at qbang.org Thu Jul 6 19:07:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 19:07:13 -0600 (MDT) Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: <44AC7902.8070407@adventnet.com> References: <44AC7902.8070407@adventnet.com> Message-ID: On Thu, 6 Jul 2006, zhanglong wrote: > Dear sir, > > When I use rxrx2.1-7-bin-r2??I can write data into serialport,But can > not read data from serialport on windowsXP. > I can not write and read data from serialport on Redhat Linux9.0. > I can get serialport list on my machine.And no error with open serialport. > > I can get and read data from serialport on windowsXP with SUN's > javacomm20-win32.zip. > > How can I read data on windows and write,read data on Linux with rxtx? > > Hi Zhanglong Make sure that you specify the flow control, timeout and threshold that you want. The defaults may vary between rxtx and Sun. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jul 6 19:10:25 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 19:10:25 -0600 (MDT) Subject: [Rxtx] Controlling Individual Signals DTR and RTS In-Reply-To: References: Message-ID: On Thu, 29 Jun 2006, Chris Pine wrote: > Dear Moussa Ba, > I hope I am not being too forward, but we are having the exact same > issue with needing to control DTR from RXTX in Linux. Did you ever have any > luck figuring it out? > > Thank you very much for your time, > Hi Chris Are you using an unusual serial port? It could be that the port does not support DTR/RTS. Especially if its an inexpensive USB->Serial dongle. I'll double check Linux tomorrow but I'm fairly sure it works. I have verified windows after a questions like yours. Some multiport cards and usb dongles do not support everything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jul 6 19:17:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 19:17:09 -0600 (MDT) Subject: [Rxtx] Locked Ports In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3EB11@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03F3EB11@hqexchange3.dot.state.co.us> Message-ID: Hi Pawan There is an example of doing this in the link I provided below. They make a pointer to the function they want to be thread safe and then use that with the glib functions. I'm not ready to just toss out a quick hack because I'd like to think through this a bit to make sure I understand what types of problems we may run into. The code still hung in the same place after synchronizing the eventLoop? I think that eventLoop needs to be refactored to pull out the initialization code so people do not need to run the monitor. On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did made the eventLoop() call in the Monitor Thread synchronized, it > improved but still see the same problem. > > Your comment >> A solution might involve making finalize_event_info_struct() and >> initialise_event_info_struct() [uk spelling?] thread safe with glib. > > I didn't follow this how I can implement this. I am not a C guy, can you > help me understand how I can implement this? > > Thanks > Pawan Kharbanda > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Wednesday, July 05, 2006 10:49 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] Locked Ports > > On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > >> Trent, >> I did put some debug statements and the "index" returned to me in >> the while loop is "0" (see the code below) and it gets into the >> infinite loop, I can put a break statement but don't know the >> ramifications of it. Can you explain in what scenarios the index can >> be "0" or are we somehow in the native code loosing refrences to the > indexes? >> >> Thanks Again >> Pawan Kharbanda >> >> while( searching ) >> { >> index = master_index; >> >> if( index ) >> { >> while( index->fd != fd && >> index->next ) index = index->next; >> if ( index->fd == fd ) searching = 0; >> } >> else >> report("Index"+index"x"); <<<<<< The code gets > to this statement >> and index is returned as "0" and I don't see anyway to break out of >> this looop after. >> if( searching ) >> { >> report("@"); >> usleep(1000); >> } >> } >> > > Hi Pawan > > I am reading with interest :) > > So it sounds like this is a thread safe problem. > > The thing I don't understand here is open and close are synchronized in > RXTXPort.java. I thought that would prevent any thread problems with > the linked list. Looking closer, the linked list is actually populated > in eventLoop/MonitorThread which is not synchronized. > > So you may be able to synchronize on an object in RXTXPort.java. A > seperate native call would probably be required for the initalization to > prevent a deadlock. > > A solution might involve making finalize_event_info_struct() and > initialise_event_info_struct() [uk spelling?] thread safe with glib. > > http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. > html#id2786034 > > glib also has more robust linked lists which could be used. Thats the > indirectly the problem found in termios.c for windows. The disadvantage > is we would require linking to glib which is another step for systems > that don't come with it. The advantage would be reduced code size we > have to maintain. We could borrow bits of glib as the licenses are the > same. > > Another solution might be to just use pthread_mutex_lock and unlock. > > http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html > > I don't think that would work on windows though. It would require > linking cygwin.dll which would not work with nonGPL projects in > practice. > > -- > Trent Jarvi > tjarvi > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Pawan.Kharbanda at dot.state.co.us Thu Jul 6 21:46:08 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 6 Jul 2006 21:46:08 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EB35@hqexchange3.dot.state.co.us> Trent, Just curious to know if you were able to replicate the problem with my example? Pawan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, July 06, 2006 7:17 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports Hi Pawan There is an example of doing this in the link I provided below. They make a pointer to the function they want to be thread safe and then use that with the glib functions. I'm not ready to just toss out a quick hack because I'd like to think through this a bit to make sure I understand what types of problems we may run into. The code still hung in the same place after synchronizing the eventLoop? I think that eventLoop needs to be refactored to pull out the initialization code so people do not need to run the monitor. On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did made the eventLoop() call in the Monitor Thread synchronized, > it improved but still see the same problem. > > Your comment >> A solution might involve making finalize_event_info_struct() and >> initialise_event_info_struct() [uk spelling?] thread safe with glib. > > I didn't follow this how I can implement this. I am not a C guy, can > you help me understand how I can implement this? > > Thanks > Pawan Kharbanda > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Wednesday, July 05, 2006 10:49 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] Locked Ports > > On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > >> Trent, >> I did put some debug statements and the "index" returned to me in >> the while loop is "0" (see the code below) and it gets into the >> infinite loop, I can put a break statement but don't know the >> ramifications of it. Can you explain in what scenarios the index can >> be "0" or are we somehow in the native code loosing refrences to the > indexes? >> >> Thanks Again >> Pawan Kharbanda >> >> while( searching ) >> { >> index = master_index; >> >> if( index ) >> { >> while( index->fd != fd && >> index->next ) index = index->next; >> if ( index->fd == fd ) searching = 0; >> } >> else >> report("Index"+index"x"); <<<<<< The code gets > to this statement >> and index is returned as "0" and I don't see anyway to break out of >> this looop after. >> if( searching ) >> { >> report("@"); >> usleep(1000); >> } >> } >> > > Hi Pawan > > I am reading with interest :) > > So it sounds like this is a thread safe problem. > > The thing I don't understand here is open and close are synchronized > in RXTXPort.java. I thought that would prevent any thread problems > with the linked list. Looking closer, the linked list is actually > populated in eventLoop/MonitorThread which is not synchronized. > > So you may be able to synchronize on an object in RXTXPort.java. A > seperate native call would probably be required for the initalization > to prevent a deadlock. > > A solution might involve making finalize_event_info_struct() and > initialise_event_info_struct() [uk spelling?] thread safe with glib. > > http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. > html#id2786034 > > glib also has more robust linked lists which could be used. Thats the > indirectly the problem found in termios.c for windows. The > disadvantage is we would require linking to glib which is another step > for systems that don't come with it. The advantage would be reduced > code size we have to maintain. We could borrow bits of glib as the > licenses are the same. > > Another solution might be to just use pthread_mutex_lock and unlock. > > http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html > > I don't think that would work on windows though. It would require > linking cygwin.dll which would not work with nonGPL projects in > practice. > > -- > Trent Jarvi > tjarvi > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jul 6 21:53:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 21:53:49 -0600 (MDT) Subject: [Rxtx] Locked Ports In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3EB35@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03F3EB35@hqexchange3.dot.state.co.us> Message-ID: Pawan: I'm sure I can reproduce the problem. What you have described makes very good sense and has changed how I think about rxtx. 64 ports. Take your design specs and write 'open source' on them. On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > Trent, > Just curious to know if you were able to replicate the problem > with my example? > > Pawan > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Thursday, July 06, 2006 7:17 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] Locked Ports > > > Hi Pawan > > There is an example of doing this in the link I provided below. They > make a pointer to the function they want to be thread safe and then use > that with the glib functions. > > I'm not ready to just toss out a quick hack because I'd like to think > through this a bit to make sure I understand what types of problems we > may run into. > > The code still hung in the same place after synchronizing the eventLoop? > > > > > I think that eventLoop needs to be refactored to pull out the > initialization code so people do not need to run the monitor. > > On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > >> Trent, >> I did made the eventLoop() call in the Monitor Thread synchronized, >> it improved but still see the same problem. >> >> Your comment >>> A solution might involve making finalize_event_info_struct() and >>> initialise_event_info_struct() [uk spelling?] thread safe with glib. >> >> I didn't follow this how I can implement this. I am not a C guy, can >> you help me understand how I can implement this? >> >> Thanks >> Pawan Kharbanda >> >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > >> Of Trent Jarvi >> Sent: Wednesday, July 05, 2006 10:49 PM >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] Locked Ports >> >> On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: >> >>> Trent, >>> I did put some debug statements and the "index" returned to me in >>> the while loop is "0" (see the code below) and it gets into the >>> infinite loop, I can put a break statement but don't know the >>> ramifications of it. Can you explain in what scenarios the index can >>> be "0" or are we somehow in the native code loosing refrences to the >> indexes? >>> >>> Thanks Again >>> Pawan Kharbanda >>> >>> while( searching ) >>> { >>> index = master_index; >>> >>> if( index ) >>> { >>> while( index->fd != fd && >>> index->next ) index = index->next; >>> if ( index->fd == fd ) searching = 0; >>> } >>> else >>> report("Index"+index"x"); <<<<<< The code gets >> to this statement >>> and index is returned as "0" and I don't see anyway to break out of >>> this looop after. >>> if( searching ) >>> { >>> report("@"); >>> usleep(1000); >>> } >>> } >>> >> >> Hi Pawan >> >> I am reading with interest :) >> >> So it sounds like this is a thread safe problem. >> >> The thing I don't understand here is open and close are synchronized >> in RXTXPort.java. I thought that would prevent any thread problems >> with the linked list. Looking closer, the linked list is actually >> populated in eventLoop/MonitorThread which is not synchronized. >> >> So you may be able to synchronize on an object in RXTXPort.java. A >> seperate native call would probably be required for the initalization >> to prevent a deadlock. >> >> A solution might involve making finalize_event_info_struct() and >> initialise_event_info_struct() [uk spelling?] thread safe with glib. >> >> > http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. >> html#id2786034 >> >> glib also has more robust linked lists which could be used. Thats the > >> indirectly the problem found in termios.c for windows. The >> disadvantage is we would require linking to glib which is another step > >> for systems that don't come with it. The advantage would be reduced >> code size we have to maintain. We could borrow bits of glib as the >> licenses are the same. >> >> Another solution might be to just use pthread_mutex_lock and unlock. >> >> http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html >> >> I don't think that would work on windows though. It would require >> linking cygwin.dll which would not work with nonGPL projects in >> practice. >> >> -- >> Trent Jarvi >> tjarvi >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pascal at quies.net Fri Jul 7 08:45:59 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Fri, 7 Jul 2006 16:45:59 +0200 Subject: [Rxtx] Java installer Message-ID: <200607071645.59765.pascal@quies.net> Hello everybody, We need a *simple* installer for the RXTX extension. I'm working on a pure Java installer right now. Let's get this thing working over the weekend. The license of choise is the modified BSD license. My plan is to make a JAR with: * the RXTX binaries * a simple API to detect any installed version * a simple Swing installer * a executeable detector: java -jar communicationapi.jar detect javax.comm * a executable installer: java -jar communicationapi.jar install gnu.io * Java 1.2 compatible Comments? _The Java API_: class CommunicationAPI { CommunicationAPI() CommunicationAPI(String path) boolean available() boolean supportsRS232() boolean supportsRS485() boolean supportsI2C() boolean supportsIEEE1280() static void main(String[] args) static boolean installRXTX(boolean headless) } Comments? To get this working we need binaries. Who is having what? The package from the official site has the following: * Linux: i686, x86_64, ia64 * Solaris: sparc32, sparc64 * Windows: i386 Now that's a start. I had to modify the code (what a mess!) to get it working on OpenBSD but I don't have the time to get it working for every platform. Any help here? From j.a.horsmeier at wanadoo.nl Fri Jul 7 09:11:24 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Fri, 7 Jul 2006 17:11:24 +0200 Subject: [Rxtx] Java installer In-Reply-To: <200607071645.59765.pascal@quies.net> Message-ID: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> > Pascal S. de Kloe wrote: > We need a *simple* installer for the RXTX extension. > I'm working on a pure Java installer right now. Let's get > this thing working > over the weekend. The license of choise is the modified BSD license. > > My plan is to make a JAR with: > * the RXTX binaries > * a simple API to detect any installed version > * a simple Swing installer > * a executeable detector: java -jar communicationapi.jar > detect javax.comm > * a executable installer: java -jar communicationapi.jar > install gnu.io > * Java 1.2 compatible > > Comments? Have a look at IzPack: http://www.izforge.com/izpack/ I use it all the time to install rxtx as part of our application. kind regards, Jos From brian at mbari.org Fri Jul 7 10:01:27 2006 From: brian at mbari.org (Brian Schlining) Date: Fri, 7 Jul 2006 09:01:27 -0700 Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: <44AC7902.8070407@adventnet.com> References: <44AC7902.8070407@adventnet.com> Message-ID: On Jul 5, 2006, at 7:44 PM, zhanglong wrote: > Dear sir, > > When I use rxrx2.1-7-bin-r2?I can write data into serialport,But can > not read data from serialport on windowsXP. > I can not write and read data from serialport on Redhat Linux9.0. > I can get serialport list on my machine.And no error with open > serialport. > > I can get and read data from serialport on windowsXP with SUN's > javacomm20-win32.zip. > > How can I read data on windows and write,read data on Linux with rxtx? On windows, if all else fails you may need to use this flow control: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_IN); Also, for some command/response applications that I've tried with RXTX, I find that if I write to the serialport and then immediately try to read from it I get byte arrays filled with zeros, no matter what I set the recieveTimeout to (this has occurred on both Mac OS X and Windows). The workaround that I found was to very briefly put the I/O thread to sleep, like so: // DO set up and get I/O streams //in = serialPort.getInputStream(); //out = serialPort.getOutputStream(); out.write(someByteArray); try { Thread.sleep(10); catch (InterruptedException e) { // handle exception } in.read(anotherByteArray); Note: I've never had to put the thread to sleep using Java comm, only with RXTX. Anyone know why this might be? Cheers B Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060707/f0799573/attachment-0358.html From pascal at quies.net Fri Jul 7 16:55:03 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 00:55:03 +0200 Subject: [Rxtx] Java installer In-Reply-To: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> Message-ID: <200607080055.04501.pascal@quies.net> Op vrijdag 7 juli 2006 17:11, schreef Jos A. Horsmeier: > > Pascal S. de Kloe wrote: > > > > We need a *simple* installer for the RXTX extension. > > I'm working on a pure Java installer right now. Let's get > > this thing working > > over the weekend. The license of choise is the modified BSD license. > > > > My plan is to make a JAR with: > > * the RXTX binaries > > * a simple API to detect any installed version > > * a simple Swing installer > > * a executeable detector: java -jar communicationapi.jar > > detect javax.comm > > * a executable installer: java -jar communicationapi.jar > > install gnu.io > > * Java 1.2 compatible > > > > Comments? > > Have a look at IzPack: http://www.izforge.com/izpack/ > I use it all the time to install rxtx as part of our application. Hello Jos, Thanks for the idea. Could you publish the IzPack configuration and the binaries? That would be very helpful since the current installation procedure is somewhat "unprofessional". ;) IzPack is great but this API is a little more than that. It allows java applications who require the extension to detect available versions and install RXTX on the fly if needed. Is Izpack: * able to install binaries for the right platform (os + hardware architecture)? * Java 1.2 compatible * able to run from the command line? I need as many pre-compiled binaries as possible. Could you help me with that? The detection system already works. Thanks again, Pascal PS Is the gnu.io namespace still necessary? I couldn't find the problem. From naranjo.manuel at gmail.com Fri Jul 7 17:04:31 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 07 Jul 2006 20:04:31 -0300 Subject: [Rxtx] Java installer In-Reply-To: <200607080055.04501.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: <44AEE87F.60202@gmail.com> Pascal: I will be a little short with my answer but very informative :) > Could you publish the IzPack configuration and the binaries? That would be > very helpful since the current installation procedure is > somewhat "unprofessional". ;) > > IzPack is great but this API is a little more than that. It allows java > applications who require the extension to detect available versions and > install RXTX on the fly if needed. > > Is Izpack: > * able to install binaries for the right platform (os + hardware > architecture)? Yes. > * Java 1.2 compatible Yes of course > * able to run from the command line? Yes, and can run from command line detecting which is the underlaying os. I have attached an old version of one of my installer, I can't find the last one, but it is like this one. In this you will see how to detect the OS and architecture and install binaries for that plataform. Regards, Manuel -------------- next part -------------- A non-text attachment was scrubbed... Name: installer.xml Type: text/xml Size: 4683 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060707/fbc3be3c/installer-0358.xml From pascal at quies.net Fri Jul 7 18:35:29 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 02:35:29 +0200 Subject: [Rxtx] Java installer In-Reply-To: <44AEE87F.60202@gmail.com> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <44AEE87F.60202@gmail.com> Message-ID: <200607080235.29486.pascal@quies.net> Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: > > Is Izpack: > > * able to install binaries for the right platform (os + hardware > > architecture)? > > Yes. > > > * Java 1.2 compatible > > Yes of course > > > * able to run from the command line? > > Yes, and can run from command line detecting which is the underlaying os. > I have attached an old version of one of my installer, I can't find the > last one, but it is like this one. In this you will see how to detect > the OS and architecture and install binaries for that plataform. > Regards, > Manuel You are right. IzPack looks like the right tool for this job. As far as I can see there is no commandline support but I'll get over it. ;) I'll link my detection system to the IzPack installation procedure and publish the results. From tjarvi at qbang.org Fri Jul 7 19:00:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 7 Jul 2006 19:00:56 -0600 (MDT) Subject: [Rxtx] Controlling Individual Signals DTR and RTS In-Reply-To: References: Message-ID: On Thu, 6 Jul 2006, Trent Jarvi wrote: > On Thu, 29 Jun 2006, Chris Pine wrote: > >> Dear Moussa Ba, >> I hope I am not being too forward, but we are having the exact same >> issue with needing to control DTR from RXTX in Linux. Did you ever have any >> luck figuring it out? >> >> Thank you very much for your time, >> > > Hi Chris > > Are you using an unusual serial port? It could be that the port does not > support DTR/RTS. Especially if its an inexpensive USB->Serial dongle. > > I'll double check Linux tomorrow but I'm fairly sure it works. I have > verified windows after a questions like yours. Some multiport cards and > usb dongles do not support everything. > I double checked that DTR and RTS are working. The system was a 64 bit opteron with an inexexpensive dual port serial card. Suse 9.3 rxtx 2.1-7 (final). I just used the demo SerialBlackBox that used to come with commapi modified to use rxtx 2.1. The serial card was a NetMos PCI NM9835CV with a 16C550 high speed UART dual port. These are not expensive cards. Everything worked fine. I could see the voltage flipping back and forth on the scope for both DTR(pin 4) and CTS(pin 7). You are not the first to report problems. But everytime I try to reproduce the problem, it appears to work. I suspect it is either hardware or kernel driver related and not specific to RXTX. Note that playing with RTS and DTR with hardware flow control enabled does not make sense as those pins are used for the flow control. I've not looked at many USB serial dongles but I have noticed that some are not as good as others. I think one lacked DTR/CTS support. Another one appeared to be fully functional. The one I noticed no issues with was the Hawking Tech HUC232S on windows. I did not test it on Mac OS X or Linux. The same variability can be observed with multiport serial cards. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jul 7 19:15:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 7 Jul 2006 19:15:06 -0600 (MDT) Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: References: <44AC7902.8070407@adventnet.com> Message-ID: On Fri, 7 Jul 2006, Brian Schlining wrote: > Also, for some command/response applications that I've tried with RXTX, I > find that if I write to the serialport and then immediately try to read from > it I get byte arrays filled with zeros, no matter what I set the > recieveTimeout to (this has occurred on both Mac OS X and Windows). The > workaround that I found was to very briefly put the I/O thread to sleep, like > so: > > // DO set up and get I/O streams > //in = serialPort.getInputStream(); > //out = serialPort.getOutputStream(); > > out.write(someByteArray); > try { > Thread.sleep(10); > catch (InterruptedException e) { > // handle exception > } > in.read(anotherByteArray); > > Note: I've never had to put the thread to sleep using Java comm, only with > RXTX. Anyone know why this might be? Hi Brian Interesting. Is this something that can be reproduced with a loopback connection or something commonly available? I was unaware of this behavior. Is it restricted to something that quickly opens, writes, reads and closes the port by chance? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jul 7 19:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 7 Jul 2006 19:39:37 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607080055.04501.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > Is the gnu.io namespace still necessary? I couldn't find the problem. Hi Pascal CommAPI is a little different in that it was grandfathered into the javax namespace with its own license at the time. It is my understanding that if CommAPI went through the JSR process, anyone would _clearly_ be able to implement a javax.comm package and RXTX would then be one of the first to do so. I believe Doug has expressed some interest in RXTX trying to work with the JSR process. Besides the license questions, there is the fact that RXTX has extensions to CommAPI which could cause confusion in the namespace. Not being a lawyer and *really* not liking to talk to lawyers in my free time, it is better to be safe than sorry. The lawyers tend to come in wolf packs when they do come. There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay there as long as we are just geeks trying to figure out if a license does or does not allow us to implement in the javax.comm namespace. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Sat Jul 8 05:30:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 13:30:24 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: <200607081330.24381.pascal@quies.net> Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > > Is the gnu.io namespace still necessary? I couldn't find the problem. > > Hi Pascal > > CommAPI is a little different in that it was grandfathered into the javax > namespace with its own license at the time. > > It is my understanding that if CommAPI went through the JSR process, > anyone would _clearly_ be able to implement a javax.comm package and RXTX > would then be one of the first to do so. I believe Doug has expressed > some interest in RXTX trying to work with the JSR process. > > Besides the license questions, there is the fact that RXTX has extensions > to CommAPI which could cause confusion in the namespace. Not being a > lawyer and *really* not liking to talk to lawyers in my free time, it is > better to be safe than sorry. The lawyers tend to come in wolf packs > when they do come. > > There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay > there as long as we are just geeks trying to figure out if a license does > or does not allow us to implement in the javax.comm namespace. Nicely said. :) The whole point of namespaces is to create a universal registry of, in this case, classes. This gnu.io namespace is very inconvenient. We feel the same way about lawyers. However I'd like to go into the details of the license (see attachment) if you don't mind? The first license does not apply since RXTX does not use the software. The second one at point 3 specifies our options. > 3. You may not modify the Java Platform Interface ("JPI", identified as > classes contained within the "java" package or any subpackages of the > "java" package), by creating additional classes within the JPI or otherwise > causing the addition to or modification of the classes in the JPI. RXTX is a extension. > In the event that you create an additional class and associated API(s) > which (i) extends the functionality of the Java platform, and (ii) is > exposed to third party software developers for the purpose of developing > additional software which invokes such additional API, you must promptly > publish broadly an accurate specification for such API for free use by all > developers. That's the way we operate. :) > You may not create, or authorize your licensees to create additional > classes, interfaces, or subpackages that are in any way identified as > "java", "javax", "sun" or similar convention as specified by Sun in any > naming convention designation. They don't want additional components in the Communication API since they don't want a mess in theire namespace. So we *can* use javax.comm for the core: javax.comm.CommDriver javax.comm.CommPort javax.comm.CommPortIdentifier javax.comm.CommPortOwnershipListener javax.comm.NoSuchPortException javax.comm.PortInUseException javax.comm.UnsupportedCommOperationException ...and for the default hardware support: javax.comm.SerialPort javax.comm.SerialPortEvent javax.comm.SerialPortEventListener javax.comm.ParralelPort javax.comm.ParralelPortEvent javax.comm.ParralelPortEventListener ...but RXTX aditional hardware support has to go somewhere else like: org.rxtx.RS485Port org.rxtx.RS485PortEvent org.rxtx.RS485PortEventListener org.rxtx.I2CPort org.rxtx.I2CPortEvent org.rxtx.I2CPortEventListener Right? -------------- next part -------------- Sun Microsystems, Inc. Binary Code License Agreement READ THE TERMS OF THIS AGREEMENT AND ANY PROVIDED SUPPLEMENTAL LICENSE TERMS (COLLECTIVELY "AGREEMENT") CAREFULLY BEFORE OPENING THE SOFTWARE MEDIA PACKAGE. BY OPENING THE SOFTWARE MEDIA PACKAGE, YOU AGREE TO THE TERMS OF THIS AGREEMENT. IF YOU ARE ACCESSING THE SOFTWARE ELECTRONICALLY, INDICATE YOUR ACCEPTANCE OF THESE TERMS BY SELECTING THE "ACCEPT" BUTTON AT THE END OF THIS AGREEMENT. IF YOU DO NOT AGREE TO ALL THESE TERMS, PROMPTLY RETURN THE UNUSED SOFTWARE TO YOUR PLACE OF PURCHASE FOR A REFUND OR, IF THE SOFTWARE IS ACCESSED ELECTRONICALLY, SELECT THE "DECLINE" BUTTON AT THE END OF THIS AGREEMENT. 1. LICENSE TO USE. Sun grants you a non-exclusive and non-transferable license for the internal use only of the accompanying software and documentation and any error corrections provided by Sun (collectively "Software"), by the number of users and the class of computer hardware for which the corresponding fee has been paid. 2. RESTRICTIONS. Software is confidential and copyrighted. Title to Software and all associated intellectual property rights is retained by Sun and/or its licensors. Except as specifically authorized in any Supplemental License Terms, you may not make copies of Software, other than a single copy of Software for archival purposes. Unless enforcement is prohibited by applicable law, you may not modify, decompile, or reverse engineer Software. Licensee acknowledges that Licensed Software is not designed or intended for use in the design, construction, operation or maintenance of any nuclear facility. Sun Microsystems, Inc. disclaims any express or implied warranty of fitness for such uses. No right, title or interest in or to any trademark, service mark, logo or trade name of Sun or its licensors is granted under this Agreement. 3. LIMITED WARRANTY. Sun warrants to you that for a period of ninety (90) days from the date of purchase, as evidenced by a copy of the receipt, the media on which Software is furnished (if any) will be free of defects in materials and workmanship under normal use. Except for the foregoing, Software is provided "AS IS". Your exclusive remedy and Sun's entire liability under this limited warranty will be at Sun's option to replace Software media or refund the fee paid for Software. 4. DISCLAIMER OF WARRANTY. UNLESS SPECIFIED IN THIS AGREEMENT, ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT THESE DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. 5.LIMITATION OF LIABILITY. TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF OR RELATED TO THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. In no event will Sun's liability to you, whether in contract, tort (including negligence), or otherwise, exceed the amount paid by you for Software under this Agreement. The foregoing limitations will apply even if the above stated warranty fails of its essential purpose. 6. TERMINATION. This Agreement is effective until terminated. You may terminate this Agreement at any time by destroying all copies of Software. This Agreement will terminate immediately without notice from Sun if you fail to comply with any provision of this Agreement. Upon Termination, you must destroy all copies of Software. 7. EXPORT REGULATIONS. All Software and technical data delivered under this Agreement are subject to US export control laws and may be subject to export or import regulations in other countries. You agree to comply strictly with all such laws and regulations and acknowledge that you have the responsibility to obtain such licenses to export, re-export, or import as may be required after delivery to you. 8. U.S. GOVERNMENT RESTRICTED RIGHTS. If Software is being acquired by or on behalf of the U.S. Government or by a U.S. Government prime contractor or subcontractor (at any tier), then the Government's rights in Software and accompanying documentation will be only as set forth in this Agreement; this is in accordance with 48 CFR 227.7201 through 227.7202-4 (for Department of Defense (DOD) acquisitions) and with 48 CFR 2.101 and 12.212 (for non-DOD acquisitions). 9. GOVERNING LAW. Any action related to this Agreement will be governed by California law and controlling U.S. federal law. No choice of law rules of any jurisdiction will apply. 10, SEVERABILITY. If any provision of this Agreement is held to be unenforceable, this Agreement will remain in effect with the provision omitted, unless omission would frustrate the intent of the parties, in which case this Agreement will immediately terminate. 11. INTEGRATION This Agreement is the entire agreement between you and Sun relating to its subject matter. It supersedes all prior or contemporaneous oral or written communications, proposals, representations and warranties and prevails over any conflicting or additional terms of any quote, order, acknowledgment, or other communication between the parties relating to its subject matter during the term of this Agreement. No modification of this Agreement will be binding, unless in writing and signed by an authorized representative of each party. JAVA OPTIONAL PACKAGE JAVAX.COMM 3.0 SUPPLEMENTAL LICENSE TERMS These supplemental license terms ("Supplemental Terms") add to or modify the terms of the Binary Code License Agreement (collectively, the "Agreement"). Capitalized terms not defined in these Supplemental Terms shall have the same meanings ascribed to them in the Agreement. These Supplemental Terms shall supersede any inconsistent or conflicting terms in the Agreement, or in any license contained within the Software. 1. Software Internal Use and Development License Grant. Subject to the terms and conditions of this Agreement, including, but not limited to Section 3 (Java(TM) Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce internally and use internally the binary form of the Software, complete and unmodified, for the sole purpose of designing, developing and testing your Java applets and applications ("Programs"). 2. License to Distribute Software. In addition to the license granted in Section 1 (Software Internal Use and Development License Grant) of these Supplemental Terms, subject to the terms and conditions of this Agreement, including but not limited to, Section 3 (Java Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce and distribute the Software in binary code form only, provided that you (i) distribute the Software complete and unmodified and only bundled as part of your Programs, (ii) do not distribute additional software intended to replace any component(s) of the Software, (iii) do not remove or alter any proprietary legends or notices contained in the Software, (iv) only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (v) agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software. 3. Java Technology Restrictions. You may not modify the Java Platform Interface ("JPI", identified as classes contained within the "java" package or any subpackages of the "java" package), by creating additional classes within the JPI or otherwise causing the addition to or modification of the classes in the JPI. In the event that you create an additional class and associated API(s) which (i) extends the functionality of the Java platform, and (ii) is exposed to third party software developers for the purpose of developing additional software which invokes such additional API, you must promptly publish broadly an accurate specification for such API for free use by all developers. You may not create, or authorize your licensees to create additional classes, interfaces, or subpackages that are in any way identified as "java", "javax", "sun" or similar convention as specified by Sun in any naming convention designation. 4. Trademarks and Logos. You acknowledge and agree as between you and Sun that Sun owns the SUN, SOLARIS, JAVA, JINI, FORTE, and iPLANET trademarks and all SUN, SOLARIS, JAVA, JINI, FORTE, and iPLANET-related trademarks, service marks, logos and other brand designations ("Sun Marks"), and you agree to comply with the Sun Trademark and Logo Usage Requirements currently located at http://www.sun.com/policies/trademarks. Any use you make of the Sun Marks inures to Sun's benefit. 5. Source Code. Software may contain source code that is provided solely for reference purposes pursuant to the terms of this Agreement. Source code may not be redistributed unless expressly provided for in this Agreement. 6. Termination for Infringement. Either party may terminate this Agreement immediately should any Software become, or in either party's opinion be likely to become, the subject of a claim of infringement of any intellectual property right. For inquiries please contact: Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, California 95054. (LFI#143217/Form ID#011801) From tjarvi at qbang.org Sat Jul 8 10:12:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 10:12:55 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607081330.24381.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <200607081330.24381.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> Is the gnu.io namespace still necessary? I couldn't find the problem. >> >> Hi Pascal >> >> CommAPI is a little different in that it was grandfathered into the javax >> namespace with its own license at the time. >> >> It is my understanding that if CommAPI went through the JSR process, >> anyone would _clearly_ be able to implement a javax.comm package and RXTX >> would then be one of the first to do so. I believe Doug has expressed >> some interest in RXTX trying to work with the JSR process. >> >> Besides the license questions, there is the fact that RXTX has extensions >> to CommAPI which could cause confusion in the namespace. Not being a >> lawyer and *really* not liking to talk to lawyers in my free time, it is >> better to be safe than sorry. The lawyers tend to come in wolf packs >> when they do come. >> >> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay >> there as long as we are just geeks trying to figure out if a license does >> or does not allow us to implement in the javax.comm namespace. > > Nicely said. :) > > The whole point of namespaces is to create a universal registry of, in this > case, classes. This gnu.io namespace is very inconvenient. > > We feel the same way about lawyers. However I'd like to go into the details of > the license (see attachment) if you don't mind? > > The first license does not apply since RXTX does not use the software. The > second one at point 3 specifies our options. > >> 3. You may not modify the Java Platform Interface ("JPI", identified as >> classes contained within the "java" package or any subpackages of the >> "java" package), by creating additional classes within the JPI or otherwise >> causing the addition to or modification of the classes in the JPI. > > RXTX is a extension. > >> In the event that you create an additional class and associated API(s) >> which (i) extends the functionality of the Java platform, and (ii) is >> exposed to third party software developers for the purpose of developing >> additional software which invokes such additional API, you must promptly >> publish broadly an accurate specification for such API for free use by all >> developers. > > That's the way we operate. :) > >> You may not create, or authorize your licensees to create additional >> classes, interfaces, or subpackages that are in any way identified as >> "java", "javax", "sun" or similar convention as specified by Sun in any >> naming convention designation. > > They don't want additional components in the Communication API since they > don't want a mess in theire namespace. > > So we *can* use javax.comm for the core: > javax.comm.CommDriver > javax.comm.CommPort > javax.comm.CommPortIdentifier > javax.comm.CommPortOwnershipListener > javax.comm.NoSuchPortException > javax.comm.PortInUseException > javax.comm.UnsupportedCommOperationException > > ...and for the default hardware support: > javax.comm.SerialPort > javax.comm.SerialPortEvent > javax.comm.SerialPortEventListener > javax.comm.ParralelPort > javax.comm.ParralelPortEvent > javax.comm.ParralelPortEventListener > > ...but RXTX aditional hardware support has to go somewhere else like: > org.rxtx.RS485Port > org.rxtx.RS485PortEvent > org.rxtx.RS485PortEventListener > org.rxtx.I2CPort > org.rxtx.I2CPortEvent > org.rxtx.I2CPortEventListener > > Right? > I do not disagree with anything you said :) RXTX and Sun agree with each other almost completely but not exactly. I think there are three uses of CommAPI and Sun is mainly interested in one. 1) Point of sale. This is the direction Sun is going with limited resources thats causing some problems. They would obviously cause fewer problems with more resources just like rxtx would work with them better with more resources. I'm sure if you talk to people in this area they are very optimitsic about what CommAPI could be. 2) Instrument Control. This is my area of interest as its my job too. I'm still formulating opinions here and it is far to early to say much but I'm very optimistic about what CommAPI could be. 3) Hobby and other hardware control. Circuts, road signs, rxtx in cell phones controlling TVs, you name it. People asking about palm, wince, embeded hardware. This is why I thought it was important to open source rxtx in the beginning and still find it my primary motive to read rxtx email every morning and evening. The optimism here is abundant and self explained. Nothing would make me happier than having someone get a working demo of controlling LEDs with parallel ports that could be used by people learning. So everyone agrees with almost everything. Nobody is looking for conflicts. But these various interests have not been _clearly_ formalized. Licenses are tools for manipulating behavior. Until the above is clearly in line with each other, the license will be a tool for lawyers to cause problems for people working for free. This is why I support a move to go through the JSR process and formalize the relationship. My concern is not really Sun comming after RXTX with Lawyers. I have a great deal of respect for Sun going back to their sunsite project. My concern is how lawyers think. They look at the intent which is not all in line. Then I get what feels like insane conference calls that cost companies over $2000 an hour which pisses me off to no end. Companies paying lawyers to take time from developers for free. This really does happen when a fortune 50 company developer asks their legal department if they can use rxtx. I don't have enough bullets for that. The way you avoid this is formalize everones intent so lawyers don't make conference call meetings in outlook. I want to put those lawyers out of work and if it takes a little discomfort, thats perfectly fine. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Sat Jul 8 11:44:40 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 19:44:40 +0200 Subject: [Rxtx] Fwd: Re: Java installer Message-ID: <200607081944.41123.pascal@quies.net> For some reason the first mail failed... ---------- Doorgestuurd bericht ---------- Subject: Re: [Rxtx] Java installer Date: zaterdag 8 juli 2006 17:18 From: "Pascal S. de Kloe" To: RXTX Developers and Users Hello Manuel, In case of a JDK the installation goes into the "jre" directory. I can't find a simple way to get this information into a variable of IzPack. (see attachment) Do you have a idea? Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: > Pascal: > I will be a little short with my answer but very informative :) > > > Could you publish the IzPack configuration and the binaries? That would > > be very helpful since the current installation procedure is > > somewhat "unprofessional". ;) > > > > IzPack is great but this API is a little more than that. It allows java > > applications who require the extension to detect available versions and > > install RXTX on the fly if needed. > > > > Is Izpack: > > * able to install binaries for the right platform (os + hardware > > architecture)? > > Yes. > > > * Java 1.2 compatible > > Yes of course > > > * able to run from the command line? > > Yes, and can run from command line detecting which is the underlaying os. > I have attached an old version of one of my installer, I can't find the > last one, but it is like this one. In this you will see how to detect > the OS and architecture and install binaries for that plataform. > Regards, > Manuel ------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: izpack.xml Type: text/xml Size: 1401 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060708/413315d2/izpack-0357.xml From joachim at buechse.de Sat Jul 8 10:02:18 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 8 Jul 2006 18:02:18 +0200 Subject: [Rxtx] Java installer In-Reply-To: <200607080055.04501.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: <7D4FA261-44FA-4A6E-8EB9-7A7B0116BB2C@buechse.de> Hello Pascal, as soon as the 2.1.8 version is "released" I'll happily provide you with a precompiled library for Mac OSX. The currently tagged version is 2.17 which has a non standard implementation for OSX. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 08.07.2006, at 00:55, Pascal S. de Kloe wrote: > > I need as many pre-compiled binaries as possible. > Could you help me with that? > > The detection system already works. > > Thanks again, > > Pascal > > > PS > Is the gnu.io namespace still necessary? I couldn't find the problem. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 8 09:18:09 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 17:18:09 +0200 Subject: [Rxtx] Java installer In-Reply-To: <44AEE87F.60202@gmail.com> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <44AEE87F.60202@gmail.com> Message-ID: <200607081718.09605.pascal@quies.net> Hello Manuel, In case of a JDK the installation goes into the "jre" directory. I can't find a simple way to get this information into a variable of IzPack. (see attachment) Do you have a idea? Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: > Pascal: > I will be a little short with my answer but very informative :) > > > Could you publish the IzPack configuration and the binaries? That would > > be very helpful since the current installation procedure is > > somewhat "unprofessional". ;) > > > > IzPack is great but this API is a little more than that. It allows java > > applications who require the extension to detect available versions and > > install RXTX on the fly if needed. > > > > Is Izpack: > > * able to install binaries for the right platform (os + hardware > > architecture)? > > Yes. > > > * Java 1.2 compatible > > Yes of course > > > * able to run from the command line? > > Yes, and can run from command line detecting which is the underlaying os. > I have attached an old version of one of my installer, I can't find the > last one, but it is like this one. In this you will see how to detect > the OS and architecture and install binaries for that plataform. > Regards, > Manuel -------------- next part -------------- A non-text attachment was scrubbed... Name: izpack.xml Type: text/xml Size: 1401 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060708/fa6f5a81/izpack-0357.xml From naranjo.manuel at gmail.com Sat Jul 8 12:52:23 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 15:52:23 -0300 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607081944.41123.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> Message-ID: <44AFFEE7.3090306@gmail.com> Pascal: I can't get exactly your point, but my installer was to avoid modifying the users JDK or JRE. Download this app made by me, and you will get my point: http://www.aircable.net/downloads/AIRcable_Configuration_Utility_v0.2_ALPHA_1.zip, this app bundles RXTX library inside the zip file, and does not need RXTX installed on the Users system. Manuel > For some reason the first mail failed... > > > ---------- Doorgestuurd bericht ---------- > > Subject: Re: [Rxtx] Java installer > Date: zaterdag 8 juli 2006 17:18 > From: "Pascal S. de Kloe" > To: RXTX Developers and Users > > Hello Manuel, > > In case of a JDK the installation goes into the "jre" directory. > I can't find a simple way to get this information into a variable of IzPack. > (see attachment) > > Do you have a idea? > > Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: >> Pascal: >> I will be a little short with my answer but very informative :) >> >>> Could you publish the IzPack configuration and the binaries? That would >>> be very helpful since the current installation procedure is >>> somewhat "unprofessional". ;) >>> >>> IzPack is great but this API is a little more than that. It allows java >>> applications who require the extension to detect available versions and >>> install RXTX on the fly if needed. >>> >>> Is Izpack: >>> * able to install binaries for the right platform (os + hardware >>> architecture)? >> Yes. >> >>> * Java 1.2 compatible >> Yes of course >> >>> * able to run from the command line? >> Yes, and can run from command line detecting which is the underlaying os. >> I have attached an old version of one of my installer, I can't find the >> last one, but it is like this one. In this you will see how to detect >> the OS and architecture and install binaries for that plataform. >> Regards, >> Manuel > > ------------------------------------------------------- > > > ------------------------------------------------------------------------ > > > > > RXTX > 2... > http://www.rxtx.org/ > 1.2 > uninstallRXTX > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Jul 8 12:53:32 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 15:53:32 -0300 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607081944.41123.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> Message-ID: <44AFFF2C.8090005@gmail.com> Even more, the variable ${CURRENT_JRE} referees to the actuall JVM as far as I know, so you will have no difference in installing towards a JDK. > For some reason the first mail failed... > > > ---------- Doorgestuurd bericht ---------- > > Subject: Re: [Rxtx] Java installer > Date: zaterdag 8 juli 2006 17:18 > From: "Pascal S. de Kloe" > To: RXTX Developers and Users > > Hello Manuel, > > In case of a JDK the installation goes into the "jre" directory. > I can't find a simple way to get this information into a variable of IzPack. > (see attachment) > > Do you have a idea? > > Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: >> Pascal: >> I will be a little short with my answer but very informative :) >> >>> Could you publish the IzPack configuration and the binaries? That would >>> be very helpful since the current installation procedure is >>> somewhat "unprofessional". ;) >>> >>> IzPack is great but this API is a little more than that. It allows java >>> applications who require the extension to detect available versions and >>> install RXTX on the fly if needed. >>> >>> Is Izpack: >>> * able to install binaries for the right platform (os + hardware >>> architecture)? >> Yes. >> >>> * Java 1.2 compatible >> Yes of course >> >>> * able to run from the command line? >> Yes, and can run from command line detecting which is the underlaying os. >> I have attached an old version of one of my installer, I can't find the >> last one, but it is like this one. In this you will see how to detect >> the OS and architecture and install binaries for that plataform. >> Regards, >> Manuel > > ------------------------------------------------------- > > > ------------------------------------------------------------------------ > > > > > RXTX > 2... > http://www.rxtx.org/ > 1.2 > uninstallRXTX > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Jul 8 12:54:22 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 15:54:22 -0300 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <200607081330.24381.pascal@quies.net> Message-ID: <44AFFF5E.50603@gmail.com> > > I do not disagree with anything you said :) > > RXTX and Sun agree with each other almost completely but not exactly. I > think there are three uses of CommAPI and Sun is mainly interested in one. > > 1) Point of sale. This is the direction Sun is going with limited > resources thats causing some problems. They would obviously cause fewer > problems with more resources just like rxtx would work with them better > with more resources. I'm sure if you talk to people in this area they are > very optimitsic about what CommAPI could be. > > 2) Instrument Control. This is my area of interest as its my job too. I'm > still formulating opinions here and it is far to early to say much but I'm > very optimistic about what CommAPI could be. > > 3) Hobby and other hardware control. Circuts, road signs, rxtx in cell > phones controlling TVs, you name it. People asking about palm, wince, > embeded hardware. This is why I thought it was important to open source > rxtx in the beginning and still find it my primary motive to read rxtx > email every morning and evening. The optimism here is abundant and self > explained. Nothing would make me happier than having someone get a > working demo of controlling LEDs with parallel ports that could be used by > people learning. > > So everyone agrees with almost everything. Nobody is looking for > conflicts. But these various interests have not been _clearly_ > formalized. Licenses are tools for manipulating behavior. Until the > above is clearly in line with each other, the license will be a tool for > lawyers to cause problems for people working for free. This is why I > support a move to go through the JSR process and formalize the > relationship. > > My concern is not really Sun comming after RXTX with Lawyers. I have a > great deal of respect for Sun going back to their sunsite project. My > concern is how lawyers think. They look at the intent which is not all in > line. Then I get what feels like insane conference calls that cost > companies over $2000 an hour which pisses me off to no end. Companies > paying lawyers to take time from developers for free. This really does > happen when a fortune 50 company developer asks their legal department if > they can use rxtx. I don't have enough bullets for that. > > The way you avoid this is formalize everones intent so lawyers don't > make conference call meetings in outlook. I want to put those lawyers out > of work and if it takes a little discomfort, thats perfectly fine. > > -- > Trent Jarvi > tjarvi at qbang.org > > Trent: GREAT MAIL, I hate lawyers too. From naranjo.manuel at gmail.com Sat Jul 8 07:52:47 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 10:52:47 -0300 Subject: [Rxtx] Java installer In-Reply-To: <200607080235.29486.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <44AEE87F.60202@gmail.com> <200607080235.29486.pascal@quies.net> Message-ID: <44AFB8AF.50403@gmail.com> > > You are right. IzPack looks like the right tool for this job. > > As far as I can see there is no commandline support but I'll get over it. ;) Actually there is a way to execute native app in the Underlaying OS. Check out the JavaDOC and all the documentation given by them. If you need to also generate warper around the jar files, check this projects out: http://launch4j.sourceforge.net and http://jsmooth.sourceforge.net/ I have been able to make and exe with jsmooth that does not need to have RXTX installed if you want I can send the source of it. But it is simple. Do not put the jar inside the exe file, and add to the classpath relative paths to rxtx jar and then your jar file, and then add to the JVM command line (I can't remeber the actual name of it :P) -Djava.library.path=bin\ (Or were ever you installed the binary package). I have tryied doing the same with Java Comm from Sun but it actually is imposible, the main difference to me that make me move to RXTX, was that there is no need to have the javax.comm.properties file, which gave me lot of headaches. Regards, Manuel. From naranjo.manuel at gmail.com Sat Jul 8 08:03:58 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 11:03:58 -0300 Subject: [Rxtx] License question. Message-ID: <44AFBB4E.70808@gmail.com> Hi: I have a question, haven't you ever thought about changing RXTX license from GNU/GPL to a more open license like Apache v2 or BSD like?. As far as I understand if I make an application that uses RXTX libraries, I must release my app under the GNU/GPL. I have no problem with that in fact I'm an Open Source user and defender. The fact is that in same cases the applications made by one, could get into hands of a company that needs to release a Closed Source app. I understand that using GNU/GPL do not give you the power to do this, but a more "open" license like Apache does. By "open" I mean that the license respects the Open Source license, but also lives the user the opportunity to use the library in closed source programs. I have seen that there is an exception to the license that applies to RXTX v2.0-5 and above, the only problem with it is that Java Comm Api (the jar file) needs the file javax.comm.properties installed correctly, which in lot of cases is a headache. RXTX jar does not need this, actually I think that RXTX is more user friendly than Java Comm. Maybe there has been a discussion like this before, but I just wanted to ask, and to get an answer that is adequate to our time. Regards, Manuel From pascal at quies.net Sat Jul 8 14:03:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:03:13 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <44AFFF2C.8090005@gmail.com> References: <200607081944.41123.pascal@quies.net> <44AFFF2C.8090005@gmail.com> Message-ID: <200607082203.13696.pascal@quies.net> Op zaterdag 8 juli 2006 20:53, schreef Manuel Naranjo: > Even more, the variable ${CURRENT_JRE} referees to the actuall JVM as > far as I know, so you will have no difference in installing towards a JDK. As far as the installation instructions go the location of the libraries is the following. Windows * JRE: $JAVA_HOME/bin/ * JDK: $JAVA_HOME/jre/bin/ UNIX * JRE: $JAVA_HOME/lib/ * JRE: $JAVA_HOME/jre/lib/ From pascal at quies.net Sat Jul 8 14:04:50 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:04:50 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <44AFFEE7.3090306@gmail.com> References: <200607081944.41123.pascal@quies.net> <44AFFEE7.3090306@gmail.com> Message-ID: <200607082204.50712.pascal@quies.net> Op zaterdag 8 juli 2006 20:52, schreef Manuel Naranjo: > Pascal: > I can't get exactly your point, but my installer was to avoid modifying > the users JDK or JRE. Download this app made by me, and you will get my > point: > http://www.aircable.net/downloads/AIRcable_Configuration_Utility_v0.2_ALPHA >_1.zip, this app bundles RXTX library inside the zip file, and does not need > RXTX installed on the Users system. > Manuel I didn't get the point indeed and I still don't get it. :$ The installation instructions state that RXTX.jar must be in the classpath and the libraries should go as my previous mail stated. Do you have another way? I don't have Windows so i can't run that EXE. From pascal at quies.net Sat Jul 8 14:05:40 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:05:40 +0200 Subject: [Rxtx] Java installer In-Reply-To: <7D4FA261-44FA-4A6E-8EB9-7A7B0116BB2C@buechse.de> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <7D4FA261-44FA-4A6E-8EB9-7A7B0116BB2C@buechse.de> Message-ID: <200607082205.40527.pascal@quies.net> Op zaterdag 8 juli 2006 18:02, schreef Joachim Buechse: > as soon as the 2.1.8 version is "released" I'll happily provide you ? > with a precompiled library for Mac OSX. The currently tagged version ? > is 2.17 which has a non standard implementation for OSX. Perfect! :) Do you have a idea when that will be? Like this month? From pascal at quies.net Sat Jul 8 14:14:44 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:14:44 +0200 Subject: [Rxtx] Java installer In-Reply-To: <44AFB8AF.50403@gmail.com> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080235.29486.pascal@quies.net> <44AFB8AF.50403@gmail.com> Message-ID: <200607082214.45115.pascal@quies.net> Op zaterdag 8 juli 2006 15:52, schreef Manuel Naranjo: > > You are right. IzPack looks like the right tool for this job. > > > > As far as I can see there is no commandline support but I'll get over it. > > ;) > > Actually there is a way to execute native app in the Underlaying OS. > Check out the JavaDOC and all the documentation given by them. > If you need to also generate warper around the jar files, check this > projects out: > http://launch4j.sourceforge.net and http://jsmooth.sourceforge.net/ > I have been able to make and exe with jsmooth that does not need to > have RXTX installed if you want I can send the source of it. But it is > simple. > Do not put the jar inside the exe file, and add to the classpath > relative paths to rxtx jar and then your jar file, and then add to the > JVM command line (I can't remeber the actual name of it :P) > -Djava.library.path=bin\ (Or were ever you installed the binary package). > I have tryied doing the same with Java Comm from Sun but it actually is > imposible, the main difference to me that make me move to RXTX, was that > there is no need to have the javax.comm.properties file, which gave me > lot of headaches. > Regards, > Manuel. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Those are verry interresting and impressive tools for Windows. However, I wanted (and still do) a universal installer for all supported platforms as a single JAR. IzPack seemed quite suitable but it is limited and not well written so I'me still searching... Thanks for the help though. :) From pascal at quies.net Sat Jul 8 14:19:59 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:19:59 +0200 Subject: [Rxtx] License question. In-Reply-To: <44AFBB4E.70808@gmail.com> References: <44AFBB4E.70808@gmail.com> Message-ID: <200607082219.59514.pascal@quies.net> I thought of the same thing. The modified BSD license would certainly make it more eazy and acceptable for Sun to include RXTX in theire products. Unfortunately in general people who chose GPL don't like other licenses. ;) Op zaterdag 8 juli 2006 16:03, schreef Manuel Naranjo: > Hi: > I have a question, haven't you ever thought about changing RXTX license > from GNU/GPL to a more open license like Apache v2 or BSD like?. > As far as I understand if I make an application that uses RXTX > libraries, I must release my app under the GNU/GPL. I have no problem > with that in fact I'm an Open Source user and defender. > The fact is that in same cases the applications made by one, could get > into hands of a company that needs to release a Closed Source app. I > understand that using GNU/GPL do not give you the power to do this, but > a more "open" license like Apache does. By "open" I mean that the > license respects the Open Source license, but also lives the user the > opportunity to use the library in closed source programs. > I have seen that there is an exception to the license that applies to > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > (the jar file) needs the file javax.comm.properties installed correctly, > which in lot of cases is a headache. RXTX jar does not need this, > actually I think that RXTX is more user friendly than Java Comm. > Maybe there has been a discussion like this before, but I just wanted to > ask, and to get an answer that is adequate to our time. > Regards, > Manuel > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jul 8 15:30:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 15:30:31 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <44AFBB4E.70808@gmail.com> References: <44AFBB4E.70808@gmail.com> Message-ID: On Sat, 8 Jul 2006, Manuel Naranjo wrote: > Hi: > I have a question, haven't you ever thought about changing RXTX license > from GNU/GPL to a more open license like Apache v2 or BSD like?. > As far as I understand if I make an application that uses RXTX > libraries, I must release my app under the GNU/GPL. I have no problem > with that in fact I'm an Open Source user and defender. > The fact is that in same cases the applications made by one, could get > into hands of a company that needs to release a Closed Source app. I > understand that using GNU/GPL do not give you the power to do this, but > a more "open" license like Apache does. By "open" I mean that the > license respects the Open Source license, but also lives the user the > opportunity to use the library in closed source programs. > I have seen that there is an exception to the license that applies to > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > (the jar file) needs the file javax.comm.properties installed correctly, > which in lot of cases is a headache. RXTX jar does not need this, > actually I think that RXTX is more user friendly than Java Comm. > Maybe there has been a discussion like this before, but I just wanted to > ask, and to get an answer that is adequate to our time. > Regards, > Manuel Hi Manuel As one of the primary copyright 'owners' and a representative of all the people who have worked on RXTX I feel very compelled to comment on this. I often observe this misconception and just ignore it. RXTX is very commercial friendly both in open and closed source. The license is LGPL not GPL. This allows for linking to any application you like without sharing yoru application code. It is not unlike Apache or BSD in that sense. I like the BSD license but not in this case. The difference is you can not keep your changes to rxtx itself if your product is distributed in practice. To me this makes no sense and is a basic flaw in BSD licensing for libraries. I have _no_ intentions of "competing" with various incarnations of RXTX. If you use RXTX in your commercial application, I hope for two things. First I want you to do well for using rxtx even if you somehow compete with me in the commercial world. Second I want to see changes to RXTX come back to RXTX so we all do well for choosing RXTX. This is not possible with the BSD, MIT ... licenses. They result in multiple forks from the code and this is used to disrupt 'standards' by companies you would recognize (I no longer mention any company when saying bad things without fair notice). Your code is your code. Thats how the LGPL works. But don't take RXTX and fork it where I or anyone else that has worked on RXTX can see it. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Sat Jul 8 16:06:17 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 00:06:17 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> Message-ID: <200607090006.18197.pascal@quies.net> Op zaterdag 8 juli 2006 23:30, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Manuel Naranjo wrote: > > Hi: > > I have a question, haven't you ever thought about changing RXTX license > > from GNU/GPL to a more open license like Apache v2 or BSD like?. > > As far as I understand if I make an application that uses RXTX > > libraries, I must release my app under the GNU/GPL. I have no problem > > with that in fact I'm an Open Source user and defender. > > The fact is that in same cases the applications made by one, could get > > into hands of a company that needs to release a Closed Source app. I > > understand that using GNU/GPL do not give you the power to do this, but > > a more "open" license like Apache does. By "open" I mean that the > > license respects the Open Source license, but also lives the user the > > opportunity to use the library in closed source programs. > > I have seen that there is an exception to the license that applies to > > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > > (the jar file) needs the file javax.comm.properties installed correctly, > > which in lot of cases is a headache. RXTX jar does not need this, > > actually I think that RXTX is more user friendly than Java Comm. > > Maybe there has been a discussion like this before, but I just wanted to > > ask, and to get an answer that is adequate to our time. > > Regards, > > Manuel > > Hi Manuel > > As one of the primary copyright 'owners' and a representative of all the > people who have worked on RXTX I feel very compelled to comment on this. > I often observe this misconception and just ignore it. > > RXTX is very commercial friendly both in open and closed source. The > license is LGPL not GPL. This allows for linking to any application you > like without sharing yoru application code. It is not unlike Apache or > BSD in that sense. I like the BSD license but not in this case. > > The difference is you can not keep your changes to rxtx itself if your > product is distributed in practice. To me this makes no sense and is a > basic flaw in BSD licensing for libraries. I have _no_ intentions of > "competing" with various incarnations of RXTX. If you use RXTX in your > commercial application, I hope for two things. First I want you to do > well for using rxtx even if you somehow compete with me in the commercial > world. Second I want to see changes to RXTX come back to RXTX so we all > do well for choosing RXTX. > > This is not possible with the BSD, MIT ... licenses. They result in > multiple forks from the code and this is used to disrupt 'standards' by > companies you would recognize (I no longer mention any company when > saying bad things without fair notice). > > Your code is your code. Thats how the LGPL works. But don't take RXTX > and fork it where I or anyone else that has worked on RXTX can see it. > > -- > Trent Jarvi Hallo Trent, The BSD license wants to give and GPL wants to improve the public available content. What do you prefer? If you build the code to provide everyone a better experience then the BSD license would be suitable since the business acceptance is much higher. If you see this as a crucial component to build a complete free Java infrastructure that has no place for commerce then the GPL would be better In both situations RXTX will be free. I say that the chance a company would not contribute does not outweight the chance that the API is less available to the users. The entire API is a dead end. Mustang has USB support. Please let's make this as good as it gets. From tjarvi at qbang.org Sat Jul 8 16:09:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 16:09:31 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <200607082219.59514.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > I thought of the same thing. The modified BSD license would certainly make it > more eazy and acceptable for Sun to include RXTX in theire products. > > Unfortunately in general people who chose GPL don't like other licenses. ;) > If Sun can not accept the license, thats their problem. I have no problem with Sun distributing RXTX and working with the community. I've even stepped down as then primary and given that power to Doug to facilitate different opinions. For licensing changes, I am the primary copyright owner and have very strong opinions though I have a great deal of respect for everyone that has contributed to RXTX. Sun has their process and we have our process - screwy but a process and real. RXTX is not going to rubber stamp into any company without process that gives major power to the contributors to RXTX. There is a community here and it is not Sun's. (It isn't "gnu" either; the license is closest) This isn't about Trent. He is a wierd guy you should fear. That said, I'm not fundamentally against Sun distributing RXTX and changing package names. What I am fundametally against is multiple RXTXs. There isnt enough space for that game. -- Trent Jarvi tarvi at qbang.org From pascal at quies.net Sat Jul 8 16:25:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 00:25:24 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> Message-ID: <200607090025.24884.pascal@quies.net> Op zondag 9 juli 2006 00:09, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > > I thought of the same thing. The modified BSD license would certainly > > make it more eazy and acceptable for Sun to include RXTX in theire > > products. > > > > Unfortunately in general people who chose GPL don't like other licenses. > > ;) > > If Sun can not accept the license, thats their problem. > > I have no problem with Sun distributing RXTX and working with the > community. I've even stepped down as then primary and given that power to > Doug to facilitate different opinions. For licensing changes, I am the > primary copyright owner and have very strong opinions though I have a > great deal of respect for everyone that has contributed to RXTX. > > Sun has their process and we have our process - screwy but a process and > real. RXTX is not going to rubber stamp into any company without process > that gives major power to the contributors to RXTX. There is a community > here and it is not Sun's. (It isn't "gnu" either; the license is closest) > This isn't about Trent. He is a wierd guy you should fear. Hahaha, I found him very reasonable. The LGPL is not going to prevent forks. Any company which would take the code and keep little improvements to theirselves is stupid since they throw away a great deal of support and they know it. RXTX works. It needs a huge cleanup and more strict platform definitions but that's just a matter of time. What do you have to loose? From tjarvi at qbang.org Sat Jul 8 16:33:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 16:33:32 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <200607090025.24884.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> <200607090025.24884.pascal@quies.net> Message-ID: On Sun, 9 Jul 2006, Pascal S. de Kloe wrote: > Op zondag 9 juli 2006 00:09, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> I thought of the same thing. The modified BSD license would certainly >>> make it more eazy and acceptable for Sun to include RXTX in theire >>> products. >>> >>> Unfortunately in general people who chose GPL don't like other licenses. >>> ;) >> >> If Sun can not accept the license, thats their problem. >> >> I have no problem with Sun distributing RXTX and working with the >> community. I've even stepped down as then primary and given that power to >> Doug to facilitate different opinions. For licensing changes, I am the >> primary copyright owner and have very strong opinions though I have a >> great deal of respect for everyone that has contributed to RXTX. >> >> Sun has their process and we have our process - screwy but a process and >> real. RXTX is not going to rubber stamp into any company without process >> that gives major power to the contributors to RXTX. There is a community >> here and it is not Sun's. (It isn't "gnu" either; the license is closest) >> This isn't about Trent. He is a wierd guy you should fear. > > Hahaha, I found him very reasonable. > > The LGPL is not going to prevent forks. No it will not, but it will allow for you or me to view forks and absorb them. It renders forks of RXTX useless at the price of whatever product is shipped. I would ask that you consider the larger picture here. Termios and DCB are almost dead but almost being used like a VISA interface. Everyone just wants it to work but it does not always. So your proposal is to make mulitiple deal protocols? -- Trent Jarvi tjarvi at qbang.org From naranjo.manuel at gmail.com Sat Jul 8 17:20:44 2006 From: naranjo.manuel at gmail.com (Naranjo Manuel Francisco) Date: Sat, 8 Jul 2006 20:20:44 -0300 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> Message-ID: <360bc8300607081620x4e5d0f23h88fef8d81e6b6a0b@mail.gmail.com> Sorry, my mistake then, I thought the license was GPL not LGPL, I guess I readed some thing badly. I have readed all the emails, and you are right, there is no need for a Fork of RXTX, I think it works right as it is. So I can make my app Apache v2 with out any worry, because RXTX is LGPL :), great then. From tjarvi at qbang.org Sat Jul 8 17:57:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 17:57:05 -0600 (MDT) Subject: [Rxtx] License question ver2. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> <200607090025.24884.pascal@quies.net> Message-ID: Are there any more questions relating to this subject? From tjarvi at qbang.org Sat Jul 8 21:14:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 21:14:09 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <200607090006.18197.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607090006.18197.pascal@quies.net> Message-ID: On Sun, 9 Jul 2006, Pascal S. de Kloe wrote: > Op zaterdag 8 juli 2006 23:30, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Manuel Naranjo wrote: >>> Hi: >>> I have a question, haven't you ever thought about changing RXTX license >>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>> As far as I understand if I make an application that uses RXTX >>> libraries, I must release my app under the GNU/GPL. I have no problem >>> with that in fact I'm an Open Source user and defender. >>> The fact is that in same cases the applications made by one, could get >>> into hands of a company that needs to release a Closed Source app. I >>> understand that using GNU/GPL do not give you the power to do this, but >>> a more "open" license like Apache does. By "open" I mean that the >>> license respects the Open Source license, but also lives the user the >>> opportunity to use the library in closed source programs. >>> I have seen that there is an exception to the license that applies to >>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>> (the jar file) needs the file javax.comm.properties installed correctly, >>> which in lot of cases is a headache. RXTX jar does not need this, >>> actually I think that RXTX is more user friendly than Java Comm. >>> Maybe there has been a discussion like this before, but I just wanted to >>> ask, and to get an answer that is adequate to our time. >>> Regards, >>> Manuel >> >> Hi Manuel >> >> As one of the primary copyright 'owners' and a representative of all the >> people who have worked on RXTX I feel very compelled to comment on this. >> I often observe this misconception and just ignore it. >> >> RXTX is very commercial friendly both in open and closed source. The >> license is LGPL not GPL. This allows for linking to any application you >> like without sharing yoru application code. It is not unlike Apache or >> BSD in that sense. I like the BSD license but not in this case. >> >> The difference is you can not keep your changes to rxtx itself if your >> product is distributed in practice. To me this makes no sense and is a >> basic flaw in BSD licensing for libraries. I have _no_ intentions of >> "competing" with various incarnations of RXTX. If you use RXTX in your >> commercial application, I hope for two things. First I want you to do >> well for using rxtx even if you somehow compete with me in the commercial >> world. Second I want to see changes to RXTX come back to RXTX so we all >> do well for choosing RXTX. >> >> This is not possible with the BSD, MIT ... licenses. They result in >> multiple forks from the code and this is used to disrupt 'standards' by >> companies you would recognize (I no longer mention any company when >> saying bad things without fair notice). >> >> Your code is your code. Thats how the LGPL works. But don't take RXTX >> and fork it where I or anyone else that has worked on RXTX can see it. >> >> -- >> Trent Jarvi > > Hallo Trent, > > The BSD license wants to give and GPL wants to improve the public available > content. What do you prefer? > > If you build the code to provide everyone a better experience then the BSD > license would be suitable since the business acceptance is much higher. > If you see this as a crucial component to build a complete free Java > infrastructure that has no place for commerce then the GPL would be better > In both situations RXTX will be free. > > I say that the chance a company would not contribute does not outweight the > chance that the API is less available to the users. > The entire API is a dead end. Mustang has USB support. Please let's make this > as good as it gets. Hi Pascal I can not speak for any company here. I just happen to have become interesting to companies. With RXTX, the intent has always been to improve functionality. I don't play between the two worlds except for borrowing a scope at late in the evening. Thats rxtx and there is nothing else going on. Note that the RXTX library is LGPL. I would be interested in knowing where the GPL confusion comes from. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Jul 9 04:46:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 09 Jul 2006 06:46:49 -0400 Subject: [Rxtx] Java installer In-Reply-To: <200607082214.45115.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080235.29486.pascal@quies.net> <44AFB8AF.50403@gmail.com> <200607082214.45115.pascal@quies.net> Message-ID: Hi All, The problem of improving Java's ability to install and configure applications is a topic of current research. Configuration is a loaded word. When I think of configuration, I think, discover the properties of the operating environment and configure the software to work within that environment. Properties may include, but are not limited to, number and kind of monitors, serial ports, JVM versions, native method libs, graphics cards, graphics libs, write access to directories, changing the default screen saver (a new research topic) etc. There are two deployment solutions I can think of, please correct me, if I have left something out: 1. A source code distro with build tools (i.e., make and or ant) that enable the user to do a build for the target platform. 2. A binary distro built for each platform. Now, Java (in theory), is compile once, run anywhere. This assumes you don't use native methods. Once you start using native methods, you end up with many builds of the libs (one for each supported platform). Assuming you want binary distros for each platform, then you are faced with how to deploy them. Here are two basic approaches I know: 1. Build an application installer 2. Build a web-start distribution Some would argue for the application installer, as this is what many people are used to. Others will argue for a web-start distro. For a JNI-based application, like one that makes use of RXTX, I don't know which approach is "better". To know, one must first establish what "better" means. I think there must be (at least) two properties here: 1. Minimal installation effort 2. Trust. For minimal installation effort, I think that I should be able to download software, on demand, and just run it. Updates are obtained with minimal effort. Everything just works. And on all platforms that I use. For trust, I want to make sure I know the author and am able to hold someone accountable for application creation. I need to be able to thwart man-in-the-middle attacks and assure my user-base that I have signed off on my software. I have been making use of web-start, as a multi-year experiment. I have had mixed results. Particularly with more complex installs that make use of Java3d. In my view, several open problems remain. And cross-platform testing is needed for each major new application, platform, or major native method revision. On the other hand, I have had some good results with Java web start and RXTX. I can cite: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Which is an address book program that should identify your serial port and enable dialing via the modem. The web start system seems to be able to adapt to multiple operating environments. The question of how well this deploys remains open. It should work on mac, windows and linux. If people want to try it and give me feedback, I would appreciate it. Deployment is semi-automatic using Project Initium. This is described in: http://show.docjava.com:8086/pub/document/jot/web.pdf and http://show.docjava.com:8086/pub/document/jot/initium.pdf Thanks! - Doug >Op zaterdag 8 juli 2006 15:52, schreef Manuel Naranjo: >> > You are right. IzPack looks like the right tool for this job. >> > >> > As far as I can see there is no commandline support but I'll get over it. >> > ;) >> >> Actually there is a way to execute native app in the Underlaying OS. >> Check out the JavaDOC and all the documentation given by them. >> If you need to also generate warper around the jar files, check this > > projects out: > > http://launch4j.sourceforge.net and http://jsmooth.sourceforge.net/ > > I have been able to make and exe with jsmooth that does not need to >> have RXTX installed if you want I can send the source of it. But it is >> simple. >> Do not put the jar inside the exe file, and add to the classpath >> relative paths to rxtx jar and then your jar file, and then add to the >> JVM command line (I can't remeber the actual name of it :P) > > -Djava.library.path=bin\ (Or were ever you installed the binary package). >> I have tryied doing the same with Java Comm from Sun but it actually is >> imposible, the main difference to me that make me move to RXTX, was that >> there is no need to have the javax.comm.properties file, which gave me >> lot of headaches. >> Regards, >> Manuel. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >Those are verry interresting and impressive tools for Windows. >However, I wanted (and still do) a universal installer for all supported >platforms as a single JAR. IzPack seemed quite suitable but it is limited and >not well written so I'me still searching... > >Thanks for the help though. :) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 9 05:15:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 13:15:13 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607090006.18197.pascal@quies.net> Message-ID: <200607091315.14053.pascal@quies.net> Op zondag 9 juli 2006 05:14, schreef Trent Jarvi: > Hi Pascal > > I can not speak for any company here. I just happen to have become > interesting to companies. > > With RXTX, the intent has always been to improve functionality. > > I don't play between the two worlds except for borrowing a scope at late > in the evening. Thats rxtx and there is nothing else going on. > > Note that the RXTX library is LGPL. I would be interested in knowing > where the GPL confusion comes from. Hi Trent, The license is stated clearly everywhere so don't worry. You are right that the LGPL should not be a problem for companies. The problem is, especially in larger companies, that the people who take the decissions think differend. When they hear about the demands of the license they rather spend "some" money on a commercial solution just to be sure because the trouble it might cause is not worth it. From pascal at quies.net Sun Jul 9 05:15:41 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 13:15:41 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607090025.24884.pascal@quies.net> Message-ID: <200607091315.41848.pascal@quies.net> Op zondag 9 juli 2006 00:33, schreef Trent Jarvi: > I would ask that you consider the larger picture here. Termios and DCB > are almost dead but almost being used like a VISA interface. Everyone > just wants it to work but it does not always. > > So your proposal is to make mulitiple deal protocols? No, nothing like that. Just use native calls where possible. I'll send you some things this week anyway. From pascal at quies.net Sun Jul 9 05:52:11 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 13:52:11 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607082214.45115.pascal@quies.net> Message-ID: <200607091352.11696.pascal@quies.net> Op zondag 9 juli 2006 12:46, schreef Dr. Douglas Lyon: > Hi All, > The problem of improving Java's ability to > install and configure applications is a topic of current research. > > Configuration is a loaded word. When I think of configuration, > I think, discover the properties of the operating environment and > configure the software to work within that environment. > > Properties may include, but are not limited to, number and > kind of monitors, serial ports, JVM versions, native method libs, > graphics cards, graphics libs, write access to directories, > changing the default screen saver (a new research topic) etc. > > There are two deployment solutions I can think of, > please correct me, if I have left something out: > 1. A source code distro with build tools (i.e., make and or ant) that > enable the user to do a build for the target platform. > 2. A binary distro built for each platform. > > Now, Java (in theory), is compile once, run anywhere. This assumes you > don't use native methods. Once you start using native methods, > you end up with many builds of the libs (one for each supported platform). > > Assuming you want binary distros for each platform, then you are faced with > how to deploy them. Here are two basic approaches I know: > 1. Build an application installer > 2. Build a web-start distribution > > Some would argue for the application installer, as this is what > many people are used to. Others will argue for a web-start distro. > > For a JNI-based application, like one that makes use of RXTX, > I don't know which approach is "better". To know, one must > first establish what "better" means. I think there must be (at least) two > properties here: > 1. Minimal installation effort > 2. Trust. > > For minimal installation effort, I think that I should be able to download > software, on demand, and just run it. Updates are obtained with minimal > effort. Everything just works. And on all platforms that I use. > > For trust, I want to make sure I know the author and am able to hold > someone accountable for application creation. I need to be able to thwart > man-in-the-middle > attacks and assure my user-base that I have signed off on my software. > > I have been making > use of web-start, as a multi-year experiment. > > I have had mixed results. Particularly with more complex installs > that make use of Java3d. In my view, several open problems remain. > And cross-platform testing is needed for each major new application, > platform, or major native method revision. > > On the other hand, I have had some good results with Java web start > and RXTX. I can cite: > http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jn >lp Which is an address book program that should identify your > serial port and enable dialing via the modem. > > The web start system seems to be able to adapt to multiple operating > environments. The question of how well this deploys remains open. > > It should work on mac, windows and linux. If people want to try it > and give me feedback, I would appreciate it. > > Deployment is semi-automatic using Project Initium. This is described in: > http://show.docjava.com:8086/pub/document/jot/web.pdf > and > http://show.docjava.com:8086/pub/document/jot/initium.pdf > > Thanks! > - Doug Hello Dough, We are bumping into the same problems. Youre web-based plan is definitely the way to go. I still didn't find a way to get around two IzPack problems without hacking into the code and it's taking too long so I started again on the inital plan. The CommunicationAPI class does leave the trust thing up to the implementation. This means that users can download and run the JAR and other applications can include the jar to install things if needed. If you could "Initum" this process then RXTX has no installating limits anymore. From joachim at buechse.de Sun Jul 9 07:13:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 9 Jul 2006 15:13:34 +0200 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44AFBB4E.70808@gmail.com> References: <44AFBB4E.70808@gmail.com> Message-ID: <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> Manuel, a simple way to avoid the javax.comm.properties file is to include a class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } into your application jar file and make sure, that you include the javax.comm jar after it. That's all you need. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 08.07.2006, at 16:03, Manuel Naranjo wrote: > Hi: > I have a question, haven't you ever thought about changing RXTX > license > from GNU/GPL to a more open license like Apache v2 or BSD like?. > As far as I understand if I make an application that uses RXTX > libraries, I must release my app under the GNU/GPL. I have no problem > with that in fact I'm an Open Source user and defender. > The fact is that in same cases the applications made by one, could get > into hands of a company that needs to release a Closed Source app. I > understand that using GNU/GPL do not give you the power to do this, > but > a more "open" license like Apache does. By "open" I mean that the > license respects the Open Source license, but also lives the user the > opportunity to use the library in closed source programs. > I have seen that there is an exception to the license that applies to > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > (the jar file) needs the file javax.comm.properties installed > correctly, > which in lot of cases is a headache. RXTX jar does not need this, > actually I think that RXTX is more user friendly than Java Comm. > Maybe there has been a discussion like this before, but I just > wanted to > ask, and to get an answer that is adequate to our time. > Regards, > Manuel > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Sun Jul 9 07:19:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 9 Jul 2006 15:19:43 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607082203.13696.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> <44AFFF2C.8090005@gmail.com> <200607082203.13696.pascal@quies.net> Message-ID: <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> Pascal, I would strongly suggest NOT to follow these installation instructions for OSX. It "poisons" the global Java VM with a specific implementation of RXTX. Plus: there is not one, but several Java VMs installed on every version of OSX. An application specific file and global preference pane defines which VM launches which application. There is really no good reason to install RXTX globally. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 08.07.2006, at 22:03, Pascal S. de Kloe wrote: > > As far as the installation instructions go the location of the > libraries is > the following. > > Windows > * JRE: $JAVA_HOME/bin/ > * JDK: $JAVA_HOME/jre/bin/ > > UNIX > * JRE: $JAVA_HOME/lib/ > * JRE: $JAVA_HOME/jre/lib/ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 9 09:01:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 17:01:24 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> References: <200607081944.41123.pascal@quies.net> <200607082203.13696.pascal@quies.net> <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> Message-ID: <200607091701.24661.pascal@quies.net> Op zondag 9 juli 2006 15:19, schreef Joachim Buechse: > Pascal, > > I would strongly suggest NOT to follow these installation > instructions for OSX. It "poisons" the global Java VM with a specific > implementation of RXTX. Plus: there is not one, but several Java VMs > installed on every version of OSX. An application specific file and > global preference pane defines which VM launches which application. > There is really no good reason to install RXTX globally. I see your points. How can you use the extension non-globally? I asked the same thing for Windows to Manuel. The system will allow you to detect any implementation. So the "poison" becomes a alternative. Applications can install the extension if needed to the current runtime with something like: CommunicationAPI comm = new CommunicationAPI(); if (! comm.available()) { if (comm.installRXTX()) restart(); else handleError("I need the extension!"); } From naranjo.manuel at gmail.com Sun Jul 9 10:36:21 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 09 Jul 2006 13:36:21 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> Message-ID: <44B13085.2000805@gmail.com> Joachim, Does that really work???? I will try it later, thanks :) Manuel > Manuel, > > a simple way to avoid the javax.comm.properties file is to include a > class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > into your application jar file and make sure, that you include the > javax.comm jar after it. That's all you need. > > Regards, > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 08.07.2006, at 16:03, Manuel Naranjo wrote: > >> Hi: >> I have a question, haven't you ever thought about changing RXTX >> license >> from GNU/GPL to a more open license like Apache v2 or BSD like?. >> As far as I understand if I make an application that uses RXTX >> libraries, I must release my app under the GNU/GPL. I have no problem >> with that in fact I'm an Open Source user and defender. >> The fact is that in same cases the applications made by one, could get >> into hands of a company that needs to release a Closed Source app. I >> understand that using GNU/GPL do not give you the power to do this, >> but >> a more "open" license like Apache does. By "open" I mean that the >> license respects the Open Source license, but also lives the user the >> opportunity to use the library in closed source programs. >> I have seen that there is an exception to the license that applies to >> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >> (the jar file) needs the file javax.comm.properties installed >> correctly, >> which in lot of cases is a headache. RXTX jar does not need this, >> actually I think that RXTX is more user friendly than Java Comm. >> Maybe there has been a discussion like this before, but I just >> wanted to >> ask, and to get an answer that is adequate to our time. >> Regards, >> Manuel >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jul 9 10:50:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Jul 2006 10:50:11 -0600 (MDT) Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44B13085.2000805@gmail.com> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> Message-ID: I won't prevent people from discussing this hack. You can discuss anything on the list including things I do not agree with. But I do not agree with that hack. That is not in line with the history of RXTX respecting all that contribute including Sun. If you do this, it is your own thing. Agreeing to disagree is fine and usually the default here :). I just want to make it clear I do disagree. On Sun, 9 Jul 2006, Manuel Naranjo wrote: > Joachim, > Does that really work???? I will try it later, thanks :) > Manuel > >> Manuel, >> >> a simple way to avoid the javax.comm.properties file is to include a >> class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> into your application jar file and make sure, that you include the >> javax.comm jar after it. That's all you need. >> >> Regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 08.07.2006, at 16:03, Manuel Naranjo wrote: >> >>> Hi: >>> I have a question, haven't you ever thought about changing RXTX >>> license >>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>> As far as I understand if I make an application that uses RXTX >>> libraries, I must release my app under the GNU/GPL. I have no problem >>> with that in fact I'm an Open Source user and defender. >>> The fact is that in same cases the applications made by one, could get >>> into hands of a company that needs to release a Closed Source app. I >>> understand that using GNU/GPL do not give you the power to do this, >>> but >>> a more "open" license like Apache does. By "open" I mean that the >>> license respects the Open Source license, but also lives the user the >>> opportunity to use the library in closed source programs. >>> I have seen that there is an exception to the license that applies to >>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>> (the jar file) needs the file javax.comm.properties installed >>> correctly, >>> which in lot of cases is a headache. RXTX jar does not need this, >>> actually I think that RXTX is more user friendly than Java Comm. >>> Maybe there has been a discussion like this before, but I just >>> wanted to >>> ask, and to get an answer that is adequate to our time. >>> Regards, >>> Manuel >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From naranjo.manuel at gmail.com Sun Jul 9 11:43:33 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 09 Jul 2006 14:43:33 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> Message-ID: <44B14045.9030601@gmail.com> Trent: Do you know any other way, to use Java Comm API with RXTX with out the javax.comm.properties?. Have any information about how is the JSR going? Regards, Manuel > > I won't prevent people from discussing this hack. You can discuss > anything on the list including things I do not agree with. > > But I do not agree with that hack. That is not in line with the history > of RXTX respecting all that contribute including Sun. If you do this, > it is your own thing. > > Agreeing to disagree is fine and usually the default here :). I just > want to make it clear I do disagree. > > On Sun, 9 Jul 2006, Manuel Naranjo wrote: > >> Joachim, >> Does that really work???? I will try it later, thanks :) >> Manuel >> >>> Manuel, >>> >>> a simple way to avoid the javax.comm.properties file is to include a >>> class >>> >>> package com.sun.comm; >>> public class SolarisDriver extends gnu.io.RXTXCommDriver { >>> } >>> >>> into your application jar file and make sure, that you include the >>> javax.comm jar after it. That's all you need. >>> >>> Regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich >>> >>> >>> On 08.07.2006, at 16:03, Manuel Naranjo wrote: >>> >>>> Hi: >>>> I have a question, haven't you ever thought about changing RXTX >>>> license >>>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>>> As far as I understand if I make an application that uses RXTX >>>> libraries, I must release my app under the GNU/GPL. I have no problem >>>> with that in fact I'm an Open Source user and defender. >>>> The fact is that in same cases the applications made by one, could get >>>> into hands of a company that needs to release a Closed Source app. I >>>> understand that using GNU/GPL do not give you the power to do this, >>>> but >>>> a more "open" license like Apache does. By "open" I mean that the >>>> license respects the Open Source license, but also lives the user the >>>> opportunity to use the library in closed source programs. >>>> I have seen that there is an exception to the license that applies to >>>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>>> (the jar file) needs the file javax.comm.properties installed >>>> correctly, >>>> which in lot of cases is a headache. RXTX jar does not need this, >>>> actually I think that RXTX is more user friendly than Java Comm. >>>> Maybe there has been a discussion like this before, but I just >>>> wanted to >>>> ask, and to get an answer that is adequate to our time. >>>> Regards, >>>> Manuel >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Jul 9 11:53:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Jul 2006 11:53:19 -0600 (MDT) Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44B14045.9030601@gmail.com> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> Message-ID: Hi Manuel I do not know of another way. If you look at rxtx.org, even the compiled version is hard to find, always late and not what you want. At rxtx.org we just worry about the source and do a minimal effort to provide binaries. I'd love nothing more than someone to start selling RXTX binaries or working with us like Doug is to deliver the problems solved to users. The Free here is Freedom. Not price. There is a need for services rxtx.org is not able to provide well. That said I do not ever expect to recieve anything. It just makes sense for everyone to work together and compete outside of the source. On Sun, 9 Jul 2006, Manuel Naranjo wrote: > Trent: > Do you know any other way, to use Java Comm API with RXTX with out the > javax.comm.properties?. > Have any information about how is the JSR going? > Regards, > Manuel >> >> I won't prevent people from discussing this hack. You can discuss >> anything on the list including things I do not agree with. >> >> But I do not agree with that hack. That is not in line with the history >> of RXTX respecting all that contribute including Sun. If you do this, >> it is your own thing. >> >> Agreeing to disagree is fine and usually the default here :). I just >> want to make it clear I do disagree. >> >> On Sun, 9 Jul 2006, Manuel Naranjo wrote: >> >>> Joachim, >>> Does that really work???? I will try it later, thanks :) >>> Manuel >>> >>>> Manuel, >>>> >>>> a simple way to avoid the javax.comm.properties file is to include a >>>> class >>>> >>>> package com.sun.comm; >>>> public class SolarisDriver extends gnu.io.RXTXCommDriver { >>>> } >>>> >>>> into your application jar file and make sure, that you include the >>>> javax.comm jar after it. That's all you need. >>>> >>>> Regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >>>> >>>> >>>> On 08.07.2006, at 16:03, Manuel Naranjo wrote: >>>> >>>>> Hi: >>>>> I have a question, haven't you ever thought about changing RXTX >>>>> license >>>>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>>>> As far as I understand if I make an application that uses RXTX >>>>> libraries, I must release my app under the GNU/GPL. I have no problem >>>>> with that in fact I'm an Open Source user and defender. >>>>> The fact is that in same cases the applications made by one, could get >>>>> into hands of a company that needs to release a Closed Source app. I >>>>> understand that using GNU/GPL do not give you the power to do this, >>>>> but >>>>> a more "open" license like Apache does. By "open" I mean that the >>>>> license respects the Open Source license, but also lives the user the >>>>> opportunity to use the library in closed source programs. >>>>> I have seen that there is an exception to the license that applies to >>>>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>>>> (the jar file) needs the file javax.comm.properties installed >>>>> correctly, >>>>> which in lot of cases is a headache. RXTX jar does not need this, >>>>> actually I think that RXTX is more user friendly than Java Comm. >>>>> Maybe there has been a discussion like this before, but I just >>>>> wanted to >>>>> ask, and to get an answer that is adequate to our time. >>>>> Regards, >>>>> Manuel >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From naranjo.manuel at gmail.com Sun Jul 9 12:04:28 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 09 Jul 2006 15:04:28 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> Message-ID: <44B1452C.60208@gmail.com> Trent Jarvi wrote: > > Hi Manuel > > I do not know of another way. If you look at rxtx.org, even the > compiled version is hard to find, always late and not what you want. At > rxtx.org we just worry about the source and do a minimal effort to > provide binaries. Then that probes my theory, RXTX is much better than Java comm :) > I'd love nothing more than someone to start selling RXTX binaries or > working with us like Doug is to deliver the problems solved to users. > The Free here is Freedom. Not price. There is a need for services > rxtx.org is not able to provide well. That said I do not ever expect to > recieve anything. It just makes sense for everyone to work together and > compete outside of the source. I would like to contribute with the project giving support, I have worked using JSmooth and IzPack, and been able to make things that make RXTX easier to use and install. I will try to debug them, and send them to the mailing list, so you can do what ever you want with this :). Regards, Manuel From tjarvi at qbang.org Sun Jul 9 22:15:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Jul 2006 22:15:28 -0600 (MDT) Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44B1452C.60208@gmail.com> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> <44B1452C.60208@gmail.com> Message-ID: On Sun, 9 Jul 2006, Manuel Naranjo wrote: > Trent Jarvi wrote: >> >> Hi Manuel >> >> I do not know of another way. If you look at rxtx.org, even the >> compiled version is hard to find, always late and not what you want. At >> rxtx.org we just worry about the source and do a minimal effort to >> provide binaries. > Then that probes my theory, RXTX is much better than Java comm :) > >> I'd love nothing more than someone to start selling RXTX binaries or >> working with us like Doug is to deliver the problems solved to users. >> The Free here is Freedom. Not price. There is a need for services >> rxtx.org is not able to provide well. That said I do not ever expect to >> recieve anything. It just makes sense for everyone to work together and >> compete outside of the source. > I would like to contribute with the project giving support, I have > worked using JSmooth and IzPack, and been able to make things that make > RXTX easier to use and install. I will try to debug them, and send them > to the mailing list, so you can do what ever you want with this :). > Regards, Hi Manuel This is interesting. There are some checks and balances that we do at rxtx.org to make sure random material does not get in. It isn't personal just a low bar that must be crossed. After you get your changes in, you will know that others must cross the same bar. The basic question asked is "Does this change reflect the intent and work of those that have contributed to RXTX." Perhaps Doug is the best person to be the bar here. I'm more than willing to admit my limitations and obviously this is a limitation I face. If Doug is willing to take this task, I'd be glad to give him CVS write access which is more than overdue as he is the official maintainer now :) He then could optionally give you write access if your changes are fine and you represent a bar for new changes. I trust Doug. We do take the bar seriously as you can see. But it is not intended to prevent fair use of RXTX or prevent facilitating new uses. If we don't manage expectations here, there will be all sorts of problems and issues. -- Trent Jarvi tjarvi at qbang.org From zhanglong at adventnet.com Mon Jul 10 02:02:20 2006 From: zhanglong at adventnet.com (zhanglong) Date: Mon, 10 Jul 2006 16:02:20 +0800 Subject: [Rxtx] rxtx can not read data from serialport Message-ID: <44B2098C.6050407@adventnet.com> Dear brian and tjarvi, Thank you! After I set flowcontrol as FLOWCONTROL_RTSCTS_IN serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_IN); Then I can read and write data from serial port on Windows. But On linux9.0,No response,no data. I can get serialport list on my machine.And no error when I open serialport. I use Wevecom GSM modem device.I install Linux in VWware Workstation. And VWware Workstation install on windowsXP,So windowsXP and redhat Linux9.0 are on the same PC. On windows,I use COM1 serialport. On Linux,I use /dev/ttyS0 serialport. I hava test with SerialPort.FLOWCONTROL_XONXOFF_IN flow control,But still no data. How to set flow control,timeout and threshold on linux9.0? Thanks & Regards, Zhanglong -------------- next part -------------- A non-text attachment was scrubbed... Name: ListPort.java Type: text/x-java Size: 1659 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060710/334802b0/ListPort-0356.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: listport return on Windows and Linux.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060710/334802b0/listportreturnonWindowsandLinux-0356.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: TwoWaySerialComm.java Type: text/x-java Size: 3516 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060710/334802b0/TwoWaySerialComm-0356.bin From joachim at buechse.de Mon Jul 10 02:53:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 10 Jul 2006 10:53:09 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607091701.24661.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> <200607082203.13696.pascal@quies.net> <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> <200607091701.24661.pascal@quies.net> Message-ID: <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> The problem is, that once the libraries are installed in JAVA_HOME/ lib they will be loaded in preference to classes in your application classpath. If all you want is to use RXTX, then: - put the native lib in your application directory - include the javax.comm classes and RXTX classes in your application classpath - add the little stub class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } before the javax.comm classes in your application classpath. Alternatively you could also include the native lib in your application jar, extract it at runtime to a temp file, load it with System.load(). This will work on Windows and OSX. I didn't test it on Linux, but it should work. Regards, Joachim On 09.07.2006, at 17:01, Pascal S. de Kloe wrote: > Op zondag 9 juli 2006 15:19, schreef Joachim Buechse: >> Pascal, >> >> I would strongly suggest NOT to follow these installation >> instructions for OSX. It "poisons" the global Java VM with a specific >> implementation of RXTX. Plus: there is not one, but several Java VMs >> installed on every version of OSX. An application specific file and >> global preference pane defines which VM launches which application. >> There is really no good reason to install RXTX globally. > > I see your points. > How can you use the extension non-globally? I asked the same thing > for Windows > to Manuel. > > The system will allow you to detect any implementation. So the > "poison" > becomes a alternative. Applications can install the extension if > needed to > the current runtime with something like: > > CommunicationAPI comm = new CommunicationAPI(); > if (! comm.available()) { > if (comm.installRXTX()) > restart(); > else > handleError("I need the extension!"); > } > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jul 10 06:07:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 10 Jul 2006 06:07:23 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607081330.24381.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <200607081330.24381.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> Is the gnu.io namespace still necessary? I couldn't find the problem. >> >> Hi Pascal >> >> CommAPI is a little different in that it was grandfathered into the javax >> namespace with its own license at the time. >> >> It is my understanding that if CommAPI went through the JSR process, >> anyone would _clearly_ be able to implement a javax.comm package and RXTX >> would then be one of the first to do so. I believe Doug has expressed >> some interest in RXTX trying to work with the JSR process. >> >> Besides the license questions, there is the fact that RXTX has extensions >> to CommAPI which could cause confusion in the namespace. Not being a >> lawyer and *really* not liking to talk to lawyers in my free time, it is >> better to be safe than sorry. The lawyers tend to come in wolf packs >> when they do come. >> >> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay >> there as long as we are just geeks trying to figure out if a license does >> or does not allow us to implement in the javax.comm namespace. > > Nicely said. :) > > The whole point of namespaces is to create a universal registry of, in this > case, classes. This gnu.io namespace is very inconvenient. > > We feel the same way about lawyers. However I'd like to go into the details of > the license (see attachment) if you don't mind? > > The first license does not apply since RXTX does not use the software. The > second one at point 3 specifies our options. > >> 3. You may not modify the Java Platform Interface ("JPI", identified as >> classes contained within the "java" package or any subpackages of the >> "java" package), by creating additional classes within the JPI or otherwise >> causing the addition to or modification of the classes in the JPI. > > RXTX is a extension. > >> In the event that you create an additional class and associated API(s) >> which (i) extends the functionality of the Java platform, and (ii) is >> exposed to third party software developers for the purpose of developing >> additional software which invokes such additional API, you must promptly >> publish broadly an accurate specification for such API for free use by all >> developers. > > That's the way we operate. :) > >> You may not create, or authorize your licensees to create additional >> classes, interfaces, or subpackages that are in any way identified as >> "java", "javax", "sun" or similar convention as specified by Sun in any >> naming convention designation. > > They don't want additional components in the Communication API since they > don't want a mess in theire namespace. > > So we *can* use javax.comm for the core: > javax.comm.CommDriver > javax.comm.CommPort > javax.comm.CommPortIdentifier > javax.comm.CommPortOwnershipListener > javax.comm.NoSuchPortException > javax.comm.PortInUseException > javax.comm.UnsupportedCommOperationException > > ...and for the default hardware support: > javax.comm.SerialPort > javax.comm.SerialPortEvent > javax.comm.SerialPortEventListener > javax.comm.ParralelPort > javax.comm.ParralelPortEvent > javax.comm.ParralelPortEventListener > > ...but RXTX aditional hardware support has to go somewhere else like: > org.rxtx.RS485Port > org.rxtx.RS485PortEvent > org.rxtx.RS485PortEventListener > org.rxtx.I2CPort > org.rxtx.I2CPortEvent > org.rxtx.I2CPortEventListener > > Right? > The one thing this discussion does not cover is in SerialPort.java. See the extensions to commapi listed after the following line: /* ---------------------- end of commapi ------------------------ */ The intent is not to break commapi but it could be perceived as so. The extensions added have been placed there as requested by users of RXTX. It would be nice to discuss these modifications with Sun and perhaps have some added to the final version of CommAPI. Some of them may not make sense while others do. Some can not be implemented in a platform neutral fashion. It would not make sense for RXTX to just bring these into Sun's namespace without due process. This is why I am fundamentally apposed to people "poisoning" Sun's namespace with RXTX 2.1 although I understand that is not their intent. These modifications are not advertised and their use is discouraged. But they are there. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Mon Jul 10 06:47:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 10 Jul 2006 14:47:24 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607081330.24381.pascal@quies.net> Message-ID: <200607101447.25071.pascal@quies.net> Op maandag 10 juli 2006 14:07, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > > Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: > >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > >>> Is the gnu.io namespace still necessary? I couldn't find the problem. > >> > >> Hi Pascal > >> > >> CommAPI is a little different in that it was grandfathered into the > >> javax namespace with its own license at the time. > >> > >> It is my understanding that if CommAPI went through the JSR process, > >> anyone would _clearly_ be able to implement a javax.comm package and > >> RXTX would then be one of the first to do so. I believe Doug has > >> expressed some interest in RXTX trying to work with the JSR process. > >> > >> Besides the license questions, there is the fact that RXTX has > >> extensions to CommAPI which could cause confusion in the namespace. Not > >> being a lawyer and *really* not liking to talk to lawyers in my free > >> time, it is better to be safe than sorry. The lawyers tend to come in > >> wolf packs when they do come. > >> > >> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay > >> there as long as we are just geeks trying to figure out if a license > >> does or does not allow us to implement in the javax.comm namespace. > > > > Nicely said. :) > > > > The whole point of namespaces is to create a universal registry of, in > > this case, classes. This gnu.io namespace is very inconvenient. > > > > We feel the same way about lawyers. However I'd like to go into the > > details of the license (see attachment) if you don't mind? > > > > The first license does not apply since RXTX does not use the software. > > The second one at point 3 specifies our options. > > > >> 3. You may not modify the Java Platform Interface ("JPI", identified as > >> classes contained within the "java" package or any subpackages of the > >> "java" package), by creating additional classes within the JPI or > >> otherwise causing the addition to or modification of the classes in the > >> JPI. > > > > RXTX is a extension. > > > >> In the event that you create an additional class and associated API(s) > >> which (i) extends the functionality of the Java platform, and (ii) is > >> exposed to third party software developers for the purpose of developing > >> additional software which invokes such additional API, you must promptly > >> publish broadly an accurate specification for such API for free use by > >> all developers. > > > > That's the way we operate. :) > > > >> You may not create, or authorize your licensees to create additional > >> classes, interfaces, or subpackages that are in any way identified as > >> "java", "javax", "sun" or similar convention as specified by Sun in any > >> naming convention designation. > > > > They don't want additional components in the Communication API since they > > don't want a mess in theire namespace. > > > > So we *can* use javax.comm for the core: > > javax.comm.CommDriver > > javax.comm.CommPort > > javax.comm.CommPortIdentifier > > javax.comm.CommPortOwnershipListener > > javax.comm.NoSuchPortException > > javax.comm.PortInUseException > > javax.comm.UnsupportedCommOperationException > > > > ...and for the default hardware support: > > javax.comm.SerialPort > > javax.comm.SerialPortEvent > > javax.comm.SerialPortEventListener > > javax.comm.ParralelPort > > javax.comm.ParralelPortEvent > > javax.comm.ParralelPortEventListener > > > > ...but RXTX aditional hardware support has to go somewhere else like: > > org.rxtx.RS485Port > > org.rxtx.RS485PortEvent > > org.rxtx.RS485PortEventListener > > org.rxtx.I2CPort > > org.rxtx.I2CPortEvent > > org.rxtx.I2CPortEventListener > > > > Right? > > The one thing this discussion does not cover is in SerialPort.java. See > the extensions to commapi listed after the following line: > > /* ---------------------- end of commapi ------------------------ */ > > The intent is not to break commapi but it could be perceived as so. The > extensions added have been placed there as requested by users of RXTX. It > would be nice to discuss these modifications with Sun and perhaps have > some added to the final version of CommAPI. > > Some of them may not make sense while others do. Some can not be > implemented in a platform neutral fashion. It would not make sense > for RXTX to just bring these into Sun's namespace without due process. > > This is why I am fundamentally apposed to people "poisoning" Sun's > namespace with RXTX 2.1 although I understand that is not their intent. > > These modifications are not advertised and their use is discouraged. But > they are there. Hi Trent, So you are saying that gnu.io.SerialPort has some aditional methods over javax.comm.SerialPort? That does not change the API at all but it would be a problem if people would start using those methods in the javax.comm namespace in the same way like some people use the com.sun namespace. Could wrapper classes at javax.comm do the job? In that way RXTX stays in its namespace, javadoc can notice the aditional methods and the Communication API will be available as expected. From pascal at quies.net Mon Jul 10 06:48:09 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 10 Jul 2006 14:48:09 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> References: <200607081944.41123.pascal@quies.net> <200607091701.24661.pascal@quies.net> <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> Message-ID: <200607101448.09594.pascal@quies.net> Op maandag 10 juli 2006 10:53, schreef Joachim Buechse: > If all you want is to use RXTX, then: > > - put the native lib in your application directory > - include the javax.comm classes and RXTX classes in your application > classpath > - add the little stub class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > before the javax.comm classes in your application classpath. > > Alternatively you could also include the native lib in your > application jar, extract it at runtime to a temp file, load it with > System.load(). So java will load the native libraries automaticly if they are in the same directory as the Java application? Why isn't this very interresting information noticed in the documentation or is that too obvious and I simply didn't knew? From naranjo.manuel at gmail.com Mon Jul 10 06:56:10 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Mon, 10 Jul 2006 09:56:10 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> <44B1452C.60208@gmail.com> Message-ID: <44B24E6A.1010805@gmail.com> Trent Jarvi wrote: > On Sun, 9 Jul 2006, Manuel Naranjo wrote: > >> Trent Jarvi wrote: >>> Hi Manuel >>> >>> I do not know of another way. If you look at rxtx.org, even the >>> compiled version is hard to find, always late and not what you want. At >>> rxtx.org we just worry about the source and do a minimal effort to >>> provide binaries. >> Then that probes my theory, RXTX is much better than Java comm :) >> >>> I'd love nothing more than someone to start selling RXTX binaries or >>> working with us like Doug is to deliver the problems solved to users. >>> The Free here is Freedom. Not price. There is a need for services >>> rxtx.org is not able to provide well. That said I do not ever expect to >>> recieve anything. It just makes sense for everyone to work together and >>> compete outside of the source. >> I would like to contribute with the project giving support, I have >> worked using JSmooth and IzPack, and been able to make things that make >> RXTX easier to use and install. I will try to debug them, and send them >> to the mailing list, so you can do what ever you want with this :). >> Regards, > > > Hi Manuel > > This is interesting. There are some checks and balances that we do at > rxtx.org to make sure random material does not get in. It isn't personal > just a low bar that must be crossed. After you get your changes in, you > will know that others must cross the same bar. The basic question asked > is "Does this change reflect the intent and work of those that have > contributed to RXTX." > > Perhaps Doug is the best person to be the bar here. I'm more than willing > to admit my limitations and obviously this is a limitation I face. > > If Doug is willing to take this task, I'd be glad to give him CVS write > access which is more than overdue as he is the official maintainer now :) > He then could optionally give you write access if your changes are fine > and you represent a bar for new changes. I trust Doug. > > We do take the bar seriously as you can see. But it is not intended to > prevent fair use of RXTX or prevent facilitating new uses. If we don't > manage expectations here, there will be all sorts of problems and issues. > > -- > Trent Jarvi > tjarvi at qbang.org > > Trent, What I want to send you is not a modification to rxtx, it just a developers helper if you want to put a name to it. I have make an IzPack installer, which installs RXTX binaries depending on underlaying OS. And make an JSmooth warper that launches my app with out the need to have rxtx installed on the host JVM folder, it only need the RXTX to be in the bin\ of my app. I think this is more useful for Wiki than to the main project. Another thing I have experience in PalmOS programming, when ever I have time, I will investigate about the JNI of J2ME and try to port RXTX to Palm, I do not know when I will start, because I have a lot of work now. Regards, Manuel From christopher.dawes at the-logic-group.com Mon Jul 10 08:00:15 2006 From: christopher.dawes at the-logic-group.com (christopher.dawes@the-logic-group.com) Date: Mon, 10 Jul 2006 15:00:15 +0100 Subject: [Rxtx] Chris Dawes/Retaillogic/NISABA is out of the office. Message-ID: I will be out of the office starting 10/07/2006 and will not return until 11/07/2008. Hello, unfortunately I no longer work for The Logic Group, if you're trying to contact me on a work related issue please contact Pete Avery (pete.avery at the-logic-group.com) however if it is a personal matter please e-mail root at ants.me.uk or phone 07899 842 759. Thanks Christopher Dawes From tjarvi at qbang.org Mon Jul 10 08:19:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 10 Jul 2006 08:19:52 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607101447.25071.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607081330.24381.pascal@quies.net> <200607101447.25071.pascal@quies.net> Message-ID: On Mon, 10 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 10 juli 2006 14:07, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: >>>> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>>>> Is the gnu.io namespace still necessary? I couldn't find the problem. >>>> >>>> Hi Pascal >>>> >>>> CommAPI is a little different in that it was grandfathered into the >>>> javax namespace with its own license at the time. >>>> >>>> It is my understanding that if CommAPI went through the JSR process, >>>> anyone would _clearly_ be able to implement a javax.comm package and >>>> RXTX would then be one of the first to do so. I believe Doug has >>>> expressed some interest in RXTX trying to work with the JSR process. >>>> >>>> Besides the license questions, there is the fact that RXTX has >>>> extensions to CommAPI which could cause confusion in the namespace. Not >>>> being a lawyer and *really* not liking to talk to lawyers in my free >>>> time, it is better to be safe than sorry. The lawyers tend to come in >>>> wolf packs when they do come. >>>> >>>> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay >>>> there as long as we are just geeks trying to figure out if a license >>>> does or does not allow us to implement in the javax.comm namespace. >>> >>> Nicely said. :) >>> >>> The whole point of namespaces is to create a universal registry of, in >>> this case, classes. This gnu.io namespace is very inconvenient. >>> >>> We feel the same way about lawyers. However I'd like to go into the >>> details of the license (see attachment) if you don't mind? >>> >>> The first license does not apply since RXTX does not use the software. >>> The second one at point 3 specifies our options. >>> >>>> 3. You may not modify the Java Platform Interface ("JPI", identified as >>>> classes contained within the "java" package or any subpackages of the >>>> "java" package), by creating additional classes within the JPI or >>>> otherwise causing the addition to or modification of the classes in the >>>> JPI. >>> >>> RXTX is a extension. >>> >>>> In the event that you create an additional class and associated API(s) >>>> which (i) extends the functionality of the Java platform, and (ii) is >>>> exposed to third party software developers for the purpose of developing >>>> additional software which invokes such additional API, you must promptly >>>> publish broadly an accurate specification for such API for free use by >>>> all developers. >>> >>> That's the way we operate. :) >>> >>>> You may not create, or authorize your licensees to create additional >>>> classes, interfaces, or subpackages that are in any way identified as >>>> "java", "javax", "sun" or similar convention as specified by Sun in any >>>> naming convention designation. >>> >>> They don't want additional components in the Communication API since they >>> don't want a mess in theire namespace. >>> >>> So we *can* use javax.comm for the core: >>> javax.comm.CommDriver >>> javax.comm.CommPort >>> javax.comm.CommPortIdentifier >>> javax.comm.CommPortOwnershipListener >>> javax.comm.NoSuchPortException >>> javax.comm.PortInUseException >>> javax.comm.UnsupportedCommOperationException >>> >>> ...and for the default hardware support: >>> javax.comm.SerialPort >>> javax.comm.SerialPortEvent >>> javax.comm.SerialPortEventListener >>> javax.comm.ParralelPort >>> javax.comm.ParralelPortEvent >>> javax.comm.ParralelPortEventListener >>> >>> ...but RXTX aditional hardware support has to go somewhere else like: >>> org.rxtx.RS485Port >>> org.rxtx.RS485PortEvent >>> org.rxtx.RS485PortEventListener >>> org.rxtx.I2CPort >>> org.rxtx.I2CPortEvent >>> org.rxtx.I2CPortEventListener >>> >>> Right? >> >> The one thing this discussion does not cover is in SerialPort.java. See >> the extensions to commapi listed after the following line: >> >> /* ---------------------- end of commapi ------------------------ */ >> >> The intent is not to break commapi but it could be perceived as so. The >> extensions added have been placed there as requested by users of RXTX. It >> would be nice to discuss these modifications with Sun and perhaps have >> some added to the final version of CommAPI. >> >> Some of them may not make sense while others do. Some can not be >> implemented in a platform neutral fashion. It would not make sense >> for RXTX to just bring these into Sun's namespace without due process. >> >> This is why I am fundamentally apposed to people "poisoning" Sun's >> namespace with RXTX 2.1 although I understand that is not their intent. >> >> These modifications are not advertised and their use is discouraged. But >> they are there. > > Hi Trent, > > So you are saying that gnu.io.SerialPort has some aditional methods over > javax.comm.SerialPort? > That does not change the API at all but it would be a problem if people would > start using those methods in the javax.comm namespace in the same way like > some people use the com.sun namespace. > Could wrapper classes at javax.comm do the job? In that way RXTX stays in its > namespace, javadoc can notice the aditional methods and the Communication API > will be available as expected. Hi Pascal Yes. There are additional methods in gnu.io.SerialPort. We clearly mark those as extensions to CommAPI and discourage their use. There just isn't a way to get the intended functionality out of CommAPI without them. I think the right thing to do here may be to remove these methods to avoid unintentional polution of the javax namespace if people are going to be putting these classes in that namespace. The way people are using RXTX 2.1 is not the same as it was originally pictured. Thats fine but we need to be responsible. We need to prevent what could be a problem. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Mon Jul 10 08:57:10 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 10 Jul 2006 16:57:10 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101447.25071.pascal@quies.net> Message-ID: <200607101657.11223.pascal@quies.net> > Yes. There are additional methods in gnu.io.SerialPort. We clearly mark > those as extensions to CommAPI and discourage their use. There just isn't > a way to get the intended functionality out of CommAPI without them. If you don't want the users to use the methods then make them class protected (remove the word "public" before the method) and if you can't do that we might do the following: ---- SerialPort.java package javax.comm class SerialPort extends gnu.io.SerialPort { public void rxtxOnlyMethod() { throw new Error("Don't use this method here!\nUse gnu.io.SerialPort instead"); } ---- end From neville_seed at yahoo.com Mon Jul 10 10:20:12 2006 From: neville_seed at yahoo.com (neville seed) Date: Mon, 10 Jul 2006 09:20:12 -0700 (PDT) Subject: [Rxtx] writing first application and compiling In-Reply-To: Message-ID: <20060710162012.9888.qmail@web51015.mail.yahoo.com> Can anyone recommend a starting place for writing, compiling and uploading the first app, ie a simple hello world. It seems that the PALM SDK does not have a build environment. I am happy to develop under linux of windows. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From bob_tai2001 at yahoo.com Mon Jul 10 14:48:30 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 10 Jul 2006 13:48:30 -0700 (PDT) Subject: [Rxtx] Java installer Message-ID: <20060710204830.53745.qmail@web32810.mail.mud.yahoo.com> Hi Manuel, I found your post from the newsletter, hope I am not off topic. You mention there is a IZpack installer for Rxtx? I been waiting for this type of deplyment idea from Rxtx! is this documented in the web site? I am in windows environment but didn't want to create classpath for each workstation. I rather install :) I apologize for cutting into this topic. Bob > >Trent, >What I want to send you is not a modification to rxtx, it just a >developers helper if you want to put a name to it. I have make an IzPack installer, which installs RXTX binaries depending on underlaying OS. And make an JSmooth warper that launches my app with out the need to have rxtx installed on the host JVM folder, it only need the RXTX to be in the bin\ of my app. I think this is more useful for Wiki than to the main project. Another thing I have experience in PalmOS programming, when ever I have time, I will investigate about the JNI of J2ME and try to port RXTX to Palm, I do not know when I will start, because I have a lot of work now. Regards, Manuel __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From naranjo.manuel at gmail.com Mon Jul 10 15:10:21 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Mon, 10 Jul 2006 18:10:21 -0300 Subject: [Rxtx] Java installer In-Reply-To: <20060710204830.53745.qmail@web32810.mail.mud.yahoo.com> References: <20060710204830.53745.qmail@web32810.mail.mud.yahoo.com> Message-ID: <44B2C23D.8050901@gmail.com> Bob, Hi, not this is not a RXTX installer, I have develop an installer with IzPack which actually installs RXTX and my hole app, and I think this can be useful for RXTX users, Regards, Manuel > Hi Manuel, > > I found your post from the newsletter, hope I am not > off topic. You mention there is a IZpack installer > for Rxtx? I been waiting for this type of deplyment > idea from Rxtx! is this documented in the web site? > I am in windows environment but didn't want to create > classpath for each workstation. I rather install :) > > I apologize for cutting into this topic. > > Bob > >> Trent, >> What I want to send you is not a modification to > rxtx, it just a >> developers > helper if you want to put a name to it. I have make an > IzPack > installer, > which installs RXTX binaries depending on underlaying > OS. And make an > JSmooth warper that launches my app with out the need > to have rxtx > installed > on the host JVM folder, it only need the RXTX to be in > the bin\ of my > app. > I think this is more useful for Wiki than to the main > project. > Another thing I have experience in PalmOS programming, > when ever I have > time, > I will investigate about the JNI of J2ME and try to > port RXTX to Palm, > I do not know when I will start, because I have a lot > of work now. > Regards, > Manuel > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From brian at mbari.org Tue Jul 11 11:59:24 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 11 Jul 2006 10:59:24 -0700 Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: References: <44AC7902.8070407@adventnet.com> Message-ID: <485C28F0-CA08-4393-9E34-4C8E7F22C125@mbari.org> Hi Trent, On Jul 7, 2006, at 6:15 PM, Trent Jarvi wrote: > On Fri, 7 Jul 2006, Brian Schlining wrote: >> Also, for some command/response applications that I've tried with >> RXTX, I >> find that if I write to the serialport and then immediately try to >> read from >> it I get byte arrays filled with zeros, no matter what I set the >> recieveTimeout to (this has occurred on both Mac OS X and >> Windows). The >> workaround that I found was to very briefly put the I/O thread to >> sleep, like >> so: >> >> // DO set up and get I/O streams >> //in = serialPort.getInputStream(); >> //out = serialPort.getOutputStream(); >> >> out.write(someByteArray); >> try { >> Thread.sleep(10); >> catch (InterruptedException e) { >> // handle exception >> } >> in.read(anotherByteArray); >> >> Note: I've never had to put the thread to sleep using Java comm, >> only with >> RXTX. Anyone know why this might be? > > Hi Brian > > Interesting. Is this something that can be reproduced with a loopback > connection or something commonly available? I was unaware of this > behavior. Is it restricted to something that quickly opens, > writes, reads > and closes the port by chance? I've encountered this while using RXTX to talk to VCR's that support RS422; I've never tried it with a loopback connection. Note that connection setup is: PC[RS232] <---> RS232/422 Converter <---> VCR[RS422] The application I'm using it for opens a connection and keeps it open for the life of the application. It makes a lot of read and writes when running...probably about as fast as the VCR hardware supports; with Javacomm, I think it was on the order of an IO transaction every 40ms. However even if I perform an IO read/write every 2 seconds with RXTX I still encounter the same problem, so it's not a matter of the frequency of the IO transactions. If you want to look at the code a test example can be found at https://svn.sourceforge.net/svnroot/vars/trunk/vars/src/test/java/ test/org/mbari/vcr/SimpleReadRxtx.java. The actual production code is at https://svn.sourceforge.net/svnroot/vars/trunk/vars/src/main/java/ org/mbari/vcr/rs422/VCR.java. The methods that you might be interested in to see how the code is used are initComm(), sendCommand (), getResponse() in VCR.java. You'll notice Thread.sleep(IO_DELAY) sprinkled in the sendCommand() methods and getResponse(). Without that I get arrays of zeros returned. If the IO_DELAY is less than 15ms then sending commands works fine but reading the responses is not reliable; I mostly get problems when trying to read the last few bytes or a response. Again, everything works fine with Sun's Javacomm w/o the Thread.sleep() on windows. Also, FYI, I tried to run this on a Mac using RXTX 2.0, but I ran into thread synchronization issues. These issues went away when I switched to RXTX 2.1. Cheers B ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining MBARI Software Engineer brian at mbari.org (831)775-1855 http://www.mbari.org/staff/brian I went to the woods because I wished to live deliberately, to front only the essential facts of life, and see if I could not learn what it had to teach, and not, when I came to die, discover that I had not lived. ~ Henry Thoreau -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060711/59b607f3/attachment-0354.html From ajmas at sympatico.ca Wed Jul 12 13:46:51 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 12 Jul 2006 15:46:51 -0400 Subject: [Rxtx] writing first application and compiling Message-ID: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Take a look in the Wiki. I have added a couple of examples in there: http://rxtx.qbang.org/wiki/index.php/Examples Andre > > From: neville seed > Date: 2006/07/10 Mon PM 12:20:12 EDT > To: RXTX Developers and Users > Subject: [Rxtx] writing first application and compiling > > > Can anyone recommend a starting place for writing, > compiling and uploading the first app, ie a simple > hello world. > > It seems that the PALM SDK does not have a build > environment. I am happy to develop under linux of windows. > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Jul 12 19:22:25 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 12 Jul 2006 19:22:25 -0600 (MDT) Subject: [Rxtx] writing first application and compiling In-Reply-To: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Thank you for doing this Andre. I'm sure it will get well used by people learning. I think the old commapi examples are no longer easily available so these are really needed. On Wed, 12 Jul 2006, Andre-John Mas wrote: > Hi, > > Take a look in the Wiki. I have added a couple of examples in there: > > http://rxtx.qbang.org/wiki/index.php/Examples > > Andre > >> >> From: neville seed >> Date: 2006/07/10 Mon PM 12:20:12 EDT >> To: RXTX Developers and Users >> Subject: [Rxtx] writing first application and compiling >> >> >> Can anyone recommend a starting place for writing, >> compiling and uploading the first app, ie a simple >> hello world. >> >> It seems that the PALM SDK does not have a build >> environment. I am happy to develop under linux of windows. >> >> __________________________________________________ >> Do You Yahoo!? >> Tired of spam? Yahoo! Mail has the best spam protection around >> http://mail.yahoo.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Thu Jul 13 17:21:26 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Thu, 13 Jul 2006 19:21:26 -0400 Subject: [Rxtx] writing first application and compiling In-Reply-To: References: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <54D55D35-A143-43AA-AF03-B89ADE9B9246@sympatico.ca> No problems. I would also like to encourage anyone else to contribute other useful stuff they might have. On 12-Jul-06, at 21:22 , Trent Jarvi wrote: > > Thank you for doing this Andre. > > I'm sure it will get well used by people learning. I think the old > commapi examples are no longer easily available so these are really > needed. > > On Wed, 12 Jul 2006, Andre-John Mas wrote: > >> Hi, >> >> Take a look in the Wiki. I have added a couple of examples in there: >> >> http://rxtx.qbang.org/wiki/index.php/Examples >> >> Andre >> >>> >>> From: neville seed >>> Date: 2006/07/10 Mon PM 12:20:12 EDT >>> To: RXTX Developers and Users >>> Subject: [Rxtx] writing first application and compiling >>> >>> >>> Can anyone recommend a starting place for writing, >>> compiling and uploading the first app, ie a simple >>> hello world. >>> >>> It seems that the PALM SDK does not have a build >>> environment. I am happy to develop under linux of windows. >>> >>> __________________________________________________ >>> Do You Yahoo!? >>> Tired of spam? Yahoo! Mail has the best spam protection around >>> http://mail.yahoo.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Sat Jul 8 15:05:46 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sat, 08 Jul 2006 17:05:46 -0400 Subject: [Rxtx] License question. In-Reply-To: <200607082219.59514.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> Message-ID: <44B01E2A.9010207@suespammers.org> Pascal S. de Kloe wrote: > I thought of the same thing. The modified BSD license would certainly make it > more eazy and acceptable for Sun to include RXTX in theire products. > > Unfortunately in general people who chose GPL don't like other licenses. ;) i have a general preference for BSD, but i'll defend RXTX here. RXTX is LGPL, not GPL. they're different, look it up. richard From pascal at quies.net Sun Jul 16 17:40:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 17 Jul 2006 01:40:13 +0200 Subject: [Rxtx] Java installer In-Reply-To: <200607101657.11223.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> Message-ID: <200607170140.14116.pascal@quies.net> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: > > Yes. There are additional methods in gnu.io.SerialPort. We clearly mark > > those as extensions to CommAPI and discourage their use. There just > > isn't a way to get the intended functionality out of CommAPI without > > them. > > If you don't want the users to use the methods then make them class > protected (remove the word "public" before the method) and if you can't do > that we might do the following: > > ---- SerialPort.java > package javax.comm > > class SerialPort extends gnu.io.SerialPort { > > public void > rxtxOnlyMethod() { > throw new Error("Don't use this method here!\nUse gnu.io.SerialPort > instead"); > } > ---- end So how about it, Trent? Can we ship those classes with the next release? From pascal at quies.net Sun Jul 16 17:45:42 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 17 Jul 2006 01:45:42 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> References: <200607081944.41123.pascal@quies.net> <200607091701.24661.pascal@quies.net> <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> Message-ID: <200607170145.43156.pascal@quies.net> Op maandag 10 juli 2006 10:53, schreef Joachim Buechse: > Alternatively you could also include the native lib in your > application jar, extract it at runtime to a temp file, load it with > System.load(). That works indeed. :) I'll finish my "detection class" with such a loader and the RXTX package tomorrow. Then one can simply include the JAR in the classpath and run org.rxtx.CommunicationAPI.initialize() to make sure the API is available. From tjarvi at qbang.org Sun Jul 16 18:59:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 16 Jul 2006 18:59:06 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607170140.14116.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> <200607170140.14116.pascal@quies.net> Message-ID: On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>> Yes. There are additional methods in gnu.io.SerialPort. We clearly mark >>> those as extensions to CommAPI and discourage their use. There just >>> isn't a way to get the intended functionality out of CommAPI without >>> them. >> >> If you don't want the users to use the methods then make them class >> protected (remove the word "public" before the method) and if you can't do >> that we might do the following: >> >> ---- SerialPort.java >> package javax.comm >> >> class SerialPort extends gnu.io.SerialPort { >> >> public void >> rxtxOnlyMethod() { >> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >> instead"); >> } >> ---- end > > So how about it, Trent? > > Can we ship those classes with the next release? Hi Pascal I'm not going to say what people can or can not ship. I'm going to propose removing all of the above extensions from SerialPort.java. I think it is the best thing to do after cooling off a bit. But thats all I've considered at this point. I'm in favor of removing the extensions and staying in gnu.io which more importantly means staying at arms length from javax. I can remove the extensions, put a windows fix in, bump the versions and tag the releases without changing packages if everyone agrees to that. If people want to know why CommAPI has not gone through a JSR which makes it clear rxtx can be in javax.comm and explains how conformancy is determined, I do not think this is the right forum though you can freely do so. -- Trent Jarvi tjarvi at qbang.org From phillip at uow.edu.au Sun Jul 16 22:08:30 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Mon, 17 Jul 2006 14:08:30 +1000 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application" in Mac OSX Message-ID: Hi I downloaded RXTX 2.1-7r2 http://rxtx.org/ (latest download), found the MacOSX folder, manually installed RXTXcomm.jar and librxtxSerial.jnilib in / Library/Java/Extensions and manually setup /var/spool/ucp and became a member of it. I have tried two programs (both built in XCode - TwoWaySerialComm and SerialDemo). Both can find the serial ports but throw a 'port in use exception' with the error "Unknown Application" when I try to open the port. The following is part of the code of TwoWaySerialComm void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { System.out.println("Current owner is " + portIdentifier.getCurrentOwner()); System.out.println("Name is " + this.getClass().getName()); CommPort commPort = portIdentifier.open(this.getClass ().getName(),2000); //throws exception if ( commPort instanceof SerialPort ) The method connect is called from main: public static void main ( String[] args ) { try { listPorts(); (new TwoWaySerialComm()).connect("/dev/tty.KeySerial1"); The following is the console run log of a program TwoWaySerialComm [Session started at 2006-07-14 14:50:29 +1000.] Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.modem - Serial /dev/cu.modem - Serial /dev/tty.KeySerial1 - Serial /dev/cu.KeySerial1 - Serial /dev/tty.USA28X2b2P2.2 - Serial /dev/cu.USA28X2b2P2.2 - Serial 6 ports found Current owner is null Name is TwoWaySerialComm gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:48) at TwoWaySerialComm.main(TwoWaySerialComm.java:163) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at apple.launcher.LaunchRunner.run(LaunchRunner.java:88) at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:50) at apple.launcher.JavaApplicationLauncher.launch (JavaApplicationLauncher.java:52) TwoWaySerialComm has exited with status 0. I am stuck, Can you help me please. thanks Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From pascal at quies.net Mon Jul 17 06:12:09 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 17 Jul 2006 14:12:09 +0200 Subject: [Rxtx] JSR In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607170140.14116.pascal@quies.net> Message-ID: <200607171412.09571.pascal@quies.net> Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: > On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > > Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: > >>> Yes. There are additional methods in gnu.io.SerialPort. We clearly > >>> mark those as extensions to CommAPI and discourage their use. There > >>> just isn't a way to get the intended functionality out of CommAPI > >>> without them. > >> > >> If you don't want the users to use the methods then make them class > >> protected (remove the word "public" before the method) and if you can't > >> do that we might do the following: > >> > >> ---- SerialPort.java > >> package javax.comm > >> > >> class SerialPort extends gnu.io.SerialPort { > >> > >> public void > >> rxtxOnlyMethod() { > >> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort > >> instead"); > >> } > >> ---- end > > > > So how about it, Trent? > > > > Can we ship those classes with the next release? > > Hi Pascal > > I'm not going to say what people can or can not ship. I'm going to > propose removing all of the above extensions from SerialPort.java. I > think it is the best thing to do after cooling off a bit. > > But thats all I've considered at this point. I'm in favor of removing the > extensions and staying in gnu.io which more importantly means staying at > arms length from javax. > > I can remove the extensions, put a windows fix in, bump the versions and > tag the releases without changing packages if everyone agrees to that. > If people want to know why CommAPI has not gone through a JSR which makes > it clear rxtx can be in javax.comm and explains how conformancy is > determined, I do not think this is the right forum though you can freely > do so. Hi Trent, If I understand it correctly you don't want to put those javax.comm classes in the distribution until a JSR completes. :( Sun wants a JSR too to change the API: > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. How about it? I can spend 5 hours a week. From tjarvi at qbang.org Mon Jul 17 07:32:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 07:32:06 -0600 (MDT) Subject: [Rxtx] JSR In-Reply-To: <200607171412.09571.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607170140.14116.pascal@quies.net> <200607171412.09571.pascal@quies.net> Message-ID: On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: >> On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: >>> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>>> Yes. There are additional methods in gnu.io.SerialPort. We clearly >>>>> mark those as extensions to CommAPI and discourage their use. There >>>>> just isn't a way to get the intended functionality out of CommAPI >>>>> without them. >>>> >>>> If you don't want the users to use the methods then make them class >>>> protected (remove the word "public" before the method) and if you can't >>>> do that we might do the following: >>>> >>>> ---- SerialPort.java >>>> package javax.comm >>>> >>>> class SerialPort extends gnu.io.SerialPort { >>>> >>>> public void >>>> rxtxOnlyMethod() { >>>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>>> instead"); >>>> } >>>> ---- end >>> >>> So how about it, Trent? >>> >>> Can we ship those classes with the next release? >> >> Hi Pascal >> >> I'm not going to say what people can or can not ship. I'm going to >> propose removing all of the above extensions from SerialPort.java. I >> think it is the best thing to do after cooling off a bit. >> >> But thats all I've considered at this point. I'm in favor of removing the >> extensions and staying in gnu.io which more importantly means staying at >> arms length from javax. >> >> I can remove the extensions, put a windows fix in, bump the versions and >> tag the releases without changing packages if everyone agrees to that. >> If people want to know why CommAPI has not gone through a JSR which makes >> it clear rxtx can be in javax.comm and explains how conformancy is >> determined, I do not think this is the right forum though you can freely >> do so. > > Hi Trent, > > If I understand it correctly you don't want to put those javax.comm classes in > the distribution until a JSR completes. :( > > Sun wants a JSR too to change the API: >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. > > How about it? I can spend 5 hours a week. Yes. I'm all in favor of this. Dr. Doug Lyon is our fearless leader in these matters and has final say. He has asked everyone if they have an issue with going through the JSR. I have seen no responses though some may have responeded to him in private. I am now working for The MathWorks in a related field. To best represent the RXTX community, we have asked Doug to be the neutral maintainer. This does not mean he is taking on all the work like making releases. He has the ability to and the power. But thats not really spending his time efficiently. It does mean when there are decisions to be made that may have conflicts, he has final say. The easy solution :) is to bug Trent or Doug and see if they will just go into javax.comm namespace. The right solution is to work with Doug and try to get the JSR process completed. I'm willing to help too as time permits. I'm willing to work with Doug. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Jul 17 09:11:20 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 17 Jul 2006 11:11:20 -0400 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Message-ID: <20060717151120.RSBG13653.tomts36-srv.bellnexxia.net@smtp1.sympatico.ca> I am told that this is an issue that will be resolved in 2.1-8. The changes are already in version control, so you can use that. I have and it resolved the problem for me. Phillip McKerrow wrote: > > Hi > > I downloaded RXTX 2.1-7r2 http://rxtx.org/ (latest download), > found the MacOSX folder, > manually installed RXTXcomm.jar and librxtxSerial.jnilib in / > Library/Java/Extensions and > manually setup /var/spool/ucp and became a member of it. > > I have tried two programs (both built in XCode - TwoWaySerialComm and > SerialDemo). Both can find the serial ports but throw a 'port in use > exception' with the error "Unknown Application" when I try to open > the port. > > The following is part of the code of TwoWaySerialComm > void connect ( String portName ) throws Exception > { > CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > if ( portIdentifier.isCurrentlyOwned() ) > { > System.out.println("Error: Port is currently in use"); > } > else > { > System.out.println("Current owner is " + > portIdentifier.getCurrentOwner()); > System.out.println("Name is " + this.getClass().getName()); > CommPort commPort = portIdentifier.open(this.getClass > ().getName(),2000); //throws exception > > if ( commPort instanceof SerialPort ) > > > The method connect is called from main: > public static void main ( String[] args ) > { > try > { > listPorts(); > (new TwoWaySerialComm()).connect("/dev/tty.KeySerial1"); > > > The following is the console run log of a program TwoWaySerialComm > [Session started at 2006-07-14 14:50:29 +1000.] > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > /dev/tty.modem - Serial > /dev/cu.modem - Serial > /dev/tty.KeySerial1 - Serial > /dev/cu.KeySerial1 - Serial > /dev/tty.USA28X2b2P2.2 - Serial > /dev/cu.USA28X2b2P2.2 - Serial > 6 ports found > Current owner is null > Name is TwoWaySerialComm > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at TwoWaySerialComm.connect(TwoWaySerialComm.java:48) > at TwoWaySerialComm.main(TwoWaySerialComm.java:163) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at apple.launcher.LaunchRunner.run(LaunchRunner.java:88) > at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:50) > at apple.launcher.JavaApplicationLauncher.launch > (JavaApplicationLauncher.java:52) > > TwoWaySerialComm has exited with status 0. > > I am stuck, Can you help me please. > > thanks > Phillip > > > ---------------------------------------------------------------------- > Phillip McKerrow http:// > www.uow.edu.au/~phillip/ > School of Information Technology and Computer Science > University of Wollongong * > Northfields Avenue, * * > Wollongong, NSW, 2522. + > AUSTRALIA * the land of the > southern cross > tel : +61 2 4221 3771 fax : +61 2 4221 4170 > > God so loved the world that he gave his one and only Son (Jesus), > that whoever believes in him shall not perish but have eternal life. > John 3:16 > ---------------------------------------------------------------------- > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Mon Jul 17 10:34:14 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 17 Jul 2006 12:34:14 -0400 Subject: [Rxtx] summary of issues In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607170140.14116.pascal@quies.net> <200607171412.09571.pascal@quies.net> Message-ID: Hi All, As I see it, at this stage of the discussion, I think it would be helpful to summarize the concerns. Let me see if I can get this straight, and please correct me, if I am wrong: 1. Sun is making no progress on improving the CommAPI spec. 2. We are seeking to reinvigorate a JSR for the CommAPI in order to keep sun involved. 3. Meanwhile we are extending the RXTX API, with non- commAPI improvements. 4. People are worried that the improvements will be non-portable, when the commAPI re-activates. 5. I have asked for feedback on the JSR approach and obtained zero response. 6. My limited imagination does not see any drawback to taking the JSR approach (except, possibly, from the overhead of a committee, or some license issue that I do not understand). 7. http://www.jcp.org/en/jsr/detail?id=922 shows the status of the JSR now. Status: Withdrawn The sun contact is: vincent.zhang at sun.com I have written to Vincent at Sun to ask him what would be involved with reactivation of JSR 922. If I hear back I will let you know. If there are any objections or suggestions, please let me know. Thanks! - Doug >On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > >> Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: >>> On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: >>>> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>>>> Yes. There are additional methods in gnu.io.SerialPort. We clearly >>>>>> mark those as extensions to CommAPI and discourage their use. There >>>>>> just isn't a way to get the intended functionality out of CommAPI >>>>>> without them. >>>>> >>>>> If you don't want the users to use the methods then make them class >>>>> protected (remove the word "public" before the method) and if you can't >>>>> do that we might do the following: >>>>> >>>>> ---- SerialPort.java >>>>> package javax.comm >>>>> >>>>> class SerialPort extends gnu.io.SerialPort { >>>>> >>>>> public void >>>>> rxtxOnlyMethod() { >>>>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>>>> instead"); >>>>> } >>>>> ---- end >>>> >>>> So how about it, Trent? >>>> >>>> Can we ship those classes with the next release? >>> >>> Hi Pascal >>> >>> I'm not going to say what people can or can not ship. I'm going to >>> propose removing all of the above extensions from SerialPort.java. I >>> think it is the best thing to do after cooling off a bit. >>> >>> But thats all I've considered at this point. I'm in favor of removing the >>> extensions and staying in gnu.io which more importantly means staying at >>> arms length from javax. >>> >>> I can remove the extensions, put a windows fix in, bump the versions and >>> tag the releases without changing packages if everyone agrees to that. >>> If people want to know why CommAPI has not gone through a JSR which makes >>> it clear rxtx can be in javax.comm and explains how conformancy is >>> determined, I do not think this is the right forum though you can freely >>> do so. >> >> Hi Trent, >> >> If I understand it correctly you don't want to put those >>javax.comm classes in >> the distribution until a JSR completes. :( >> >> Sun wants a JSR too to change the API: >>> Ultimately the COMMAPI would be better served if a Java >>> Community Process JSR (http://www.jcp.org) was opened and >>> the COMMAPI was rearchitected to provide a more pluggable >>> framework to improve cross-platform support. Such an >>> architecture would embody a better defined and better >>> documented SPI interface, including a way for comm. ports >>> to be revealed to the client application through the API >>> via platform-aware plugins. Similarly, native code used >>> to access comm port in general could be handled more >>> flexibly using a plugin model, whereby on any platform, >>> multiple native modules could be in use simultaneously. >> >> How about it? I can spend 5 hours a week. > >Yes. I'm all in favor of this. Dr. Doug Lyon is our fearless leader in >these matters and has final say. He has asked everyone if they have an >issue with going through the JSR. I have seen no responses though some >may have responeded to him in private. > >I am now working for The MathWorks in a related field. To best represent >the RXTX community, we have asked Doug to be the neutral maintainer. >This does not mean he is taking on all the work like making releases. He >has the ability to and the power. But thats not really spending his time >efficiently. It does mean when there are decisions to be made that may >have conflicts, he has final say. > >The easy solution :) is to bug Trent or Doug and see if they will just go >into javax.comm namespace. The right solution is to work with Doug and >try to get the JSR process completed. I'm willing to help too as time >permits. > >I'm willing to work with Doug. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jul 17 11:31:58 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 17 Jul 2006 13:31:58 -0400 Subject: [Rxtx] JSR Message-ID: <20060717173158.USWI24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> In the meantime could these methods not be added to a child class. This way the extra functionality can be provided, but you would have to explictly check to see of the class is an RXTX specifc interface. For example: class RxTxCommPort extends CommPort { //RxTx specific methods } CommPort port = commPortIdentifierInstance.open(...); if ( port instanceof RxTxCommPort ) { // do RxTx specifc stuff } // continue doing usual stuff Andre > > From: "Pascal S. de Kloe" > Date: 2006/07/17 Mon AM 08:12:09 EDT > To: RXTX Developers and Users > Subject: [Rxtx] JSR > > Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: > > On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > > > Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: > > >>> Yes. There are additional methods in gnu.io.SerialPort. We clearly > > >>> mark those as extensions to CommAPI and discourage their use. There > > >>> just isn't a way to get the intended functionality out of CommAPI > > >>> without them. > > >> > > >> If you don't want the users to use the methods then make them class > > >> protected (remove the word "public" before the method) and if you can't > > >> do that we might do the following: > > >> > > >> ---- SerialPort.java > > >> package javax.comm > > >> > > >> class SerialPort extends gnu.io.SerialPort { > > >> > > >> public void > > >> rxtxOnlyMethod() { > > >> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort > > >> instead"); > > >> } > > >> ---- end > > > > > > So how about it, Trent? > > > > > > Can we ship those classes with the next release? > > > > Hi Pascal > > > > I'm not going to say what people can or can not ship. I'm going to > > propose removing all of the above extensions from SerialPort.java. I > > think it is the best thing to do after cooling off a bit. > > > > But thats all I've considered at this point. I'm in favor of removing the > > extensions and staying in gnu.io which more importantly means staying at > > arms length from javax. > > > > I can remove the extensions, put a windows fix in, bump the versions and > > tag the releases without changing packages if everyone agrees to that. > > If people want to know why CommAPI has not gone through a JSR which makes > > it clear rxtx can be in javax.comm and explains how conformancy is > > determined, I do not think this is the right forum though you can freely > > do so. > > Hi Trent, > > If I understand it correctly you don't want to put those javax.comm classes in > the distribution until a JSR completes. :( > > Sun wants a JSR too to change the API: > > Ultimately the COMMAPI would be better served if a Java > > Community Process JSR (http://www.jcp.org) was opened and > > the COMMAPI was rearchitected to provide a more pluggable > > framework to improve cross-platform support. Such an > > architecture would embody a better defined and better > > documented SPI interface, including a way for comm. ports > > to be revealed to the client application through the API > > via platform-aware plugins. Similarly, native code used > > to access comm port in general could be handled more > > flexibly using a plugin model, whereby on any platform, > > multiple native modules could be in use simultaneously. > > How about it? I can spend 5 hours a week. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From joachim at buechse.de Mon Jul 17 11:59:19 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 17 Jul 2006 19:59:19 +0200 Subject: [Rxtx] Bumping versions In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> <200607170140.14116.pascal@quies.net> Message-ID: <6ABAF770-41AE-4BA0-800D-2DCC8025FCA8@buechse.de> Hello Trent, I would appreciate if we could get to a version 2.1.8. In fact as several recent posting have shown, almost anyone working on OSX would appreciate getting there. Should anything be removed before that? I dont know. There is nothing wrong with having 2.1.9 following shortly after 2.1.8. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 17.07.2006, at 02:59, Trent Jarvi wrote: > On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > >> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>> Yes. There are additional methods in gnu.io.SerialPort. We >>>> clearly mark >>>> those as extensions to CommAPI and discourage their use. There >>>> just >>>> isn't a way to get the intended functionality out of CommAPI >>>> without >>>> them. >>> >>> If you don't want the users to use the methods then make them class >>> protected (remove the word "public" before the method) and if you >>> can't do >>> that we might do the following: >>> >>> ---- SerialPort.java >>> package javax.comm >>> >>> class SerialPort extends gnu.io.SerialPort { >>> >>> public void >>> rxtxOnlyMethod() { >>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>> instead"); >>> } >>> ---- end >> >> So how about it, Trent? >> >> Can we ship those classes with the next release? > > Hi Pascal > > I'm not going to say what people can or can not ship. I'm going to > propose removing all of the above extensions from SerialPort.java. I > think it is the best thing to do after cooling off a bit. > > But thats all I've considered at this point. I'm in favor of > removing the > extensions and staying in gnu.io which more importantly means > staying at > arms length from javax. > > I can remove the extensions, put a windows fix in, bump the > versions and > tag the releases without changing packages if everyone agrees to that. > If people want to know why CommAPI has not gone through a JSR which > makes > it clear rxtx can be in javax.comm and explains how conformancy is > determined, I do not think this is the right forum though you can > freely > do so. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jul 17 12:40:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 12:40:32 -0600 (MDT) Subject: [Rxtx] Bumping versions In-Reply-To: <6ABAF770-41AE-4BA0-800D-2DCC8025FCA8@buechse.de> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> <200607170140.14116.pascal@quies.net> <6ABAF770-41AE-4BA0-800D-2DCC8025FCA8@buechse.de> Message-ID: Hi Joachim I will work with you towards that. I'm going to the Linux Symposium this week which should mean I have time to tinker. I'll work on rxtx while riding in a carpool to Ottawa. On Mon, 17 Jul 2006, Joachim Buechse wrote: > Hello Trent, > > I would appreciate if we could get to a version 2.1.8. In fact as > several recent posting have shown, almost anyone working on OSX would > appreciate getting there. Should anything be removed before that? I > dont know. There is nothing wrong with having 2.1.9 following shortly > after 2.1.8. > > Regards, > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 17.07.2006, at 02:59, Trent Jarvi wrote: > >> On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: >> >>> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>>> Yes. There are additional methods in gnu.io.SerialPort. We >>>>> clearly mark >>>>> those as extensions to CommAPI and discourage their use. There >>>>> just >>>>> isn't a way to get the intended functionality out of CommAPI >>>>> without >>>>> them. >>>> >>>> If you don't want the users to use the methods then make them class >>>> protected (remove the word "public" before the method) and if you >>>> can't do >>>> that we might do the following: >>>> >>>> ---- SerialPort.java >>>> package javax.comm >>>> >>>> class SerialPort extends gnu.io.SerialPort { >>>> >>>> public void >>>> rxtxOnlyMethod() { >>>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>>> instead"); >>>> } >>>> ---- end >>> >>> So how about it, Trent? >>> >>> Can we ship those classes with the next release? >> >> Hi Pascal >> >> I'm not going to say what people can or can not ship. I'm going to >> propose removing all of the above extensions from SerialPort.java. I >> think it is the best thing to do after cooling off a bit. >> >> But thats all I've considered at this point. I'm in favor of >> removing the >> extensions and staying in gnu.io which more importantly means >> staying at >> arms length from javax. >> >> I can remove the extensions, put a windows fix in, bump the >> versions and >> tag the releases without changing packages if everyone agrees to that. >> If people want to know why CommAPI has not gone through a JSR which >> makes >> it clear rxtx can be in javax.comm and explains how conformancy is >> determined, I do not think this is the right forum though you can >> freely >> do so. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pascal at quies.net Mon Jul 17 17:54:56 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Tue, 18 Jul 2006 01:54:56 +0200 Subject: [Rxtx] summary of issues In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> Message-ID: <200607180154.56359.pascal@quies.net> Op maandag 17 juli 2006 18:34, schreef Dr. Douglas Lyon: > Hi All, > As I see it, at this stage of the discussion, I think it would be helpful > to summarize the concerns. Let me see if I can get this > straight, and please correct me, if I am wrong: Thank you. :) > 1. Sun is making no progress on improving the CommAPI spec. > 2. We are seeking to reinvigorate a JSR for the CommAPI in order > to keep sun involved. Sun wants a JSR becouse they have other concerns than a almost obsolete piece of hardware. > 3. Meanwhile we are extending the RXTX API, with non- > commAPI improvements. > 4. People are worried that the improvements will be non-portable, > when the commAPI re-activates. > 5. I have asked for feedback on the JSR approach and obtained > zero response. > 6. My limited imagination does not see any drawback to taking > the JSR approach (except, possibly, from the overhead of a committee, or > some license issue that I do not understand). > 7. http://www.jcp.org/en/jsr/detail?id=922 shows the status of the JSR now. > Status: Withdrawn > The sun contact is: vincent.zhang at sun.com > I have written to Vincent at Sun to ask him what would be involved with > reactivation of JSR 922. We don't need to communicate with the employees but we need a plan. We need a working implementation with a free license. They have offered us some ideas like in the 2.0.3 README (see attachment). Is there a plan based on the differences of the various platforms? Is there a API purposal? Is there a plan of the JNI? If not I am willing to help. I can write/represent the POSIX part with special interrest of the free UNIX systems. -------------- next part -------------- DISTRIBUTION NOTES: This distribution contains the comm.jar file original part of the COMMAPI 2.0.3 release. The 2.0.3 release itself is no longer distributed. comm.jar, which contains the comm API java class files (eg. Sun's binary implementation of the interface classes), is being made available, unsupported, with no obligation to fix bugs, at the request of the RXTX project. The RxTx project (http://www.rxtx.org), uses the comm.jar class files, but provides their own native library components to provide support for other platforms. The 2.0.3 comm.jar is being provided in this way because as of COMMAPI 3.x, the java binary implementation forked and became incompatible with the RxTx project's native code. Due to the lack of a clear business case, and to resource constraints, no additional resources are being provided to provide an alternative engineering solution at the time of writing. RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: Ultimately the COMMAPI would be better served if a Java Community Process JSR (http://www.jcp.org) was opened and the COMMAPI was rearchitected to provide a more pluggable framework to improve cross-platform support. Such an architecture would embody a better defined and better documented SPI interface, including a way for comm. ports to be revealed to the client application through the API via platform-aware plugins. Similarly, native code used to access comm port in general could be handled more flexibly using a plugin model, whereby on any platform, multiple native modules could be in use simultaneously. Since there are now various ways serial ports can be implemented and accessed, modular comm. port JNI native libraries would be of benefit insofar as removing the burden of over-generalization from any single native component, or inversely, by relieving the implicit constraint that comm. drivers be accessed only via a monolithic mechanism, such as the UNIX vnode interface. paul.klissner at sun.com 6/10/06 From tjarvi at qbang.org Mon Jul 17 18:24:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 18:24:47 -0600 (MDT) Subject: [Rxtx] summary of issues In-Reply-To: <200607180154.56359.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607180154.56359.pascal@quies.net> Message-ID: On Tue, 18 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 17 juli 2006 18:34, schreef Dr. Douglas Lyon: >> Hi All, >> As I see it, at this stage of the discussion, I think it would be helpful >> to summarize the concerns. Let me see if I can get this >> straight, and please correct me, if I am wrong: > > Thank you. :) > >> 1. Sun is making no progress on improving the CommAPI spec. >> 2. We are seeking to reinvigorate a JSR for the CommAPI in order >> to keep sun involved. > > Sun wants a JSR becouse they have other concerns than a almost obsolete piece > of hardware. > >> 3. Meanwhile we are extending the RXTX API, with non- >> commAPI improvements. >> 4. People are worried that the improvements will be non-portable, >> when the commAPI re-activates. >> 5. I have asked for feedback on the JSR approach and obtained >> zero response. >> 6. My limited imagination does not see any drawback to taking >> the JSR approach (except, possibly, from the overhead of a committee, or >> some license issue that I do not understand). >> 7. http://www.jcp.org/en/jsr/detail?id=922 shows the status of the JSR now. >> Status: Withdrawn >> The sun contact is: vincent.zhang at sun.com >> I have written to Vincent at Sun to ask him what would be involved with >> reactivation of JSR 922. > > We don't need to communicate with the employees but we need a plan. We need a > working implementation with a free license. They have offered us some ideas > like in the 2.0.3 README (see attachment). > > Is there a plan based on the differences of the various platforms? Is there a > API purposal? Is there a plan of the JNI? > > If not I am willing to help. I can write/represent the POSIX part with special > interrest of the free UNIX systems. > Not to put words in your mouth but it sounds like you would rather not be in javax.comm namespace at all and do something like a VFS for serial ports as suggested in the readme? Maybe call it a VCS for character streams. That sounds like a major version change rather than an incremental change. So a vote for cutting the ropes and floating in the current? rxtx 3.0 or whatever abandoning current application requirements and perhaps largely rewriting rxtx.. Thats possible and could happen at the same time. An email to Vincent sounds polite enough at this stage. -- Trent Jarvi tjarvi at qbang.org From phillip at uow.edu.au Mon Jul 17 19:33:19 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Tue, 18 Jul 2006 11:33:19 +1000 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application in Mac OSX" Message-ID: <7DBE5FEB-EA06-45BC-ABBE-A9990281E32D@uow.edu.au> Hi We found a workaround - Problem fixed by creating /var/lock directory - seems that they changed the directory from /var/spool/uucp for the lock file but didn't update the documentation. audfg5:~ phillip$ sudo mkdir /var/lock Password: audfg5:~ phillip$ ls -ld /var/lock drwxr-xr-x 2 root wheel 68 Jul 18 09:51 /var/lock audfg5:~ phillip$ sudo chmod 775 /var/lock audfg5:~ phillip$ ls -ld /var/lock drwxrwxr-x 2 root wheel 68 Jul 18 09:51 /var/lock audfg5:~ phillip$ sudo chgrp uucp /var/lock audfg5:~ phillip$ ls -ld /var/lock drwxrwxr-x 2 root uucp 68 Jul 18 09:51 /var/lock audfg5:~ phillip$ ls -l /var/lock total 8 -r--r--r-- 1 phillip uucp 11 Jul 18 09:58 LK.003.009.002 Now both programs work and we get a warning on the console: RXTX Warning: Removing stale lock file. /var/lock/LK.003.009.002 Do we still need the /var/spool/uucp directory?? thanks Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From tjarvi at qbang.org Mon Jul 17 19:40:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 19:40:26 -0600 (MDT) Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application in Mac OSX" In-Reply-To: <7DBE5FEB-EA06-45BC-ABBE-A9990281E32D@uow.edu.au> References: <7DBE5FEB-EA06-45BC-ABBE-A9990281E32D@uow.edu.au> Message-ID: On Tue, 18 Jul 2006, Phillip McKerrow wrote: > Hi > We found a workaround - Problem fixed by creating /var/lock directory > - seems that they changed the directory from /var/spool/uucp for the > lock file but didn't update the documentation. > > audfg5:~ phillip$ sudo mkdir /var/lock > Password: > audfg5:~ phillip$ ls -ld /var/lock > drwxr-xr-x 2 root wheel 68 Jul 18 09:51 /var/lock > audfg5:~ phillip$ sudo chmod 775 /var/lock > audfg5:~ phillip$ ls -ld /var/lock > drwxrwxr-x 2 root wheel 68 Jul 18 09:51 /var/lock > audfg5:~ phillip$ sudo chgrp uucp /var/lock > audfg5:~ phillip$ ls -ld /var/lock > drwxrwxr-x 2 root uucp 68 Jul 18 09:51 /var/lock > audfg5:~ phillip$ ls -l /var/lock > total 8 > -r--r--r-- 1 phillip uucp 11 Jul 18 09:58 LK.003.009.002 > > Now both programs work and we get a warning on the console: > RXTX Warning: Removing stale lock file. /var/lock/LK.003.009.002 > > Do we still need the /var/spool/uucp directory?? > [The new code in CVS will not use Lockfiles on Mac OS X.] The above can happen if you did not close the port before exiting the program. The warning is harmless. RXTX notes that the old program is not running and removes the stale lockfile. -- Trent Jarvi tjarvi at qbang.org From phillip at uow.edu.au Tue Jul 18 01:07:40 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Tue, 18 Jul 2006 17:07:40 +1000 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX Message-ID: Hi I am trying to run a precompiled Java program (JavaKit for setting up the TINI processor over a serial link from http://www.maxim-ic.com/ products/tini/software/downloads.cfm). It uses javax.comm for serial communication. 1. I downloaded the Sparc Solaris version of comm.jar and placed it in /Library/Java/Extensions with RXTXcomm.jar and librxtxSerial.jnilib. 2. I added a javax.com.properties file to /System/Library/Frameworks/ JavaVM.framework/Versions/CurrentJDK/Home/lib It is a text file with one line Driver=gnu.io.RXTXCommDriver 3. When I execute JavaKit it crashes with the following console output audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver (CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:109) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Exception in thread "main" java.lang.UnsatisfiedLinkError: isSessionActive at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts (Portmapping.java:155) at com.sun.comm.Portmapping.refreshPortDatabase (Portmapping.java:100) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:138) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ Home/lib/ext instead of /Library/Java/Extensions it makes no difference: If I use the generic version of comm,jar file from Sun, JavaKit brings up a gui but can't find the serial ports: The console output is: audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while loading driver gnu.io.RXTXCommDriver Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no SolarisSerialParallel in java.library.path Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while loading driver com.sun.comm.SolarisDriver Am I doing something wrong in my efforts to get this going? Should I have another file loaded somewhere or have I run into a bug in RXTX?? thanks again for your help. Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From joachim at buechse.de Tue Jul 18 02:53:38 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 18 Jul 2006 10:53:38 +0200 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: References: Message-ID: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> 2.1.7 is the gnu.io.* version. You need 2.0.7 ie the javax.comm.* version. --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 18.07.2006, at 09:07, Phillip McKerrow wrote: > Hi > > I am trying to run a precompiled Java program (JavaKit for setting up > the TINI processor over a serial link from http://www.maxim-ic.com/ > products/tini/software/downloads.cfm). It uses javax.comm for serial > communication. > > 1. I downloaded the Sparc Solaris version of comm.jar and placed it > in /Library/Java/Extensions with RXTXcomm.jar and > librxtxSerial.jnilib. > > 2. I added a javax.com.properties file to /System/Library/Frameworks/ > JavaVM.framework/Versions/CurrentJDK/Home/lib > It is a text file with one line > Driver=gnu.io.RXTXCommDriver > > 3. When I execute JavaKit it crashes with the following console output > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver > (CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:109) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > Exception in thread "main" java.lang.UnsatisfiedLinkError: > isSessionActive > at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > at com.sun.comm.Portmapping.registerCommPorts > (Portmapping.java:155) > at com.sun.comm.Portmapping.refreshPortDatabase > (Portmapping.java:100) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:138) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > > If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ > Home/lib/ext > instead of /Library/Java/Extensions it makes no difference: > > If I use the generic version of comm,jar file from Sun, JavaKit > brings up a gui but can't find the serial ports: The console > output is: > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while > loading driver gnu.io.RXTXCommDriver > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no > SolarisSerialParallel in java.library.path > Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while > loading driver com.sun.comm.SolarisDriver > > > Am I doing something wrong in my efforts to get this going? Should I > have another file loaded somewhere or have I run into a bug in RXTX?? > > thanks again for your help. > > Phillip > > > ---------------------------------------------------------------------- > Phillip McKerrow http:// > www.uow.edu.au/~phillip/ > School of Information Technology and Computer Science > University of Wollongong * > Northfields Avenue, * * > Wollongong, NSW, 2522. + > AUSTRALIA * the land of the > southern cross > tel : +61 2 4221 3771 fax : +61 2 4221 > 4170 > > God so loved the world that he gave his one and only Son (Jesus), > that whoever believes in him shall not perish but have eternal life. > John 3:16 > ---------------------------------------------------------------------- > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alex at det.ua.pt Tue Jul 18 03:29:15 2006 From: alex at det.ua.pt (Alexandre Mota) Date: Tue, 18 Jul 2006 10:29:15 +0100 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: Message-ID: Hello Edit the JavaKit.java in order to use the gnu.io and compile everything. If you have the RXTX already installed and working it will work. I am using it on linux and windows with jdk 1.5. Best Regards Alexandre -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Phillip McKerrow Sent: ter?a-feira, 18 de Julho de 2006 8:08 To: rxtx at qbang.org Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX Hi I am trying to run a precompiled Java program (JavaKit for setting up the TINI processor over a serial link from http://www.maxim-ic.com/ products/tini/software/downloads.cfm). It uses javax.comm for serial communication. 1. I downloaded the Sparc Solaris version of comm.jar and placed it in /Library/Java/Extensions with RXTXcomm.jar and librxtxSerial.jnilib. 2. I added a javax.com.properties file to /System/Library/Frameworks/ JavaVM.framework/Versions/CurrentJDK/Home/lib It is a text file with one line Driver=gnu.io.RXTXCommDriver 3. When I execute JavaKit it crashes with the following console output audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver (CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:109) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Exception in thread "main" java.lang.UnsatisfiedLinkError: isSessionActive at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts (Portmapping.java:155) at com.sun.comm.Portmapping.refreshPortDatabase (Portmapping.java:100) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:138) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ Home/lib/ext instead of /Library/Java/Extensions it makes no difference: If I use the generic version of comm,jar file from Sun, JavaKit brings up a gui but can't find the serial ports: The console output is: audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while loading driver gnu.io.RXTXCommDriver Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no SolarisSerialParallel in java.library.path Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while loading driver com.sun.comm.SolarisDriver Am I doing something wrong in my efforts to get this going? Should I have another file loaded somewhere or have I run into a bug in RXTX?? thanks again for your help. Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jul 18 04:52:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 18 Jul 2006 04:52:02 -0600 (MDT) Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: References: Message-ID: On Tue, 18 Jul 2006, Phillip McKerrow wrote: > Hi > > I am trying to run a precompiled Java program (JavaKit for setting up > the TINI processor over a serial link from http://www.maxim-ic.com/ > products/tini/software/downloads.cfm). It uses javax.comm for serial > communication. > > 1. I downloaded the Sparc Solaris version of comm.jar and placed it > in /Library/Java/Extensions with RXTXcomm.jar and > librxtxSerial.jnilib. > > 2. I added a javax.com.properties file to /System/Library/Frameworks/ > JavaVM.framework/Versions/CurrentJDK/Home/lib > It is a text file with one line > Driver=gnu.io.RXTXCommDriver > > 3. When I execute JavaKit it crashes with the following console output > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver > (CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:109) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > Exception in thread "main" java.lang.UnsatisfiedLinkError: > isSessionActive > at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > at com.sun.comm.Portmapping.registerCommPorts > (Portmapping.java:155) > at com.sun.comm.Portmapping.refreshPortDatabase > (Portmapping.java:100) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:138) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > > If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ > Home/lib/ext > instead of /Library/Java/Extensions it makes no difference: > > If I use the generic version of comm,jar file from Sun, JavaKit > brings up a gui but can't find the serial ports: The console output is: > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while > loading driver gnu.io.RXTXCommDriver > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no > SolarisSerialParallel in java.library.path > Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while > loading driver com.sun.comm.SolarisDriver > > > Am I doing something wrong in my efforts to get this going? Should I > have another file loaded somewhere or have I run into a bug in RXTX?? > > thanks again for your help. > RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for that. Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Tue Jul 18 16:14:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 18 Jul 2006 18:14:38 -0400 Subject: [Rxtx] jcp and jsr In-Reply-To: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> References: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> Message-ID: Hi All, I have been in touch with: Paul Klissner Please read what Paul writes below. I am not sure, but this might be a good chance for the RXTX group to take action. As to what we should write for the JSR, I am thinking about something in the javax.comm namespace. What is the collective feeling about that? Thanks! - Doug Paul writes: "I think a JSR should be opened, but I don't see any point in proceeding with 922, which never formed and expert group, or provided a specification or reference implementation. It was a placeholder, and the title wasn't even relevant. I think we should discuss our ideas about what we'd like to accomplish and javax.comm and see if we can reach an agreement. You would submit a JSR through the Java Community Process, and if you do, I'd like to represent Sun on the expert group, and contribute to the effort. We may want to start with a fresh specification, borrowing what we want from the current javax.com, adding what we need, and creating a reference implementation. Paul" From pascal at quies.net Tue Jul 18 18:12:26 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 02:12:26 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> Message-ID: <200607190212.27131.pascal@quies.net> Hi Dr., The namespace is the last thing we need to worry about. Let's start with the common goals. For instance the current API is not very object oriented. It might be a good idea to have a static set of objects available representing every supported port available on the system in realtime. Each object should clearly know its own state and its capabilities. To get a port there could be a method like synchronized void connect(PortUser) where PortUser is a interface which handles the interaction with a input and a output stream and listers like PortStillAvailableListener, PortBufferListener and a DataAvailableListener. What is the collective feeling about that? Op woensdag 19 juli 2006 00:14, schreef Dr. Douglas Lyon: > Hi All, > I have been in touch with: > Paul Klissner > Please read what Paul writes below. > I am not sure, but this might be a good chance for > the RXTX group to take action. > As to what we should write for the JSR, I am thinking > about something in the javax.comm namespace. > What is the collective feeling about that? > Thanks! > - Doug > > Paul writes: > "I think a JSR should be opened, but I don't see any point > in proceeding with 922, which never formed and expert group, > or provided a specification or reference implementation. > It was a placeholder, and the title wasn't even relevant. > > I think we should discuss our ideas about what we'd like > to accomplish and javax.comm and see if we can reach an > agreement. > > You would submit a JSR through the Java Community Process, > and if you do, I'd like to represent Sun on the expert group, > and contribute to the effort. We may want to start with > a fresh specification, borrowing what we want from the > current javax.com, adding what we need, and creating > a reference implementation. From phillip at uow.edu.au Tue Jul 18 23:44:25 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Wed, 19 Jul 2006 15:44:25 +1000 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application in Mac OSX" Message-ID: <7EEF3F56-A406-4532-BB3D-AA642A4818CA@uow.edu.au> > > Do we still need the /var/spool/uucp directory?? > > >> Trent Jarvi wrote >>[The new code in CVS will not use Lockfiles on Mac OS X.] Great, that should make installation easier. When will the next version be released? Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From phillip at uow.edu.au Wed Jul 19 00:14:26 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Wed, 19 Jul 2006 16:14:26 +1000 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: References: Message-ID: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> > > Edit the JavaKit.java in order to use the gnu.io and compile > everything. > > Alexandre > Unfotunately all I have is a .jar that contains it. I haven't found the source on their web site. > From: Joachim Buechse > 2.1.7 is the gnu.io.* version. You need 2.0.7 ie the javax.comm.* > version. > > RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for > that. > > Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. > > Trent Jarv I found the rxtx download page and downloaded rxtx-2.0-7pre1 (source/ Mac) The Install folder in ForPackageMaker has librxtxSerial.jnilib and java.com.properties but instead of RXTXComm.jar it has jcl.jar (I have no idea what is is for - it doesn't seem to be a replacement for RXTXCom.jar) I tried to run the XCode project to build it but there is a syntax error - nativeSetSerialPortParams returns a void not a jboolean. Also, there is no target to make RXTXComm.jar JNIEXPORT void JNICALL Java_gnu_io_RXTXPort_nativeSetSerialPortParams (JNIEnv *, jobject, jint, jint, jint, jint); Can you tell me where to find either a working copy of 2.0 for Mac OSX, or RXTXComm.jar or a working XCode project for Version 2. This is getting very frustrating. thanks Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From joachim at buechse.de Wed Jul 19 01:17:03 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 19 Jul 2006 09:17:03 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607190212.27131.pascal@quies.net> References: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> <200607190212.27131.pascal@quies.net> Message-ID: <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> The static objects will work for Windows and Linux, however for OSX they will create problems: - ports can appear and disappear at any time with VCP drivers for USB - the port names are not known until the usb-port is "plugged in" Please do not forget that tty ports can be opened by several applications concurrently. All of those will "loose" the port if anyone opens the corresponding cu port. As this naming based mechanism does not exist on Windows (maybe it does via an API) it should probably be reflected in the API. In other words there are "two levels of open": - Open for reading status lines (1) - Open for reading/writing data (2) I am not sure if state (1) should also allow the modification of certain status lines (ie to set a modem ready). I am also not sure if the api should unify corresponding cu. and tty. ports into one single port. Regards, Joachim On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: > For instance the current API is not very object oriented. > It might be a good idea to have a static set of objects available > representing > every supported port available on the system in realtime. Each > object should > clearly know its own state and its capabilities. To get a port > there could be > a method like synchronized void connect(PortUser) where PortUser is a > interface which handles the interaction with a input and a output > stream and > listers like PortStillAvailableListener, PortBufferListener and a > DataAvailableListener. > > What is the collective feeling about that? From joachim at buechse.de Wed Jul 19 01:29:53 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 19 Jul 2006 09:29:53 +0200 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> References: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> Message-ID: <2D32167B-3830-41D6-9FDD-462301F0453F@buechse.de> As you have already downloaded the source, just cd into the main folder and do a "cvs up -d" this will remove some outdated files and create a new XCode project which should compile without problems. You may also want to search the mail archive or checkout README.OSX for my suggestion on how to avoid the javax.comm.properties file by creating a class com.sun.comm.SolarisDriver. Regards, Joachim PS: I can feel your pain... it was the same for me. In fact I never understood why there are different native or java implementations for 2.0 and 2.1. The two versions could easily be unified by using the simplest of OO programing (intermediate abstract classes). But I guess at the time of branching the direction was not clear. Also the licences are not the same... On 19.07.2006, at 08:14, Phillip McKerrow wrote: >> RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for >> that. >> >> Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. >> >> Trent Jarv > > I found the rxtx download page and downloaded rxtx-2.0-7pre1 (source/ > Mac) > > The Install folder in ForPackageMaker has librxtxSerial.jnilib and > java.com.properties but instead of RXTXComm.jar it has jcl.jar (I > have no idea what is is for - it doesn't seem to be a replacement for > RXTXCom.jar) > > I tried to run the XCode project to build it but there is a syntax > error - nativeSetSerialPortParams returns a void not a jboolean. > Also, there is no target to make RXTXComm.jar > > JNIEXPORT void JNICALL Java_gnu_io_RXTXPort_nativeSetSerialPortParams > (JNIEnv *, jobject, jint, jint, jint, jint); > > Can you tell me where to find either a working copy of 2.0 for Mac > OSX, or RXTXComm.jar or a working XCode project for Version 2. This > is getting very frustrating. > > thanks > > Phillip > > ---------------------------------------------------------------------- > Phillip McKerrow http:// > www.uow.edu.au/~phillip/ > School of Information Technology and Computer Science > University of Wollongong * > Northfields Avenue, * * > Wollongong, NSW, 2522. + > AUSTRALIA * the land of the > southern cross > tel : +61 2 4221 3771 fax : +61 2 4221 > 4170 > > God so loved the world that he gave his one and only Son (Jesus), > that whoever believes in him shall not perish but have eternal life. > John 3:16 > ---------------------------------------------------------------------- > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alex at det.ua.pt Wed Jul 19 03:02:40 2006 From: alex at det.ua.pt (Alexandre Mota) Date: Wed, 19 Jul 2006 10:02:40 +0100 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> References: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> Message-ID: <44BDF530.5080502@det.ua.pt> Phillip McKerrow wrote: >>Edit the JavaKit.java in order to use the gnu.io and compile >>everything. >> >>Alexandre >> >> >> >Unfotunately all I have is a .jar that contains it. I haven't found >the source on their web site. > > > > Download http://files.dalsemi.com/pub/tini/tini1_17.tgz Decompress it and you will find the JavaKiTSrc.jar in the src dir. Decompress it with jar -xf JavaKitSrc.jar and you will get all the source files you need. Alexandre PS: Remenber that puting JavaKit into work is allways a pain... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060719/f5172a01/attachment-0347.html From lyon at docjava.com Wed Jul 19 05:27:47 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 19 Jul 2006 07:27:47 -0400 Subject: [Rxtx] RXTX binary for mac In-Reply-To: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> References: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> Message-ID: Hi All, I have some older RXTX binaries that are deployed in a webstart application. You can try it with: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp The libs are signed and packed for webstart disto by me. http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/ Shows them. - DL > > >> Edit the JavaKit.java in order to use the gnu.io and compile? >> everything. >> >> Alexandre >> >Unfotunately all I have is a .jar that contains it. I haven't found? >the source on their web site. > > >> From: Joachim Buechse >> 2.1.7 is the gnu.io.* version. You need 2.0.7 ie the javax.comm.* >> version. >> > >> RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for? >> that. >> >> Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. >> >> Trent Jarv > >I found the rxtx download page and downloaded rxtx-2.0-7pre1 (source/ >Mac) > >The Install folder in ForPackageMaker has librxtxSerial.jnilib and? >java.com.properties but instead of RXTXComm.jar it has jcl.jar (I? >have no idea what is is for - it doesn't seem to be a replacement for? >RXTXCom.jar) > >I tried to run the XCode project to build it but there is a syntax? >error - nativeSetSerialPortParams returns a void not a jboolean.?? >Also, there is no target to make RXTXComm.jar > >JNIEXPORT void JNICALL Java_gnu_io_RXTXPort_nativeSetSerialPortParams > (JNIEnv *, jobject, jint, jint, jint, jint); > >Can you tell me where to find either a working copy of 2.0 for Mac? >OSX, or RXTXComm.jar or a working XCode project for Version 2. This? >is getting very frustrating. > >thanks > >Phillip > >---------------------------------------------------------------------- >Phillip McKerrow http:// >www.uow.edu.au/~phillip/ >School of Information Technology and Computer Science >University of Wollongong * >Northfields Avenue, * * >Wollongong, NSW, 2522. + >AUSTRALIA * the land of the? >southern cross >tel : +61 2 4221 3771 fax : +61 2 4221 4170 > >God so loved the world that he gave his one and only Son (Jesus), >that whoever believes in him shall not perish but have eternal life. >John 3:16 >---------------------------------------------------------------------- > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Wed Jul 19 06:11:27 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 14:11:27 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> Message-ID: <200607191411.27566.pascal@quies.net> Hi Joachim, Thanks for the constructive critisism. :) Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: > The static objects will work for Windows and Linux, however for OSX > they will create problems: > - ports can appear and disappear at any time with VCP drivers for USB > - the port names are not known until the usb-port is "plugged in" Ports can appear and disappear on *any* OS with USB support. Some Linux distributions even create and remove devicefiles on the fly. With the current API you fetch a list of all available ports and then you try to cast one. What happens if the port is no longer available at that time? What happens if a port vanishes during the data transfer? Of course you can catch exceptions but that makes the code quite messy. The idea was to get a PortStillAvailableListener interface. In that way the implementation is free to handle a cleanup or wait for return routine in a OO way. The I/O streams should just lock. The word static was not ment as persistent but as Java static available. Considder the following: java.lang.hw.HardwareConfiguration { public enum PortType { RS232, I2C, etc. }; /** Gets the currently available ports of type {@code PortType}. */ public static java.lang.hw.Port[] getPorts(PortType); } com.example.Driver implements PortUser, implements PortStillAvailableListener { public portNoLongerAvailable(PortEvent event) { // cleanup & dismiss. } } com.example.Application { public static void main(String[] args) { Driver someDriver = new Driver(); Port radomPort = HardwareConfiguration.getPorts( HardwareConfiguration.PortType.RS232)[1]; myDevice.addStillAvailableListener(someDriver); myDevice.connect(someDriver); } } > Please do not forget that tty ports can be opened by several > applications concurrently. All of those will "loose" the port if > anyone opens the corresponding cu port. Indeed we need a good overview of the differences between the various platforms. Should we create a document or a Wiki for this purpose? FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: http://www.openbsd.org/cgi-bin/man.cgi?query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html Linux uses /var/lock: http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES Is there absolutely no way to get a lock under Windows? > As this naming based > mechanism does not exist on Windows (maybe it does via an API) it > should probably be reflected in the API. In other words there are > "two levels of open": > > - Open for reading status lines (1) > - Open for reading/writing data (2) > > I am not sure if state (1) should also allow the modification of > certain status lines (ie to set a modem ready). I'm not sure I understand. Do you mean canonical and noncanonical mode? How far is Windows with the canonical mode. Is it comparable to POSIX? > I am also not sure if > the api should unify corresponding cu. and tty. ports into one single > port. I think the API should hide low-level details like devicefiles. Who is participating anyway? Is it just the four of us? Cheers, Pascal > On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: > > For instance the current API is not very object oriented. > > It might be a good idea to have a static set of objects available > > representing > > every supported port available on the system in realtime. Each > > object should > > clearly know its own state and its capabilities. To get a port > > there could be > > a method like synchronized void connect(PortUser) where PortUser is a > > interface which handles the interaction with a input and a output > > stream and > > listers like PortStillAvailableListener, PortBufferListener and a > > DataAvailableListener. > > > > What is the collective feeling about that? From joachim at buechse.de Wed Jul 19 07:09:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 19 Jul 2006 15:09:27 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191411.27566.pascal@quies.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> Message-ID: <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> Pascal, I think that the PortNoLongerAvailableListener creates more problems than it solves. I think that exceptions are much better suited for this case. There might be an additional method "Port.isOpen" or "Port.isAvailable" which interested applications may call at times best suited. Most implementations will only find out, that a port disappeared when trying to read or write. Anything else would require polling with a high frequency or kernel hooks that do not exist (in POSIX). Any kind of call back like portNoLongerAvailable() creates the risk of deadlocks and races which require an involved implementation as the library does not know what it is calling (ie a user might try to call close from the callback which can block a very long time). Callbacks introduce concurrency which unneccessarily increases the complexity. Regards, Joachim On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: > Hi Joachim, > > Thanks for the constructive critisism. :) > > Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >> The static objects will work for Windows and Linux, however for OSX >> they will create problems: >> - ports can appear and disappear at any time with VCP drivers for USB >> - the port names are not known until the usb-port is "plugged in" > > Ports can appear and disappear on *any* OS with USB support. Some > Linux > distributions even create and remove devicefiles on the fly. > > With the current API you fetch a list of all available ports and > then you try > to cast one. What happens if the port is no longer available at > that time? > What happens if a port vanishes during the data transfer? Of course > you can > catch exceptions but that makes the code quite messy. > > The idea was to get a PortStillAvailableListener interface. In that > way the > implementation is free to handle a cleanup or wait for return > routine in a OO > way. The I/O streams should just lock. > > The word static was not ment as persistent but as Java static > available. > Considder the following: > > java.lang.hw.HardwareConfiguration { > public enum PortType { RS232, I2C, etc. }; > > /** Gets the currently available ports of type {@code PortType}. */ > public static java.lang.hw.Port[] getPorts(PortType); > } > > com.example.Driver implements PortUser, implements > PortStillAvailableListener > { > public portNoLongerAvailable(PortEvent event) { > // cleanup & dismiss. > } > } > > com.example.Application { > public static void main(String[] args) { > Driver someDriver = new Driver(); > Port radomPort = HardwareConfiguration.getPorts( > HardwareConfiguration.PortType.RS232)[1]; > myDevice.addStillAvailableListener(someDriver); > myDevice.connect(someDriver); > } > } > >> Please do not forget that tty ports can be opened by several >> applications concurrently. All of those will "loose" the port if >> anyone opens the corresponding cu port. > > Indeed we need a good overview of the differences between the various > platforms. Should we create a document or a Wiki for this purpose? > > FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: > http://www.openbsd.org/cgi-bin/man.cgi? > query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD > +Current&arch=i386&format=html > > Linux uses /var/lock: > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > Is there absolutely no way to get a lock under Windows? > >> As this naming based >> mechanism does not exist on Windows (maybe it does via an API) it >> should probably be reflected in the API. In other words there are >> "two levels of open": >> >> - Open for reading status lines (1) >> - Open for reading/writing data (2) >> >> I am not sure if state (1) should also allow the modification of >> certain status lines (ie to set a modem ready). > > I'm not sure I understand. Do you mean canonical and noncanonical > mode? > > How far is Windows with the canonical mode. Is it comparable to POSIX? > >> I am also not sure if >> the api should unify corresponding cu. and tty. ports into one single >> port. > > I think the API should hide low-level details like devicefiles. > > > Who is participating anyway? Is it just the four of us? > > Cheers, > > Pascal > > >> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>> For instance the current API is not very object oriented. >>> It might be a good idea to have a static set of objects available >>> representing >>> every supported port available on the system in realtime. Each >>> object should >>> clearly know its own state and its capabilities. To get a port >>> there could be >>> a method like synchronized void connect(PortUser) where PortUser >>> is a >>> interface which handles the interaction with a input and a output >>> stream and >>> listers like PortStillAvailableListener, PortBufferListener and a >>> DataAvailableListener. >>> >>> What is the collective feeling about that? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Wed Jul 19 08:33:08 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Wed, 19 Jul 2006 11:33:08 -0300 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191411.27566.pascal@quies.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> Message-ID: <44BE42A4.3030203@gmail.com> > Linux uses /var/lock: > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > Is there absolutely no way to get a lock under Windows? Indeed Windows block ports when someone open ones. Java Comm could manage this feature. > Who is participating anyway? Is it just the four of us? I can help too. Regards, Manuel From pascal at quies.net Wed Jul 19 09:01:17 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 17:01:17 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> References: <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> Message-ID: <200607191701.17607.pascal@quies.net> In the POSIX world things are simple. If any transaction fails with ENOTTY we lock the I/O streams and create a PortNoLongerAvailableEvent. We *might* even go so far as to start a thread which polls the tty say once a second afther a PortNoLongerAvailableEvent and kill it if there is succes with a PortAvailableAgainEvent but there won't be anything like deadlocks and races. I promise. ;) Methods like isOpen and isAvailable require polling which is exactly what we both don't want and they can't be reliable since it is a moment. A clean sepparation of the functional code and Listeners for events makes the code better readable and more flexible. PS If OS X has a notification system for changes in the available ports this OS specific functionality is more simple to implement too. Op woensdag 19 juli 2006 15:09, schreef Joachim Buechse: > Pascal, > > I think that the PortNoLongerAvailableListener creates more problems > than it solves. > > I think that exceptions are much better suited for this case. There > might be an additional method "Port.isOpen" or "Port.isAvailable" > which interested applications may call at times best suited. > > Most implementations will only find out, that a port disappeared when > trying to read or write. Anything else would require polling with a > high frequency or kernel hooks that do not exist (in POSIX). Any kind > of call back like portNoLongerAvailable() creates the risk of > deadlocks and races which require an involved implementation as the > library does not know what it is calling (ie a user might try to call > close from the callback which can block a very long time). Callbacks > introduce concurrency which unneccessarily increases the complexity. > > Regards, > Joachim From jredman at ergotech.com Wed Jul 19 09:20:39 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 09:20:39 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191411.27566.pascal@quies.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> Message-ID: <44BE4DC7.7@ergotech.com> Pascal S. de Kloe wrote: >> I am also not sure if >> the api should unify corresponding cu. and tty. ports into one single >> port. > > I think the API should hide low-level details like devicefiles. Not all ports have device files. It's long been my goal to add support for virtual serial ports, that is, serial ports on Ethernet terminal servers, for example integrating RFC2217. This means that the port name is some combination of an IP address and TCP port number. Nothing in /dev. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From brian at mbari.org Wed Jul 19 10:04:51 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 19 Jul 2006 09:04:51 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BE42A4.3030203@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <44BE42A4.3030203@gmail.com> Message-ID: <5FDA8DB5-FD08-4EAA-81A7-C46A7CF6FA18@mbari.org> >> Who is participating anyway? Is it just the four of us? > I'm not much of a POSIX or C guy. But I do a lot of OO design. I'm happy to throw my 2 cents in too. Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060719/404de230/attachment-0346.html From pascal at quies.net Wed Jul 19 10:16:16 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 18:16:16 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BE4DC7.7@ergotech.com> References: <200607191411.27566.pascal@quies.net> <44BE4DC7.7@ergotech.com> Message-ID: <200607191816.17099.pascal@quies.net> Op woensdag 19 juli 2006 17:20, schreef Jim Redman: > Pascal S. de Kloe wrote: > >> I am also not sure if > >> the api should unify corresponding cu. and tty. ports into one single > >> port. > > > > I think the API should hide low-level details like devicefiles. > > Not all ports have device files. It's long been my goal to add support > for virtual serial ports, that is, serial ports on Ethernet terminal > servers, for example integrating RFC2217. This means that the port name > is some combination of an IP address and TCP port number. Nothing in /dev. > > Jim This idea doesn't need any native calls at all, right? How would you like to realize that? Jini? I'm sure you knew that the server is already there: http://www.viara.cn/en/jts.htm From pascal at quies.net Wed Jul 19 10:17:12 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 18:17:12 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <5FDA8DB5-FD08-4EAA-81A7-C46A7CF6FA18@mbari.org> References: <44BE42A4.3030203@gmail.com> <5FDA8DB5-FD08-4EAA-81A7-C46A7CF6FA18@mbari.org> Message-ID: <200607191817.12769.pascal@quies.net> Op woensdag 19 juli 2006 18:04, schreef Brian Schlining: > >> Who is participating anyway? Is it just the four of us? > > I'm not much of a POSIX or C guy. But I do a lot of OO design. I'm > happy to throw my 2 cents in too. > > Brian Schlining > Software Engineer > http://www.mbari.org Excellent! :) We need a lot of opinions from all kinds of users. From jredman at ergotech.com Wed Jul 19 10:54:18 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 10:54:18 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191816.17099.pascal@quies.net> References: <200607191411.27566.pascal@quies.net> <44BE4DC7.7@ergotech.com> <200607191816.17099.pascal@quies.net> Message-ID: <44BE63BA.9090905@ergotech.com> Pascal, Pascal S. de Kloe wrote: > Op woensdag 19 juli 2006 17:20, schreef Jim Redman: >> Pascal S. de Kloe wrote: >>>> I am also not sure if >>>> the api should unify corresponding cu. and tty. ports into one single >>>> port. >>> I think the API should hide low-level details like devicefiles. >> Not all ports have device files. It's long been my goal to add support >> for virtual serial ports, that is, serial ports on Ethernet terminal >> servers, for example integrating RFC2217. This means that the port name >> is some combination of an IP address and TCP port number. Nothing in /dev. >> >> Jim > > This idea doesn't need any native calls at all, right? No native calls, it's just a Socket link. > > How would you like to realize that? I keep wondering that myself. I had in mind port names that are, for example, "192.168.0.99:3000". These would need to be added to the properties file (or the -D option). I'm open for suggestion. It's conceptually, it's the same as USB. Instead of USB->Serial it's Ethernet->Serial. The difference is that the USB devices create virtual serial ports within the OS. Some Ethernet devices also do this, but since, unlike USB communications, TCP/IP is supported natively within Java such a driver is unnecessary. > Jini? Is that still alive and kicking? > > I'm sure you knew that the server is already there: > > http://www.viara.cn/en/jts.htm Yes, that library is part of the plan. These devices are real serial ports. Somewhere, out in the Ether there's a DB9/DB25 cable with RS232/485 bits flowing over it. Since these are real ports, I'd like the ports to look like real serial ports (SerialPort) and not have to handle them as special cases. We have a bunch of code that deals with serial devices (PLCs, Barcode, Temperature Controllers, RFID, SECS, etc. etc.) and to rewrite each one of those to handle this case doesn't make much sense when the correct place to encapsulate a serial port is in the SerialPort layer. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From pascal at quies.net Wed Jul 19 12:44:01 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 20:44:01 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BE63BA.9090905@ergotech.com> References: <200607191816.17099.pascal@quies.net> <44BE63BA.9090905@ergotech.com> Message-ID: <200607192044.01966.pascal@quies.net> Op woensdag 19 juli 2006 18:54, schreef Jim Redman: > I keep wondering that myself. I had in mind port names that are, for > example, "192.168.0.99:3000". These would need to be added to the > properties file (or the -D option). > > I'm open for suggestion. Jini works very well especialy for ethernets like the one you describe. It's a shame that it never got the attention it deserves. > > Jini? > > Is that still alive and kicking? Not that it does matter becouse Java software doesn't need much maintenance. ;) Have a look at http://www.jini.org/. From Paul.Klissner at Sun.COM Wed Jul 19 15:45:38 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 14:45:38 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> Message-ID: <44BEA802.7060508@sun.com> Joachim Buechse wrote: > Pascal, > > I think that the PortNoLongerAvailableListener creates more problems > than it solves. > > I think that exceptions are much better suited for this case. There > might be an additional method "Port.isOpen" or "Port.isAvailable" > which interested applications may call at times best suited. > > Most implementations will only find out, that a port disappeared when > trying to read or write. Anything else would require polling with a > high frequency or kernel hooks that do not exist (in POSIX). Any kind > of call back like portNoLongerAvailable() creates the risk of > deadlocks and races which require an involved implementation as the > library does not know what it is calling (ie a user might try to call > close from the callback which can block a very long time). Callbacks > introduce concurrency which unneccessarily increases the complexity. I think we should find out what are the minimum requirements to get a JSR open, form an expert group, and get that group discussing these things in the JSR. I'm not pushing for Sun to sponsor it, as I think there is a community interest already and that it deserves an independent life and commitment. ACCESS EXCEPTIONS: ----------------- I agree, exceptions of this sort are the way to go. Exceptions are already simpler than having to err check at each function call, so a big improvement. No need to architect a more trouble prone complexity into the API. PROJECT SCOPE: ------------- Also, we should think carefully about what the scope of this project would be. Should it be javax."comm" which handles both serial and parallel (is parallel going by the wayside). Should it be split into two project: javax.EIA232 (or javax.RS232), and javax.IEEE1284? Should we differentiate between single-ended serial protocols, like EIA232, I2C, 2-WIRE, SPI, vs. quasi-multidrop and full multidrop busses such as EIA422, EIA432 and EIA485? If we really were to add I2C support to the API, we'd have to delve into the semantics more, because there could be some implicit decoding of the bus the API users would want to see. At this point, I'm thinking they're all different, and should be their own projects.. perhaps there could be an umbrella layer that abstracted out some of the generic issues like device ownership and access, perhaps not. javax.eia232 javax.eia485 or (javax.EIX4xx?) javax.i2c, javax.spi (or javax.chipbus?) DRIVER PLUGINS: -------------- Taking javax.eia232 for example, I think we need an architecture that allows for multiple plugins to provide multiple simultaneous drivers/adapters to allow for heterogeneous providers on a single system. For example, not only can there be USB based serial devices but networked serial devices, for example accessing devices on thin clients. PORTMAPPING: ----------- For Sun's javax.comm 3.0, we introduced a portmapping abstraction layer, that creates a mechansim to help administer the view (filtering)of available ports given to the application, and the name of such ports. I hope we can consider the right platform neutral way to accomplish that. In javax.comm as it is now, the API has to know where to go and look to find ports. In 3.x I added the ability to specify where to look for standard ports as properties to make it more flexible, but for our thin client platform, which can represent a very dynamic buffet of ports splayed in the leaf nodes of a tree that isn't good enough. That complicates things for the users (having to specify and manage unique and long path names to ports which can come and go), so there is an option whereby the user can configure something like "com1" such that on a thin client it represents the first port of the first USB/serial dongle connected. Javax.comm knows how to find that in the context of the current thin client, but the administrator doesn't have to worry about it. How to architect the API flexibly enough to allow for this kind of thing needs to be considered. Paul > > Regards, > Joachim > > On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: > >> Hi Joachim, >> >> Thanks for the constructive critisism. :) >> >> Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >>> The static objects will work for Windows and Linux, however for OSX >>> they will create problems: >>> - ports can appear and disappear at any time with VCP drivers for USB >>> - the port names are not known until the usb-port is "plugged in" >> Ports can appear and disappear on *any* OS with USB support. Some >> Linux >> distributions even create and remove devicefiles on the fly. >> >> With the current API you fetch a list of all available ports and >> then you try >> to cast one. What happens if the port is no longer available at >> that time? >> What happens if a port vanishes during the data transfer? Of course >> you can >> catch exceptions but that makes the code quite messy. >> >> The idea was to get a PortStillAvailableListener interface. In that >> way the >> implementation is free to handle a cleanup or wait for return >> routine in a OO >> way. The I/O streams should just lock. >> >> The word static was not ment as persistent but as Java static >> available. >> Considder the following: >> >> java.lang.hw.HardwareConfiguration { >> public enum PortType { RS232, I2C, etc. }; >> >> /** Gets the currently available ports of type {@code PortType}. */ >> public static java.lang.hw.Port[] getPorts(PortType); >> } >> >> com.example.Driver implements PortUser, implements >> PortStillAvailableListener >> { >> public portNoLongerAvailable(PortEvent event) { >> // cleanup & dismiss. >> } >> } >> >> com.example.Application { >> public static void main(String[] args) { >> Driver someDriver = new Driver(); >> Port radomPort = HardwareConfiguration.getPorts( >> HardwareConfiguration.PortType.RS232)[1]; >> myDevice.addStillAvailableListener(someDriver); >> myDevice.connect(someDriver); >> } >> } >> >>> Please do not forget that tty ports can be opened by several >>> applications concurrently. All of those will "loose" the port if >>> anyone opens the corresponding cu port. >> Indeed we need a good overview of the differences between the various >> platforms. Should we create a document or a Wiki for this purpose? >> >> FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: >> http://www.openbsd.org/cgi-bin/man.cgi? >> query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD >> +Current&arch=i386&format=html >> >> Linux uses /var/lock: >> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES >> >> Is there absolutely no way to get a lock under Windows? >> >>> As this naming based >>> mechanism does not exist on Windows (maybe it does via an API) it >>> should probably be reflected in the API. In other words there are >>> "two levels of open": >>> >>> - Open for reading status lines (1) >>> - Open for reading/writing data (2) >>> >>> I am not sure if state (1) should also allow the modification of >>> certain status lines (ie to set a modem ready). >> I'm not sure I understand. Do you mean canonical and noncanonical >> mode? >> >> How far is Windows with the canonical mode. Is it comparable to POSIX? >> >>> I am also not sure if >>> the api should unify corresponding cu. and tty. ports into one single >>> port. >> I think the API should hide low-level details like devicefiles. >> >> >> Who is participating anyway? Is it just the four of us? >> >> Cheers, >> >> Pascal >> >> >>> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>>> For instance the current API is not very object oriented. >>>> It might be a good idea to have a static set of objects available >>>> representing >>>> every supported port available on the system in realtime. Each >>>> object should >>>> clearly know its own state and its capabilities. To get a port >>>> there could be >>>> a method like synchronized void connect(PortUser) where PortUser >>>> is a >>>> interface which handles the interaction with a input and a output >>>> stream and >>>> listers like PortStillAvailableListener, PortBufferListener and a >>>> DataAvailableListener. >>>> >>>> What is the collective feeling about that? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Wed Jul 19 16:32:37 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 16:32:37 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEA802.7060508@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <44BEB305.3030208@ergotech.com> For one, I'd object to the splitting of 232 and 485 and question why it's necessary. Often the only difference between 232 access and 485 access is whether there's a converter attached to the serial port. Put another way, while 485 is multidrop, I think that's an application level issue rather than a driver level issue. If the issue is electrical, I don't think that it's possible to reliably support receiver switching of a 2-wire 485 network within Java, the timing is just too tight, so your stuck with requiring a 485 converter that automatically switches (not an onerous burden for us) or some OS level intervention. Anyway, if we're going to start differentiating at the electrical level we still support some current loop systems (Siemens S5 PLC if you care). Jim Paul Klissner wrote: > Joachim Buechse wrote: >> Pascal, >> >> I think that the PortNoLongerAvailableListener creates more problems >> than it solves. >> >> I think that exceptions are much better suited for this case. There >> might be an additional method "Port.isOpen" or "Port.isAvailable" >> which interested applications may call at times best suited. >> >> Most implementations will only find out, that a port disappeared when >> trying to read or write. Anything else would require polling with a >> high frequency or kernel hooks that do not exist (in POSIX). Any kind >> of call back like portNoLongerAvailable() creates the risk of >> deadlocks and races which require an involved implementation as the >> library does not know what it is calling (ie a user might try to call >> close from the callback which can block a very long time). Callbacks >> introduce concurrency which unneccessarily increases the complexity. > > I think we should find out what are the minimum requirements > to get a JSR open, form an expert group, and get that group > discussing these things in the JSR. I'm not pushing for > Sun to sponsor it, as I think there is a community interest > already and that it deserves an independent life and > commitment. > > ACCESS EXCEPTIONS: > ----------------- > I agree, exceptions of this sort are the way to go. > Exceptions are already simpler than having to err > check at each function call, so a big improvement. > No need to architect a more trouble prone complexity > into the API. > > PROJECT SCOPE: > ------------- > > Also, we should think carefully about what the scope of > this project would be. Should it be javax."comm" which > handles both serial and parallel (is parallel going by the > wayside). Should it be split into two project: > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > > Should we differentiate between single-ended serial > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > quasi-multidrop and full multidrop busses such as > EIA422, EIA432 and EIA485? If we really were to > add I2C support to the API, we'd have to delve into > the semantics more, because there could be some > implicit decoding of the bus the API users would > want to see. > > At this point, I'm thinking they're all different, > and should be their own projects.. perhaps there > could be an umbrella layer that abstracted out > some of the generic issues like device ownership > and access, perhaps not. > > javax.eia232 > javax.eia485 or (javax.EIX4xx?) > javax.i2c, javax.spi (or javax.chipbus?) > > DRIVER PLUGINS: > -------------- > Taking javax.eia232 for example, I think we need an > architecture that allows for multiple plugins to > provide multiple simultaneous drivers/adapters to > allow for heterogeneous providers on a single system. > For example, not only can there be USB based serial > devices but networked serial devices, for example > accessing devices on thin clients. > > PORTMAPPING: > ----------- > For Sun's javax.comm 3.0, we introduced a portmapping > abstraction layer, that creates a mechansim to help > administer the view (filtering)of available ports given > to the application, and the name of such ports. I hope we > can consider the right platform neutral way to > accomplish that. > > In javax.comm as it is now, the API has to know > where to go and look to find ports. In 3.x I added > the ability to specify where to look for standard > ports as properties to make it more flexible, but > for our thin client platform, which can represent > a very dynamic buffet of ports splayed in the > leaf nodes of a tree that isn't good enough. > That complicates things for the users (having > to specify and manage unique and long path names > to ports which can come and go), so there is > an option whereby the user can configure > something like "com1" such that on a thin client > it represents the first port of the first USB/serial > dongle connected. Javax.comm knows how to find > that in the context of the current thin client, > but the administrator doesn't have to worry about it. > > How to architect the API flexibly enough to allow > for this kind of thing needs to be considered. > > Paul > > > >> Regards, >> Joachim >> >> On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: >> >>> Hi Joachim, >>> >>> Thanks for the constructive critisism. :) >>> >>> Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >>>> The static objects will work for Windows and Linux, however for OSX >>>> they will create problems: >>>> - ports can appear and disappear at any time with VCP drivers for USB >>>> - the port names are not known until the usb-port is "plugged in" >>> Ports can appear and disappear on *any* OS with USB support. Some >>> Linux >>> distributions even create and remove devicefiles on the fly. >>> >>> With the current API you fetch a list of all available ports and >>> then you try >>> to cast one. What happens if the port is no longer available at >>> that time? >>> What happens if a port vanishes during the data transfer? Of course >>> you can >>> catch exceptions but that makes the code quite messy. >>> >>> The idea was to get a PortStillAvailableListener interface. In that >>> way the >>> implementation is free to handle a cleanup or wait for return >>> routine in a OO >>> way. The I/O streams should just lock. >>> >>> The word static was not ment as persistent but as Java static >>> available. >>> Considder the following: >>> >>> java.lang.hw.HardwareConfiguration { >>> public enum PortType { RS232, I2C, etc. }; >>> >>> /** Gets the currently available ports of type {@code PortType}. */ >>> public static java.lang.hw.Port[] getPorts(PortType); >>> } >>> >>> com.example.Driver implements PortUser, implements >>> PortStillAvailableListener >>> { >>> public portNoLongerAvailable(PortEvent event) { >>> // cleanup & dismiss. >>> } >>> } >>> >>> com.example.Application { >>> public static void main(String[] args) { >>> Driver someDriver = new Driver(); >>> Port radomPort = HardwareConfiguration.getPorts( >>> HardwareConfiguration.PortType.RS232)[1]; >>> myDevice.addStillAvailableListener(someDriver); >>> myDevice.connect(someDriver); >>> } >>> } >>> >>>> Please do not forget that tty ports can be opened by several >>>> applications concurrently. All of those will "loose" the port if >>>> anyone opens the corresponding cu port. >>> Indeed we need a good overview of the differences between the various >>> platforms. Should we create a document or a Wiki for this purpose? >>> >>> FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: >>> http://www.openbsd.org/cgi-bin/man.cgi? >>> query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD >>> +Current&arch=i386&format=html >>> >>> Linux uses /var/lock: >>> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES >>> >>> Is there absolutely no way to get a lock under Windows? >>> >>>> As this naming based >>>> mechanism does not exist on Windows (maybe it does via an API) it >>>> should probably be reflected in the API. In other words there are >>>> "two levels of open": >>>> >>>> - Open for reading status lines (1) >>>> - Open for reading/writing data (2) >>>> >>>> I am not sure if state (1) should also allow the modification of >>>> certain status lines (ie to set a modem ready). >>> I'm not sure I understand. Do you mean canonical and noncanonical >>> mode? >>> >>> How far is Windows with the canonical mode. Is it comparable to POSIX? >>> >>>> I am also not sure if >>>> the api should unify corresponding cu. and tty. ports into one single >>>> port. >>> I think the API should hide low-level details like devicefiles. >>> >>> >>> Who is participating anyway? Is it just the four of us? >>> >>> Cheers, >>> >>> Pascal >>> >>> >>>> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>>>> For instance the current API is not very object oriented. >>>>> It might be a good idea to have a static set of objects available >>>>> representing >>>>> every supported port available on the system in realtime. Each >>>>> object should >>>>> clearly know its own state and its capabilities. To get a port >>>>> there could be >>>>> a method like synchronized void connect(PortUser) where PortUser >>>>> is a >>>>> interface which handles the interaction with a input and a output >>>>> stream and >>>>> listers like PortStillAvailableListener, PortBufferListener and a >>>>> DataAvailableListener. >>>>> >>>>> What is the collective feeling about that? >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Paul.Klissner at Sun.COM Wed Jul 19 17:31:36 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 16:31:36 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEB305.3030208@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> Message-ID: <44BEC0D8.4050806@sun.com> Jim Redman wrote: > For one, I'd object to the splitting of 232 and 485 and question why > it's necessary. Often the only difference between 232 access and 485 > access is whether there's a converter attached to the serial port. > > Put another way, while 485 is multidrop, I think that's an application > level issue rather than a driver level issue. > > If the issue is electrical, I don't think that it's possible to reliably > support receiver switching of a 2-wire 485 network within Java, the > timing is just too tight, so your stuck with requiring a 485 converter > that automatically switches (not an onerous burden for us) or some OS > level intervention. > > Anyway, if we're going to start differentiating at the electrical level > we still support some current loop systems (Siemens S5 PLC if you care). > > Jim To be honest, I've not done anything with 422, 423 or 485, so I have no objection to keeping them together if there isn't enough of a protocol distinction to make it worth seperating them out. I'd just like to find another suitable name than javax.comm, unless the JSR wants to start with javax.comm 4.0, since all the previous 'major revisions' are accounted for. javax.serialport? Paul > > Paul Klissner wrote: >> Joachim Buechse wrote: >>> Pascal, >>> >>> I think that the PortNoLongerAvailableListener creates more problems >>> than it solves. >>> >>> I think that exceptions are much better suited for this case. There >>> might be an additional method "Port.isOpen" or "Port.isAvailable" >>> which interested applications may call at times best suited. >>> >>> Most implementations will only find out, that a port disappeared when >>> trying to read or write. Anything else would require polling with a >>> high frequency or kernel hooks that do not exist (in POSIX). Any kind >>> of call back like portNoLongerAvailable() creates the risk of >>> deadlocks and races which require an involved implementation as the >>> library does not know what it is calling (ie a user might try to call >>> close from the callback which can block a very long time). Callbacks >>> introduce concurrency which unneccessarily increases the complexity. >> I think we should find out what are the minimum requirements >> to get a JSR open, form an expert group, and get that group >> discussing these things in the JSR. I'm not pushing for >> Sun to sponsor it, as I think there is a community interest >> already and that it deserves an independent life and >> commitment. >> >> ACCESS EXCEPTIONS: >> ----------------- >> I agree, exceptions of this sort are the way to go. >> Exceptions are already simpler than having to err >> check at each function call, so a big improvement. >> No need to architect a more trouble prone complexity >> into the API. >> >> PROJECT SCOPE: >> ------------- >> >> Also, we should think carefully about what the scope of >> this project would be. Should it be javax."comm" which >> handles both serial and parallel (is parallel going by the >> wayside). Should it be split into two project: >> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >> >> Should we differentiate between single-ended serial >> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >> quasi-multidrop and full multidrop busses such as >> EIA422, EIA432 and EIA485? If we really were to >> add I2C support to the API, we'd have to delve into >> the semantics more, because there could be some >> implicit decoding of the bus the API users would >> want to see. >> >> At this point, I'm thinking they're all different, >> and should be their own projects.. perhaps there >> could be an umbrella layer that abstracted out >> some of the generic issues like device ownership >> and access, perhaps not. >> >> javax.eia232 >> javax.eia485 or (javax.EIX4xx?) >> javax.i2c, javax.spi (or javax.chipbus?) >> >> DRIVER PLUGINS: >> -------------- >> Taking javax.eia232 for example, I think we need an >> architecture that allows for multiple plugins to >> provide multiple simultaneous drivers/adapters to >> allow for heterogeneous providers on a single system. >> For example, not only can there be USB based serial >> devices but networked serial devices, for example >> accessing devices on thin clients. >> >> PORTMAPPING: >> ----------- >> For Sun's javax.comm 3.0, we introduced a portmapping >> abstraction layer, that creates a mechansim to help >> administer the view (filtering)of available ports given >> to the application, and the name of such ports. I hope we >> can consider the right platform neutral way to >> accomplish that. >> >> In javax.comm as it is now, the API has to know >> where to go and look to find ports. In 3.x I added >> the ability to specify where to look for standard >> ports as properties to make it more flexible, but >> for our thin client platform, which can represent >> a very dynamic buffet of ports splayed in the >> leaf nodes of a tree that isn't good enough. >> That complicates things for the users (having >> to specify and manage unique and long path names >> to ports which can come and go), so there is >> an option whereby the user can configure >> something like "com1" such that on a thin client >> it represents the first port of the first USB/serial >> dongle connected. Javax.comm knows how to find >> that in the context of the current thin client, >> but the administrator doesn't have to worry about it. >> >> How to architect the API flexibly enough to allow >> for this kind of thing needs to be considered. >> >> Paul >> >> >> >>> Regards, >>> Joachim >>> >>> On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: >>> >>>> Hi Joachim, >>>> >>>> Thanks for the constructive critisism. :) >>>> >>>> Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >>>>> The static objects will work for Windows and Linux, however for OSX >>>>> they will create problems: >>>>> - ports can appear and disappear at any time with VCP drivers for USB >>>>> - the port names are not known until the usb-port is "plugged in" >>>> Ports can appear and disappear on *any* OS with USB support. Some >>>> Linux >>>> distributions even create and remove devicefiles on the fly. >>>> >>>> With the current API you fetch a list of all available ports and >>>> then you try >>>> to cast one. What happens if the port is no longer available at >>>> that time? >>>> What happens if a port vanishes during the data transfer? Of course >>>> you can >>>> catch exceptions but that makes the code quite messy. >>>> >>>> The idea was to get a PortStillAvailableListener interface. In that >>>> way the >>>> implementation is free to handle a cleanup or wait for return >>>> routine in a OO >>>> way. The I/O streams should just lock. >>>> >>>> The word static was not ment as persistent but as Java static >>>> available. >>>> Considder the following: >>>> >>>> java.lang.hw.HardwareConfiguration { >>>> public enum PortType { RS232, I2C, etc. }; >>>> >>>> /** Gets the currently available ports of type {@code PortType}. */ >>>> public static java.lang.hw.Port[] getPorts(PortType); >>>> } >>>> >>>> com.example.Driver implements PortUser, implements >>>> PortStillAvailableListener >>>> { >>>> public portNoLongerAvailable(PortEvent event) { >>>> // cleanup & dismiss. >>>> } >>>> } >>>> >>>> com.example.Application { >>>> public static void main(String[] args) { >>>> Driver someDriver = new Driver(); >>>> Port radomPort = HardwareConfiguration.getPorts( >>>> HardwareConfiguration.PortType.RS232)[1]; >>>> myDevice.addStillAvailableListener(someDriver); >>>> myDevice.connect(someDriver); >>>> } >>>> } >>>> >>>>> Please do not forget that tty ports can be opened by several >>>>> applications concurrently. All of those will "loose" the port if >>>>> anyone opens the corresponding cu port. >>>> Indeed we need a good overview of the differences between the various >>>> platforms. Should we create a document or a Wiki for this purpose? >>>> >>>> FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: >>>> http://www.openbsd.org/cgi-bin/man.cgi? >>>> query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD >>>> +Current&arch=i386&format=html >>>> >>>> Linux uses /var/lock: >>>> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES >>>> >>>> Is there absolutely no way to get a lock under Windows? >>>> >>>>> As this naming based >>>>> mechanism does not exist on Windows (maybe it does via an API) it >>>>> should probably be reflected in the API. In other words there are >>>>> "two levels of open": >>>>> >>>>> - Open for reading status lines (1) >>>>> - Open for reading/writing data (2) >>>>> >>>>> I am not sure if state (1) should also allow the modification of >>>>> certain status lines (ie to set a modem ready). >>>> I'm not sure I understand. Do you mean canonical and noncanonical >>>> mode? >>>> >>>> How far is Windows with the canonical mode. Is it comparable to POSIX? >>>> >>>>> I am also not sure if >>>>> the api should unify corresponding cu. and tty. ports into one single >>>>> port. >>>> I think the API should hide low-level details like devicefiles. >>>> >>>> >>>> Who is participating anyway? Is it just the four of us? >>>> >>>> Cheers, >>>> >>>> Pascal >>>> >>>> >>>>> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>>>>> For instance the current API is not very object oriented. >>>>>> It might be a good idea to have a static set of objects available >>>>>> representing >>>>>> every supported port available on the system in realtime. Each >>>>>> object should >>>>>> clearly know its own state and its capabilities. To get a port >>>>>> there could be >>>>>> a method like synchronized void connect(PortUser) where PortUser >>>>>> is a >>>>>> interface which handles the interaction with a input and a output >>>>>> stream and >>>>>> listers like PortStillAvailableListener, PortBufferListener and a >>>>>> DataAvailableListener. >>>>>> >>>>>> What is the collective feeling about that? >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Wed Jul 19 18:03:40 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 18:03:40 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEC0D8.4050806@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> Message-ID: <44BEC85C.2030809@ergotech.com> Paul Klissner wrote: > I'd just like to find another suitable name than javax.comm, unless > the JSR wants to start with javax.comm 4.0, since all the previous > 'major revisions' are accounted for. javax.serialport? Which perhaps brings us back to what are we trying to fix and how badly. There are a number of 3rd party implementation of Java Comm, at least one from IBM - part of what was J9, now Websphere, or something (presumbly soon to get a name that has eclipse in it sometime soon). Esmertec has one, and there are few others rolling around. If RXTX is the only implementation of the JSR with no backward compatibility, we've just forked Java Serial support and we (for a least one) will be worse off. We won't be able to use the new support because of a lack of support on J2ME platforms that we have no control over and RXTX/current JavaComm will be in maintenance mode or unsupported on all other platforms. So, is there any chance of building a compatibility requirement into this. To pick are really bad example JDBC has support for a DataSource or a Driver. Could we have an ExcellentSerialPort with a fallback to a SerialPort on a class not found exception? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From pascal at quies.net Wed Jul 19 18:22:45 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Thu, 20 Jul 2006 02:22:45 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEC85C.2030809@ergotech.com> References: <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> Message-ID: <200607200222.46023.pascal@quies.net> Op donderdag 20 juli 2006 02:03, schreef Jim Redman: > Which perhaps brings us back to what are we trying to fix and how badly. The initail problem was the license. :) RXTX is sitting in this gnu.comm namespace and is afraid to go to javax.comm. Getting a JSR would solve this problem. And while we're at it we might as well improve the situation with the various platforms. I made some sugestions that where denied as too complex. Cheers, Pascal From Paul.Klissner at Sun.COM Wed Jul 19 19:09:35 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 18:09:35 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607200222.46023.pascal@quies.net> References: <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <200607200222.46023.pascal@quies.net> Message-ID: <44BED7CF.5080405@sun.com> Pascal S. de Kloe wrote: > Op donderdag 20 juli 2006 02:03, schreef Jim Redman: >> Which perhaps brings us back to what are we trying to fix and how badly. > > The initail problem was the license. :) > > RXTX is sitting in this gnu.comm namespace and is afraid to go to javax.comm. > Getting a JSR would solve this problem. > > And while we're at it we might as well improve the situation with the various > platforms. I made some sugestions that where denied as too complex. "Denied" is a bit harsh :) I'll re-examine your e-mails to see if my preferences change. It's not like your proposition has been put up to a formal vote, just discussion. Paul From Paul.Klissner at Sun.COM Wed Jul 19 19:28:47 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 18:28:47 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEC85C.2030809@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> Message-ID: <44BEDC4F.9030403@sun.com> Jim Redman wrote: > Paul Klissner wrote: >> I'd just like to find another suitable name than javax.comm, unless >> the JSR wants to start with javax.comm 4.0, since all the previous >> 'major revisions' are accounted for. javax.serialport? > > Which perhaps brings us back to what are we trying to fix and how badly. The goals I'm most interested in at the moment are: 1. A pluggable platform portmapping scheme wherein each platform can determine which ports to present to the application, and preferably as some configurable logical name. For example on the Sun Ray thin client platform, if an application aquiring a view of serial ports available on the system, it will be informed of Sun Ray serial ports if the application is running in a session currently directed to that particular Sun Ray unit, even though the serial port's device node happens to be server-side deeply nested in a leaf node. If the application is not running on a Sun Ray the port doesn't show up. The Sun Ray plugin would make the decision about when and which ports to present to the application. 2. Pluggable driver-side interface where multiple platform-specific drivers can be utilized simultaneously to introduce more flexibility with the back end. > There are a number of 3rd party implementation of Java Comm, at least > one from IBM - part of what was J9, now Websphere, or something > (presumbly soon to get a name that has eclipse in it sometime soon). > Esmertec has one, and there are few others rolling around. I have not been advocating gutting the API, since much of it is perfectly adequate. I'm not totally opposed to making substantial changes or improvements depending on other people's needs. There's no reason previous versions of javax.comm need to suddenly disappear if products need legacy support. > > If RXTX is the only implementation of the JSR with no backward > compatibility, we've just forked Java Serial support and we (for a least > one) will be worse off. We won't be able to use the new support because > of a lack of support on J2ME platforms that we have no control over and > RXTX/current JavaComm will be in maintenance mode or unsupported on all > other platforms. There can't be *that* many platforms this is ported to. And it will be no javax.usb. Seems like most of the standard platforms will be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, JDBC... > > So, is there any chance of building a compatibility requirement into > this. To pick are really bad example JDBC has support for a DataSource > or a Driver. Could we have an ExcellentSerialPort with a fallback to a > SerialPort on a class not found exception? Maybe, or maybe we just let people know what we are doing and try to figure out how to get their applications ported. Might not be that difficult. From my standpoint anyway, earthshaking changes aren't really necessary. Others might disagree. Paul From rwelty at averillpark.net Wed Jul 19 19:35:54 2006 From: rwelty at averillpark.net (Richard P. Welty) Date: Wed, 19 Jul 2006 21:35:54 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter Message-ID: <44BEDDFA.7020108@averillpark.net> I'm returning to the use of rxtx after 2 years off doing things that don't need serial ports. I'm trying to get my laptop (fedora core 1) talking to a set of portable auto scales through a Keyspan USB adapter (in my past use of rxtx, I had actual serial ports, but those days are long gone.) I have the keyspan kernel module loaded, and lsusb shows the device as correctly identified. I'm missing the bit of magic needed to get rxtx to provide the port in response to CommPortIdentifier.getPortIdentifiers() thanks in advance for any help, richard From jredman at ergotech.com Wed Jul 19 19:43:25 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 19:43:25 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BED7CF.5080405@sun.com> References: <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <200607200222.46023.pascal@quies.net> <44BED7CF.5080405@sun.com> Message-ID: <44BEDFBD.4020404@ergotech.com> Paul Klissner wrote: > Pascal S. de Kloe wrote: >> Op donderdag 20 juli 2006 02:03, schreef Jim Redman: >>> Which perhaps brings us back to what are we trying to fix and how badly. >> The initail problem was the license. :) >> >> RXTX is sitting in this gnu.comm namespace and is afraid to go to javax.comm. >> Getting a JSR would solve this problem. >> >> And while we're at it we might as well improve the situation with the various >> platforms. I made some sugestions that where denied as too complex. > > "Denied" is a bit harsh :) I'll re-examine your e-mails > to see if my preferences change. It's not like your > proposition has been put up to a formal vote, just discussion. OK, I'll officially float backwards compatibility in the form of "It should be possible to use anything that comes out of the JSR in place of an existing java comm implementation". I wonder if "Denied" is too harsh for that one :) Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From ajmas at sympatico.ca Wed Jul 19 19:47:06 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Wed, 19 Jul 2006 21:47:06 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEDDFA.7020108@averillpark.net> References: <44BEDDFA.7020108@averillpark.net> Message-ID: <35101C10-59A5-4F02-AEEE-DB69112F8130@sympatico.ca> Do you see an associated device in /dev ? On 19-Jul-06, at 21:35 , Richard P. Welty wrote: > I'm returning to the use of rxtx after 2 years off doing > things that don't need serial ports. > > I'm trying to get my laptop (fedora core 1) talking to a > set of portable auto scales through a Keyspan USB adapter > (in my past use of rxtx, I had actual serial ports, but those > days are long gone.) I have the keyspan kernel module loaded, > and lsusb shows the device as correctly identified. I'm missing > the bit of magic needed to get rxtx to provide the port > in response to CommPortIdentifier.getPortIdentifiers() > > thanks in advance for any help, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Wed Jul 19 19:54:03 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 19:54:03 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEDC4F.9030403@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> Message-ID: <44BEE23B.30908@ergotech.com> Paul, For the record we're STILL supporting some PersonalJava platforms. We're _almost_ at the point where we can assume that the platforms will have a Collections framework, but routinely compile with a 1.1 check so that we don't make that assumption unnecessarily. Of 50+ non-graphical Factory Automation JavaBeans we have 2 that require Java2 (Reporting and JavaScripting), and we have people asking for a back-port. Embedded platforms don't change in a hurry. Unlike desktop platforms, embedded systems are expected to last 5-10+ years. There are factory automation vendors in the pharmaceutical industry who are buying systems on eBay because that's the FDA validate platform. It must be that make/model, spec'd sometime in the mid-90's. So... If you make an incompatible change TODAY figure we can start using that code _at the earliest_ somewhere around 2012 or the low teens. Are we _really_ the only people on the list supporting embedded/factory automation platforms? Jim Paul Klissner wrote: > Jim Redman wrote: >> Paul Klissner wrote: >>> I'd just like to find another suitable name than javax.comm, unless >>> the JSR wants to start with javax.comm 4.0, since all the previous >>> 'major revisions' are accounted for. javax.serialport? >> Which perhaps brings us back to what are we trying to fix and how badly. > The goals I'm most interested in at the moment are: > > 1. A pluggable platform portmapping scheme wherein each platform > can determine which ports to present to the application, and > preferably as some configurable logical name. > > For example on the Sun Ray thin client platform, if an application > aquiring a view of serial ports available on the system, it will > be informed of Sun Ray serial ports if the application is running > in a session currently directed to that particular Sun Ray unit, > even though the serial port's device node happens to be server-side > deeply nested in a leaf node. If the application is not running on > a Sun Ray the port doesn't show up. The Sun Ray plugin would make > the decision about when and which ports to present to the application. > > 2. Pluggable driver-side interface where multiple platform-specific > drivers can be utilized simultaneously to introduce more flexibility > with the back end. > >> There are a number of 3rd party implementation of Java Comm, at least >> one from IBM - part of what was J9, now Websphere, or something >> (presumbly soon to get a name that has eclipse in it sometime soon). >> Esmertec has one, and there are few others rolling around. > > I have not been advocating gutting the API, since much of it is > perfectly adequate. I'm not totally opposed to making substantial > changes or improvements depending on other people's needs. There's > no reason previous versions of javax.comm need to suddenly disappear > if products need legacy support. > > >> If RXTX is the only implementation of the JSR with no backward >> compatibility, we've just forked Java Serial support and we (for a least >> one) will be worse off. We won't be able to use the new support because >> of a lack of support on J2ME platforms that we have no control over and >> RXTX/current JavaComm will be in maintenance mode or unsupported on all >> other platforms. > > There can't be *that* many platforms this is ported to. And it will > be no javax.usb. Seems like most of the standard platforms will > be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, > JDBC... > >> So, is there any chance of building a compatibility requirement into >> this. To pick are really bad example JDBC has support for a DataSource >> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >> SerialPort on a class not found exception? > > Maybe, or maybe we just let people know what we are doing and > try to figure out how to get their applications ported. Might not > be that difficult. From my standpoint anyway, earthshaking > changes aren't really necessary. Others might disagree. > > Paul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tod at todbot.com Wed Jul 19 19:59:52 2006 From: tod at todbot.com (Tod E. Kurt) Date: Wed, 19 Jul 2006 18:59:52 -0700 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEDDFA.7020108@averillpark.net> References: <44BEDDFA.7020108@averillpark.net> Message-ID: Hi, "lsusb" doesn't show if you have the proper drivers loaded for the specific USB device, just that a USB device is plugged in. The text identifiers sent by the USB device aren't used by the OS except for things like lsusb. Look at the output of "dmesg" or /var/log/messages and see if you have a lines that looks like: keyspan 1-1:1.0: Keyspan 1 port adapter converter detected usb 1-1: Keyspan 1 port adapter converter now attached to ttyUSB0 If you do, then you've got a serial port at "/dev/ttyUSB0", and you can use minicom or whatever (even RXTX!) to play with it. If you get a message like: usb.c: USB device 4 (vend/prod 0x06cd/0x0121) is not claimed by any active driver. Then the USB driver can't find the 'keyspan' driver. If you're sure you have this driver, then hotplug isn't working for some reason. You could try running the command: % sudo modprobe keyspan And see if anything useful happens. You should see the 'keyspan' driver when you type "lsmod" to list the currently loaded kernel modules. -=tod On Jul 19, 2006, at 6:35 PM, Richard P. Welty wrote: > I'm returning to the use of rxtx after 2 years off doing > things that don't need serial ports. > > I'm trying to get my laptop (fedora core 1) talking to a > set of portable auto scales through a Keyspan USB adapter > (in my past use of rxtx, I had actual serial ports, but those > days are long gone.) I have the keyspan kernel module loaded, > and lsusb shows the device as correctly identified. I'm missing > the bit of magic needed to get rxtx to provide the port > in response to CommPortIdentifier.getPortIdentifiers() > > thanks in advance for any help, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From rwelty at suespammers.org Wed Jul 19 20:05:18 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Wed, 19 Jul 2006 22:05:18 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <35101C10-59A5-4F02-AEEE-DB69112F8130@sympatico.ca> References: <44BEDDFA.7020108@averillpark.net> <35101C10-59A5-4F02-AEEE-DB69112F8130@sympatico.ca> Message-ID: <44BEE4DE.9080707@suespammers.org> Andr?-John Mas wrote: > Do you see an associated device in /dev ? Well, there are lots of /dev/ttyUSB devices, there, but nothing jumps out as having been assigned to the keyspan. But then, I'm not that knowledgable about the USB mapping here; this is the first time I've tried to use one this way and I'm on the steep part of the learning curve. richard From rwelty at suespammers.org Wed Jul 19 20:08:20 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Wed, 19 Jul 2006 22:08:20 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: References: <44BEDDFA.7020108@averillpark.net> Message-ID: <44BEE594.50402@suespammers.org> Tod E. Kurt wrote: > Then the USB driver can't find the 'keyspan' driver. If you're sure > you have this driver, then hotplug isn't working for some reason. > You could try running the command: Ok, it looks like the keyspan driver may be the problem; it's having some sort of problem loading it. I'll have to look into this further tomorrow night. thanks, richard From pascal at quies.net Wed Jul 19 20:11:21 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Thu, 20 Jul 2006 04:11:21 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEDFBD.4020404@ergotech.com> References: <44BED7CF.5080405@sun.com> <44BEDFBD.4020404@ergotech.com> Message-ID: <200607200411.22012.pascal@quies.net> Op donderdag 20 juli 2006 03:43, schreef Jim Redman: > Paul Klissner wrote: > > Pascal S. de Kloe wrote: > >> Op donderdag 20 juli 2006 02:03, schreef Jim Redman: > >>> Which perhaps brings us back to what are we trying to fix and how > >>> badly. > >> > >> The initail problem was the license. :) > >> > >> RXTX is sitting in this gnu.comm namespace and is afraid to go to > >> javax.comm. Getting a JSR would solve this problem. > >> > >> And while we're at it we might as well improve the situation with the > >> various platforms. I made some sugestions that where denied as too > >> complex. > > > > "Denied" is a bit harsh :) I'll re-examine your e-mails > > to see if my preferences change. It's not like your > > proposition has been put up to a formal vote, just discussion. > > OK, I'll officially float backwards compatibility in the form of "It > should be possible to use anything that comes out of the JSR in place of > an existing java comm implementation". > > I wonder if "Denied" is too harsh for that one :) > > Jim Hehehe. I don't have any troubles with people voting against my ideas at all so don't worry Paul. :) However, it is exactly the compatibilty thing where Jim is talking about what makes me want to make a *huge* change if any. From jredman at ergotech.com Wed Jul 19 20:25:50 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 20:25:50 -0600 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEE594.50402@suespammers.org> References: <44BEDDFA.7020108@averillpark.net> <44BEE594.50402@suespammers.org> Message-ID: <44BEE9AE.3030200@ergotech.com> Some who remembers this better than me please help. You also need something like: -Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3 When you start the application. This can be put in a properties files (where?). Jim Richard P. Welty wrote: > Tod E. Kurt wrote: > >> Then the USB driver can't find the 'keyspan' driver. If you're sure >> you have this driver, then hotplug isn't working for some reason. >> You could try running the command: > > Ok, it looks like the keyspan driver may be the problem; it's having > some sort of problem loading it. I'll have to look into this further > tomorrow night. > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From ajmas at sympatico.ca Wed Jul 19 20:32:52 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Wed, 19 Jul 2006 22:32:52 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEE9AE.3030200@ergotech.com> References: <44BEDDFA.7020108@averillpark.net> <44BEE594.50402@suespammers.org> <44BEE9AE.3030200@ergotech.com> Message-ID: Are you sure about this? I know on MacOS X no such configuration was needed. If this is indeed true, this is poor design, in this day and age of dynamic devices. On 19-Jul-06, at 22:25 , Jim Redman wrote: > Some who remembers this better than me please help. > > You also need something like: > > -Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyUSB0:/dev/ttyUSB1:/ > dev/ttyUSB2:/dev/ttyUSB3 > > When you start the application. This can be put in a properties files > (where?). > > Jim > > Richard P. Welty wrote: >> Tod E. Kurt wrote: >> >>> Then the USB driver can't find the 'keyspan' driver. If you're sure >>> you have this driver, then hotplug isn't working for some reason. >>> You could try running the command: >> >> Ok, it looks like the keyspan driver may be the problem; it's having >> some sort of problem loading it. I'll have to look into this further >> tomorrow night. >> >> thanks, >> richard >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Wed Jul 19 20:41:01 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Wed, 19 Jul 2006 22:41:01 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEE9AE.3030200@ergotech.com> References: <44BEDDFA.7020108@averillpark.net> <44BEE594.50402@suespammers.org> <44BEE9AE.3030200@ergotech.com> Message-ID: <44BEED3D.5020304@suespammers.org> Jim Redman wrote: > Some who remembers this better than me please help. > > You also need something like: > > -Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3 > > When you start the application. This can be put in a properties files > (where?). Thanks for all the help, guys. Thinking back on how this laptop came to be in its current state, I'm of the opinion a format and complete rebuild with a newer version of Fedora is in order before I waste any more time in diagnosis. The problems I'm seeing clearly have nothing to do with RXTX and everything to do with how many upgrades have been chained together getting this laptop from whereever I started (RH 7.0 or 7.1) to FC1. It could probably be fixed in place, but I shudder to think about the amount of time needed to figure out the proper fix. But the software I'm putting together will need to run on Y2K/XP and Mac OS X, so I'll be following portability and installer discussions on this list rather intently (http://scale-app.sourceforge.net for anyone who cares.) richard From Paul.Klissner at Sun.COM Wed Jul 19 22:53:53 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 21:53:53 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEE23B.30908@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> Message-ID: <44BF0C61.4020900@sun.com> Jim Redman wrote: > Paul, > > For the record we're STILL supporting some PersonalJava platforms. > We're _almost_ at the point where we can assume that the platforms will > have a Collections framework, but routinely compile with a 1.1 check so > that we don't make that assumption unnecessarily. Of 50+ non-graphical > Factory Automation JavaBeans we have 2 that require Java2 (Reporting and > JavaScripting), and we have people asking for a back-port. > > Embedded platforms don't change in a hurry. Unlike desktop platforms, > embedded systems are expected to last 5-10+ years. > > There are factory automation vendors in the pharmaceutical industry who > are buying systems on eBay because that's the FDA validate platform. It > must be that make/model, spec'd sometime in the mid-90's. > > So... If you make an incompatible change TODAY figure we can start using > that code _at the earliest_ somewhere around 2012 or the low teens. > > Are we _really_ the only people on the list supporting embedded/factory > automation platforms? > > Jim Do you provide your own implementation classes? Why can't you just continue to use 2.1 for the embedded platform until 2012 if you're locked down? Are you worried bugs won't get fixed? Sun might consider open sourcing the 2.1 Java source. I can't promise that, but it's been discussed and hasn't met resistance, except from me, because I wasn't super impressed with the code. I can probably be persuaded to champion open sourcing that and going through the process/legal machinations within Sun if it frees us to pursue a JSR for a new generation of javax.comm where we can have a chunk of common code in Open Source and each platform is simply responsible for it's platform specific plugins. I don't have many opinions about this set in stone because there are a lot of technical and pragmatic considerations such as yours the community has that I am probably not aware of or sufficiently sensitive to yet. I don't feel I really have the bird's eye view of all of this yet. The other thing is, I can only offer 10% of my time right now, according to my management, which is why I'm not pushing to be the spec lead for the JSR, and want only to be a participant to represent Sun's interests on the E.G. There is nothing sacred about Sun employees in the JCP as far as a JSR initiated by another entity is concerned. I am not the person everything needs to be cleared through. Ideas I have will pass or fail based on their merit and the community perception just like anyone else's. Paul > > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul Klissner wrote: >>>> I'd just like to find another suitable name than javax.comm, unless >>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>> 'major revisions' are accounted for. javax.serialport? >>> Which perhaps brings us back to what are we trying to fix and how badly. >> The goals I'm most interested in at the moment are: >> >> 1. A pluggable platform portmapping scheme wherein each platform >> can determine which ports to present to the application, and >> preferably as some configurable logical name. >> >> For example on the Sun Ray thin client platform, if an application >> aquiring a view of serial ports available on the system, it will >> be informed of Sun Ray serial ports if the application is running >> in a session currently directed to that particular Sun Ray unit, >> even though the serial port's device node happens to be server-side >> deeply nested in a leaf node. If the application is not running on >> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >> the decision about when and which ports to present to the application. >> >> 2. Pluggable driver-side interface where multiple platform-specific >> drivers can be utilized simultaneously to introduce more flexibility >> with the back end. >> >>> There are a number of 3rd party implementation of Java Comm, at least >>> one from IBM - part of what was J9, now Websphere, or something >>> (presumbly soon to get a name that has eclipse in it sometime soon). >>> Esmertec has one, and there are few others rolling around. >> I have not been advocating gutting the API, since much of it is >> perfectly adequate. I'm not totally opposed to making substantial >> changes or improvements depending on other people's needs. There's >> no reason previous versions of javax.comm need to suddenly disappear >> if products need legacy support. >> >> >>> If RXTX is the only implementation of the JSR with no backward >>> compatibility, we've just forked Java Serial support and we (for a least >>> one) will be worse off. We won't be able to use the new support because >>> of a lack of support on J2ME platforms that we have no control over and >>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>> other platforms. >> There can't be *that* many platforms this is ported to. And it will >> be no javax.usb. Seems like most of the standard platforms will >> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >> JDBC... >> >>> So, is there any chance of building a compatibility requirement into >>> this. To pick are really bad example JDBC has support for a DataSource >>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>> SerialPort on a class not found exception? >> Maybe, or maybe we just let people know what we are doing and >> try to figure out how to get their applications ported. Might not >> be that difficult. From my standpoint anyway, earthshaking >> changes aren't really necessary. Others might disagree. >> >> Paul >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From Paul.Klissner at Sun.COM Thu Jul 20 00:27:41 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 23:27:41 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BF0C61.4020900@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> Message-ID: <44BF225D.80104@sun.com> Paul Klissner wrote: > Jim Redman wrote: >> Paul, >> >> For the record we're STILL supporting some PersonalJava platforms. >> We're _almost_ at the point where we can assume that the platforms will >> have a Collections framework, but routinely compile with a 1.1 check so >> that we don't make that assumption unnecessarily. Of 50+ non-graphical >> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >> JavaScripting), and we have people asking for a back-port. >> >> Embedded platforms don't change in a hurry. Unlike desktop platforms, >> embedded systems are expected to last 5-10+ years. >> >> There are factory automation vendors in the pharmaceutical industry who >> are buying systems on eBay because that's the FDA validate platform. It >> must be that make/model, spec'd sometime in the mid-90's. >> >> So... If you make an incompatible change TODAY figure we can start using >> that code _at the earliest_ somewhere around 2012 or the low teens. >> >> Are we _really_ the only people on the list supporting embedded/factory >> automation platforms? >> >> Jim > > Do you provide your own implementation classes? > > Why can't you just continue to use 2.1 for the embedded platform until > 2012 if you're locked down? Are you worried bugs won't get fixed? > Sun might consider open sourcing the 2.1 Java source. Excuse me, I meant 2.0.3 > I can't promise > that, but it's been discussed and hasn't met resistance, except > from me, because I wasn't super impressed with the code. I can probably > be persuaded to champion open sourcing that and going through the > process/legal machinations within Sun if it frees us to pursue > a JSR for a new generation of javax.comm where we can have a chunk of > common code in Open Source and each platform is simply responsible > for it's platform specific plugins. > > I don't have many opinions about this set in stone because there > are a lot of technical and pragmatic considerations such as yours > the community has that I am probably not aware of or sufficiently > sensitive to yet. I don't feel I really have the bird's eye view > of all of this yet. > > The other thing is, I can only offer 10% of my time right now, > according to my management, which is why I'm not pushing to > be the spec lead for the JSR, and want only to be a participant > to represent Sun's interests on the E.G. There is nothing sacred > about Sun employees in the JCP as far as a JSR initiated by another > entity is concerned. I am not the person everything needs to be > cleared through. Ideas I have will pass or fail based on their > merit and the community perception just like anyone else's. > > Paul > >> Paul Klissner wrote: >>> Jim Redman wrote: >>>> Paul Klissner wrote: >>>>> I'd just like to find another suitable name than javax.comm, unless >>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>> 'major revisions' are accounted for. javax.serialport? >>>> Which perhaps brings us back to what are we trying to fix and how badly. >>> The goals I'm most interested in at the moment are: >>> >>> 1. A pluggable platform portmapping scheme wherein each platform >>> can determine which ports to present to the application, and >>> preferably as some configurable logical name. >>> >>> For example on the Sun Ray thin client platform, if an application >>> aquiring a view of serial ports available on the system, it will >>> be informed of Sun Ray serial ports if the application is running >>> in a session currently directed to that particular Sun Ray unit, >>> even though the serial port's device node happens to be server-side >>> deeply nested in a leaf node. If the application is not running on >>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>> the decision about when and which ports to present to the application. >>> >>> 2. Pluggable driver-side interface where multiple platform-specific >>> drivers can be utilized simultaneously to introduce more flexibility >>> with the back end. >>> >>>> There are a number of 3rd party implementation of Java Comm, at least >>>> one from IBM - part of what was J9, now Websphere, or something >>>> (presumbly soon to get a name that has eclipse in it sometime soon). >>>> Esmertec has one, and there are few others rolling around. >>> I have not been advocating gutting the API, since much of it is >>> perfectly adequate. I'm not totally opposed to making substantial >>> changes or improvements depending on other people's needs. There's >>> no reason previous versions of javax.comm need to suddenly disappear >>> if products need legacy support. >>> >>> >>>> If RXTX is the only implementation of the JSR with no backward >>>> compatibility, we've just forked Java Serial support and we (for a least >>>> one) will be worse off. We won't be able to use the new support because >>>> of a lack of support on J2ME platforms that we have no control over and >>>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>>> other platforms. >>> There can't be *that* many platforms this is ported to. And it will >>> be no javax.usb. Seems like most of the standard platforms will >>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>> JDBC... >>> >>>> So, is there any chance of building a compatibility requirement into >>>> this. To pick are really bad example JDBC has support for a DataSource >>>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>>> SerialPort on a class not found exception? >>> Maybe, or maybe we just let people know what we are doing and >>> try to figure out how to get their applications ported. Might not >>> be that difficult. From my standpoint anyway, earthshaking >>> changes aren't really necessary. Others might disagree. >>> >>> Paul >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Thu Jul 20 00:50:21 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 20 Jul 2006 08:50:21 +0200 Subject: [Rxtx] jcp and jsr Message-ID: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> Hi all, I work with SNIJDER Micro Systems. We're doing embedded Java and just heard about this discussion by way of Ted Kosan from the embedded Java community. We think Jim is right about the compatibility issues for embedded Java platforms. Our own embedded Java platform (see http://www.embedded-web.com ) uses a 3rd party implementation of javax.comm written by the JVM vendor. As Jim says, changes take much longer to propagate in the embedded space. If the 'new' javax.comm is not backwards compatible, embedded JVM vendors (esmertec, IBM, Tao Group, etc.) will probably evaluate whether it makes sense for them to support the new API. Some will eventually adopt it, but that will take time. Some will just stay with the current API, thus increasing the gap between embedded Java developers and desktop Java developers (different APIs to do the same thing) This is a very real problem in our opinion. Also taking into account that many desktop computers nowadays don't even have standard serial ports, I believe that the embedded Java community already gathers a significant share of the potential javax.comm users. I think backwards compatibility should be seriously considered. Best regards, Guillermo Jim Redman wrote: >Paul Klissner wrote: > > I'd just like to find another suitable name than javax.comm, unless > > the JSR wants to start with javax.comm 4.0, since all the previous > > 'major revisions' are accounted for. javax.serialport? > >Which perhaps brings us back to what are we trying to fix and how badly. > >There are a number of 3rd party implementation of Java Comm, at least >one from IBM - part of what was J9, now Websphere, or something >(presumbly soon to get a name that has eclipse in it sometime soon). >Esmertec has one, and there are few others rolling around. > >If RXTX is the only implementation of the JSR with no backward >compatibility, we've just forked Java Serial support and we (for a least >one) will be worse off. We won't be able to use the new support because >of a lack of support on J2ME platforms that we have no control over and >RXTX/current JavaComm will be in maintenance mode or unsupported on all >other platforms. > >So, is there any chance of building a compatibility requirement into >this. To pick are really bad example JDBC has support for a DataSource >or a Driver. Could we have an ExcellentSerialPort with a fallback to a >SerialPort on a class not found exception? > >Jim -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Thu Jul 20 00:57:04 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 20 Jul 2006 08:57:04 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> References: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> Message-ID: <7.0.1.0.0.20060720085221.036d88e8@sms.nl> Paul Klissner wrote: >Jim Redman wrote: > > Paul, > > > > For the record we're STILL supporting some PersonalJava platforms. > > We're _almost_ at the point where we can assume that the platforms will > > have a Collections framework, but routinely compile with a 1.1 check so > > that we don't make that assumption unnecessarily. Of 50+ non-graphical > > Factory Automation JavaBeans we have 2 that require Java2 (Reporting and > > JavaScripting), and we have people asking for a back-port. > > > > Embedded platforms don't change in a hurry. Unlike desktop platforms, > > embedded systems are expected to last 5-10+ years. > > > > There are factory automation vendors in the pharmaceutical industry who > > are buying systems on eBay because that's the FDA validate platform. It > > must be that make/model, spec'd sometime in the mid-90's. > > > > So... If you make an incompatible change TODAY figure we can start using > > that code _at the earliest_ somewhere around 2012 or the low teens. > > > > Are we _really_ the only people on the list supporting embedded/factory > > automation platforms? > > > > Jim > >Do you provide your own implementation classes? > >Why can't you just continue to use 2.1 for the embedded platform until >2012 if you're locked down? Are you worried bugs won't get fixed? If embedded platforms keep using the "old" (current) javax.comm API but the desktop Java world starts to use a new, backwards-incompatible API, then this will result in more trouble for embedded Java application developers as they will no longer be able to use the same API on desktop systems and embedded platforms. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Thu Jul 20 00:59:16 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 20 Jul 2006 08:59:16 +0200 Subject: [Rxtx] jcp and jsr Message-ID: <7.0.1.0.0.20060720085812.036d9c28@sms.nl> Pascal S. de Kloe wrote: >Who is participating anyway? Is it just the four of us? > >Cheers, > >Pascal We would be more than happy to participate if we can be of any help. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From Paul.Klissner at Sun.COM Thu Jul 20 02:23:42 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Thu, 20 Jul 2006 01:23:42 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <7.0.1.0.0.20060720085221.036d88e8@sms.nl> References: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> <7.0.1.0.0.20060720085221.036d88e8@sms.nl> Message-ID: <44BF3D8E.4030705@sun.com> Guillermo Rodriguez Garcia wrote: > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul, >>> >>> For the record we're STILL supporting some PersonalJava platforms. >>> We're _almost_ at the point where we can assume that the platforms will >>> have a Collections framework, but routinely compile with a 1.1 check so >>> that we don't make that assumption unnecessarily. Of 50+ non-graphical >>> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >>> JavaScripting), and we have people asking for a back-port. >>> >>> Embedded platforms don't change in a hurry. Unlike desktop platforms, >>> embedded systems are expected to last 5-10+ years. >>> >>> There are factory automation vendors in the pharmaceutical industry who >>> are buying systems on eBay because that's the FDA validate platform. It >>> must be that make/model, spec'd sometime in the mid-90's. >>> >>> So... If you make an incompatible change TODAY figure we can start using >>> that code _at the earliest_ somewhere around 2012 or the low teens. >>> >>> Are we _really_ the only people on the list supporting embedded/factory >>> automation platforms? >>> >>> Jim >> Do you provide your own implementation classes? >> >> Why can't you just continue to use 2.1 for the embedded platform until >> 2012 if you're locked down? Are you worried bugs won't get fixed? > > If embedded platforms keep using the "old" (current) javax.comm API but > the desktop Java world starts to use a new, backwards-incompatible API, > then this will result in more trouble for embedded Java application > developers as they will no longer be able to use the same API on desktop > systems and embedded platforms. OK, I understand the situation more clearly now. The kinds of changes I'm opting don't seem difficult to design in a backward compatible way. I haven't scrutinized the other requests on the list. I guess it will be interesting to hear what the proponents for other changes have to say. Paul > > Guillermo > > -- > Guillermo Rodriguez Garcia > > Snijder Micro Systems phone +31-493-351020 > G. Rodriguez Garcia fax +31-493-351530 > Visser 25 email guille at sms.nl > NL5751 BL Deurne > The Netherlands http://www.snijder.com > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jul 20 02:46:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 20 Jul 2006 10:46:09 +0200 Subject: [Rxtx] quo vadis API/namespace (Re: jcp and jsr) In-Reply-To: <44BEDC4F.9030403@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> Message-ID: Paul, for the first time in many months, I have the impression, that we have the same agenda;-) If the "driver-level"-api changes however "nobody" will be disappointed. However, regarding the user-level-api I disagree. As fundamental changes to the API have been suggested several times I must be ignoring something. I would be delighted to learn were the current API fails - i.e. what can not be done or is overly complex based on the current API. Of course it is better fun to start something from scratch, but unless there are really substantial gains from completely redesigning an API I don't see the point. The promise of Java is to write once (which I interpret as write against the same API for all platforms). Getting VM providers like esmertec to support a new/replacement API is not a simple task, it requires a business case which for the biggest part simply does not exist. If we keep the javax.comm namespace and keep the "user-level"-api a superset of the current PortIdentifier/Port-api, the same application can work against javax.comm 2.0/3.0/future.x. Of course a factory/wrapping approach can always unify different APIs but this adds more implementation/ testing complexity to every application. So in short: Unless we find a strong argument why javax.comm can't be used I prefer that we keep it. Unless we find a strong feature / use- case that can not be handled with (an extension of) the current CommPort/CommPortIndentifier I'd prefer to keep that as well. Regards, Joachim On 20.07.2006, at 03:28, Paul Klissner wrote: > The goals I'm most interested in at the moment are: > > 1. A pluggable platform portmapping scheme wherein each platform > can determine which ports to present to the application, and > preferably as some configurable logical name. > > For example on the Sun Ray thin client platform, if an application > aquiring a view of serial ports available on the system, it will > be informed of Sun Ray serial ports if the application is running > in a session currently directed to that particular Sun Ray unit, > even though the serial port's device node happens to be server-side > deeply nested in a leaf node. If the application is not running on > a Sun Ray the port doesn't show up. The Sun Ray plugin would make > the decision about when and which ports to present to the application. > > 2. Pluggable driver-side interface where multiple platform-specific > drivers can be utilized simultaneously to introduce more flexibility > with the back end. > >> There are a number of 3rd party implementation of Java Comm, at least >> one from IBM - part of what was J9, now Websphere, or something >> (presumbly soon to get a name that has eclipse in it sometime soon). >> Esmertec has one, and there are few others rolling around. > > I have not been advocating gutting the API, since much of it is > perfectly adequate. I'm not totally opposed to making substantial > changes or improvements depending on other people's needs. There's > no reason previous versions of javax.comm need to suddenly disappear > if products need legacy support. > > >> >> If RXTX is the only implementation of the JSR with no backward >> compatibility, we've just forked Java Serial support and we (for a >> least >> one) will be worse off. We won't be able to use the new support >> because >> of a lack of support on J2ME platforms that we have no control >> over and >> RXTX/current JavaComm will be in maintenance mode or unsupported >> on all >> other platforms. > > There can't be *that* many platforms this is ported to. And it will > be no javax.usb. Seems like most of the standard platforms will > be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, > JDBC... > >> >> So, is there any chance of building a compatibility requirement into >> this. To pick are really bad example JDBC has support for a >> DataSource >> or a Driver. Could we have an ExcellentSerialPort with a fallback >> to a >> SerialPort on a class not found exception? > > Maybe, or maybe we just let people know what we are doing and > try to figure out how to get their applications ported. Might not > be that difficult. From my standpoint anyway, earthshaking > changes aren't really necessary. Others might disagree. > > Paul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Luis.Moreira at jet.uk Thu Jul 20 03:56:38 2006 From: Luis.Moreira at jet.uk (Luis Moreira) Date: Thu, 20 Jul 2006 10:56:38 +0100 Subject: [Rxtx] problems with setting up Rxtx Message-ID: Hi Guys, I have just joined the list and I am very new to JAVA. I am investigating serial communications and I just realised that the JAVAX.COMM package does not support windows anymore. I then looked at alternatives and the RXTX package came up. The problem I have at the moment is not using the classes but, rather how to install RXTX package so that I can use the classes, what do I need to install to support it and how if I write a program using it, do I make it portable. Best regards Luis From lyon at docjava.com Thu Jul 20 07:16:55 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 20 Jul 2006 09:16:55 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> Message-ID: Hi All, There has been some discussion about plugins for serial communications. As I see it, what Java really needs is a NativeLibraryManager. This is a rather much larger charge than "just" RXTX. The RXTX basic mode of operation is that we associate static blocks of code with a "System.load". Failure occurs when the class containing such a block of code is loaded AND the native library is not found. What are some of the options? 1. Do nothing, let the program fail with an exception. 2. try to catch an UnsatisfiedLinkError as a part of making the driver. 3. Search the java.library.path to see if the driver is present (i.e., guard the input). 4. Other?? In the case of either step 2 or 3, we need to fix the lack of a library. What are the options for fixing a library? 1. Do nothing, but give the user an interesting error with instructions on what to do. 2. Attempt to find the library on the file system (perhaps with user help). 3. Attempt to download the library and install it (perhaps with user permission). 4. Attempt to internalize the library as a UUEncoded serialized object and install it (better ask the user, again!). 5. Other?? My attempts at making RXTX more robust on install have led to mixed results. Altering the java.library.path has led to a bit of byte-code engineering (as this is loaded at JVM start time). Internalizing of libraries is attractive, until you realize how many libraries are involved. Dyanmically changing libraries during development is very attractive, for developers, who are changing libraries often. It is also very interesting for those who want to control the version of the libraries in the run-time. For example, something like the following will guard the input to the system load: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getInstance() { if (driver != null) return driver; if (!NativeLibDetect.isLibInPath("rxtxSerial")) fixDriver(); if (NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } At the other extreme, something like: try { System.load("rxtxSerial"); } catch (UnsatisfiedLinkError e) { System.out.println("could not load lib"); } Will at least attempt to handle the missing lib, in a simple way. Perhaps some error handling is better than none. To fix the driver, I can beam it down from a web page, using: private static void fixDriver() { File tmpDir = new File( SystemUtils.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); try { UrlUtils.getUrl(getResourceUrl(), tmpDir); String nativeLib = getNativeLibName(); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(nativeLib); if (b == null) { System.out.println("could not get:" + nativeLib); return; } File f = getRxtxHome(); Futil.writeBytes(getRxtxLibFile(), b); SystemUtils.appendJavaLibraryPath(f); } catch (IOException e) { e.printStackTrace(); } } Where the libraries are stored in the hacky dispatch: private static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isMacOs()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); System.out.println("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } Appending to the library path is tricky, at run-time: public static void appendJavaLibraryPath(File p) { if (p.isFile()) System.out.println("warning: appendJavaLibraryPath:" + "only directories are findable:"+p); System.out.println("appending:"+p+" to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:"+System.getProperty(javaLibraryPa th)); } The key is altering the core visibility of the sys_paths in the class loader: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } No, it isn't simple (nor even easy) but once the API is set we have a kind of NativeLibraryManager that helps us to make libraries, like RXTX more robust. As far as I know, there is nothing quite like it (unless you all know differently). Is there any interest in this? Forgive me if this is too far off the beaten path, but the inability to load a native library remains a source of fragility in the RXTX system, IMHO. Thanks for your thoughts! - Doug From jredman at ergotech.com Thu Jul 20 08:06:41 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 20 Jul 2006 08:06:41 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BF0C61.4020900@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> Message-ID: <44BF8DF1.4040101@ergotech.com> Paul, The issue with a new, incompatible implementation is, as you've identified below, is support for the old API. Open sourcing would be helpful, but then someone (us?) would have to maintain the source through changing versions of Window, and RXTX on Linux platforms. Or we'd have to have to versions of our codebase, which doesn't appeal too much. The maintenance issue is not impossible, but I think that in essence I'm agreeing with a comment you made earlier. IF a huge change is required, then lets get on with it. However, if the changes that are required are just extensions and enhancements, with some low-level re-engineering, then can we keep a compatible high-level API so that people needing the new features can use an extended API and those who need cross-platform compatibility can continue to use the existing features. Jim Paul Klissner wrote: > Jim Redman wrote: >> Paul, >> >> For the record we're STILL supporting some PersonalJava platforms. >> We're _almost_ at the point where we can assume that the platforms will >> have a Collections framework, but routinely compile with a 1.1 check so >> that we don't make that assumption unnecessarily. Of 50+ non-graphical >> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >> JavaScripting), and we have people asking for a back-port. >> >> Embedded platforms don't change in a hurry. Unlike desktop platforms, >> embedded systems are expected to last 5-10+ years. >> >> There are factory automation vendors in the pharmaceutical industry who >> are buying systems on eBay because that's the FDA validate platform. It >> must be that make/model, spec'd sometime in the mid-90's. >> >> So... If you make an incompatible change TODAY figure we can start using >> that code _at the earliest_ somewhere around 2012 or the low teens. >> >> Are we _really_ the only people on the list supporting embedded/factory >> automation platforms? >> >> Jim > > Do you provide your own implementation classes? > > Why can't you just continue to use 2.1 for the embedded platform until > 2012 if you're locked down? Are you worried bugs won't get fixed? > Sun might consider open sourcing the 2.1 Java source. I can't promise > that, but it's been discussed and hasn't met resistance, except > from me, because I wasn't super impressed with the code. I can probably > be persuaded to champion open sourcing that and going through the > process/legal machinations within Sun if it frees us to pursue > a JSR for a new generation of javax.comm where we can have a chunk of > common code in Open Source and each platform is simply responsible > for it's platform specific plugins. > > I don't have many opinions about this set in stone because there > are a lot of technical and pragmatic considerations such as yours > the community has that I am probably not aware of or sufficiently > sensitive to yet. I don't feel I really have the bird's eye view > of all of this yet. > > The other thing is, I can only offer 10% of my time right now, > according to my management, which is why I'm not pushing to > be the spec lead for the JSR, and want only to be a participant > to represent Sun's interests on the E.G. There is nothing sacred > about Sun employees in the JCP as far as a JSR initiated by another > entity is concerned. I am not the person everything needs to be > cleared through. Ideas I have will pass or fail based on their > merit and the community perception just like anyone else's. > > Paul > >> Paul Klissner wrote: >>> Jim Redman wrote: >>>> Paul Klissner wrote: >>>>> I'd just like to find another suitable name than javax.comm, unless >>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>> 'major revisions' are accounted for. javax.serialport? >>>> Which perhaps brings us back to what are we trying to fix and how badly. >>> The goals I'm most interested in at the moment are: >>> >>> 1. A pluggable platform portmapping scheme wherein each platform >>> can determine which ports to present to the application, and >>> preferably as some configurable logical name. >>> >>> For example on the Sun Ray thin client platform, if an application >>> aquiring a view of serial ports available on the system, it will >>> be informed of Sun Ray serial ports if the application is running >>> in a session currently directed to that particular Sun Ray unit, >>> even though the serial port's device node happens to be server-side >>> deeply nested in a leaf node. If the application is not running on >>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>> the decision about when and which ports to present to the application. >>> >>> 2. Pluggable driver-side interface where multiple platform-specific >>> drivers can be utilized simultaneously to introduce more flexibility >>> with the back end. >>> >>>> There are a number of 3rd party implementation of Java Comm, at least >>>> one from IBM - part of what was J9, now Websphere, or something >>>> (presumbly soon to get a name that has eclipse in it sometime soon). >>>> Esmertec has one, and there are few others rolling around. >>> I have not been advocating gutting the API, since much of it is >>> perfectly adequate. I'm not totally opposed to making substantial >>> changes or improvements depending on other people's needs. There's >>> no reason previous versions of javax.comm need to suddenly disappear >>> if products need legacy support. >>> >>> >>>> If RXTX is the only implementation of the JSR with no backward >>>> compatibility, we've just forked Java Serial support and we (for a least >>>> one) will be worse off. We won't be able to use the new support because >>>> of a lack of support on J2ME platforms that we have no control over and >>>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>>> other platforms. >>> There can't be *that* many platforms this is ported to. And it will >>> be no javax.usb. Seems like most of the standard platforms will >>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>> JDBC... >>> >>>> So, is there any chance of building a compatibility requirement into >>>> this. To pick are really bad example JDBC has support for a DataSource >>>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>>> SerialPort on a class not found exception? >>> Maybe, or maybe we just let people know what we are doing and >>> try to figure out how to get their applications ported. Might not >>> be that difficult. From my standpoint anyway, earthshaking >>> changes aren't really necessary. Others might disagree. >>> >>> Paul >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Paul.Klissner at Sun.COM Thu Jul 20 09:31:38 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Thu, 20 Jul 2006 08:31:38 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BF8DF1.4040101@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> <44BF8DF1.4040101@ergotech.com> Message-ID: <44BFA1DA.10301@sun.com> Jim Redman wrote: > Paul, > > The issue with a new, incompatible implementation is, as you've > identified below, is support for the old API. Open sourcing would be > helpful, but then someone (us?) would have to maintain the source > through changing versions of Window, and RXTX on Linux platforms. Or > we'd have to have to versions of our codebase, which doesn't appeal too > much. > > The maintenance issue is not impossible, but I think that in essence I'm > agreeing with a comment you made earlier. > > IF a huge change is required, then lets get on with it. However, if the > changes that are required are just extensions and enhancements, with > some low-level re-engineering, then can we keep a compatible high-level > API so that people needing the new features can use an extended API and > those who need cross-platform compatibility can continue to use the > existing features. > > Jim Guillermo made a crystal clear case and I understand the problem that that will be caused by forking the API in any sense of the word. I only want to uphold Sun's interests and resolve the problems we ran into with the RXTX community when Sun added portmapping to 3.0, which was not easily undone and was implemented as kind of a hack because it wasn't directly supported by the javax.comm architection. As I mentioned previously the changes I want to make have primarily to do with adding platform-specific portmapping via plugins, and supporting multiple javax.comm backend drivers on the same host (some ports would use one driver, others ports might use another). Also I'd like to address some bugfixes that were done in Sun's version 3.0 (including better error reporting, and more robust code for locating configuration files). Besides that, I'm not aware of any deficiences, but I've glanced other e-mails where people have suggested some. It would be good to get a summary of everyone's wishes. I've stated mine. I given much thought to what it would take to properly address EIA-422, EIA-423 and EIA-485 (if any); but those would probably be extensions. Sounds like the differences might be transparent to the API. I'll look into that more. Paul > > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul, >>> >>> For the record we're STILL supporting some PersonalJava platforms. >>> We're _almost_ at the point where we can assume that the platforms will >>> have a Collections framework, but routinely compile with a 1.1 check so >>> that we don't make that assumption unnecessarily. Of 50+ non-graphical >>> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >>> JavaScripting), and we have people asking for a back-port. >>> >>> Embedded platforms don't change in a hurry. Unlike desktop platforms, >>> embedded systems are expected to last 5-10+ years. >>> >>> There are factory automation vendors in the pharmaceutical industry who >>> are buying systems on eBay because that's the FDA validate platform. It >>> must be that make/model, spec'd sometime in the mid-90's. >>> >>> So... If you make an incompatible change TODAY figure we can start using >>> that code _at the earliest_ somewhere around 2012 or the low teens. >>> >>> Are we _really_ the only people on the list supporting embedded/factory >>> automation platforms? >>> >>> Jim >> Do you provide your own implementation classes? >> >> Why can't you just continue to use 2.1 for the embedded platform until >> 2012 if you're locked down? Are you worried bugs won't get fixed? >> Sun might consider open sourcing the 2.1 Java source. I can't promise >> that, but it's been discussed and hasn't met resistance, except >> from me, because I wasn't super impressed with the code. I can probably >> be persuaded to champion open sourcing that and going through the >> process/legal machinations within Sun if it frees us to pursue >> a JSR for a new generation of javax.comm where we can have a chunk of >> common code in Open Source and each platform is simply responsible >> for it's platform specific plugins. >> >> I don't have many opinions about this set in stone because there >> are a lot of technical and pragmatic considerations such as yours >> the community has that I am probably not aware of or sufficiently >> sensitive to yet. I don't feel I really have the bird's eye view >> of all of this yet. >> >> The other thing is, I can only offer 10% of my time right now, >> according to my management, which is why I'm not pushing to >> be the spec lead for the JSR, and want only to be a participant >> to represent Sun's interests on the E.G. There is nothing sacred >> about Sun employees in the JCP as far as a JSR initiated by another >> entity is concerned. I am not the person everything needs to be >> cleared through. Ideas I have will pass or fail based on their >> merit and the community perception just like anyone else's. >> >> Paul >> >>> Paul Klissner wrote: >>>> Jim Redman wrote: >>>>> Paul Klissner wrote: >>>>>> I'd just like to find another suitable name than javax.comm, unless >>>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>>> 'major revisions' are accounted for. javax.serialport? >>>>> Which perhaps brings us back to what are we trying to fix and how badly. >>>> The goals I'm most interested in at the moment are: >>>> >>>> 1. A pluggable platform portmapping scheme wherein each platform >>>> can determine which ports to present to the application, and >>>> preferably as some configurable logical name. >>>> >>>> For example on the Sun Ray thin client platform, if an application >>>> aquiring a view of serial ports available on the system, it will >>>> be informed of Sun Ray serial ports if the application is running >>>> in a session currently directed to that particular Sun Ray unit, >>>> even though the serial port's device node happens to be server-side >>>> deeply nested in a leaf node. If the application is not running on >>>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>>> the decision about when and which ports to present to the application. >>>> >>>> 2. Pluggable driver-side interface where multiple platform-specific >>>> drivers can be utilized simultaneously to introduce more flexibility >>>> with the back end. >>>> >>>>> There are a number of 3rd party implementation of Java Comm, at least >>>>> one from IBM - part of what was J9, now Websphere, or something >>>>> (presumbly soon to get a name that has eclipse in it sometime soon). >>>>> Esmertec has one, and there are few others rolling around. >>>> I have not been advocating gutting the API, since much of it is >>>> perfectly adequate. I'm not totally opposed to making substantial >>>> changes or improvements depending on other people's needs. There's >>>> no reason previous versions of javax.comm need to suddenly disappear >>>> if products need legacy support. >>>> >>>> >>>>> If RXTX is the only implementation of the JSR with no backward >>>>> compatibility, we've just forked Java Serial support and we (for a least >>>>> one) will be worse off. We won't be able to use the new support because >>>>> of a lack of support on J2ME platforms that we have no control over and >>>>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>>>> other platforms. >>>> There can't be *that* many platforms this is ported to. And it will >>>> be no javax.usb. Seems like most of the standard platforms will >>>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>>> JDBC... >>>> >>>>> So, is there any chance of building a compatibility requirement into >>>>> this. To pick are really bad example JDBC has support for a DataSource >>>>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>>>> SerialPort on a class not found exception? >>>> Maybe, or maybe we just let people know what we are doing and >>>> try to figure out how to get their applications ported. Might not >>>> be that difficult. From my standpoint anyway, earthshaking >>>> changes aren't really necessary. Others might disagree. >>>> >>>> Paul >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From Paul.Klissner at Sun.COM Thu Jul 20 09:45:11 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Thu, 20 Jul 2006 08:45:11 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BFA1DA.10301@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> <44BF8DF1.4040101@ergotech.com> <44BFA1DA.10301@sun.com> Message-ID: <44BFA507.3020001@sun.com> Paul Klissner wrote: > Jim Redman wrote: >> Paul, >> >> The issue with a new, incompatible implementation is, as you've >> identified below, is support for the old API. Open sourcing would be >> helpful, but then someone (us?) would have to maintain the source >> through changing versions of Window, and RXTX on Linux platforms. Or >> we'd have to have to versions of our codebase, which doesn't appeal >> too much. >> >> The maintenance issue is not impossible, but I think that in essence >> I'm agreeing with a comment you made earlier. >> >> IF a huge change is required, then lets get on with it. However, if >> the changes that are required are just extensions and enhancements, >> with some low-level re-engineering, then can we keep a compatible >> high-level API so that people needing the new features can use an >> extended API and those who need cross-platform compatibility can >> continue to use the existing features. >> >> Jim > > Guillermo made a crystal clear case and I understand the problem > that that will be caused by forking the API in any sense of the > word. I only want to uphold Sun's interests and resolve the problems > we ran into with the RXTX community when Sun added portmapping > to 3.0, which was not easily undone and was implemented as kind > of a hack because it wasn't directly supported by the javax.comm > architection. ^^^"architecture" > > As I mentioned previously the changes I want to make have primarily > to do with adding platform-specific portmapping via plugins, > and supporting multiple javax.comm backend drivers on the same > host (some ports would use one driver, others ports might use another). > > Also I'd like to address some bugfixes that were done in Sun's > version 3.0 (including better error reporting, and more robust > code for locating configuration files). Besides that, I'm not > aware of any deficiences, but I've glanced other e-mails where > people have suggested some. It would be good to get a summary > of everyone's wishes. I've stated mine. > > I given much thought to what it would take to properly address ^^^haven't > EIA-422, EIA-423 and EIA-485 (if any); but those would > probably be extensions. Sounds like the differences might > be transparent to the API. I'll look into that more. > > Paul > > >> >> Paul Klissner wrote: >>> Jim Redman wrote: >>>> Paul, >>>> >>>> For the record we're STILL supporting some PersonalJava platforms. >>>> We're _almost_ at the point where we can assume that the platforms >>>> will have a Collections framework, but routinely compile with a 1.1 >>>> check so that we don't make that assumption unnecessarily. Of 50+ >>>> non-graphical Factory Automation JavaBeans we have 2 that require >>>> Java2 (Reporting and JavaScripting), and we have people asking for a >>>> back-port. >>>> >>>> Embedded platforms don't change in a hurry. Unlike desktop >>>> platforms, embedded systems are expected to last 5-10+ years. >>>> >>>> There are factory automation vendors in the pharmaceutical industry >>>> who are buying systems on eBay because that's the FDA validate >>>> platform. It must be that make/model, spec'd sometime in the mid-90's. >>>> >>>> So... If you make an incompatible change TODAY figure we can start >>>> using that code _at the earliest_ somewhere around 2012 or the low >>>> teens. >>>> >>>> Are we _really_ the only people on the list supporting >>>> embedded/factory automation platforms? >>>> >>>> Jim >>> Do you provide your own implementation classes? >>> >>> Why can't you just continue to use 2.1 for the embedded platform until >>> 2012 if you're locked down? Are you worried bugs won't get fixed? >>> Sun might consider open sourcing the 2.1 Java source. I can't promise >>> that, but it's been discussed and hasn't met resistance, except >>> from me, because I wasn't super impressed with the code. I can probably >>> be persuaded to champion open sourcing that and going through the >>> process/legal machinations within Sun if it frees us to pursue >>> a JSR for a new generation of javax.comm where we can have a chunk of >>> common code in Open Source and each platform is simply responsible >>> for it's platform specific plugins. >>> >>> I don't have many opinions about this set in stone because there >>> are a lot of technical and pragmatic considerations such as yours >>> the community has that I am probably not aware of or sufficiently >>> sensitive to yet. I don't feel I really have the bird's eye view >>> of all of this yet. >>> >>> The other thing is, I can only offer 10% of my time right now, >>> according to my management, which is why I'm not pushing to >>> be the spec lead for the JSR, and want only to be a participant >>> to represent Sun's interests on the E.G. There is nothing sacred >>> about Sun employees in the JCP as far as a JSR initiated by another >>> entity is concerned. I am not the person everything needs to be >>> cleared through. Ideas I have will pass or fail based on their >>> merit and the community perception just like anyone else's. >>> >>> Paul >>> >>>> Paul Klissner wrote: >>>>> Jim Redman wrote: >>>>>> Paul Klissner wrote: >>>>>>> I'd just like to find another suitable name than javax.comm, unless >>>>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>>>> 'major revisions' are accounted for. javax.serialport? >>>>>> Which perhaps brings us back to what are we trying to fix and how >>>>>> badly. >>>>> The goals I'm most interested in at the moment are: >>>>> >>>>> 1. A pluggable platform portmapping scheme wherein each platform >>>>> can determine which ports to present to the application, and >>>>> preferably as some configurable logical name. >>>>> >>>>> For example on the Sun Ray thin client platform, if an application >>>>> aquiring a view of serial ports available on the system, it will >>>>> be informed of Sun Ray serial ports if the application is running >>>>> in a session currently directed to that particular Sun Ray unit, >>>>> even though the serial port's device node happens to be server-side >>>>> deeply nested in a leaf node. If the application is not running on >>>>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>>>> the decision about when and which ports to present to the application. >>>>> >>>>> 2. Pluggable driver-side interface where multiple platform-specific >>>>> drivers can be utilized simultaneously to introduce more flexibility >>>>> with the back end. >>>>> >>>>>> There are a number of 3rd party implementation of Java Comm, at >>>>>> least one from IBM - part of what was J9, now Websphere, or >>>>>> something (presumbly soon to get a name that has eclipse in it >>>>>> sometime soon). Esmertec has one, and there are few others rolling >>>>>> around. >>>>> I have not been advocating gutting the API, since much of it is >>>>> perfectly adequate. I'm not totally opposed to making substantial >>>>> changes or improvements depending on other people's needs. There's >>>>> no reason previous versions of javax.comm need to suddenly disappear >>>>> if products need legacy support. >>>>> >>>>> >>>>>> If RXTX is the only implementation of the JSR with no backward >>>>>> compatibility, we've just forked Java Serial support and we (for a >>>>>> least one) will be worse off. We won't be able to use the new >>>>>> support because of a lack of support on J2ME platforms that we >>>>>> have no control over and RXTX/current JavaComm will be in >>>>>> maintenance mode or unsupported on all other platforms. >>>>> There can't be *that* many platforms this is ported to. And it will >>>>> be no javax.usb. Seems like most of the standard platforms will >>>>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>>>> JDBC... >>>>> >>>>>> So, is there any chance of building a compatibility requirement >>>>>> into this. To pick are really bad example JDBC has support for a >>>>>> DataSource or a Driver. Could we have an ExcellentSerialPort with >>>>>> a fallback to a SerialPort on a class not found exception? >>>>> Maybe, or maybe we just let people know what we are doing and >>>>> try to figure out how to get their applications ported. Might not >>>>> be that difficult. From my standpoint anyway, earthshaking >>>>> changes aren't really necessary. Others might disagree. >>>>> >>>>> Paul >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From jredman at ergotech.com Thu Jul 20 10:30:01 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 20 Jul 2006 10:30:01 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BFA507.3020001@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> <44BF8DF1.4040101@ergotech.com> <44BFA1DA.10301@sun.com> <44BFA507.3020001@sun.com> Message-ID: <44BFAF89.5010003@ergotech.com> Thast what hapens if you post late at nihgt nad erly in the moning as wel. :) Paul Klissner wrote: > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul, >>> >>> The issue with a new, incompatible implementation is, as you've >>> identified below, is support for the old API. Open sourcing would be >>> helpful, but then someone (us?) would have to maintain the source >>> through changing versions of Window, and RXTX on Linux platforms. Or >>> we'd have to have to versions of our codebase, which doesn't appeal >>> too much. >>> >>> The maintenance issue is not impossible, but I think that in essence >>> I'm agreeing with a comment you made earlier. >>> >>> IF a huge change is required, then lets get on with it. However, if >>> the changes that are required are just extensions and enhancements, >>> with some low-level re-engineering, then can we keep a compatible >>> high-level API so that people needing the new features can use an >>> extended API and those who need cross-platform compatibility can >>> continue to use the existing features. >>> >>> Jim >> Guillermo made a crystal clear case and I understand the problem >> that that will be caused by forking the API in any sense of the >> word. I only want to uphold Sun's interests and resolve the problems >> we ran into with the RXTX community when Sun added portmapping >> to 3.0, which was not easily undone and was implemented as kind >> of a hack because it wasn't directly supported by the javax.comm >> architection. > ^^^"architecture" >> As I mentioned previously the changes I want to make have primarily >> to do with adding platform-specific portmapping via plugins, >> and supporting multiple javax.comm backend drivers on the same >> host (some ports would use one driver, others ports might use another). >> >> Also I'd like to address some bugfixes that were done in Sun's >> version 3.0 (including better error reporting, and more robust >> code for locating configuration files). Besides that, I'm not >> aware of any deficiences, but I've glanced other e-mails where >> people have suggested some. It would be good to get a summary >> of everyone's wishes. I've stated mine. >> >> I given much thought to what it would take to properly address > ^^^haven't >> EIA-422, EIA-423 and EIA-485 (if any); but those would >> probably be extensions. Sounds like the differences might >> be transparent to the API. I'll look into that more. >> >> Paul >> >> >>> Paul Klissner wrote: >>>> Jim Redman wrote: >>>>> Paul, >>>>> >>>>> For the record we're STILL supporting some PersonalJava platforms. >>>>> We're _almost_ at the point where we can assume that the platforms >>>>> will have a Collections framework, but routinely compile with a 1.1 >>>>> check so that we don't make that assumption unnecessarily. Of 50+ >>>>> non-graphical Factory Automation JavaBeans we have 2 that require >>>>> Java2 (Reporting and JavaScripting), and we have people asking for a >>>>> back-port. >>>>> >>>>> Embedded platforms don't change in a hurry. Unlike desktop >>>>> platforms, embedded systems are expected to last 5-10+ years. >>>>> >>>>> There are factory automation vendors in the pharmaceutical industry >>>>> who are buying systems on eBay because that's the FDA validate >>>>> platform. It must be that make/model, spec'd sometime in the mid-90's. >>>>> >>>>> So... If you make an incompatible change TODAY figure we can start >>>>> using that code _at the earliest_ somewhere around 2012 or the low >>>>> teens. >>>>> >>>>> Are we _really_ the only people on the list supporting >>>>> embedded/factory automation platforms? >>>>> >>>>> Jim >>>> Do you provide your own implementation classes? >>>> >>>> Why can't you just continue to use 2.1 for the embedded platform until >>>> 2012 if you're locked down? Are you worried bugs won't get fixed? >>>> Sun might consider open sourcing the 2.1 Java source. I can't promise >>>> that, but it's been discussed and hasn't met resistance, except >>>> from me, because I wasn't super impressed with the code. I can probably >>>> be persuaded to champion open sourcing that and going through the >>>> process/legal machinations within Sun if it frees us to pursue >>>> a JSR for a new generation of javax.comm where we can have a chunk of >>>> common code in Open Source and each platform is simply responsible >>>> for it's platform specific plugins. >>>> >>>> I don't have many opinions about this set in stone because there >>>> are a lot of technical and pragmatic considerations such as yours >>>> the community has that I am probably not aware of or sufficiently >>>> sensitive to yet. I don't feel I really have the bird's eye view >>>> of all of this yet. >>>> >>>> The other thing is, I can only offer 10% of my time right now, >>>> according to my management, which is why I'm not pushing to >>>> be the spec lead for the JSR, and want only to be a participant >>>> to represent Sun's interests on the E.G. There is nothing sacred >>>> about Sun employees in the JCP as far as a JSR initiated by another >>>> entity is concerned. I am not the person everything needs to be >>>> cleared through. Ideas I have will pass or fail based on their >>>> merit and the community perception just like anyone else's. >>>> >>>> Paul >>>> >>>>> Paul Klissner wrote: >>>>>> Jim Redman wrote: >>>>>>> Paul Klissner wrote: >>>>>>>> I'd just like to find another suitable name than javax.comm, unless >>>>>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>>>>> 'major revisions' are accounted for. javax.serialport? >>>>>>> Which perhaps brings us back to what are we trying to fix and how >>>>>>> badly. >>>>>> The goals I'm most interested in at the moment are: >>>>>> >>>>>> 1. A pluggable platform portmapping scheme wherein each platform >>>>>> can determine which ports to present to the application, and >>>>>> preferably as some configurable logical name. >>>>>> >>>>>> For example on the Sun Ray thin client platform, if an application >>>>>> aquiring a view of serial ports available on the system, it will >>>>>> be informed of Sun Ray serial ports if the application is running >>>>>> in a session currently directed to that particular Sun Ray unit, >>>>>> even though the serial port's device node happens to be server-side >>>>>> deeply nested in a leaf node. If the application is not running on >>>>>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>>>>> the decision about when and which ports to present to the application. >>>>>> >>>>>> 2. Pluggable driver-side interface where multiple platform-specific >>>>>> drivers can be utilized simultaneously to introduce more flexibility >>>>>> with the back end. >>>>>> >>>>>>> There are a number of 3rd party implementation of Java Comm, at >>>>>>> least one from IBM - part of what was J9, now Websphere, or >>>>>>> something (presumbly soon to get a name that has eclipse in it >>>>>>> sometime soon). Esmertec has one, and there are few others rolling >>>>>>> around. >>>>>> I have not been advocating gutting the API, since much of it is >>>>>> perfectly adequate. I'm not totally opposed to making substantial >>>>>> changes or improvements depending on other people's needs. There's >>>>>> no reason previous versions of javax.comm need to suddenly disappear >>>>>> if products need legacy support. >>>>>> >>>>>> >>>>>>> If RXTX is the only implementation of the JSR with no backward >>>>>>> compatibility, we've just forked Java Serial support and we (for a >>>>>>> least one) will be worse off. We won't be able to use the new >>>>>>> support because of a lack of support on J2ME platforms that we >>>>>>> have no control over and RXTX/current JavaComm will be in >>>>>>> maintenance mode or unsupported on all other platforms. >>>>>> There can't be *that* many platforms this is ported to. And it will >>>>>> be no javax.usb. Seems like most of the standard platforms will >>>>>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>>>>> JDBC... >>>>>> >>>>>>> So, is there any chance of building a compatibility requirement >>>>>>> into this. To pick are really bad example JDBC has support for a >>>>>>> DataSource or a Driver. Could we have an ExcellentSerialPort with >>>>>>> a fallback to a SerialPort on a class not found exception? >>>>>> Maybe, or maybe we just let people know what we are doing and >>>>>> try to figure out how to get their applications ported. Might not >>>>>> be that difficult. From my standpoint anyway, earthshaking >>>>>> changes aren't really necessary. Others might disagree. >>>>>> >>>>>> Paul >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Thu Jul 20 10:31:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 20 Jul 2006 10:31:57 -0600 (MDT) Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEA802.7060508@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: > PROJECT SCOPE: > ------------- > > Also, we should think carefully about what the scope of > this project would be. Should it be javax."comm" which > handles both serial and parallel (is parallel going by the > wayside). Should it be split into two project: > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > > Should we differentiate between single-ended serial > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > quasi-multidrop and full multidrop busses such as > EIA422, EIA432 and EIA485? If we really were to > add I2C support to the API, we'd have to delve into > the semantics more, because there could be some > implicit decoding of the bus the API users would > want to see. > Hi Paul The way RXTX works, which is a fair representation of the people using the API, is complete support for RIA232, minimal support for IEEE1284. From what I understand, Sun was going along the same lines. If we combined both projects, we would have half a parallel port implementation. I see maybe 4 requests for features not in the parallel support a year. The other protocols should not be limited by a JSR which is going to be focused upon serial port interests. The IEA485 hacks in RXTX along with I2C and Raw should _not_ be considered a strong basis for extending the API to cover these protocols. If people want to do real implementations, they should not face a 'standard' which wasnt really focused upon their interests. I think we understand the parallel port issues fairly well but have not implemented many features and I don't know if we would. So a versatile API is favorable but I do not think we have the proper community to represent much more than Serial. We could provide a framework or maybe just a model for further work with other standards. -- Trent Jarvi tjarvi at qbang.org From naranjo.manuel at gmail.com Thu Jul 20 10:49:33 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Thu, 20 Jul 2006 13:49:33 -0300 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <44BFB41D.4010604@gmail.com> Trent Jarvi wrote: >> PROJECT SCOPE: >> ------------- >> >> Also, we should think carefully about what the scope of >> this project would be. Should it be javax."comm" which >> handles both serial and parallel (is parallel going by the >> wayside). Should it be split into two project: >> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >> >> Should we differentiate between single-ended serial >> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >> quasi-multidrop and full multidrop busses such as >> EIA422, EIA432 and EIA485? If we really were to >> add I2C support to the API, we'd have to delve into >> the semantics more, because there could be some >> implicit decoding of the bus the API users would >> want to see. >> > > Hi Paul > > The way RXTX works, which is a fair representation of the people using the > API, is complete support for RIA232, minimal support for IEEE1284. From > what I understand, Sun was going along the same lines. If we combined > both projects, we would have half a parallel port implementation. I see > maybe 4 requests for features not in the parallel support a year. > > The other protocols should not be limited by a JSR which is going to be > focused upon serial port interests. The IEA485 hacks in RXTX along with > I2C and Raw should _not_ be considered a strong basis for extending the > API to cover these protocols. If people want to do real implementations, > they should not face a 'standard' which wasnt really focused upon their > interests. I think we understand the parallel port issues fairly well but > have not implemented many features and I don't know if we would. > > So a versatile API is favorable but I do not think we have the proper > community to represent much more than Serial. We could provide a > framework or maybe just a model for further work with other standards. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Hi, I agree with Trent, as far as I have seen most projects that were using RXTX and Java Comm where designed to work only with Serial Ports. What is fact is that a Parallel port can not be modeled at all like a Serial Port, except that they both expose and Input Stream and an Output Stream. As I have read there is a huge market of embedded applications using port accessing. We could take two different aproaches with the JSR, one could be define a way to access every kind of port independent of the implementation of the port himself. We could access Serial, Parallel, I2C, USB, etc. But we will have huge problems with it, because we will have to face a lot of low level programming which of course will be platform dependent, and that is were the write one use everywhere of Java could dye. The other approach is to define an Api that only supports Serial Ports, compatible with the one that is defined in javax.comm 2.0, and make some classes that extend that packages, maybe even in another package, like AWT and JSWING do. We then could eventually extend to other kinds of ports but that will require a lot of work more. I'm not a person specialized on Informatical Engineering, so I do not think I can give a hand on Low Level programming, I do can help with the Java part, debugging and testing. Regards, Manuel From brian at mbari.org Thu Jul 20 11:19:33 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 20 Jul 2006 10:19:33 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <8BFCAB48-6302-44CD-ABF0-560BC04AD26E@mbari.org> > The way RXTX works, which is a fair representation of the people > using the > API, is complete support for RIA232, minimal support for IEEE1284. > From > what I understand, Sun was going along the same lines. If we combined > both projects, we would have half a parallel port implementation. > I see > maybe 4 requests for features not in the parallel support a year. > > The other protocols should not be limited by a JSR which is going > to be > focused upon serial port interests. The IEA485 hacks in RXTX along > with > I2C and Raw should _not_ be considered a strong basis for extending > the > API to cover these protocols. If people want to do real > implementations, > they should not face a 'standard' which wasnt really focused upon > their > interests. I think we understand the parallel port issues fairly > well but > have not implemented many features and I don't know if we would. > > So a versatile API is favorable but I do not think we have the proper > community to represent much more than Serial. We could provide a > framework or maybe just a model for further work with other standards. I agree completely. Folks use RXTX for serial ports. In my field (Oceanography), we uses RS232 to talk to nearly all our instruments. So we really need a great implementation of serial port communications in Java that runs on a variety of architectures. I'd prefer if the JSR focused on that. >> I given much thought to what it would take to properly address >> > ^^^haven't > >> EIA-422, EIA-423 and EIA-485 (if any); but those would >> probably be extensions. Sounds like the differences might >> be transparent to the API. I'll look into that more. I've had good luck using the current implementation of RXTX with RS422, although you'll need to use a pin converter. my 2 cents. Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060720/fb956c68/attachment-0345.html From pascal at quies.net Fri Jul 21 15:43:40 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Fri, 21 Jul 2006 23:43:40 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: Message-ID: <200607212343.40882.pascal@quies.net> Op donderdag 20 juli 2006 15:16, schreef Dr. Douglas Lyon: > Hi All, > There has been some discussion about plugins for serial communications. > > As I see it, what Java really needs is a NativeLibraryManager. This is > a rather much larger charge than "just" RXTX. > > The RXTX basic mode of operation is that we associate static > blocks of code with a "System.load". > > Failure occurs when the class containing such a block of code is > loaded AND the native library is not found. > > What are some of the options? > > 1. Do nothing, let the program fail with an exception. > 2. try to catch an UnsatisfiedLinkError as a part of making > the driver. > 3. Search the java.library.path to see if the driver is present > (i.e., guard the input). > 4. Other?? > > In the case of either step 2 or 3, we need to fix the lack of a library. > > What are the options for fixing a library? > 1. Do nothing, but give the user an interesting error with instructions on > what to do. > 2. Attempt to find the library on the file system (perhaps with user help). > 3. Attempt to download the library and install it (perhaps with user > permission). > 4. Attempt to internalize the library as a UUEncoded serialized object and > install it (better ask the user, again!). > 5. Other?? 5. Put the binaries together with the attached classes in a jar. Joachim told me that and it works! I forgot to publish the results. :$ ---- begin example import org.rxtx.CommunicationAPI; ... CommunicationAPI commExtension = new CommunicationAPI(); try { commExtenios.loadNativeLibraries(); } catch (Exception e) { // We *need* javax.comm } // Now we have the extension available. ... ---- end example Do you like it? Commens anyone? The path to the libraries is in the form of /native/rxtx/-/{libserial,libparallel} so /native/rxtx/windows-i386/libserial would do. I asked for binaries but only Joachim offered me help with OS X on the next release. Does anyone have javax.comm warper classes? -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 6781 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060721/b39a5592/CommunicationAPI-0344.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: PlatformNotSupportedException.java Type: text/x-java Size: 1621 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060721/b39a5592/PlatformNotSupportedException-0344.bin From pascal at quies.net Fri Jul 21 15:45:30 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Fri, 21 Jul 2006 23:45:30 +0200 Subject: [Rxtx] quo vadis API/namespace (Re: jcp and jsr) In-Reply-To: References: <44BEDC4F.9030403@sun.com> Message-ID: <200607212345.30495.pascal@quies.net> Op donderdag 20 juli 2006 10:46, schreef Joachim Buechse: > So in short: Unless we find a strong argument why javax.comm can't be > used I prefer that we keep it. Unless we find a strong feature / use- > case that can not be handled with (an extension of) the current > CommPort/CommPortIndentifier I'd prefer to keep that as well. I seem to be the only one who sees failures in the API so lets keep it that way. Now how do we get a JSR/lisence if we don't want any changes? :P From lyon at docjava.com Sat Jul 22 06:07:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 22 Jul 2006 08:07:03 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607212343.40882.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> Message-ID: Hi All, I like the idea of the native lib in a jar with other classes. An alternative I did not know would work. Now, if you place the rxtx classes and native library in the same jar, do they both have to be in any specific place in order to be found? In my approach, you can locate the native library at run-time, and you need not alter any environmental variables nor mangle the JDK home. Thus, each user can have a different native library, one for development and one for release, for example. Regards, - Doug >Op donderdag 20 juli 2006 15:16, schreef Dr. Douglas Lyon: >> Hi All, >> There has been some discussion about plugins for serial communications. >> >> As I see it, what Java really needs is a NativeLibraryManager. This is >> a rather much larger charge than "just" RXTX. >> >> The RXTX basic mode of operation is that we associate static >> blocks of code with a "System.load". >> >> Failure occurs when the class containing such a block of code is >> loaded AND the native library is not found. >> >> What are some of the options? >> >> 1. Do nothing, let the program fail with an exception. >> 2. try to catch an UnsatisfiedLinkError as a part of making >> the driver. >> 3. Search the java.library.path to see if the driver is present >> (i.e., guard the input). >> 4. Other?? >> >> In the case of either step 2 or 3, we need to fix the lack of a library. >> >> What are the options for fixing a library? >> 1. Do nothing, but give the user an interesting error with instructions on >> what to do. >> 2. Attempt to find the library on the file system (perhaps with user help). >> 3. Attempt to download the library and install it (perhaps with user >> permission). >> 4. Attempt to internalize the library as a UUEncoded serialized object and >> install it (better ask the user, again!). >> 5. Other?? > >5. Put the binaries together with the attached classes in a jar. > >Joachim told me that and it works! I forgot to publish the results. :$ > > >---- begin example >import org.rxtx.CommunicationAPI; > >... >CommunicationAPI commExtension = new CommunicationAPI(); >try { > commExtenios.loadNativeLibraries(); >} catch (Exception e) { > // We *need* javax.comm >} > >// Now we have the extension available. >... >---- end example > > >Do you like it? Commens anyone? > > >The path to the libraries is in the form >of /native/rxtx/-/{libserial,libparallel} >so /native/rxtx/windows-i386/libserial would do. > >I asked for binaries but only Joachim offered me help with OS X on the next >release. > >Does anyone have javax.comm warper classes? > >Attachment converted: PowerBookHd:CommunicationAPI.java (TEXT/ttxt) (001C1686) >Attachment converted: PowerBookHd:PlatformNotSupporte#1C1687.java >(TEXT/ttxt) (001C1687) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 22 07:06:06 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 15:06:06 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607212343.40882.pascal@quies.net> Message-ID: <200607221506.07140.pascal@quies.net> > Now, if you place the rxtx classes and native library in the same > jar, do they both have to be in any specific place in order to be found? Answer: > >The path to the libraries is in the form > >of /native/rxtx/-/{libserial,libparallel} > >so /native/rxtx/windows-i386/libserial would do. I'me looking for the various os.name and os.arch values right now. From lyon at docjava.com Sat Jul 22 08:06:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 22 Jul 2006 10:06:26 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607221506.07140.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> <200607221506.07140.pascal@quies.net> Message-ID: Hi All, Here is how I have arranged my signed versions of the native binaries: http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/windows/native.jar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/native.jar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/linux/native.jar Then I do: public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isMacOs()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); System.out.println("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } My new-age NativeLibraryManger concept-thang allows you to write stuff like: /** * This method fixes the driver by beaming over * to the tmp directory a native.jar file. * The native.jar file is signed and its * native libs are beamed over to the user home directory * ~/.rxtx/
* Finally, the java.library.path is altered to include
* ~/.rxtx/ */ private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), NativeLibraryManager.mapLibraryName("rxtxSerial")); } catch (IOException e) { e.printStackTrace(); } } I do a lazy singleton design pattern: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getInstance() { if (driver != null) return driver; if (!NativeLibraryManager.isLibInPath("rxtxSerial")) fixDriver(); if (NativeLibraryManager.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } I am at a cross-roads here, since a file-based distro might be preferable to a URL based distro. To make this really general, and to "remember" where the last version of a native library came from, I serialize a bean into user preferences The user can then store native libraries anywhere, remembering the location in the preferences. What is the general feeling about this? Thanks! - Doug > > Now, if you place the rxtx classes and native library in the same >> jar, do they both have to be in any specific place in order to be found? > >Answer: > >> >The path to the libraries is in the form >> >of /native/rxtx/-/{libserial,libparallel} >> >so /native/rxtx/windows-i386/libserial would do. > >I'me looking for the various os.name and os.arch values right now. >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Sat Jul 22 10:30:55 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 22 Jul 2006 11:30:55 -0500 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607212343.40882.pascal@quies.net> Message-ID: <44C252BF.6040404@cox.net> Dr. Douglas Lyon wrote: > Hi All, > I like the idea of the native lib in a jar with other classes. > An alternative I did not know would work. I have several applications that run with a security policy. In these applications, native library loading will require an appropriate FilePermission that should be known about ahead of time. The current native library implementation will require the native library to be extracted from the jar and written to disk, requiring a FilePermission("...","write") for that file, and then will also require read access to load the library. I personally don't want to give write access to a JVM for a shared library which can provide a point of abuse by errant code. Gregg Wonderly From gergg at cox.net Sat Jul 22 10:33:52 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 22 Jul 2006 11:33:52 -0500 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607212343.40882.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> Message-ID: <44C25370.9070506@cox.net> >Pascal S. de Kloe wrote: >>> I am also not sure if >>> the api should unify corresponding cu. and tty. ports into one single >>> port. >> >> I think the API should hide low-level details like devicefiles. > >Not all ports have device files. It's long been my goal to add support >for virtual serial ports, that is, serial ports on Ethernet terminal >servers, for example integrating RFC2217. This means that the port name >is some combination of an IP address and TCP port number. Nothing in /dev. What I think would make the most sense is a simple "device" enumeration Server Provider Interface that would bring port objects into the JVM based on the platform JVM providers knowledge of how to enumerate those ports. Application writers would provide a plugin using the SPI that would codify those devices into named entities that they are interested in. public interface HardwarePort { public String getName(); public String getHardwareID(); public String getManufacturer(); public List getCapabilities(); public Object getImplementation(); } public interface PortCapability { public String getDescription(); public CapabilityId getIdentifier(); } public enum CapabilityId { INPUT, // Can receive input OUTPUT, // Can send output ASYNCHRONOUS, // Can send and receive at the same time SYNCHRONOUS, // No synchronous I/O ADDRESSABLE // Port has an address associated } Then, you might imagine that the enumerated capabilities had a standardized/specified interface that you'd find implemented on ports that had such capabilities. The getImplementation() method would return the implementation class provided by the JVM provider that had all of the interfaces tied to it. These are just some quick thoughts, pick away at them. I am very interested in getting a new comm api in place which can provide the ability for all USB connected devices to have drivers provided as 100% java for all non-timing critical types of device interfaces. The JVM provider should have an SPI to write to which will enable them to abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into something that we can talk 100% java to. That's my big desire. Starting with something simple which gives a good start in that direction would be great! Gregg Wonderly From pascal at quies.net Sat Jul 22 10:43:27 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 18:43:27 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <44C252BF.6040404@cox.net> References: <44C252BF.6040404@cox.net> Message-ID: <200607221843.27765.pascal@quies.net> Op zaterdag 22 juli 2006 18:30, schreef Gregg Wonderly: > Dr. Douglas Lyon wrote: > > Hi All, > > I like the idea of the native lib in a jar with other classes. > > An alternative I did not know would work. > > I have several applications that run with a security policy. In these > applications, native library loading will require an appropriate > FilePermission that should be known about ahead of time. The current > native library implementation will require the native library to be > extracted from the jar and written to disk, requiring a > FilePermission("...","write") for that file, and then will also require > read access to load the library. I personally don't want to give write > access to a JVM for a shared library which can provide a point of abuse by > errant code. > > Gregg Wonderly That's indeed a pitty limitation. It creates a lot of possible exceptions too. On the other hand, any native lib passes the securiy model. Applications who can access hardware ports can be expected to create files, right? From pascal at quies.net Sat Jul 22 10:54:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 18:54:13 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607221506.07140.pascal@quies.net> Message-ID: <200607221854.13467.pascal@quies.net> Hi Dr., We're both trying to do the same thing. The CommunicationAPI does not only look at the OS but it also indexes the available hardware architectures and does not need OsUtils. Any Java 2 runtime will do. The plan was to make a single JAR with the binaries for all supported platforms, the RXTX gnu.io package and the javax.comm wrapers. A signed version would be nice. A few questions remain tough. Does anybody know how Sun uses the SunOS and Solaris identifiers for the Java property os.name? Op zaterdag 22 juli 2006 16:06, schreef Dr. Douglas Lyon: > Hi All, > Here is how I have arranged my signed versions of the native > binaries: > http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/windows/native.j >ar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/native.jar > http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/linux/native.jar > > Then I do: > public static URL getResourceUrl() throws MalformedURLException { > String rxtxUrl = "http://show.docjava.com:8086/" + > "book/cgij/code/jnlp/libs/rxtx/"; > if (OsUtils.isLinux()) > return new URL(rxtxUrl + "linux/native.jar"); > if (OsUtils.isMacOs()) > return new URL(rxtxUrl + "mac/native.jar"); > if (OsUtils.isWindows()) > return new URL(rxtxUrl + "windows/native.jar"); > System.out.println("no automatic install supported for this > platform. " + > "Please e-mail lyon at docjava.com with a bug report"); > return null; > } > > My new-age NativeLibraryManger concept-thang allows you to > write stuff like: > > /** > * This method fixes the driver by beaming over > * to the tmp directory a native.jar file. > * The native.jar file is signed and its > * native libs are beamed over to the user home directory > * ~/.rxtx/
> * Finally, the java.library.path is altered to include
> * ~/.rxtx/ > */ > private static void fixDriver() { > > try { > NativeLibraryManager.fixDriver(getResourceUrl(), > NativeLibraryManager.mapLibraryName("rxtxSerial")); > } catch (IOException e) { > e.printStackTrace(); > } > } > > I do a lazy singleton design pattern: > > public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public synchronized static RXTXCommDriver getInstance() { > if (driver != null) return driver; > if (!NativeLibraryManager.isLibInPath("rxtxSerial")) > fixDriver(); > if (NativeLibraryManager.isLibInPath("rxtxSerial")) { > driver = new RXTXCommDriver(); > driver.initialize(); > } > return driver; > } > > I am at a cross-roads here, since a file-based distro might be preferable > to a URL based distro. To make this really general, and to "remember" where > the last version of a native library came from, I serialize a bean into > user preferences > The user can then store native libraries anywhere, remembering the location > in the preferences. > > What is the general feeling about this? > > Thanks! > - Doug > > > > Now, if you place the rxtx classes and native library in the same > >> > >> jar, do they both have to be in any specific place in order to be > >> found? > > > >Answer: > >> >The path to the libraries is in the form > >> >of /native/rxtx/-/{libserial,libparallel} > >> >so /native/rxtx/windows-i386/libserial would do. > > > >I'me looking for the various os.name and os.arch values right now. > >_______________________________________________ > >Rxtx mailing list > >Rxtx at qbang.org > >http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Sat Jul 22 11:17:51 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 22 Jul 2006 19:17:51 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <44C252BF.6040404@cox.net> References: <200607212343.40882.pascal@quies.net> <44C252BF.6040404@cox.net> Message-ID: <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> We could easily have a stub method / flag that allows you to explicitly load the native library (via System.loadLibrary ie from the java.library.path). In this case the "auto-extraction" would not take place. On 22.07.2006, at 18:30, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> Hi All, >> I like the idea of the native lib in a jar with other classes. >> An alternative I did not know would work. > > I have several applications that run with a security policy. In these > applications, native library loading will require an appropriate > FilePermission > that should be known about ahead of time. The current native library > implementation will require the native library to be extracted from > the jar and > written to disk, requiring a FilePermission("...","write") for that > file, and > then will also require read access to load the library. I > personally don't want > to give write access to a JVM for a shared library which can > provide a point of > abuse by errant code. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 22 11:20:19 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 19:20:19 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607221506.07140.pascal@quies.net> Message-ID: <200607221920.20096.pascal@quies.net> The attachment setup.zip contains a very small update of CommunicationAPI and a good start with the various platforms. All we need to do is fill those directories with binaries. Various binaries are missing the pararlel library. Why is that? -------------- next part -------------- A non-text attachment was scrubbed... Name: setup.zip Type: application/x-zip Size: 8459 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060722/12770623/setup-0343.bin From gregg at cytetech.com Thu Jul 20 21:32:55 2006 From: gregg at cytetech.com (Gregg Wonderly) Date: Thu, 20 Jul 2006 22:32:55 -0500 Subject: [Rxtx] jcp and jsr Message-ID: <44C04AE7.9050800@cytetech.com> >Pascal S. de Kloe wrote: >>> I am also not sure if >>> the api should unify corresponding cu. and tty. ports into one single >>> port. >> >> I think the API should hide low-level details like devicefiles. > >Not all ports have device files. It's long been my goal to add support >for virtual serial ports, that is, serial ports on Ethernet terminal >servers, for example integrating RFC2217. This means that the port name >is some combination of an IP address and TCP port number. Nothing in /dev. What I think would make the most sense is a simple "device" enumeration Server Provider Interface that would bring port objects into the JVM based on the platform JVM providers knowledge of how to enumerate those ports. Application writers would provide a plugin using the SPI that would codify those devices into named entities that they are interested in. public interface HardwarePort { public String getName(); public String getHardwareID(); public String getManufacturer(); public List getCapabilities(); public Object getImplementation(); } public interface PortCapability { public String getDescription(); public CapabilityId getIdentifier(); } public enum CapabilityId { INPUT, // Can receive input OUTPUT, // Can send output ASYNCHRONOUS, // Can send and receive at the same time SYNCHRONOUS, // No synchronous I/O ADDRESSABLE // Port has an address associated } Then, you might imagine that the enumerated capabilities had a standardized/specified interface that you'd find implemented on ports that had such capabilities. The getImplementation() method would return the implementation class provided by the JVM provider that had all of the interfaces tied to it. These are just some quick thoughts, pick away at them. I am very interested in getting a new comm api in place which can provide the ability for all USB connected devices to have drivers provided as 100% java for all non-timing critical types of device interfaces. The JVM provider should have an SPI to write to which will enable them to abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into something that we can talk 100% java to. That's my big desire. Starting with something simple which gives a good start in that direction would be great! Gregg Wonderly From pascal at quies.net Sat Jul 22 11:32:03 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 19:32:03 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44C25370.9070506@cox.net> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> Message-ID: <200607221932.04194.pascal@quies.net> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: > >Pascal S. de Kloe wrote: > >>> I am also not sure if > >>> the api should unify corresponding cu. and tty. ports into one single > >>> port. > >> > >> I think the API should hide low-level details like devicefiles. > > > >Not all ports have device files. It's long been my goal to add support > >for virtual serial ports, that is, serial ports on Ethernet terminal > >servers, for example integrating RFC2217. This means that the port name > >is some combination of an IP address and TCP port number. Nothing in > > /dev. > > What I think would make the most sense is a simple "device" enumeration > Server Provider Interface that would bring port objects into the JVM based > on the platform JVM providers knowledge of how to enumerate those ports. > Application writers would provide a plugin using the SPI that would codify > those devices into named entities that they are interested in. > > public interface HardwarePort { > public String getName(); > public String getHardwareID(); > public String getManufacturer(); > public List getCapabilities(); > public Object getImplementation(); > } > > public interface PortCapability { > public String getDescription(); > public CapabilityId getIdentifier(); > } > > public enum CapabilityId { > INPUT, // Can receive input > OUTPUT, // Can send output > ASYNCHRONOUS, // Can send and receive at the same time > SYNCHRONOUS, // No synchronous I/O > ADDRESSABLE // Port has an address associated > } > > Then, you might imagine that the enumerated capabilities had a > standardized/specified interface that you'd find implemented on ports that > had such capabilities. > > The getImplementation() method would return the implementation class > provided by the JVM provider that had all of the interfaces tied to it. > > These are just some quick thoughts, pick away at them. > > I am very interested in getting a new comm api in place which can provide > the ability for all USB connected devices to have drivers provided as 100% > java for all non-timing critical types of device interfaces. > > The JVM provider should have an SPI to write to which will enable them to > abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into something > that we can talk 100% java to. > > That's my big desire. Starting with something simple which gives a good > start in that direction would be great! That was exactly my wish too. The point people brought up was: 1) It's too complex. 2) What does it solve? In both facts they are right. It'll take a *long* time to plan such a thing right but if it works you have a product. Anyway, I'd like to join. ;) From joachim at buechse.de Sat Jul 22 11:37:11 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 22 Jul 2006 19:37:11 +0200 Subject: [Rxtx] Strange error (show stopper) Message-ID: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> I just discovered a strange error in RXTX on OSX. SerialDemo.java manages to corrupt the event_info_structure by a simple OpenPort,ClosePort - this could be in relation to the deadlock problem that was reported recently. Could anyone try to reproduce this on Solaris or some other system which is neither WIN32 nor Linux (ie which uses a drain thread). In SerialImp.c : RXTXPort(interruptEventLoop) Apparently the event_info_structure gets corrupted shortly after pthread_kill(index->drain_tid, SIGABRT); In particular, the index->closing flag gets overwritten by a pointer value. **** Adding the following debugging code: pthread_kill(index->drain_tid, SIGABRT); sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i \n", index->fd, index, index->closing ); report( message ); /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ usleep(50 * 1000); sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i \n", index->fd, index, index->closing ); report( message ); **** gives me: 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 drain_loop: received EINTR------------------ drain_loop exiting --------------------- entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 eventLoop: got interrupt 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 **** Modifying SerialImp.h : event_info_struct by moving the prev*, next* pointers jmethodID checkMonitorThread; struct event_info_struct *dummy, *dummy2; fd_set rfds; struct timeval tv_sleep; int closing; struct event_info_struct *next, *prev; *** (ie replacing their original position with dummys and moving them *** behind the closing flag) results in this: 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 drain_loop: received EINTR------------------ drain_loop exiting --------------------- entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 eventLoop: got interrupt 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 *** I was not able to track down the problem. If anyone could check wether this happens on other platforms as well, we may get closer to a fix. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich From joachim at buechse.de Sat Jul 22 11:46:35 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 22 Jul 2006 19:46:35 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607221932.04194.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> Message-ID: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> It seems that Gregg's suggestion could be implemented without changing the existing "user-level" API of javax.comm. Most of the information suggested for HardwarePort is not accessible from within the POSSIX-API but this is a different story. It is clear that javax.comm can never provide a way to talk to all USB devices, simply because some USB devices have several endpoints. But it could provide a means of talking to devices that function as a bidirectional-pipe (ie any USB to serial bridge). Regards, Joachim On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>> Pascal S. de Kloe wrote: >>>>> I am also not sure if >>>>> the api should unify corresponding cu. and tty. ports into one >>>>> single >>>>> port. >>>> >>>> I think the API should hide low-level details like devicefiles. >>> >>> Not all ports have device files. It's long been my goal to add >>> support >>> for virtual serial ports, that is, serial ports on Ethernet terminal >>> servers, for example integrating RFC2217. This means that the >>> port name >>> is some combination of an IP address and TCP port number. >>> Nothing in >>> /dev. >> >> What I think would make the most sense is a simple "device" >> enumeration >> Server Provider Interface that would bring port objects into the >> JVM based >> on the platform JVM providers knowledge of how to enumerate those >> ports. >> Application writers would provide a plugin using the SPI that >> would codify >> those devices into named entities that they are interested in. >> >> public interface HardwarePort { >> public String getName(); >> public String getHardwareID(); >> public String getManufacturer(); >> public List getCapabilities(); >> public Object getImplementation(); >> } >> >> public interface PortCapability { >> public String getDescription(); >> public CapabilityId getIdentifier(); >> } >> >> public enum CapabilityId { >> INPUT, // Can receive input >> OUTPUT, // Can send output >> ASYNCHRONOUS, // Can send and receive at the same time >> SYNCHRONOUS, // No synchronous I/O >> ADDRESSABLE // Port has an address associated >> } >> >> Then, you might imagine that the enumerated capabilities had a >> standardized/specified interface that you'd find implemented on >> ports that >> had such capabilities. >> >> The getImplementation() method would return the implementation class >> provided by the JVM provider that had all of the interfaces tied >> to it. >> >> These are just some quick thoughts, pick away at them. >> >> I am very interested in getting a new comm api in place which can >> provide >> the ability for all USB connected devices to have drivers provided >> as 100% >> java for all non-timing critical types of device interfaces. >> >> The JVM provider should have an SPI to write to which will enable >> them to >> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >> something >> that we can talk 100% java to. >> >> That's my big desire. Starting with something simple which gives >> a good >> start in that direction would be great! > > That was exactly my wish too. > > The point people brought up was: > 1) It's too complex. > 2) What does it solve? > > In both facts they are right. It'll take a *long* time to plan such > a thing > right but if it works you have a product. Anyway, I'd like to join. ;) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Jul 22 11:55:23 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 22 Jul 2006 14:55:23 -0300 Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: <44C2668B.5080703@gmail.com> Joachim Buechse escribi?: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. > > It is clear that javax.comm can never provide a way to talk to all > USB devices, simply because some USB devices have several endpoints. > But it could provide a means of talking to devices that function as a > bidirectional-pipe (ie any USB to serial bridge). > > Regards, > Joachim Hi, About USB, why do not we contact the guys that make a library to support USB under Java from Linux? I think there is all ready an JSR for USB access, what we could do to this JSR is help to implement Usb access from other OSes. Regards, Manuel > > On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > >> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>> Pascal S. de Kloe wrote: >>>>>> I am also not sure if >>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>> single >>>>>> port. >>>>> I think the API should hide low-level details like devicefiles. >>>> Not all ports have device files. It's long been my goal to add >>>> support >>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>> servers, for example integrating RFC2217. This means that the >>>> port name >>>> is some combination of an IP address and TCP port number. >>>> Nothing in >>>> /dev. >>> What I think would make the most sense is a simple "device" >>> enumeration >>> Server Provider Interface that would bring port objects into the >>> JVM based >>> on the platform JVM providers knowledge of how to enumerate those >>> ports. >>> Application writers would provide a plugin using the SPI that >>> would codify >>> those devices into named entities that they are interested in. >>> >>> public interface HardwarePort { >>> public String getName(); >>> public String getHardwareID(); >>> public String getManufacturer(); >>> public List getCapabilities(); >>> public Object getImplementation(); >>> } >>> >>> public interface PortCapability { >>> public String getDescription(); >>> public CapabilityId getIdentifier(); >>> } >>> >>> public enum CapabilityId { >>> INPUT, // Can receive input >>> OUTPUT, // Can send output >>> ASYNCHRONOUS, // Can send and receive at the same time >>> SYNCHRONOUS, // No synchronous I/O >>> ADDRESSABLE // Port has an address associated >>> } >>> >>> Then, you might imagine that the enumerated capabilities had a >>> standardized/specified interface that you'd find implemented on >>> ports that >>> had such capabilities. >>> >>> The getImplementation() method would return the implementation class >>> provided by the JVM provider that had all of the interfaces tied >>> to it. >>> >>> These are just some quick thoughts, pick away at them. >>> >>> I am very interested in getting a new comm api in place which can >>> provide >>> the ability for all USB connected devices to have drivers provided >>> as 100% >>> java for all non-timing critical types of device interfaces. >>> >>> The JVM provider should have an SPI to write to which will enable >>> them to >>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>> something >>> that we can talk 100% java to. >>> >>> That's my big desire. Starting with something simple which gives >>> a good >>> start in that direction would be great! >> That was exactly my wish too. >> >> The point people brought up was: >> 1) It's too complex. >> 2) What does it solve? >> >> In both facts they are right. It'll take a *long* time to plan such >> a thing >> right but if it works you have a product. Anyway, I'd like to join. ;) >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Sat Jul 22 11:58:00 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Sat, 22 Jul 2006 13:58:00 -0400 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> Message-ID: <41E45C85-4A22-4C5B-915F-62ED36BACCF2@sympatico.ca> A couple of questions: - what version are you using? - does this happen with the version in cvs? Andre On 22-Jul-06, at 13:37 , Joachim Buechse wrote: > I just discovered a strange error in RXTX on OSX. SerialDemo.java > manages to corrupt the event_info_structure by a simple > OpenPort,ClosePort - this could be in relation to the deadlock > problem that was reported recently. > > Could anyone try to reproduce this on Solaris or some other system > which is neither WIN32 nor Linux (ie which uses a drain thread). > > In SerialImp.c : RXTXPort(interruptEventLoop) > > Apparently the event_info_structure gets corrupted shortly after > > pthread_kill(index->drain_tid, SIGABRT); > > In particular, the index->closing flag gets overwritten by a pointer > value. > > > **** Adding the following debugging code: > > pthread_kill(index->drain_tid, SIGABRT); > sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ > usleep(50 * 1000); > sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > > **** gives me: > > 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 > > **** Modifying SerialImp.h : event_info_struct by moving the > prev*, next* pointers > > jmethodID checkMonitorThread; > struct event_info_struct *dummy, *dummy2; > fd_set rfds; > struct timeval tv_sleep; > int closing; > struct event_info_struct *next, *prev; > > *** (ie replacing their original position with dummys and moving them > *** behind the closing flag) results in this: > > 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 > > > *** I was not able to track down the problem. If anyone could check > wether this happens on other platforms as well, we may get closer to > a fix. > > Regards, > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Paul.Klissner at Sun.COM Sat Jul 22 12:19:41 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Sat, 22 Jul 2006 11:19:41 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: <44C26C3D.8020501@sun.com> Joachim Buechse wrote: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. > > It is clear that javax.comm can never provide a way to talk to all > USB devices, simply because some USB devices have several endpoints. > But it could provide a means of talking to devices that function as a > bidirectional-pipe (ie any USB to serial bridge). If the 'back end' driver could be java as well an .so then driver's could be written using javax.usb, which is available currently for Linux. Paul > > Regards, > Joachim > > On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > >> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>> Pascal S. de Kloe wrote: >>>>>> I am also not sure if >>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>> single >>>>>> port. >>>>> I think the API should hide low-level details like devicefiles. >>>> Not all ports have device files. It's long been my goal to add >>>> support >>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>> servers, for example integrating RFC2217. This means that the >>>> port name >>>> is some combination of an IP address and TCP port number. >>>> Nothing in >>>> /dev. >>> What I think would make the most sense is a simple "device" >>> enumeration >>> Server Provider Interface that would bring port objects into the >>> JVM based >>> on the platform JVM providers knowledge of how to enumerate those >>> ports. >>> Application writers would provide a plugin using the SPI that >>> would codify >>> those devices into named entities that they are interested in. >>> >>> public interface HardwarePort { >>> public String getName(); >>> public String getHardwareID(); >>> public String getManufacturer(); >>> public List getCapabilities(); >>> public Object getImplementation(); >>> } >>> >>> public interface PortCapability { >>> public String getDescription(); >>> public CapabilityId getIdentifier(); >>> } >>> >>> public enum CapabilityId { >>> INPUT, // Can receive input >>> OUTPUT, // Can send output >>> ASYNCHRONOUS, // Can send and receive at the same time >>> SYNCHRONOUS, // No synchronous I/O >>> ADDRESSABLE // Port has an address associated >>> } >>> >>> Then, you might imagine that the enumerated capabilities had a >>> standardized/specified interface that you'd find implemented on >>> ports that >>> had such capabilities. >>> >>> The getImplementation() method would return the implementation class >>> provided by the JVM provider that had all of the interfaces tied >>> to it. >>> >>> These are just some quick thoughts, pick away at them. >>> >>> I am very interested in getting a new comm api in place which can >>> provide >>> the ability for all USB connected devices to have drivers provided >>> as 100% >>> java for all non-timing critical types of device interfaces. >>> >>> The JVM provider should have an SPI to write to which will enable >>> them to >>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>> something >>> that we can talk 100% java to. >>> >>> That's my big desire. Starting with something simple which gives >>> a good >>> start in that direction would be great! >> That was exactly my wish too. >> >> The point people brought up was: >> 1) It's too complex. >> 2) What does it solve? >> >> In both facts they are right. It'll take a *long* time to plan such >> a thing >> right but if it works you have a product. Anyway, I'd like to join. ;) >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 22 12:48:15 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 20:48:15 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607221920.20096.pascal@quies.net> References: <200607221920.20096.pascal@quies.net> Message-ID: <200607222048.16215.pascal@quies.net> http://quies.net/communicationapi.jar Fixed a few typo's and it works on Linux i386. It should also work on Windows i386. The rest is missing libParallel or more... -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 6664 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060722/5fd7c1ce/CommunicationAPI-0343.bin From Paul.Klissner at Sun.COM Sat Jul 22 12:53:12 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Sat, 22 Jul 2006 11:53:12 -0700 Subject: [Rxtx] jcp and jsr (libusb, javax.usb) In-Reply-To: <44C2668B.5080703@gmail.com> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> <44C2668B.5080703@gmail.com> Message-ID: <44C27418.1090309@sun.com> Manuel Naranjo wrote: > Joachim Buechse escribi?: >> It seems that Gregg's suggestion could be implemented without >> changing the existing "user-level" API of javax.comm. Most of the >> information suggested for HardwarePort is not accessible from within >> the POSSIX-API but this is a different story. >> >> It is clear that javax.comm can never provide a way to talk to all >> USB devices, simply because some USB devices have several endpoints. >> But it could provide a means of talking to devices that function as a >> bidirectional-pipe (ie any USB to serial bridge). >> >> Regards, >> Joachim > > Hi, > About USB, why do not we contact the guys that make a library to support > USB under Java from Linux? > I think there is all ready an JSR for USB access, what we could do to this > JSR is help to implement Usb access from other OSes. JAVAX.USB --------- javax.usb already a SourceForge project. I was Sun's rep on the expert group for JSR-80, javax.usb. I lived and breathed it for a 1.5 yrs working with spec lead from IBM on it. It's for real and the linux implementation works (not sure about the Win32 port on sourceforge). IBM even created a porting layer to simplify porting it to other platforms by implementing in Java all of the numerous 'clerical' functions of the API in Java so that the porting layer is absolutely minimal. The hardest part is managing the hotpluggable device tree topology as objects, and depending on one's platform or coding skills probably wouldn't take more than a week or two to get right. LIBUSB 1.0 (*NOT* libusb 0.1.8) ---------- There is also the native C library libusb. libusb 0.1.8 is weak, but libusb 1.0 under development holds the promise of being an extrordinarily robust C API to access USB devices through, and could definitely use some help getting people to port it to other platforms. I've attached the proposed libusb 1.0 API header which Sun worked with Johannes on for months before he went off into oblivion. The API has stalled and a fire might need to be lit under Johannes or it might need to be forked to get it moving again, but the spec for 1.0 is awesome, and this puppy is ready to turn into something sweet with some fresh blood on it. And it is a really good technology to become aquainted with... hint hint. Both of those APIs are really excellent and hold great promise for the community and use of USB technology in general. One of my goals, now which competes for my time with other higher priority projects was to layer an implementation of javax.usb over libusb 1.0, so that javax.usb would follow libusb to any platform and only one port would be required. But since libusb 1.0 is moving slowly, largely because the current sourceforge gatekeeper for the project, Johannes Erdfelt's lack of energy and sparse communication, it might be faster to simply port javax.usb to Mac OS, Win, Solaris and BSD if some people could get behind those, unless someone want's to get behind making libusb happen. >>>> >>>> public enum CapabilityId { >>>> INPUT, // Can receive input >>>> OUTPUT, // Can send output >>>> ASYNCHRONOUS, // Can send and receive at the same time >>>> SYNCHRONOUS, // No synchronous I/O >>>> ADDRESSABLE // Port has an address associated >>>> } My understanding is that synchronous/asynchronous refers to the way the data is clocked. I think FULLDUPLEX/HALFDUPLEX is what the author meant, or needs to be added. Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: libusb.h Type: text/x-sun-h-file Size: 26696 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060722/4a43e034/libusb-0343.bin From pascal at quies.net Sat Jul 22 17:53:31 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 01:53:31 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> References: <44C252BF.6040404@cox.net> <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> Message-ID: <200607230153.32328.pascal@quies.net> Hi Joachim, I'm not getting it. How do you easily get a "stub method / flag"? Op zaterdag 22 juli 2006 19:17, schreef Joachim Buechse: > We could easily have a stub method / flag that allows you to > explicitly load the native library (via System.loadLibrary ie from > the java.library.path). In this case the "auto-extraction" would not > take place. > > On 22.07.2006, at 18:30, Gregg Wonderly wrote: > > Dr. Douglas Lyon wrote: > >> Hi All, > >> I like the idea of the native lib in a jar with other classes. > >> An alternative I did not know would work. > > > > I have several applications that run with a security policy. In these > > applications, native library loading will require an appropriate > > FilePermission > > that should be known about ahead of time. The current native library > > implementation will require the native library to be extracted from > > the jar and > > written to disk, requiring a FilePermission("...","write") for that > > file, and > > then will also require read access to load the library. I > > personally don't want > > to give write access to a JVM for a shared library which can > > provide a point of > > abuse by errant code. > > > > Gregg Wonderly > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat Jul 22 18:46:33 2006 From: jredman at ergotech.com (Jim Redman) Date: Sat, 22 Jul 2006 18:46:33 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44C26C3D.8020501@sun.com> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> <44C26C3D.8020501@sun.com> Message-ID: <44C2C6E9.8020408@ergotech.com> Paul, I think that you've already proposed a "pluggable" underlying architecture and I think that this might be better implemented there. If you need some more examples, I'd like to have a Bluetooth interface (with dynamic discovery). Jim Paul Klissner wrote: > Joachim Buechse wrote: >> It seems that Gregg's suggestion could be implemented without >> changing the existing "user-level" API of javax.comm. Most of the >> information suggested for HardwarePort is not accessible from within >> the POSSIX-API but this is a different story. >> >> It is clear that javax.comm can never provide a way to talk to all >> USB devices, simply because some USB devices have several endpoints. >> But it could provide a means of talking to devices that function as a >> bidirectional-pipe (ie any USB to serial bridge). > > If the 'back end' driver could be java as well an .so > then driver's could be written using javax.usb, which > is available currently for Linux. > > Paul > > > >> Regards, >> Joachim >> >> On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: >> >>> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>>> Pascal S. de Kloe wrote: >>>>>>> I am also not sure if >>>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>>> single >>>>>>> port. >>>>>> I think the API should hide low-level details like devicefiles. >>>>> Not all ports have device files. It's long been my goal to add >>>>> support >>>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>>> servers, for example integrating RFC2217. This means that the >>>>> port name >>>>> is some combination of an IP address and TCP port number. >>>>> Nothing in >>>>> /dev. >>>> What I think would make the most sense is a simple "device" >>>> enumeration >>>> Server Provider Interface that would bring port objects into the >>>> JVM based >>>> on the platform JVM providers knowledge of how to enumerate those >>>> ports. >>>> Application writers would provide a plugin using the SPI that >>>> would codify >>>> those devices into named entities that they are interested in. >>>> >>>> public interface HardwarePort { >>>> public String getName(); >>>> public String getHardwareID(); >>>> public String getManufacturer(); >>>> public List getCapabilities(); >>>> public Object getImplementation(); >>>> } >>>> >>>> public interface PortCapability { >>>> public String getDescription(); >>>> public CapabilityId getIdentifier(); >>>> } >>>> >>>> public enum CapabilityId { >>>> INPUT, // Can receive input >>>> OUTPUT, // Can send output >>>> ASYNCHRONOUS, // Can send and receive at the same time >>>> SYNCHRONOUS, // No synchronous I/O >>>> ADDRESSABLE // Port has an address associated >>>> } >>>> >>>> Then, you might imagine that the enumerated capabilities had a >>>> standardized/specified interface that you'd find implemented on >>>> ports that >>>> had such capabilities. >>>> >>>> The getImplementation() method would return the implementation class >>>> provided by the JVM provider that had all of the interfaces tied >>>> to it. >>>> >>>> These are just some quick thoughts, pick away at them. >>>> >>>> I am very interested in getting a new comm api in place which can >>>> provide >>>> the ability for all USB connected devices to have drivers provided >>>> as 100% >>>> java for all non-timing critical types of device interfaces. >>>> >>>> The JVM provider should have an SPI to write to which will enable >>>> them to >>>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>>> something >>>> that we can talk 100% java to. >>>> >>>> That's my big desire. Starting with something simple which gives >>>> a good >>>> start in that direction would be great! >>> That was exactly my wish too. >>> >>> The point people brought up was: >>> 1) It's too complex. >>> 2) What does it solve? >>> >>> In both facts they are right. It'll take a *long* time to plan such >>> a thing >>> right but if it works you have a product. Anyway, I'd like to join. ;) >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From lyon at docjava.com Sun Jul 23 04:27:22 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 06:27:22 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607222048.16215.pascal@quies.net> References: <200607221920.20096.pascal@quies.net> <200607222048.16215.pascal@quies.net> Message-ID: The Class.forName is a static method. Therefore myClass.forName Should be Class.forName and myClass becomes an unused parameter. - DL >http://quies.net/communicationapi.jar > >Fixed a few typo's and it works on Linux i386. It should also work on Windows >i386. The rest is missing libParallel or more... > > >Attachment converted: PowerBookHd:CommunicationAPI 1.java >(TEXT/ttxt) (001C1A15) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Jul 23 04:32:45 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 06:32:45 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607222048.16215.pascal@quies.net> References: <200607221920.20096.pascal@quies.net> <200607222048.16215.pascal@quies.net> Message-ID: Also, the is Java2 check does not check if you are running under jdk1.5 - DL >http://quies.net/communicationapi.jar > >Fixed a few typo's and it works on Linux i386. It should also work on Windows >i386. The rest is missing libParallel or more... > > >Attachment converted: PowerBookHd:CommunicationAPI 1.java >(TEXT/ttxt) (001C1A15) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Jul 23 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 06:54:12 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607221843.27765.pascal@quies.net> References: <44C252BF.6040404@cox.net> <200607221843.27765.pascal@quies.net> Message-ID: Hi All, Perhaps Java web start can address Gregg's concerns. The native libs are placed into a signed jar for distribution. As to the assertion that serial-port based programs need file io abilities, that seems true, to me. Particularly for /dev/ttyN type native libs or libs that use lock files. The question of how to obtain a signed application that is given file-io authority may be settled by using a signing technology. Even applets can be signed, to enable improved access to the file system. What else can we try? Any ideas? Thanks! - Doug >Op zaterdag 22 juli 2006 18:30, schreef Gregg Wonderly: >> Dr. Douglas Lyon wrote: >> > Hi All, >> > I like the idea of the native lib in a jar with other classes. >> > An alternative I did not know would work. >> >> I have several applications that run with a security policy. In these >> applications, native library loading will require an appropriate >> FilePermission that should be known about ahead of time. The current >> native library implementation will require the native library to be >> extracted from the jar and written to disk, requiring a >> FilePermission("...","write") for that file, and then will also require >> read access to load the library. I personally don't want to give write >> access to a JVM for a shared library which can provide a point of abuse by >> errant code. >> >> Gregg Wonderly > >That's indeed a pitty limitation. It creates a lot of possible exceptions too. > >On the other hand, any native lib passes the securiy model. Applications who >can access hardware ports can be expected to create files, right? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 04:57:33 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 12:57:33 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607222048.16215.pascal@quies.net> Message-ID: <200607231257.34284.pascal@quies.net> Op zondag 23 juli 2006 12:27, schreef Dr. Douglas Lyon: > The Class.forName is a static method. Therefore > myClass.forName Should be Class.forName and > myClass becomes an unused parameter. > - DL Thank you. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 6625 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060723/00f3b627/CommunicationAPI-0343.bin From pascal at quies.net Sun Jul 23 05:02:59 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 13:02:59 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607222048.16215.pascal@quies.net> Message-ID: <200607231302.59252.pascal@quies.net> Op zondag 23 juli 2006 12:32, schreef Dr. Douglas Lyon: > Also, the is Java2 check does not check if you are running under > jdk1.5 > - DL Could you please explain? The JDK 1.5 will pass the check just fine. From lyon at docjava.com Sun Jul 23 05:34:10 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 07:34:10 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607221854.13467.pascal@quies.net> References: <200607221506.07140.pascal@quies.net> <200607221854.13467.pascal@quies.net> Message-ID: Hi All, Please call me Doug (the Dr. is for the classroom). Thanks! - Doug >Hi Dr., > >We're both trying to do the same thing. > >The CommunicationAPI does not only look at the OS but it also indexes the >available hardware architectures and does not need OsUtils. Any Java 2 >runtime will do. > >The plan was to make a single JAR with the binaries for all supported >platforms, the RXTX gnu.io package and the javax.comm wrapers. > >A signed version would be nice. > >A few questions remain tough. Does anybody know how Sun uses the SunOS and >Solaris identifiers for the Java property os.name? > > > >Op zaterdag 22 juli 2006 16:06, schreef Dr. Douglas Lyon: >> Hi All, >> Here is how I have arranged my signed versions of the native >> binaries: >> http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/windows/native.j >>ar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/native.jar >> http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/linux/native.jar >> >> Then I do: >> public static URL getResourceUrl() throws MalformedURLException { >> String rxtxUrl = "http://show.docjava.com:8086/" + >> "book/cgij/code/jnlp/libs/rxtx/"; >> if (OsUtils.isLinux()) >> return new URL(rxtxUrl + "linux/native.jar"); >> if (OsUtils.isMacOs()) >> return new URL(rxtxUrl + "mac/native.jar"); >> if (OsUtils.isWindows()) >> return new URL(rxtxUrl + "windows/native.jar"); >> System.out.println("no automatic install supported for this >> platform. " + >> "Please e-mail lyon at docjava.com with a bug report"); >> return null; >> } >> >> My new-age NativeLibraryManger concept-thang allows you to >> write stuff like: >> >> /** >> * This method fixes the driver by beaming over >> * to the tmp directory a native.jar file. >> * The native.jar file is signed and its >> * native libs are beamed over to the user home directory >> * ~/.rxtx/
>> * Finally, the java.library.path is altered to include
>> * ~/.rxtx/ >> */ >> private static void fixDriver() { >> >> try { >> NativeLibraryManager.fixDriver(getResourceUrl(), >> NativeLibraryManager.mapLibraryName("rxtxSerial")); >> } catch (IOException e) { >> e.printStackTrace(); >> } >> } >> >> I do a lazy singleton design pattern: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public synchronized static RXTXCommDriver getInstance() { >> if (driver != null) return driver; >> if (!NativeLibraryManager.isLibInPath("rxtxSerial")) >> fixDriver(); >> if (NativeLibraryManager.isLibInPath("rxtxSerial")) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> } >> return driver; >> } >> >> I am at a cross-roads here, since a file-based distro might be preferable >> to a URL based distro. To make this really general, and to "remember" where >> the last version of a native library came from, I serialize a bean into >> user preferences >> The user can then store native libraries anywhere, remembering the location >> in the preferences. >> >> What is the general feeling about this? >> >> Thanks! >> - Doug >> >> > > Now, if you place the rxtx classes and native library in the same >> >> >> >> jar, do they both have to be in any specific place in order to be >> >> found? >> > >> >Answer: >> >> >The path to the libraries is in the form >> >> >of /native/rxtx/-/{libserial,libparallel} >> >> >so /native/rxtx/windows-i386/libserial would do. >> > >> >I'me looking for the various os.name and os.arch values right now. >> >_______________________________________________ >> >Rxtx mailing list >> >Rxtx at qbang.org >> >http://mailman.qbang.org/mailman/listinfo/rxtx > > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 06:12:33 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 14:12:33 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607221843.27765.pascal@quies.net> Message-ID: <200607231412.34078.pascal@quies.net> Op zondag 23 juli 2006 12:54, schreef Dr. Douglas Lyon: > Hi All, > Perhaps Java web start can address Gregg's concerns. > The native libs are placed into a signed jar for distribution. > As to the assertion that serial-port based programs need file io > abilities, that seems true, to me. Particularly for /dev/ttyN type > native libs or libs that use lock files. > The question of how to obtain a signed application that is given > file-io authority may be settled by using a signing technology. > > Even applets can be signed, to enable improved access to the file > system. > > What else can we try? Any ideas? It might be a good idea to use a more optimized version for youre networked applications. These native libraries are huge for some reason. Can you build a "downloader"? From lyon at docjava.com Sun Jul 23 06:46:43 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 08:46:43 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607231302.59252.pascal@quies.net> References: <200607222048.16215.pascal@quies.net> <200607231302.59252.pascal@quies.net> Message-ID: public static void main(String[] args) { System.out.println("isJava2="+System.getProperty("java.version")); } Prints out 1.5_06 on my system, but you seem to need the "1.2" to be present on the system...right? RXTX does work under 1.5, at least on my system. - DL >Op zondag 23 juli 2006 12:32, schreef Dr. Douglas Lyon: >> Also, the is Java2 check does not check if you are running under >> jdk1.5 >> - DL > >Could you please explain? >The JDK 1.5 will pass the check just fine. >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Jul 23 06:58:02 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 08:58:02 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607231412.34078.pascal@quies.net> References: <200607221843.27765.pascal@quies.net> <200607231412.34078.pascal@quies.net> Message-ID: Hi All, Yes, I do have a download, as to the question of "huge": ls -al native.jar -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar 28kbytes is not really huge, right? In fact, if you uncompress the jar, you get: -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so Which is almost 80kbytes, so the jar is 40% of the native libs size, and it is signed. At least on the Linux version, it is smaller. I did not check the other versions. And with java web start, the JNLP only downloads the native jar if it is new or changed. And it only downloads the native jar used for the target platform. Here is how the jnlp looks, FYI... addbk.JAddressBook.Main DocJava, Inc. I have been playing around with "eager" and "lazy" directives, but I can't really tell the difference. Cheers! - Doug >Op zondag 23 juli 2006 12:54, schreef Dr. Douglas Lyon: >> Hi All, >> Perhaps Java web start can address Gregg's concerns. >> The native libs are placed into a signed jar for distribution. >> As to the assertion that serial-port based programs need file io >> abilities, that seems true, to me. Particularly for /dev/ttyN type >> native libs or libs that use lock files. >> The question of how to obtain a signed application that is given >> file-io authority may be settled by using a signing technology. >> >> Even applets can be signed, to enable improved access to the file >> system. >> >> What else can we try? Any ideas? > >It might be a good idea to use a more optimized version for youre networked >applications. These native libraries are huge for some reason. >Can you build a "downloader"? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 07:53:54 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 15:53:54 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607231302.59252.pascal@quies.net> Message-ID: <200607231553.55088.pascal@quies.net> Op zondag 23 juli 2006 14:46, schreef Dr. Douglas Lyon: > public static void main(String[] args) { > System.out.println("isJava2="+System.getProperty("java.version")); > > } > Prints out 1.5_06 on my system, but you seem to need the "1.2" to be > present on the system...right? if (System.getProperty("java.version").compareTo("1.2") < 0) throw new Error("RXTX requires a Java 2 platform."); The line requires a version string of "1.2" or higher. Sun decided to name all versions since 1.2 as Java 2. (That is why there is this 2 in J2SE.) The error should never happen anyway if you compile the code with the -target 1.2 flag. From pascal at quies.net Sun Jul 23 07:55:52 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 15:55:52 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607231412.34078.pascal@quies.net> Message-ID: <200607231555.52419.pascal@quies.net> Op zondag 23 juli 2006 14:58, schreef Dr. Douglas Lyon: > Hi All, > Yes, I do have a download, as to the question of "huge": > ls -al native.jar > -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar > 28kbytes is not really huge, right? > In fact, if you uncompress the jar, you get: > -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so > -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so > Which is almost 80kbytes, so the jar is 40% of the native libs size, and > it is signed. > At least on the Linux version, it is smaller. I did not check the > other versions. > > And with java web start, the JNLP only downloads the native jar if it is > new or changed. > And it only downloads the native jar used for the target platform. > > Here is how the jnlp looks, FYI... > codebase="http://show.docjava.com:8086/book/cgij/code/jnlp/"> > > addbk.JAddressBook.Main > DocJava, Inc. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have been playing around with "eager" and "lazy" directives, > but I can't really tell the difference. > > Cheers! > - Doug That is a nice sollution. Is there a tag for the architecture too becouse now you assume i386 and that is of course not necesairy true. From joachim at buechse.de Sun Jul 23 11:17:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 23 Jul 2006 19:17:29 +0200 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <41E45C85-4A22-4C5B-915F-62ED36BACCF2@sympatico.ca> References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> <41E45C85-4A22-4C5B-915F-62ED36BACCF2@sympatico.ca> Message-ID: <0B7FC525-4C71-49E8-B652-CCF6C67B4A58@buechse.de> This happens with the versions in CVS (2.07+ and 2.17+). On 22.07.2006, at 19:58, Andr?-John Mas wrote: > A couple of questions: > - what version are you using? > - does this happen with the version in cvs? > > Andre > > On 22-Jul-06, at 13:37 , Joachim Buechse wrote: > >> I just discovered a strange error in RXTX on OSX. SerialDemo.java >> manages to corrupt the event_info_structure by a simple >> OpenPort,ClosePort - this could be in relation to the deadlock >> problem that was reported recently. >> >> Could anyone try to reproduce this on Solaris or some other system >> which is neither WIN32 nor Linux (ie which uses a drain thread). >> >> In SerialImp.c : RXTXPort(interruptEventLoop) >> >> Apparently the event_info_structure gets corrupted shortly after >> >> pthread_kill(index->drain_tid, SIGABRT); >> >> In particular, the index->closing flag gets overwritten by a pointer >> value. >> >> >> **** Adding the following debugging code: >> >> pthread_kill(index->drain_tid, SIGABRT); >> sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i >> \n", index->fd, index, index->closing ); >> report( message ); >> /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ >> usleep(50 * 1000); >> sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i >> \n", index->fd, index, index->closing ); >> report( message ); >> >> **** gives me: >> >> 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 >> drain_loop: received EINTR------------------ drain_loop exiting >> --------------------- >> entering check_tiocmget_changes >> leaving check_tiocmget_changes >> port_has_changed_fionread: change is 0 >> eventLoop: got interrupt >> 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 >> >> **** Modifying SerialImp.h : event_info_struct by moving the >> prev*, next* pointers >> >> jmethodID checkMonitorThread; >> struct event_info_struct *dummy, *dummy2; >> fd_set rfds; >> struct timeval tv_sleep; >> int closing; >> struct event_info_struct *next, *prev; >> >> *** (ie replacing their original position with dummys and moving them >> *** behind the closing flag) results in this: >> >> 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 >> drain_loop: received EINTR------------------ drain_loop exiting >> --------------------- >> entering check_tiocmget_changes >> leaving check_tiocmget_changes >> port_has_changed_fionread: change is 0 >> eventLoop: got interrupt >> 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 >> >> >> *** I was not able to track down the problem. If anyone could check >> wether this happens on other platforms as well, we may get closer to >> a fix. >> >> Regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Sun Jul 23 11:44:48 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 23 Jul 2006 19:44:48 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607230153.32328.pascal@quies.net> References: <44C252BF.6040404@cox.net> <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> <200607230153.32328.pascal@quies.net> Message-ID: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> Gregg's concern was, that extracting the library from the jar and loading it via System.load needs file access privileges. To solve this concern, all that's required is a static method/flag that triggers loading via System.loadLibrary instead (of course, then he needs to make sure, that the library is on the java.library.path). This could also be handled via a system property of course. Regards, Joachim On 23.07.2006, at 01:53, Pascal S. de Kloe wrote: > Hi Joachim, > > I'm not getting it. > How do you easily get a "stub method / flag"? > > > Op zaterdag 22 juli 2006 19:17, schreef Joachim Buechse: >> We could easily have a stub method / flag that allows you to >> explicitly load the native library (via System.loadLibrary ie from >> the java.library.path). In this case the "auto-extraction" would not >> take place. >> >> On 22.07.2006, at 18:30, Gregg Wonderly wrote: >>> Dr. Douglas Lyon wrote: >>>> Hi All, >>>> I like the idea of the native lib in a jar with other classes. >>>> An alternative I did not know would work. >>> >>> I have several applications that run with a security policy. In >>> these >>> applications, native library loading will require an appropriate >>> FilePermission >>> that should be known about ahead of time. The current native >>> library >>> implementation will require the native library to be extracted from >>> the jar and >>> written to disk, requiring a FilePermission("...","write") for that >>> file, and >>> then will also require read access to load the library. I >>> personally don't want >>> to give write access to a JVM for a shared library which can >>> provide a point of >>> abuse by errant code. >>> >>> Gregg Wonderly >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 13:34:17 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 21:34:17 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> References: <200607230153.32328.pascal@quies.net> <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> Message-ID: <200607232134.17451.pascal@quies.net> Aaah, the penny drops. I was reading it as the stub method _root_ flag like using the root of a jar as a context for java.library.path. Thanks for explaining. :) I'll build it right away. Op zondag 23 juli 2006 19:44, schreef Joachim Buechse: > Gregg's concern was, that extracting the library from the jar and > loading it via System.load needs file access privileges. To solve > this concern, all that's required is a static method/flag that > triggers loading via System.loadLibrary instead (of course, then he > needs to make sure, that the library is on the java.library.path). > This could also be handled via a system property of course. > > Regards, > Joachim > > On 23.07.2006, at 01:53, Pascal S. de Kloe wrote: > > Hi Joachim, > > > > I'm not getting it. > > How do you easily get a "stub method / flag"? > > > > Op zaterdag 22 juli 2006 19:17, schreef Joachim Buechse: > >> We could easily have a stub method / flag that allows you to > >> explicitly load the native library (via System.loadLibrary ie from > >> the java.library.path). In this case the "auto-extraction" would not > >> take place. > >> > >> On 22.07.2006, at 18:30, Gregg Wonderly wrote: > >>> Dr. Douglas Lyon wrote: > >>>> Hi All, > >>>> I like the idea of the native lib in a jar with other classes. > >>>> An alternative I did not know would work. > >>> > >>> I have several applications that run with a security policy. In > >>> these > >>> applications, native library loading will require an appropriate > >>> FilePermission > >>> that should be known about ahead of time. The current native > >>> library > >>> implementation will require the native library to be extracted from > >>> the jar and > >>> written to disk, requiring a FilePermission("...","write") for that > >>> file, and > >>> then will also require read access to load the library. I > >>> personally don't want > >>> to give write access to a JVM for a shared library which can > >>> provide a point of > >>> abuse by errant code. > >>> > >>> Gregg Wonderly > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 18:10:45 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 02:10:45 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607232134.17451.pascal@quies.net> References: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> <200607232134.17451.pascal@quies.net> Message-ID: <200607240210.45992.pascal@quies.net> Hello gentleman, The CommunicationAPI class / utility is almost ready. Could you please have a final look and give your opinion? Does anybody know how the SunOS and the Solaris os.name is used? Sun uses just sparc as the description for os.arch. Is it safe to use the 32-bit binaries? @Gregg You can extract the necessary libraries during the installation with the extractNativeLibraries method to the application directory so they get loaded automatically. Is that good enough? @Trent Would you include this class afther any possible comments in the distribution? -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 10884 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060723/d2e99122/CommunicationAPI-0342.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: PlatformNotSupportedException.java Type: text/x-java Size: 1621 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060723/d2e99122/PlatformNotSupportedException-0342.bin From lyon at docjava.com Sun Jul 23 18:14:08 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 20:14:08 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607231555.52419.pascal@quies.net> References: <200607231412.34078.pascal@quies.net> <200607231555.52419.pascal@quies.net> Message-ID: Hi All, The present JNLP distro that I use: > > >> >> > Works for Macs using G3 and G4's. I have not tested this with an i386 mac, as I do not have one. And it only works with i386 based linux... As far as architecture goes: Allows for a chip arch, and this might address your question. The real bottleneck is that you need one of everything to test a deployment, or you have to know a bunch of people (like on this list!) to do a proper test. Cheers! - Doug >Op zondag 23 juli 2006 14:58, schreef Dr. Douglas Lyon: >> Hi All, >> Yes, I do have a download, as to the question of "huge": >> ls -al native.jar >> -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar >> 28kbytes is not really huge, right? >> In fact, if you uncompress the jar, you get: >> -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so >> -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so >> Which is almost 80kbytes, so the jar is 40% of the native libs size, and >> it is signed. >> At least on the Linux version, it is smaller. I did not check the >> other versions. >> >> And with java web start, the JNLP only downloads the native jar if it is >> new or changed. >> And it only downloads the native jar used for the target platform. >> >> Here is how the jnlp looks, FYI... >> > codebase="http://show.docjava.com:8086/book/cgij/code/jnlp/"> >> >> addbk.JAddressBook.Main >> DocJava, Inc. >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > >> >> > > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> I have been playing around with "eager" and "lazy" directives, >> but I can't really tell the difference. >> >> Cheers! >> - Doug > >That is a nice sollution. > >Is there a tag for the architecture too becouse now you assume i386 and that >is of course not necesairy true. >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Sun Jul 23 10:38:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 23 Jul 2006 11:38:50 -0500 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607221843.27765.pascal@quies.net> References: <44C252BF.6040404@cox.net> <200607221843.27765.pascal@quies.net> Message-ID: <44C3A61A.3060706@cox.net> Pascal S. de Kloe wrote: > Op zaterdag 22 juli 2006 18:30, schreef Gregg Wonderly: >>I have several applications that run with a security policy. In these >>applications, native library loading will require an appropriate >>FilePermission that should be known about ahead of time. The current >>native library implementation will require the native library to be >>extracted from the jar and written to disk, requiring a >>FilePermission("...","write") for that file, and then will also require >>read access to load the library. I personally don't want to give write >>access to a JVM for a shared library which can provide a point of abuse by >>errant code. > That's indeed a pitty limitation. It creates a lot of possible exceptions too. > > On the other hand, any native lib passes the securiy model. Applications who > can access hardware ports can be expected to create files, right? The use of an appropriate security policy is a deployment time configuration. There needs to be appropriate limits that confine the software to its intended tasks. Gregg Wonderly From gergg at cox.net Sun Jul 23 10:56:39 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 23 Jul 2006 11:56:39 -0500 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607221920.20096.pascal@quies.net> <200607222048.16215.pascal@quies.net> Message-ID: <44C3AA47.4060003@cox.net> Dr. Douglas Lyon wrote: > The Class.forName is a static method. Therefore > myClass.forName Should be Class.forName and > myClass becomes an unused parameter. Or better yet, make that parameter a context classloader and call Class.forName( classname, classloader); so that the location of the codebase for loading classes can be separate from the applications classpath. Gregg Wonderly From tjarvi at qbang.org Sun Jul 23 20:26:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 20:26:04 -0600 (MDT) Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: I do not see a point of having CommAPI do much more than basic termios interfaces and possibly parallel ports. The kernels can deliver that interface just fine for USB and other types. One problem with the current implementation for USB and IrDA is hotplug. There is a HAL daemon that can send connect and disconnect events which should probably be added to a new API. Sun is also working on a HAL port for Solaris. It is hackish but I saw at the Linux symposium that it will be getting attention and improving. The point being that these events could be included not that HAL is the end of all problems. It would appear to me that anything further in USB space should be done with the/a USB API to avoid duplication of efforts. USB is only one of many low level options for termios interfaces. On Sat, 22 Jul 2006, Joachim Buechse wrote: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. > > It is clear that javax.comm can never provide a way to talk to all > USB devices, simply because some USB devices have several endpoints. > But it could provide a means of talking to devices that function as a > bidirectional-pipe (ie any USB to serial bridge). > > Regards, > Joachim > > On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > >> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>> Pascal S. de Kloe wrote: >>>>>> I am also not sure if >>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>> single >>>>>> port. >>>>> >>>>> I think the API should hide low-level details like devicefiles. >>>> >>>> Not all ports have device files. It's long been my goal to add >>>> support >>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>> servers, for example integrating RFC2217. This means that the >>>> port name >>>> is some combination of an IP address and TCP port number. >>>> Nothing in >>>> /dev. >>> >>> What I think would make the most sense is a simple "device" >>> enumeration >>> Server Provider Interface that would bring port objects into the >>> JVM based >>> on the platform JVM providers knowledge of how to enumerate those >>> ports. >>> Application writers would provide a plugin using the SPI that >>> would codify >>> those devices into named entities that they are interested in. >>> >>> public interface HardwarePort { >>> public String getName(); >>> public String getHardwareID(); >>> public String getManufacturer(); >>> public List getCapabilities(); >>> public Object getImplementation(); >>> } >>> >>> public interface PortCapability { >>> public String getDescription(); >>> public CapabilityId getIdentifier(); >>> } >>> >>> public enum CapabilityId { >>> INPUT, // Can receive input >>> OUTPUT, // Can send output >>> ASYNCHRONOUS, // Can send and receive at the same time >>> SYNCHRONOUS, // No synchronous I/O >>> ADDRESSABLE // Port has an address associated >>> } >>> >>> Then, you might imagine that the enumerated capabilities had a >>> standardized/specified interface that you'd find implemented on >>> ports that >>> had such capabilities. >>> >>> The getImplementation() method would return the implementation class >>> provided by the JVM provider that had all of the interfaces tied >>> to it. >>> >>> These are just some quick thoughts, pick away at them. >>> >>> I am very interested in getting a new comm api in place which can >>> provide >>> the ability for all USB connected devices to have drivers provided >>> as 100% >>> java for all non-timing critical types of device interfaces. >>> >>> The JVM provider should have an SPI to write to which will enable >>> them to >>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>> something >>> that we can talk 100% java to. >>> >>> That's my big desire. Starting with something simple which gives >>> a good >>> start in that direction would be great! >> >> That was exactly my wish too. >> >> The point people brought up was: >> 1) It's too complex. >> 2) What does it solve? >> >> In both facts they are right. It'll take a *long* time to plan such >> a thing >> right but if it works you have a product. Anyway, I'd like to join. ;) >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jul 23 20:31:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 20:31:45 -0600 (MDT) Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607231412.34078.pascal@quies.net> References: <200607221843.27765.pascal@quies.net> <200607231412.34078.pascal@quies.net> Message-ID: On Sun, 23 Jul 2006, Pascal S. de Kloe wrote: > Op zondag 23 juli 2006 12:54, schreef Dr. Douglas Lyon: >> Hi All, >> Perhaps Java web start can address Gregg's concerns. >> The native libs are placed into a signed jar for distribution. >> As to the assertion that serial-port based programs need file io >> abilities, that seems true, to me. Particularly for /dev/ttyN type >> native libs or libs that use lock files. >> The question of how to obtain a signed application that is given >> file-io authority may be settled by using a signing technology. >> >> Even applets can be signed, to enable improved access to the file >> system. >> >> What else can we try? Any ideas? > > It might be a good idea to use a more optimized version for youre networked > applications. These native libraries are huge for some reason. > Can you build a "downloader"? It may be that the binaries are not stripped. "strip librtxserial.so" for instance. That will remove the symbols which are not usually needed in production. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jul 23 20:49:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 20:49:16 -0600 (MDT) Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607240210.45992.pascal@quies.net> References: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> <200607232134.17451.pascal@quies.net> <200607240210.45992.pascal@quies.net> Message-ID: On Mon, 24 Jul 2006, Pascal S. de Kloe wrote: > Hello gentleman, > > The CommunicationAPI class / utility is almost ready. > Could you please have a final look and give your opinion? > > > Does anybody know how the SunOS and the Solaris os.name is used? > > Sun uses just sparc as the description for os.arch. Is it safe to use the > 32-bit binaries? > > > > @Gregg > You can extract the necessary libraries during the installation with the > extractNativeLibraries method to the application directory so they get loaded > automatically. Is that good enough? > > @Trent > Would you include this class afther any possible comments in the distribution? > Hi Pascal, It would appear to me that this is a tool for using the API, not an API. So perhaps the classname is not the best choice. The class also has a main which would not make a great deal of sense to include in the library to me. It would make a nice example for the contrib directory or a new utility directory though. Documentation of its availability in the main document could make it stand out from the other contrib files. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jul 23 21:27:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 21:27:48 -0600 (MDT) Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> Message-ID: On Sat, 22 Jul 2006, Joachim Buechse wrote: > I just discovered a strange error in RXTX on OSX. SerialDemo.java > manages to corrupt the event_info_structure by a simple > OpenPort,ClosePort - this could be in relation to the deadlock > problem that was reported recently. > > Could anyone try to reproduce this on Solaris or some other system > which is neither WIN32 nor Linux (ie which uses a drain thread). > > In SerialImp.c : RXTXPort(interruptEventLoop) > > Apparently the event_info_structure gets corrupted shortly after > > pthread_kill(index->drain_tid, SIGABRT); > > In particular, the index->closing flag gets overwritten by a pointer > value. > > > **** Adding the following debugging code: > > pthread_kill(index->drain_tid, SIGABRT); > sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ > usleep(50 * 1000); > sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > > **** gives me: > > 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 > > **** Modifying SerialImp.h : event_info_struct by moving the > prev*, next* pointers > > jmethodID checkMonitorThread; > struct event_info_struct *dummy, *dummy2; > fd_set rfds; > struct timeval tv_sleep; > int closing; > struct event_info_struct *next, *prev; > > *** (ie replacing their original position with dummys and moving them > *** behind the closing flag) results in this: > > 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 > > > *** I was not able to track down the problem. If anyone could check > wether this happens on other platforms as well, we may get closer to > a fix. > Hi Joachim Interesting. I did run many tests with that code on may OSs. To be fair, the tests are just starting to get into good shape again. I'm still tagging releases with a bit of feel and not enough process. I'll look at this some more tomorrow night. The SIGABRT was added recently as part of the close speedups. Thats from memory. I can provide the exact patch that introduced that tomorrow. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jul 23 22:22:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 22:22:26 -0600 (MDT) Subject: [Rxtx] clarification Message-ID: It should be clear that doug is the maintainer of rxtx.org now. I'll be running around very fast trying to make that easier for him but if you want something in rxtx, it is doug that does that. There are some things doug isnt very good at. He needs some help there. If he asks others for their opinion, thats his call. If he asks others for help, thats his call. This was setup to help the community. I hope everyone makes good use of it as they are now. I'm very happy with what I see but I want to make it clear that nobody should be asking me to be in rxtx. I have interests but they may not always be yours. -- Trent Jarvi tjarvi at qbang.org From guille at sms.nl Mon Jul 24 00:32:26 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Mon, 24 Jul 2006 08:32:26 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <7.0.1.0.0.20060724082455.038aa518@sms.nl> At 18:31 20/07/2006, Trent Jarvi wrote: > > PROJECT SCOPE: > > ------------- > > > > Also, we should think carefully about what the scope of > > this project would be. Should it be javax."comm" which > > handles both serial and parallel (is parallel going by the > > wayside). Should it be split into two project: > > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > > > > Should we differentiate between single-ended serial > > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > > quasi-multidrop and full multidrop busses such as > > EIA422, EIA432 and EIA485? If we really were to > > add I2C support to the API, we'd have to delve into > > the semantics more, because there could be some > > implicit decoding of the bus the API users would > > want to see. > > > >Hi Paul > >The way RXTX works, which is a fair representation of the people using the >API, is complete support for RIA232, minimal support for IEEE1284. From >what I understand, Sun was going along the same lines. If we combined >both projects, we would have half a parallel port implementation. I see >maybe 4 requests for features not in the parallel support a year. > >The other protocols should not be limited by a JSR which is going to be >focused upon serial port interests. The IEA485 hacks in RXTX along with >I2C and Raw should _not_ be considered a strong basis for extending the >API to cover these protocols. If people want to do real implementations, >they should not face a 'standard' which wasnt really focused upon their >interests. I think we understand the parallel port issues fairly well but >have not implemented many features and I don't know if we would. I agree with all of this. API requirements for I2C, SPI, etc. are very different from those for RS232/485/422. Our embedded Java platform has APIs for all of these and more and they don't share a lot apart from the fact that they all use Input/OutputStreams (and in the case of SPI you still need to cater with the fact that every time you want to read you must also write to the device.) If I was to design javax.comm from scratch, I think I would focus on serial ports exclusively (== whatever the underlying OS represents as serial ports). Even parallel is a bit out of place IMHO, although I understand it needs to stay for backwards compatibility. >So a versatile API is favorable but I do not think we have the proper >community to represent much more than Serial. Yes, I think the same. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From joachim at buechse.de Mon Jul 24 01:33:14 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 24 Jul 2006 09:33:14 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607231412.34078.pascal@quies.net> <200607231555.52419.pascal@quies.net> Message-ID: <106C7BEC-EC26-4A05-8E94-61E2C9F2A54E@buechse.de> Or you put your project on Sourceforge and use this: http://sourceforge.net/docs/compile_farm#hosts On 24.07.2006, at 02:14, Dr. Douglas Lyon wrote: > Hi All, > The present JNLP distro that I use: >>> >>> >> download="eager" /> >>> >> > > Works for Macs using G3 and G4's. I have not tested > this with an i386 mac, as I do not have one. And it only works > with i386 based linux... > > As far as architecture goes: > > > > Allows for a chip arch, and this might address your question. > > The real bottleneck is that you need one of everything to test a > deployment, > or you have to know a bunch of people (like on this list!) to do a > proper test. > > Cheers! > - Doug > > >> Op zondag 23 juli 2006 14:58, schreef Dr. Douglas Lyon: >>> Hi All, >>> Yes, I do have a download, as to the question of "huge": >>> ls -al native.jar >>> -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar >>> 28kbytes is not really huge, right? >>> In fact, if you uncompress the jar, you get: >>> -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so >>> -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so >>> Which is almost 80kbytes, so the jar is 40% of the native libs >>> size, and >>> it is signed. >>> At least on the Linux version, it is smaller. I did not check the >>> other versions. >>> >>> And with java web start, the JNLP only downloads the native jar >>> if it is >>> new or changed. >>> And it only downloads the native jar used for the target platform. >>> >>> Here is how the jnlp looks, FYI... >>> >> codebase="http://show.docjava.com:8086/book/cgij/code/ >>> jnlp/"> >>> >>> addbk.JAddressBook.Main >>> DocJava, Inc. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> download="eager" /> >>> >>> >>> >>> >>> >> download="lazy" /> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I have been playing around with "eager" and "lazy" directives, >>> but I can't really tell the difference. >>> >>> Cheers! >>> - Doug >> >> That is a nice sollution. >> >> Is there a tag for the architecture too becouse now you assume >> i386 and that >> is of course not necesairy true. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jul 24 02:13:15 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 24 Jul 2006 10:13:15 +0200 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> Message-ID: <939306BB-2AEE-4D20-906E-9A9B40C76125@buechse.de> The pthread_kill is followed by a sleep. When the sleep returns the structure is damaged. I did not find the source that overwrites the closing field - it is correctly set by the exiting drain thread. But something overwrites it afterwards. I currently believe that this existed for some time but was never seen because the previous versions did not rely on the structure to be in good shape when tearing down connections. However I may be completely wrong and it is an OSX problem. To help me find the source, it would be nice to get some indications what the 2 debug lines I suggested return on other platforms. Joachim On 24.07.2006, at 05:27, Trent Jarvi wrote: > On Sat, 22 Jul 2006, Joachim Buechse wrote: > >> I just discovered a strange error in RXTX on OSX. SerialDemo.java >> manages to corrupt the event_info_structure by a simple >> OpenPort,ClosePort - this could be in relation to the deadlock >> problem that was reported recently. >> >> Could anyone try to reproduce this on Solaris or some other system >> which is neither WIN32 nor Linux (ie which uses a drain thread). >> >> In SerialImp.c : RXTXPort(interruptEventLoop) >> >> Apparently the event_info_structure gets corrupted shortly after >> >> pthread_kill(index->drain_tid, SIGABRT); >> >> In particular, the index->closing flag gets overwritten by a pointer >> value. > > Hi Joachim > > Interesting. I did run many tests with that code on may OSs. To > be fair, > the tests are just starting to get into good shape again. I'm still > tagging releases with a bit of feel and not enough process. I'll > look at > this some more tomorrow night. > > The SIGABRT was added recently as part of the close speedups. > Thats from > memory. I can provide the exact patch that introduced that tomorrow. > > -- > Trent Jarvi > tjarvi at qbang.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Mon Jul 24 05:58:21 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 13:58:21 +0200 Subject: [Rxtx] =?iso-8859-1?q?NativeLibraryManager_-_A_general_solution_a?= =?iso-8859-1?q?n_to_old=09problem=2E?= In-Reply-To: <44C3AA47.4060003@cox.net> References: <44C3AA47.4060003@cox.net> Message-ID: <200607241358.21366.pascal@quies.net> Op zondag 23 juli 2006 18:56, schreef Gregg Wonderly: > Dr. Douglas Lyon wrote: > > The Class.forName is a static method. Therefore > > myClass.forName Should be Class.forName and > > myClass becomes an unused parameter. > > Or better yet, make that parameter a context classloader and call > > Class.forName( classname, classloader); > > so that the location of the codebase for loading classes can be separate > from the applications classpath. I agree. -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 10719 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060724/693f269d/CommunicationAPI-0342.bin From pascal at quies.net Mon Jul 24 06:05:53 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 14:05:53 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607240210.45992.pascal@quies.net> Message-ID: <200607241405.53456.pascal@quies.net> Op maandag 24 juli 2006 04:49, schreef Trent Jarvi: > > @Trent > > Would you include this class afther any possible comments in the > > distribution? > > Hi Pascal, > > It would appear to me that this is a tool for using the API, not an API. > So perhaps the classname is not the best choice. > > The class also has a main which would not make a great deal of sense to > include in the library to me. It would make a nice example for the > contrib directory or a new utility directory though. Documentation of its > availability in the main document could make it stand out from the other > contrib files. The name-change and the removal of main() would ofcourse be no problem. You really don't want to distribute binaries, huh? How can the developers of RXTX know whether it works on a machine they don't have? Anyway, I don't see anotherway to get a version of the extension "that just works" than to build my own distribution. :@ I also can't believe that nobody on this list has binaries for official supported platforms like Windows IA64 and Windows x86_64 unless the build fails on these platforms (which would be nice to know). http://java.sun.com/j2se/1.4.2/system-configurations.html http://java.sun.com/j2se/1.5.0/system-configurations.html From pascal at quies.net Mon Jul 24 06:08:45 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 14:08:45 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <106C7BEC-EC26-4A05-8E94-61E2C9F2A54E@buechse.de> References: <106C7BEC-EC26-4A05-8E94-61E2C9F2A54E@buechse.de> Message-ID: <200607241408.45956.pascal@quies.net> Op maandag 24 juli 2006 09:33, schreef Joachim Buechse: > Or you put your project on Sourceforge and use this: > > http://sourceforge.net/docs/compile_farm#hosts That's nice. :) I'll host a distribution on Sourceforge real soon. HP also has a such a facility for PA-RISC and IA64 architectures at http://www.testdrive.hp.com/ The other day I was thinking about building a big bittorrent with Qemu images for developers. The number of platforms seems impressive: http://qemu.org/status.html With each image compressed with bzip2 a clean installation of OpenBSD and FreeBSD and a Debian Woody + gmake + gcc for each Qemu platform will take about 1.5GB. From lyon at docjava.com Mon Jul 24 07:07:02 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 24 Jul 2006 09:07:02 -0400 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060724082455.038aa518@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: Hi All, There has been a lot of discussion regarding RS485. Let me see if I can summarize this, please correct me if I am wrong; I am deliberately ignoring connector and electrical issues, focusing, instead, on protocol and software issues. Also, I have never used RS485, and I don't know much about it. 1. Serial ports that claim RS232 are typically used in the data link layer of the OSI model of networking. Basically, this means that they work with a point-to-point protocol and are meant to connect two devices. 2. Within the RS232 standard there are framing bits (start and stop bits) and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. Thats' it. 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) you do it in software, not in the RS232 standard. 4. RS485 is different from RS232 in that it is in the Network Layer of the OSI model of networking. 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in a factory). RS-485 is similar to RS-422, but RS-422 allows just one driver with multiple receivers whereas RS-485 supports multiple drivers and receivers. 6. RS-485 is a serial bus with multiple nodes and thus must handle network link layer protocols. By using high-impedance receivers, you can have as many as 256 nodes. 7. The RS-485 can be implemented with RXTX in the core and a layer of software on top to handle media access control (MAC sublayer). There are also hardware converters. http://www.rs485.com/pconverters.html for example. However, some of these require software control. There is some support in the form of the Rs485.java class, in RXTX. 8. The RS-485 specification will add to the size of the JSR 9. Javax.comm specification, version 2.0 (the Real OLD version) says: This version of the Java communications API contains support for RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not mentioned. 10. DO people want to add RS485 to a new JSR? Would it make sense for the RS-485 people to speak up now? Please let me know if you think my summary is wrong. Thanks! - Doug >At 18:31 20/07/2006, Trent Jarvi wrote: >> > PROJECT SCOPE: >> > ------------- >> > >> > Also, we should think carefully about what the scope of >> > this project would be. Should it be javax."comm" which >> > handles both serial and parallel (is parallel going by the >> > wayside). Should it be split into two project: >> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >> > >> > Should we differentiate between single-ended serial >> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >> > quasi-multidrop and full multidrop busses such as >> > EIA422, EIA432 and EIA485? If we really were to >> > add I2C support to the API, we'd have to delve into >> > the semantics more, because there could be some >> > implicit decoding of the bus the API users would >> > want to see. >> > >> >>Hi Paul >> >>The way RXTX works, which is a fair representation of the people using the >>API, is complete support for RIA232, minimal support for IEEE1284. From >>what I understand, Sun was going along the same lines. If we combined >>both projects, we would have half a parallel port implementation. I see >>maybe 4 requests for features not in the parallel support a year. >> >>The other protocols should not be limited by a JSR which is going to be >>focused upon serial port interests. The IEA485 hacks in RXTX along with >>I2C and Raw should _not_ be considered a strong basis for extending the >>API to cover these protocols. If people want to do real implementations, >>they should not face a 'standard' which wasnt really focused upon their >>interests. I think we understand the parallel port issues fairly well but >>have not implemented many features and I don't know if we would. > >I agree with all of this. API requirements for I2C, SPI, etc. are very >different from those for RS232/485/422. Our embedded Java platform has >APIs for all of these and more and they don't share a lot apart from the >fact that they all use Input/OutputStreams (and in the case of SPI you >still need to cater with the fact that every time you want to read you >must also write to the device.) > >If I was to design javax.comm from scratch, I think I would focus on >serial ports exclusively (== whatever the underlying OS represents as >serial ports). Even parallel is a bit out of place IMHO, although I >understand it needs to stay for backwards compatibility. > > >>So a versatile API is favorable but I do not think we have the proper >>community to represent much more than Serial. > >Yes, I think the same. > >Guillermo >-- >Guillermo Rodriguez Garcia > >Snijder Micro Systems phone +31-493-351020 >G. Rodriguez Garcia fax +31-493-351530 >Visser 25 email guille at sms.nl >NL5751 BL Deurne >The Netherlands http://www.snijder.com > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Mon Jul 24 07:46:55 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Mon, 24 Jul 2006 10:46:55 -0300 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: <44C4CF4F.1080706@gmail.com> Doug: I do not think that RS485 is a must by now. I do think we must make a JSR to standarize a bit Serial Ports accessing. Maybe we can make a JSR just for serial ports, and then start trying with other kind of ports and make others JSR. Or try to expand our first JSR, but I trully do not know if that can be made. About other ports besides RS485, the others I2C, SPI, etc, run at a very low level, maybe too close to the processor for Java. I do not know if Java is fast enough to access this ports, even more as this ports depends directly from the architecture, the write once run every way of Java is somekind useless at this level, so I do not think this is suitable for us. Regards, Manuel > Hi All, > There has been a lot of discussion regarding RS485. > > Let me see if I can summarize this, please correct me if I am wrong; > I am deliberately ignoring connector and electrical issues, focusing, > instead, on protocol and software issues. Also, I have never used > RS485, and I don't know much about it. > > 1. Serial ports that claim RS232 are typically used in > the data link layer of the OSI model of networking. Basically, this means > that they work with a point-to-point protocol and are meant to connect two > devices. > > 2. Within the RS232 standard there are framing bits (start and stop bits) > and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. > Thats' it. > > 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) > you do it in software, not in the RS232 standard. > > 4. RS485 is different from RS232 in that it is in the Network Layer of > the OSI model of networking. > > 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > a factory). > RS-485 is similar to RS-422, but RS-422 allows just one driver with > multiple receivers whereas RS-485 supports multiple drivers and > receivers. > > 6. RS-485 is a serial bus with multiple nodes and thus must handle network > link layer protocols. By using high-impedance receivers, you can have > as many as 256 nodes. > > 7. The RS-485 can be implemented with RXTX in the core and a layer of software > on top to handle media access control (MAC sublayer). There are also > hardware converters. > http://www.rs485.com/pconverters.html for example. However, some of > these require software control. There is some support in the form of > the Rs485.java class, > in RXTX. > > 8. The RS-485 specification will add to the size of the JSR > > 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > This version of the Java communications API contains support for > RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > mentioned. > > 10. DO people want to add RS485 to a new JSR? > > Would it make sense for the RS-485 people to speak up now? > Please let me know if you think my summary is wrong. > > Thanks! > - Doug > > > > > > >> At 18:31 20/07/2006, Trent Jarvi wrote: >> >>> > PROJECT SCOPE: >>> > ------------- >>> > >>> > Also, we should think carefully about what the scope of >>> > this project would be. Should it be javax."comm" which >>> > handles both serial and parallel (is parallel going by the >>> > wayside). Should it be split into two project: >>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>> > >>> > Should we differentiate between single-ended serial >>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>> > quasi-multidrop and full multidrop busses such as >>> > EIA422, EIA432 and EIA485? If we really were to >>> > add I2C support to the API, we'd have to delve into >>> > the semantics more, because there could be some >>> > implicit decoding of the bus the API users would >>> > want to see. >>> > >>> >>> Hi Paul >>> >>> The way RXTX works, which is a fair representation of the people using the >>> API, is complete support for RIA232, minimal support for IEEE1284. From >>> what I understand, Sun was going along the same lines. If we combined >>> both projects, we would have half a parallel port implementation. I see >>> maybe 4 requests for features not in the parallel support a year. >>> >>> The other protocols should not be limited by a JSR which is going to be >>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>> I2C and Raw should _not_ be considered a strong basis for extending the >>> API to cover these protocols. If people want to do real implementations, >>> they should not face a 'standard' which wasnt really focused upon their >>> interests. I think we understand the parallel port issues fairly well but >>> have not implemented many features and I don't know if we would. >>> >> I agree with all of this. API requirements for I2C, SPI, etc. are very >> different from those for RS232/485/422. Our embedded Java platform has >> APIs for all of these and more and they don't share a lot apart from the >> fact that they all use Input/OutputStreams (and in the case of SPI you >> still need to cater with the fact that every time you want to read you >> must also write to the device.) >> >> If I was to design javax.comm from scratch, I think I would focus on >> serial ports exclusively (== whatever the underlying OS represents as >> serial ports). Even parallel is a bit out of place IMHO, although I >> understand it needs to stay for backwards compatibility. >> >> >> >>> So a versatile API is favorable but I do not think we have the proper >>> community to represent much more than Serial. >>> >> Yes, I think the same. >> >> Guillermo >> -- >> Guillermo Rodriguez Garcia >> >> Snijder Micro Systems phone +31-493-351020 >> G. Rodriguez Garcia fax +31-493-351530 >> Visser 25 email guille at sms.nl >> NL5751 BL Deurne >> The Netherlands http://www.snijder.com >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From gergg at cox.net Mon Jul 24 07:51:53 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 08:51:53 -0500 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607240210.45992.pascal@quies.net> References: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> <200607232134.17451.pascal@quies.net> <200607240210.45992.pascal@quies.net> Message-ID: <44C4D079.80609@cox.net> Pascal S. de Kloe wrote: > @Gregg > You can extract the necessary libraries during the installation with the > extractNativeLibraries method to the application directory so they get loaded > automatically. Is that good enough? If you start the JVM with -Djava.security.manager what permissions are required? Can you send me a policy that is applicable so that I can review what permissions are being required? Gregg Wonderly From gergg at cox.net Mon Jul 24 07:54:22 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 08:54:22 -0500 Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: <44C4D10E.50604@cox.net> Joachim Buechse wrote: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. Sorry for the late reply here. My intent was this. That there could be a low level port/device SPI that could be put in place once, and then overtime we could layer other APIs, including an updated javax.comm which would make use of this SPI. Gregg Wonderly From cmalan at lhar.co.za Mon Jul 24 08:04:01 2006 From: cmalan at lhar.co.za (Christo Malan) Date: Mon, 24 Jul 2006 16:04:01 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: <44C4D351.603@lhar.co.za> Hi I don't think RS-485 belong in rxtx, the scope of the spec is not wide enough as it only specify the electrical layer. Their is no data protocol recommended or defined. This mean that we have no idea when to sample for a bit, how long is a bit and how many bits before we can say new data is available. Christo Dr. Douglas Lyon wrote: > Hi All, > There has been a lot of discussion regarding RS485. > > Let me see if I can summarize this, please correct me if I am wrong; > I am deliberately ignoring connector and electrical issues, focusing, > instead, on protocol and software issues. Also, I have never used > RS485, and I don't know much about it. > > 1. Serial ports that claim RS232 are typically used in > the data link layer of the OSI model of networking. Basically, this means > that they work with a point-to-point protocol and are meant to connect two > devices. > > 2. Within the RS232 standard there are framing bits (start and stop bits) > and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. > Thats' it. > > 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) > you do it in software, not in the RS232 standard. > > 4. RS485 is different from RS232 in that it is in the Network Layer of > the OSI model of networking. > > 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > a factory). > RS-485 is similar to RS-422, but RS-422 allows just one driver with > multiple receivers whereas RS-485 supports multiple drivers and > receivers. > > 6. RS-485 is a serial bus with multiple nodes and thus must handle network > link layer protocols. By using high-impedance receivers, you can have > as many as 256 nodes. > > 7. The RS-485 can be implemented with RXTX in the core and a layer of software > on top to handle media access control (MAC sublayer). There are also > hardware converters. > http://www.rs485.com/pconverters.html for example. However, some of > these require software control. There is some support in the form of > the Rs485.java class, > in RXTX. > > 8. The RS-485 specification will add to the size of the JSR > > 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > This version of the Java communications API contains support for > RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > mentioned. > > 10. DO people want to add RS485 to a new JSR? > > Would it make sense for the RS-485 people to speak up now? > Please let me know if you think my summary is wrong. > > Thanks! > - Doug > > > > > > >> At 18:31 20/07/2006, Trent Jarvi wrote: >> >>> > PROJECT SCOPE: >>> > ------------- >>> > >>> > Also, we should think carefully about what the scope of >>> > this project would be. Should it be javax."comm" which >>> > handles both serial and parallel (is parallel going by the >>> > wayside). Should it be split into two project: >>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>> > >>> > Should we differentiate between single-ended serial >>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>> > quasi-multidrop and full multidrop busses such as >>> > EIA422, EIA432 and EIA485? If we really were to >>> > add I2C support to the API, we'd have to delve into >>> > the semantics more, because there could be some >>> > implicit decoding of the bus the API users would >>> > want to see. >>> > >>> >>> Hi Paul >>> >>> The way RXTX works, which is a fair representation of the people using the >>> API, is complete support for RIA232, minimal support for IEEE1284. From >>> what I understand, Sun was going along the same lines. If we combined >>> both projects, we would have half a parallel port implementation. I see >>> maybe 4 requests for features not in the parallel support a year. >>> >>> The other protocols should not be limited by a JSR which is going to be >>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>> I2C and Raw should _not_ be considered a strong basis for extending the >>> API to cover these protocols. If people want to do real implementations, >>> they should not face a 'standard' which wasnt really focused upon their >>> interests. I think we understand the parallel port issues fairly well but >>> have not implemented many features and I don't know if we would. >>> >> I agree with all of this. API requirements for I2C, SPI, etc. are very >> different from those for RS232/485/422. Our embedded Java platform has >> APIs for all of these and more and they don't share a lot apart from the >> fact that they all use Input/OutputStreams (and in the case of SPI you >> still need to cater with the fact that every time you want to read you >> must also write to the device.) >> >> If I was to design javax.comm from scratch, I think I would focus on >> serial ports exclusively (== whatever the underlying OS represents as >> serial ports). Even parallel is a bit out of place IMHO, although I >> understand it needs to stay for backwards compatibility. >> >> >> >>> So a versatile API is favorable but I do not think we have the proper >>> community to represent much more than Serial. >>> >> Yes, I think the same. >> >> Guillermo >> -- >> Guillermo Rodriguez Garcia >> >> Snijder Micro Systems phone +31-493-351020 >> G. Rodriguez Garcia fax +31-493-351530 >> Visser 25 email guille at sms.nl >> NL5751 BL Deurne >> The Netherlands http://www.snijder.com >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > From pascal at quies.net Mon Jul 24 08:19:03 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 16:19:03 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <44C4D079.80609@cox.net> References: <200607240210.45992.pascal@quies.net> <44C4D079.80609@cox.net> Message-ID: <200607241619.04053.pascal@quies.net> Op maandag 24 juli 2006 15:51, schreef Gregg Wonderly: > Pascal S. de Kloe wrote: > > @Gregg > > You can extract the necessary libraries during the installation with the > > extractNativeLibraries method to the application directory so they get > > loaded automatically. Is that good enough? > > If you start the JVM with -Djava.security.manager what permissions are > required? Can you send me a policy that is applicable so that I can review > what permissions are being required? Just look at the javadoc in CommunicationAPI.java for SecurityExceptions. ;) From gergg at cox.net Mon Jul 24 08:21:49 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 09:21:49 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4CF4F.1080706@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> Message-ID: <44C4D77D.5080200@cox.net> Manuel Francisco Naranjo wrote: > Doug: > I do not think that RS485 is a must by now. I do think we must make a > JSR to standarize a bit Serial Ports accessing. Maybe we can make a JSR > just for serial ports, and then start trying with other kind of ports > and make others JSR. Or try to expand our first JSR, but I trully do > not know if that can be made. I think that anyone aimed at the javax.comm space should be interested in creating a hardware access SPI first. This is the predominate stumbling block for java having access to various hardware devices. The more we can promote as a standard, the more we can expect consistency and availability! > About other ports besides RS485, the others I2C, SPI, etc, run at a very > low level, maybe too close to the processor for Java. SPI (not service provider interface) is a great protocol for disparet systems because the clocking is synchronous based on the fastest speed available at each end. This means that you can do SPI, today, in java by connecting serial port signal lines, or parallel port data lines to an SPI device, and bit banging the protocol. It won't be lightening fast, but it will be very much functional. What would make the most since is the ability for applications to designate various signalling line sources such as serial signaling lines and parallel port data lines as SPI data, slave select and clock signals, and plug those into an existing API. public class SPISlaveSelectLine { public SPISlaveSelectLine( int slave, SignalPort sp ) { ... } } public class SPIClockLine { public SPIClockLine( SignalPort sp ) { ... } } public class SPIDataLine { public SPIDataLine( SignalPort sp ) { ... } } I'd really like to see the embedded systems community take up this task and push these kinds of things forward. Having standard APIs would make it possible to run your software on aJile's AJ processors, the Muvium PIC environment, javacard, J2ME, etc. Imagine being able to plug a cellphone into the wall, attach a cable which has signalling lines and presto a remote terminal for monitoring and control. Data collection is a very needed capability as the next wave of technology evolution. The Java platform is not enabled with APIs to do this trivially yet. So, it doesn't look viable to many... Gregg Wonderly From guille at sms.nl Mon Jul 24 08:37:21 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 16:37:21 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: <1153751841.44c4db21de4bb@webmail.eatserver.nl> Hi Doug, Some comments below. Quoting "Dr. Douglas Lyon" : > Hi All, > There has been a lot of discussion regarding RS485. > > Let me see if I can summarize this, please correct me if I am wrong; > I am deliberately ignoring connector and electrical issues, focusing, > instead, on protocol and software issues. Also, I have never used > RS485, and I don't know much about it. > > 1. Serial ports that claim RS232 are typically used in > the data link layer of the OSI model of networking. Basically, this means > that they work with a point-to-point protocol and are meant to connect two > devices. It is actually physical + link (layers 1 and 2 of the OSI model), but yes, this is essentially right. > > 2. Within the RS232 standard there are framing bits (start and stop bits) > and error control bits (parity). The flow control is xon-xoff or DTR, CTS, > RTS. Thats' it. I'm not even sure that the RS232 standard talks about xon-xoff and such, I think it does not do much more than defining the electrical signals. Also note that RS232 was originally defined for the DTE-DCE interface (e.g. a device such as a modem connected to a computer). The current use of RS232 as a "general purpose" point to point link is a generalization of the RS232 standard. > > 3. If you want more than that from RS232 (forward error correction, ARQ, > etc.) > you do it in software, not in the RS232 standard. > > 4. RS485 is different from RS232 in that it is in the Network Layer of > the OSI model of networking. I would not put it that way. RS485 is very similar to RS232 with three main differences: - Only tx/rx, no extra signals such as DTR, RTS, CTS, etc (but then many "RS232" serial ports don't have them either) - Different electrical specs (which do not concern us here) - Multidrop and only one node talks at a given time (half duplex) But it does not define addresses (many RS485-based protocol use addresses for the nodes but that's not part of the RS485 standard), routing, etc. For software developers it still looks like a serial port (which it is!) except for the half-duplex part. More on this below. So RS485 is still about layers 1 and 2, same as RS232. I think all of this could be easier if we talk about UARTs instead of "RS232/RS485/RS422". All of these three are typically UARTs with some sort of buffer to get the electrical levels right: RS232 interface == UART + RS232 buffer/transceiver RS485 interface == UART + RS485 buffer/transceiver RS422 interface == UART + RS422 buffer/transceiver > > 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > a factory). > RS-485 is similar to RS-422, but RS-422 allows just one driver with > multiple receivers whereas RS-485 supports multiple drivers and > receivers. RS422 is exactly the same as RS485 except that it uses 4 wires instead of 2 wires so it can be full duplex again (but again this depends on the protocol you layer on top) > > 6. RS-485 is a serial bus with multiple nodes and thus must handle network > link layer protocols. By using high-impedance receivers, you can have > as many as 256 nodes. > > 7. The RS-485 can be implemented with RXTX in the core and a layer of > software > on top to handle media access control (MAC sublayer). There are also > hardware converters. > http://www.rs485.com/pconverters.html for example. However, some of > these require software control. There is some support in the form of > the Rs485.java class, > in RXTX. > > 8. The RS-485 specification will add to the size of the JSR > > 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > This version of the Java communications API contains support for > RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > mentioned. > > 10. DO people want to add RS485 to a new JSR? > > Would it make sense for the RS-485 people to speak up now? > Please let me know if you think my summary is wrong. Basically, for a software developer the only difference between RS485 and RS232 is the half-duplex nature of RS485, which means that you cannot receive and send at the same time. This has some implications depending on how RS485 is implemented in hardware, and on the (application) protocol defined on top of RS485. As I said, a RS485 interface is normally implemented using a standard UART plus a RS485 buffer/transceiver. RS485 buffers/transceivers can be in transmit mode or in receive mode. In a given RS485 bus, only one node should be in transmit mode at any given time, with the rest of the nodes 'listening' until it is their turn to transmit (and it is the application level protocol the one defines who should transmit next.) The RS485 chips used as buffers/transceivers normally have a control pin that is used to switch them into transmit or receive mode. There are typically three ways to handle this: 1. One of the control signals from the UART, such as RTS, DTR, etc. is connected to this control pin. The software must explicitly toggle this signal in order to switch the RS485 buffer/transceiver into transmit or receive mode. This puts a lot of burden on the software side and is sometimes unreliable because of complex timing issues as well as issues with buffering at the device driver level, but it is still a popular solution. 2. The UART itself knows about RS485 and can be configured to control the RS485 buffer/transceiver automatically, without any sort of software intervention. This is a very good solution since it is transparent to the software. However most UARTs don't know about RS485. 3. Standard UART + some custom hardware to control the direction pin. This is also transparent to the software. RS232/RS485 converters are an example of this approach. Implications for the software: For 3/ the software does not need to do anything special. For 2/ all you need is some sort of mechanism to tell the UART to enter RS485-mode (typically a ioctlex). For 1/ there is no simple solution. The timing issues make it difficult to implement this sort of mechanism in user space so it is often done at the device driver level. If this is the case, then all one needs is a mechanism to tell the driver to enter RS485-mode (again, a ioctlex). If this is NOT the case, then the application will need to take care. To do this more or less reliably, you would probably need a couple of things: - Some way to disable software buffering (and FIFOs if possible) - Some way to poll the UART's serial transmit register so that you can determine exactly when all data has been sent (many UARTs don't even support this) and switch to receive mode. - High resolution timers. - Real-time capabilities. Pretty strict requirements as you can see, which is why this approach never works very well except for very specific applications. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From naranjo.manuel at gmail.com Mon Jul 24 08:39:15 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Mon, 24 Jul 2006 11:39:15 -0300 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D77D.5080200@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> Message-ID: <44C4DB93.8080008@gmail.com> Gregg: Thanks for taking me out of the dark ;). Trully I did not know that SPI was an underlaying level of Serial ports, and Parallel ports. I give back what I said. I also would like to see my cell phone plug to every were, and be able to program it with java, is just that I do not know if we are going to get ourselves in a very almost unfinishable task. Regards, Manuel > Manuel Francisco Naranjo wrote: > >> Doug: >> I do not think that RS485 is a must by now. I do think we must make a >> JSR to standarize a bit Serial Ports accessing. Maybe we can make a JSR >> > > just for serial ports, and then start trying with other kind of ports > > and make others JSR. Or try to expand our first JSR, but I trully do > > not know if that can be made. > > I think that anyone aimed at the javax.comm space should be interested in > creating a hardware access SPI first. This is the predominate stumbling > block for java having access to various hardware devices. The more we can > promote as a standard, the more we can expect consistency and availability! > > >> About other ports besides RS485, the others I2C, SPI, etc, run at a very >> low level, maybe too close to the processor for Java. >> > > SPI (not service provider interface) is a great protocol for disparet systems > because the clocking is synchronous based on the fastest speed available at each > end. This means that you can do SPI, today, in java by connecting serial port > signal lines, or parallel port data lines to an SPI device, and bit banging the > protocol. It won't be lightening fast, but it will be very much functional. > What would make the most since is the ability for applications to designate > various signalling line sources such as serial signaling lines and parallel port > data lines as SPI data, slave select and clock signals, and plug those into an > existing API. > > public class SPISlaveSelectLine { > public SPISlaveSelectLine( int slave, SignalPort sp ) { > ... > } > } > > public class SPIClockLine { > public SPIClockLine( SignalPort sp ) { > ... > } > } > > public class SPIDataLine { > public SPIDataLine( SignalPort sp ) { > ... > } > } > > I'd really like to see the embedded systems community take up this task and push > these kinds of things forward. Having standard APIs would make it possible to > run your software on aJile's AJ processors, the Muvium PIC environment, > javacard, J2ME, etc. Imagine being able to plug a cellphone into the wall, > attach a cable which has signalling lines and presto a remote terminal for > monitoring and control. > > Data collection is a very needed capability as the next wave of technology > evolution. The Java platform is not enabled with APIs to do this trivially yet. > So, it doesn't look viable to many... > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From guille at sms.nl Mon Jul 24 08:41:21 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 16:41:21 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D351.603@lhar.co.za> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: <1153752081.44c4dc11eedf3@webmail.eatserver.nl> Quoting Christo Malan : > Hi > > I don't think RS-485 belong in rxtx, the scope of the spec is not wide > enough as it only specify the electrical layer. Their is no data > protocol recommended or defined. RS485 is exactly at the same level as RS232, no more and no less. > This mean that we have no idea when to > sample for a bit, how long is a bit and how many bits before we can say > new data is available. A "RS485 serial port" is just a UART whose output complies with the RS485 electrical spec, just as a "RS232 serial port" is just a UART whose output complies with the RS232 electrical spec. Bit times, sampling intervals, character structure etc. are the same for both protocols... Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From tjarvi at qbang.org Mon Jul 24 08:44:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 24 Jul 2006 08:44:53 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D351.603@lhar.co.za> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: A JSR/JCP would not just involve RXTX. In fact it would be very nice to have others with expertise in various areas like I2C, IrDA, RS485, RS422, ... involved. Within the RXTX community, I do not think we have enough depth to tackle RS485 alone. I'm aware of some of the low level issues but to be honest, I've never actually used it. The RS485 classes in RXTX are more like notes to myself about the issues involved without hardware solutions. In operating systems like Linux, this may be much less of an issue in the future. Linux is putting realtime patches now in the kernels which could make RS485 over EIA232 possible. This is probably the last chance RS485 has to get into a published spec for a long time though. Right now, I do not think its reasonable to include it in the process. Others could make that less of a problem. On Mon, 24 Jul 2006, Christo Malan wrote: > Hi > > I don't think RS-485 belong in rxtx, the scope of the spec is not wide > enough as it only specify the electrical layer. Their is no data > protocol recommended or defined. This mean that we have no idea when to > sample for a bit, how long is a bit and how many bits before we can say > new data is available. > > Christo > > Dr. Douglas Lyon wrote: >> Hi All, >> There has been a lot of discussion regarding RS485. >> >> Let me see if I can summarize this, please correct me if I am wrong; >> I am deliberately ignoring connector and electrical issues, focusing, >> instead, on protocol and software issues. Also, I have never used >> RS485, and I don't know much about it. >> >> 1. Serial ports that claim RS232 are typically used in >> the data link layer of the OSI model of networking. Basically, this means >> that they work with a point-to-point protocol and are meant to connect two >> devices. >> >> 2. Within the RS232 standard there are framing bits (start and stop bits) >> and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. >> Thats' it. >> >> 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) >> you do it in software, not in the RS232 standard. >> >> 4. RS485 is different from RS232 in that it is in the Network Layer of >> the OSI model of networking. >> >> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in >> a factory). >> RS-485 is similar to RS-422, but RS-422 allows just one driver with >> multiple receivers whereas RS-485 supports multiple drivers and >> receivers. >> >> 6. RS-485 is a serial bus with multiple nodes and thus must handle network >> link layer protocols. By using high-impedance receivers, you can have >> as many as 256 nodes. >> >> 7. The RS-485 can be implemented with RXTX in the core and a layer of software >> on top to handle media access control (MAC sublayer). There are also >> hardware converters. >> http://www.rs485.com/pconverters.html for example. However, some of >> these require software control. There is some support in the form of >> the Rs485.java class, >> in RXTX. >> >> 8. The RS-485 specification will add to the size of the JSR >> >> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: >> This version of the Java communications API contains support for >> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not >> mentioned. >> >> 10. DO people want to add RS485 to a new JSR? >> >> Would it make sense for the RS-485 people to speak up now? >> Please let me know if you think my summary is wrong. >> >> Thanks! >> - Doug >> >> >> >> >> >> >>> At 18:31 20/07/2006, Trent Jarvi wrote: >>> >>>> > PROJECT SCOPE: >>>> > ------------- >>>> > >>>> > Also, we should think carefully about what the scope of >>>> > this project would be. Should it be javax."comm" which >>>> > handles both serial and parallel (is parallel going by the >>>> > wayside). Should it be split into two project: >>>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>>> > >>>> > Should we differentiate between single-ended serial >>>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>>> > quasi-multidrop and full multidrop busses such as >>>> > EIA422, EIA432 and EIA485? If we really were to >>>> > add I2C support to the API, we'd have to delve into >>>> > the semantics more, because there could be some >>>> > implicit decoding of the bus the API users would >>>> > want to see. >>>> > >>>> >>>> Hi Paul >>>> >>>> The way RXTX works, which is a fair representation of the people using the >>>> API, is complete support for RIA232, minimal support for IEEE1284. From >>>> what I understand, Sun was going along the same lines. If we combined >>>> both projects, we would have half a parallel port implementation. I see >>>> maybe 4 requests for features not in the parallel support a year. >>>> >>>> The other protocols should not be limited by a JSR which is going to be >>>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>>> I2C and Raw should _not_ be considered a strong basis for extending the >>>> API to cover these protocols. If people want to do real implementations, >>>> they should not face a 'standard' which wasnt really focused upon their >>>> interests. I think we understand the parallel port issues fairly well but >>>> have not implemented many features and I don't know if we would. >>>> >>> I agree with all of this. API requirements for I2C, SPI, etc. are very >>> different from those for RS232/485/422. Our embedded Java platform has >>> APIs for all of these and more and they don't share a lot apart from the >>> fact that they all use Input/OutputStreams (and in the case of SPI you >>> still need to cater with the fact that every time you want to read you >>> must also write to the device.) >>> >>> If I was to design javax.comm from scratch, I think I would focus on >>> serial ports exclusively (== whatever the underlying OS represents as >>> serial ports). Even parallel is a bit out of place IMHO, although I >>> understand it needs to stay for backwards compatibility. >>> >>> >>> >>>> So a versatile API is favorable but I do not think we have the proper >>>> community to represent much more than Serial. >>>> >>> Yes, I think the same. >>> >>> Guillermo >>> -- >>> Guillermo Rodriguez Garcia >>> >>> Snijder Micro Systems phone +31-493-351020 >>> G. Rodriguez Garcia fax +31-493-351530 >>> Visser 25 email guille at sms.nl >>> NL5751 BL Deurne >>> The Netherlands http://www.snijder.com >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From guille at sms.nl Mon Jul 24 08:47:47 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 16:47:47 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D77D.5080200@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> Message-ID: <1153752467.44c4dd93c08f7@webmail.eatserver.nl> Hi Gregg, Quoting Gregg Wonderly : > SPI (not service provider interface) is a great protocol for disparet systems > > because the clocking is synchronous based on the fastest speed available at > each > end. This means that you can do SPI, today, in java by connecting serial > port > signal lines, or parallel port data lines to an SPI device, and bit banging > the > protocol. It won't be lightening fast, but it will be very much functional. [...] > I'd really like to see the embedded systems community take up this task and > push > these kinds of things forward. Having standard APIs would make it possible > to > run your software on aJile's AJ processors, the Muvium PIC environment, > javacard, J2ME, etc. Imagine being able to plug a cellphone into the wall, > attach a cable which has signalling lines and presto a remote terminal for > monitoring and control. As an embedded Java vendor, SNIJDER Micro Systems certainly sees the value of standardized APIs to talk to different types of communication buses including SPI, I2C, 1-Wire, etc., for embedded applications. However we think this has nothing to do with javax.comm. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From guille at sms.nl Mon Jul 24 09:05:22 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 17:05:22 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4DB93.8080008@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <44C4DB93.8080008@gmail.com> Message-ID: <1153753522.44c4e1b24f2e1@webmail.eatserver.nl> Quoting Manuel Francisco Naranjo : > Gregg: > Thanks for taking me out of the dark ;). Trully I did not know that SPI > was an underlaying level of Serial ports, and Parallel ports. In fact it isn't; it is just another serial protocol, just like I2C. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From jredman at ergotech.com Mon Jul 24 09:29:10 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 09:29:10 -0600 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: <44C4E746.8070808@ergotech.com> Folks, The RS232/485/422/etc. etc. is a complete red herring (http://en.wikipedia.org/wiki/Red_herring in case you don't know the expression). The differences between the two are at the electrical level, not at the RXTX level. I'll provide a concrete example and see if we can get away from this issue. There's an industrial serial communications standard - Modbus. Modbus capable devices are very common and can be purchased, generally, with an RS232 or a 485 or a 422 - you decide when you buy it. Some actually provide both 232 and 485 on the same connector. Now, within our environment you configure a Modbus JavaBean. One of the parameters is the "Station Number". The station number is required for both RS232 and RS485 devices - the protocol doesn't change based on the electrical requirements of the device. Now I can configure an application talking to, say, station 2 and station 7. I can add an RS485 converter to the computer serial port and put two physical devices there, configured as station 2 and station 7 and everything works fine. HOWEVER, over RS232 some devices will respond to both station 2 and station 7. So THE SAME APPLICATION will work with both 232 and 485. The only changes are hardware related. This same behavior is true of a number of 485 "networks" and many industrial devices that have 485 interfaces have 232 as an option using the same protocol. Jim Trent Jarvi wrote: > A JSR/JCP would not just involve RXTX. In fact it would be very nice to > have others with expertise in various areas like I2C, IrDA, RS485, RS422, > ... involved. > > Within the RXTX community, I do not think we have enough depth to tackle > RS485 alone. I'm aware of some of the low level issues but to be honest, > I've never actually used it. The RS485 classes in RXTX are more like > notes to myself about the issues involved without hardware solutions. In > operating systems like Linux, this may be much less of an issue in the > future. Linux is putting realtime patches now in the kernels which could > make RS485 over EIA232 possible. > > This is probably the last chance RS485 has to get into a published spec > for a long time though. Right now, I do not think its reasonable to > include it in the process. Others could make that less of a problem. > > On Mon, 24 Jul 2006, Christo Malan wrote: > >> Hi >> >> I don't think RS-485 belong in rxtx, the scope of the spec is not wide >> enough as it only specify the electrical layer. Their is no data >> protocol recommended or defined. This mean that we have no idea when to >> sample for a bit, how long is a bit and how many bits before we can say >> new data is available. >> >> Christo >> >> Dr. Douglas Lyon wrote: >>> Hi All, >>> There has been a lot of discussion regarding RS485. >>> >>> Let me see if I can summarize this, please correct me if I am wrong; >>> I am deliberately ignoring connector and electrical issues, focusing, >>> instead, on protocol and software issues. Also, I have never used >>> RS485, and I don't know much about it. >>> >>> 1. Serial ports that claim RS232 are typically used in >>> the data link layer of the OSI model of networking. Basically, this means >>> that they work with a point-to-point protocol and are meant to connect two >>> devices. >>> >>> 2. Within the RS232 standard there are framing bits (start and stop bits) >>> and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. >>> Thats' it. >>> >>> 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) >>> you do it in software, not in the RS232 standard. >>> >>> 4. RS485 is different from RS232 in that it is in the Network Layer of >>> the OSI model of networking. >>> >>> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in >>> a factory). >>> RS-485 is similar to RS-422, but RS-422 allows just one driver with >>> multiple receivers whereas RS-485 supports multiple drivers and >>> receivers. >>> >>> 6. RS-485 is a serial bus with multiple nodes and thus must handle network >>> link layer protocols. By using high-impedance receivers, you can have >>> as many as 256 nodes. >>> >>> 7. The RS-485 can be implemented with RXTX in the core and a layer of software >>> on top to handle media access control (MAC sublayer). There are also >>> hardware converters. >>> http://www.rs485.com/pconverters.html for example. However, some of >>> these require software control. There is some support in the form of >>> the Rs485.java class, >>> in RXTX. >>> >>> 8. The RS-485 specification will add to the size of the JSR >>> >>> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: >>> This version of the Java communications API contains support for >>> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not >>> mentioned. >>> >>> 10. DO people want to add RS485 to a new JSR? >>> >>> Would it make sense for the RS-485 people to speak up now? >>> Please let me know if you think my summary is wrong. >>> >>> Thanks! >>> - Doug >>> >>> >>> >>> >>> >>> >>>> At 18:31 20/07/2006, Trent Jarvi wrote: >>>> >>>>>> PROJECT SCOPE: >>>>>> ------------- >>>>>> >>>>>> Also, we should think carefully about what the scope of >>>>>> this project would be. Should it be javax."comm" which >>>>>> handles both serial and parallel (is parallel going by the >>>>>> wayside). Should it be split into two project: >>>>>> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>>>>> >>>>>> Should we differentiate between single-ended serial >>>>>> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>>>>> quasi-multidrop and full multidrop busses such as >>>>>> EIA422, EIA432 and EIA485? If we really were to >>>>>> add I2C support to the API, we'd have to delve into >>>>>> the semantics more, because there could be some >>>>>> implicit decoding of the bus the API users would >>>>>> want to see. >>>>>> >>>>> Hi Paul >>>>> >>>>> The way RXTX works, which is a fair representation of the people using the >>>>> API, is complete support for RIA232, minimal support for IEEE1284. From >>>>> what I understand, Sun was going along the same lines. If we combined >>>>> both projects, we would have half a parallel port implementation. I see >>>>> maybe 4 requests for features not in the parallel support a year. >>>>> >>>>> The other protocols should not be limited by a JSR which is going to be >>>>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>>>> I2C and Raw should _not_ be considered a strong basis for extending the >>>>> API to cover these protocols. If people want to do real implementations, >>>>> they should not face a 'standard' which wasnt really focused upon their >>>>> interests. I think we understand the parallel port issues fairly well but >>>>> have not implemented many features and I don't know if we would. >>>>> >>>> I agree with all of this. API requirements for I2C, SPI, etc. are very >>>> different from those for RS232/485/422. Our embedded Java platform has >>>> APIs for all of these and more and they don't share a lot apart from the >>>> fact that they all use Input/OutputStreams (and in the case of SPI you >>>> still need to cater with the fact that every time you want to read you >>>> must also write to the device.) >>>> >>>> If I was to design javax.comm from scratch, I think I would focus on >>>> serial ports exclusively (== whatever the underlying OS represents as >>>> serial ports). Even parallel is a bit out of place IMHO, although I >>>> understand it needs to stay for backwards compatibility. >>>> >>>> >>>> >>>>> So a versatile API is favorable but I do not think we have the proper >>>>> community to represent much more than Serial. >>>>> >>>> Yes, I think the same. >>>> >>>> Guillermo >>>> -- >>>> Guillermo Rodriguez Garcia >>>> >>>> Snijder Micro Systems phone +31-493-351020 >>>> G. Rodriguez Garcia fax +31-493-351530 >>>> Visser 25 email guille at sms.nl >>>> NL5751 BL Deurne >>>> The Netherlands http://www.snijder.com >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From jredman at ergotech.com Mon Jul 24 09:50:21 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 09:50:21 -0600 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D77D.5080200@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> Message-ID: <44C4EC3D.6010204@ergotech.com> Jim, How about we go back to basics and define a serial port. Under Java, I can open /dev/ttyS0, COM1:, etc and read/write a serial port. So what does RXTX bring to the table? If we can define what we need from the product at a high level (functional spec.) then we can look at what's wrong underneath (design requirements). I can do this fairly easily. Functionally, I want support for SerialPort - a superset of that would be fine. SerialPort provides an abstraction that provides everything I need for accessing serial devices. At the design level, I'd like a "pluggable" architecture. That is, I'd like to able to accommodate anything that it makes sense to implement in terms of the SerialPort interface. An obvious plugin is one that supports the current RXTX serial port access - through device files. But _I'd_ like a plugin for serial ports over Ethernet, serial ports over BlueTooth (including discovery), etc. I'm sure others could think of modules they'd like i2c, SPI, etc. etc. I'm not sure that ANY of these should be part of the spec. although perhaps the device file based version could be part of a reference implementation. I don't know that this is really much different from the existing architecture. I doubt that much code could be shared between, for example, a BlueTooth serial port and a /dev/ttyS0 serial port, but perhaps those more familiar with the code could comment. I suspect some cleanup of registration, etc. would be needed to formalize plugins, but I doubt it's too great. Some time ago I learnt the definition of a "Goal". It should be concrete, winnable and build unity. So, I have laid out a concrete goal, build to a superset of the SerialPort interface, it's winnable because it's not a complete rewrite of RXTX and it builds unity because anyone's pet electrical specification can be added. A simplistic view, tell me where I went wrong. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From lyon at docjava.com Mon Jul 24 10:06:40 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 24 Jul 2006 12:06:40 -0400 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4E746.8070808@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> Message-ID: >Hi All, Wow, what an informed and interesting debate from my most innocent and well-intentioned of e-mails. I must say that I am learning a great deal from this list! When I speak about RS232 I wanted to focus on the protocol, not the connector shape or pin-out or electrical issues. Issues like that are addressed by the rs232c standard. The RS232 is a really loaded term! The C revision of the standard was issued in 1969 in part to accommodate electrical characteristics. Revision D was issued in 1986. The current revision is TIA-232-F Interface Between Data Terminal Equipment and Data Circuit-Terminating Equipment Employing Serial Binary Data Interchange, issued in 1997. None of this is of any particular relevance to the basic underlying question: Should the next JSR attempt to address the multi-drop abilities of RS-485? Thanks! - Doug >Folks, > >The RS232/485/422/etc. etc. is a complete red herring >(http://en.wikipedia.org/wiki/Red_herring in case you don't know the >expression). The differences between the two are at the electrical >level, not at the RXTX level. I'll provide a concrete example and see >if we can get away from this issue. > >There's an industrial serial communications standard - Modbus. Modbus >capable devices are very common and can be purchased, generally, with an >RS232 or a 485 or a 422 - you decide when you buy it. Some actually >provide both 232 and 485 on the same connector. Now, within our >environment you configure a Modbus JavaBean. One of the parameters is >the "Station Number". The station number is required for both RS232 and >RS485 devices - the protocol doesn't change based on the electrical >requirements of the device. Now I can configure an application talking >to, say, station 2 and station 7. I can add an RS485 converter to the >computer serial port and put two physical devices there, configured as >station 2 and station 7 and everything works fine. HOWEVER, over RS232 >some devices will respond to both station 2 and station 7. So THE SAME >APPLICATION will work with both 232 and 485. The only changes are >hardware related. This same behavior is true of a number of 485 >"networks" and many industrial devices that have 485 interfaces have 232 >as an option using the same protocol. > >Jim > > >Trent Jarvi wrote: >> A JSR/JCP would not just involve RXTX. In fact it would be very nice to >> have others with expertise in various areas like I2C, IrDA, RS485, RS422, >> ... involved. >> >> Within the RXTX community, I do not think we have enough depth to tackle >> RS485 alone. I'm aware of some of the low level issues but to be honest, >> I've never actually used it. The RS485 classes in RXTX are more like >> notes to myself about the issues involved without hardware solutions. In >> operating systems like Linux, this may be much less of an issue in the >> future. Linux is putting realtime patches now in the kernels which could >> make RS485 over EIA232 possible. >> >> This is probably the last chance RS485 has to get into a published spec >> for a long time though. Right now, I do not think its reasonable to >> include it in the process. Others could make that less of a problem. >> >> On Mon, 24 Jul 2006, Christo Malan wrote: >> >>> Hi >>> >>> I don't think RS-485 belong in rxtx, the scope of the spec is not wide >>> enough as it only specify the electrical layer. Their is no data >>> protocol recommended or defined. This mean that we have no idea when to >>> sample for a bit, how long is a bit and how many bits before we can say >>> new data is available. >>> >>> Christo >>> >>> Dr. Douglas Lyon wrote: >>>> Hi All, >>>> There has been a lot of discussion regarding RS485. >>>> >>>> Let me see if I can summarize this, please correct me if I am wrong; >>>> I am deliberately ignoring connector and electrical issues, focusing, >>>> instead, on protocol and software issues. Also, I have never used >>>> RS485, and I don't know much about it. > >>> >>>> 1. Serial ports that claim RS232 are typically used in >>>> the data link layer of the OSI model of networking. Basically, this means >>>> that they work with a point-to-point protocol and are meant to connect two > >>> devices. >>>> >>>> 2. Within the RS232 standard there are framing bits (start and stop bits) >>>> and error control bits (parity). The flow control is xon-xoff or >>>>DTR, CTS, RTS. >>>> Thats' it. >>>> >>>> 3. If you want more than that from RS232 (forward error >>>>correction, ARQ, etc.) >>>> you do it in software, not in the RS232 standard. >>>> >>>> 4. RS485 is different from RS232 in that it is in the Network Layer of >>>> the OSI model of networking. >>>> >>>> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in >>>> a factory). >>>> RS-485 is similar to RS-422, but RS-422 allows just one driver with >>>> multiple receivers whereas RS-485 supports multiple drivers and >>>> receivers. >>>> >>>> 6. RS-485 is a serial bus with multiple nodes and thus must handle network >>>> link layer protocols. By using high-impedance receivers, you can have >>>> as many as 256 nodes. >>>> >>>> 7. The RS-485 can be implemented with RXTX in the core and a >>>>layer of software >>>> on top to handle media access control (MAC sublayer). There are also >>>> hardware converters. >>>> http://www.rs485.com/pconverters.html for example. However, some of >>>> these require software control. There is some support in the form of >>>> the Rs485.java class, >>>> in RXTX. >>>> >>>> 8. The RS-485 specification will add to the size of the JSR >>>> >>>> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: >>>> This version of the Java communications API contains support for >>>> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not >>>> mentioned. >>>> >>>> 10. DO people want to add RS485 to a new JSR? >>>> >>>> Would it make sense for the RS-485 people to speak up now? >>>> Please let me know if you think my summary is wrong. >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>> >>>> >>>> >>>> >>>>> At 18:31 20/07/2006, Trent Jarvi wrote: >>>>> >>>>>>> PROJECT SCOPE: >>>>>>> ------------- >>>>>>> >>>>>>> Also, we should think carefully about what the scope of >>>>>>> this project would be. Should it be javax."comm" which >>>>>>> handles both serial and parallel (is parallel going by the >>>>>>> wayside). Should it be split into two project: >>>>>>> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>>>>>> >>>>>>> Should we differentiate between single-ended serial >>>>>>> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>>>>>> quasi-multidrop and full multidrop busses such as >>>>>>> EIA422, EIA432 and EIA485? If we really were to >>>>>>> add I2C support to the API, we'd have to delve into >>>>>>> the semantics more, because there could be some >>>>>>> implicit decoding of the bus the API users would >>>>>>> want to see. >>>>>>> >>>>>> Hi Paul >>>>>> >>>>>> The way RXTX works, which is a fair representation of the >>>>>>people using the >>>>>> API, is complete support for RIA232, minimal support for IEEE1284. From >>>>>> what I understand, Sun was going along the same lines. If we combined >>>>>> both projects, we would have half a parallel port implementation. I see >>>>>> maybe 4 requests for features not in the parallel support a year. >>>>>> >>>>>> The other protocols should not be limited by a JSR which is going to be >>>>>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>>>>> I2C and Raw should _not_ be considered a strong basis for extending the >>>>>> API to cover these protocols. If people want to do real >>>>>>implementations, >>>>>> they should not face a 'standard' which wasnt really focused upon their >>>>>> interests. I think we understand the parallel port issues >>>>>>fairly well but >>>>>> have not implemented many features and I don't know if we would. >>>>>> >>>>> I agree with all of this. API requirements for I2C, SPI, etc. are very >>>>> different from those for RS232/485/422. Our embedded Java platform has >>>>> APIs for all of these and more and they don't share a lot apart from the >>>>> fact that they all use Input/OutputStreams (and in the case of SPI you > >>>> still need to cater with the fact that every time you want to read you >>>>> must also write to the device.) >>>>> >>>>> If I was to design javax.comm from scratch, I think I would focus on >>>>> serial ports exclusively (== whatever the underlying OS represents as > >>>> serial ports). Even parallel is a bit out of place IMHO, although I >>>>> understand it needs to stay for backwards compatibility. >>>>> >>>>> >>>>> >>>>>> So a versatile API is favorable but I do not think we have the proper >>>>>> community to represent much more than Serial. >>>>>> >>>>> Yes, I think the same. >>>>> >>>>> Guillermo >>>>> -- >>>>> Guillermo Rodriguez Garcia >>>>> >>>>> Snijder Micro Systems phone +31-493-351020 >>>>> G. Rodriguez Garcia fax +31-493-351530 >>>>> Visser 25 email guille at sms.nl >>>>> NL5751 BL Deurne >>>>> The Netherlands http://www.snijder.com >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >-- >Jim Redman >(505) 662 5156 x85 >http://www.ergotech.com >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Mon Jul 24 10:16:44 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 18:16:44 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> Message-ID: <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> Hi Doug, Quoting "Dr. Douglas Lyon" : > >Hi All, > > > Wow, what an informed and interesting debate from my most > innocent and well-intentioned of e-mails. > > I must say that I am learning a great deal from this list! > > When I speak about > RS232 I wanted to focus on the protocol, not the connector shape or > pin-out or electrical issues. Issues like that are addressed by the > rs232c standard. > The RS232 is a really loaded term! Right. Maybe we should be talking about "serial ports" instead. At the functional level it does not make any difference whether it is RS232, RS485, or RS422... except maybe for the direction control in the case of RS485 ports. [...] > > None of this is of any particular relevance to the basic underlying > question: > > Should the next JSR attempt to address the multi-drop abilities of RS-485? What I would suggest is to just add a new 'ioctlex'-like method to the SerialPort API: A method that you'd use to pass platform- or implementation-specific info to the underlying driver or OS to do things such as "enabling RS485 mode" or "disable FIFOs" or "poll the TSR register". No need to define any function codes. This is for stuff that is platform- or implementation-specific and as such cannot be easily abstracted anyway. The goal is to accomodate hat those systems that have serial ports with special, non-standard capabilities without forcing developers to leave javax.comm. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From Paul.Klissner at Sun.COM Mon Jul 24 10:45:33 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Mon, 24 Jul 2006 09:45:33 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> Message-ID: <44C4F92D.6090807@sun.com> >> None of this is of any particular relevance to the basic underlying >> question: >> >> Should the next JSR attempt to address the multi-drop abilities of RS-485? > > What I would suggest is to just add a new 'ioctlex'-like method > to the SerialPort API: A method that you'd use to pass platform- > or implementation-specific info to the underlying driver or OS > to do things such as "enabling RS485 mode" or "disable FIFOs" or > "poll the TSR register". > > No need to define any function codes. This is for stuff that is > platform- or implementation-specific and as such cannot be easily > abstracted anyway. Detrimental to platform independence. Paul From berkland at spamcop.net Mon Jul 24 11:07:58 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 24 Jul 2006 13:07:58 -0400 Subject: [Rxtx] jcp and jsr In-Reply-To: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> Message-ID: <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> Gregg Wonderly wrote: > That there could be a low level port/device SPI > that could be put in place once, and then overtime > we could layer other APIs, including an updated > javax.comm which would make use of this SPI. I think there is great merit in this suggestion. I would like to see the ability to register a new "port" along with a custom handler in the Java client code before attempting to access the port. e.g . CommManager.getInstance().registerPortImpl("USB1:", new HidPortAdapter(/*vendorId=*/ "1234", /*deviceId=*/ "4321"); CommManager.getInstance().registerPortImpl("Ether1:", new InetPortAdapter(/*ipAndPort=*/ "192.168.1.101:8088"); It would allow other protocols that this group doesn't have depth in to be developed by someone who does on an "as needed" basis. Additionally, the value of this would be with some devices that implement basically the same protocol that was initially used over RS232 for a USB (via an HID) or Ethernet interface. There are a number of these in POS hardware. The existing JavaPOS driver written against JavaCOMM 2.0 could be reused by plugging in an HID or IP adapter before attempting to access the device. It might also be valuable to use something like an extended version of the portmapping file found in JavaCOMM 3.0. A configuration file could allow this definition to take place outside of any Java client code. Such a mapping file wouldn't even need to be part of the JSR API or reference implementation. It could be handled in a specific implementation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060724/7f51342e/attachment-0341.html From guille at sms.nl Mon Jul 24 11:14:54 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 19:14:54 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4F92D.6090807@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> Message-ID: <1153761294.44c5000ec1360@webmail.eatserver.nl> Quoting Paul Klissner : > >> None of this is of any particular relevance to the basic underlying > >> question: > >> > >> Should the next JSR attempt to address the multi-drop abilities of > RS-485? > > > > What I would suggest is to just add a new 'ioctlex'-like method > > to the SerialPort API: A method that you'd use to pass platform- > > or implementation-specific info to the underlying driver or OS > > to do things such as "enabling RS485 mode" or "disable FIFOs" or > > "poll the TSR register". > > > > No need to define any function codes. This is for stuff that is > > platform- or implementation-specific and as such cannot be easily > > abstracted anyway. > > Detrimental to platform independence. Yes, it is. But as you go closer and closer to the hardware level some things are by nature platform-dependent, and sometimes just cannot be solved in a platform-independent way. In these cases, is it better to have no solution at all than having one that is less than perfect? Put it another way, would you prefer having people say "I just cannot do this in Java; I'll go somewhere else" rather than "I can do this in Java -- only not in a platform-independent way" ? Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From gergg at cox.net Mon Jul 24 11:34:00 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 12:34:00 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153752467.44c4dd93c08f7@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> Message-ID: <44C50488.1040508@cox.net> Guillermo Rodriguez wrote: > As an embedded Java vendor, SNIJDER Micro Systems certainly sees the > value of standardized APIs to talk to different types of communication > buses including SPI, I2C, 1-Wire, etc., for embedded applications. > However we think this has nothing to do with javax.comm. I don't think this is only about javax.comm. Certainly that's important. I'm just wading into this conversation mainstream and trying to say: If you are going to do anything about "fixing" javax.comm to work on all platforms, please, please, please start with a hardware port SPI definition that lets you get to serial ports, and then provide the existing javax.com API and whatever new API you think is necessary (I don't have any really issues with the existing API directly). Then, there will be a place for others interesting in SPI, i2C, USB and other things to get started with providing access to devices that are also interesting in Java applications, and directly, in embedded Java applications. Gregg Wonderly From Paul.Klissner at Sun.COM Mon Jul 24 11:41:51 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Mon, 24 Jul 2006 10:41:51 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153761294.44c5000ec1360@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> Message-ID: <44C5065F.3060802@sun.com> Guillermo Rodriguez wrote: > Quoting Paul Klissner : > >>>> None of this is of any particular relevance to the basic underlying >>>> question: >>>> >>>> Should the next JSR attempt to address the multi-drop abilities of >> RS-485? >>> What I would suggest is to just add a new 'ioctlex'-like method >>> to the SerialPort API: A method that you'd use to pass platform- >>> or implementation-specific info to the underlying driver or OS >>> to do things such as "enabling RS485 mode" or "disable FIFOs" or >>> "poll the TSR register". >>> >>> No need to define any function codes. This is for stuff that is >>> platform- or implementation-specific and as such cannot be easily >>> abstracted anyway. >> Detrimental to platform independence. > > Yes, it is. But as you go closer and closer to the hardware level some > things are by nature platform-dependent, and sometimes just cannot be > solved in a platform-independent way. In these cases, is it better to > have no solution at all than having one that is less than perfect? > > Put it another way, would you prefer having people say "I just cannot > do this in Java; I'll go somewhere else" rather than "I can do this > in Java -- only not in a platform-independent way" ? If there isn't a reasonable way to abstract it out, then why use Java? The whole idea is platform neutrality, otherwise, what is the huge advantage of adopting a standardized Java API? I think it is wrong to subvert the API. I think we have to arrive at some sort of consensus about the scope of the API and do our best to engineer a robust API in terms of that scope using abstraction. There may be outliers, but the outliers probably aren't portable, and probably would do just as well to not use java for that particular application. If this was a JSR, if we found some compelling problem that kept cropping up the API could be reved so as not to just orphan cases with legitimate requests. If someone really needs to do funky things with the hardware, why wouldn't that be put in the native back end? Couldn't some of this be addressed by the multiple SPI layer that I recommended as one of the two changes I'd like to see made to javax.comm (the other being a port mapping plugin layer)? Paul From jredman at ergotech.com Mon Jul 24 11:49:46 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 11:49:46 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> Message-ID: <44C5083A.6090902@ergotech.com> A thought for later since we haven't really reached this level of detail, but since this type of approach seems likely... If a configuration file is mandatory, can we specify what the file is called and what the format of the options are (mandatory?, and optional) without limiting extensions. This just adds consistency across platforms/implementations. Jim Doug Berkland wrote: > Gregg Wonderly wrote: > > That there could be a low level port/device SPI > > that could be put in place once, and then overtime > > we could layer other APIs, including an updated > > javax.comm which would make use of this SPI. > > I think there is great merit in this suggestion. I would like to see > the ability to register a new "port" along with a custom handler in the > Java client code before attempting to access the port. > e.g . > CommManager.getInstance().registerPortImpl("USB1:", new > HidPortAdapter(/*vendorId=*/ "1234", /*deviceId=*/ "4321"); > CommManager.getInstance().registerPortImpl("Ether1:", new > InetPortAdapter(/*ipAndPort=*/ " 192.168.1.101:8088 > "); > > It would allow other protocols that this group doesn't have depth in to > be developed by someone who does on an "as needed" basis. > > Additionally, the value of this would be with some devices that > implement basically the same protocol that was initially used over RS232 > for a USB (via an HID) or Ethernet interface. There are a number of > these in POS hardware. The existing JavaPOS driver written against > JavaCOMM 2.0 could be reused by plugging in an HID or IP adapter before > attempting to access the device. > > It might also be valuable to use something like an extended version of > the portmapping file found in JavaCOMM 3.0. A configuration file could > allow this definition to take place outside of any Java client code. > Such a mapping file wouldn't even need to be part of the JSR API or > reference implementation. It could be handled in a specific > implementation. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From mtnvega at yahoo.com.br Mon Jul 24 11:51:40 2006 From: mtnvega at yahoo.com.br (mtnvega) Date: Mon, 24 Jul 2006 14:51:40 -0300 Subject: [Rxtx] Serial Read/Write Details Message-ID: <44C508AC.7060103@yahoo.com.br> Hello, I'm have being flirting with RXTX for a while since I'm working on a college project where I will need to communicate with a microcontroller using USART. Now is the time to start using it! But I have some doubts and I hope you can help-me. I will need to both send and receive data from the serial port. First I will need to send some command bytes then wait for some data that will be returned from the microcontroller. And I would like to know which is the best way to do that. I'm mean, of course send and receive data is the purpose of the serial port and RXTX but I'm looking for some details since there will be no package control but just a fixed command format and confirmation messages from the microcontroller side. I would like to know if I should open and close the port or if I can just open it once. I read that upon writing to output the input buffer are filled with the same data, is it right? If yes, isn't it a problem since I'm waiting for data back in a very small time? Thank you, Luiz _______________________________________________________ Voc? quer respostas para suas perguntas? Ou voc? sabe muito e quer compartilhar seu conhecimento? Experimente o Yahoo! Respostas ! http://br.answers.yahoo.com/ From jredman at ergotech.com Mon Jul 24 12:45:50 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 12:45:50 -0600 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C50488.1040508@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> Message-ID: <44C5155E.7080105@ergotech.com> Gregg, Is SPI applicable to a SerialPort interface over Ethernet (or Bluetooth)? I've assumed that it's specific to directly-connected-UART-based serial ports - something similar to I2C. I'm starting to think that I'm opposed to having hardware definitions (transport layer?) in the JavaComm spec., but then what's left? Jim Gregg Wonderly wrote: > Guillermo Rodriguez wrote: >> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the >> value of standardized APIs to talk to different types of communication >> buses including SPI, I2C, 1-Wire, etc., for embedded applications. >> However we think this has nothing to do with javax.comm. > > I don't think this is only about javax.comm. Certainly that's important. I'm > just wading into this conversation mainstream and trying to say: > > If you are going to do anything about "fixing" javax.comm to work on all > platforms, please, please, please start with a hardware port SPI definition that > lets you get to serial ports, and then provide the existing javax.com API and > whatever new API you think is necessary (I don't have any really issues with the > existing API directly). > > Then, there will be a place for others interesting in SPI, i2C, USB and other > things to get started with providing access to devices that are also interesting > in Java applications, and directly, in embedded Java applications. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Mon Jul 24 13:15:19 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 14:15:19 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C5155E.7080105@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <44C5155E.7080105@ergotech.com> Message-ID: <44C51C47.90409@cox.net> Jim Redman wrote: > Is SPI applicable to a SerialPort interface over Ethernet (or > Bluetooth)? I've assumed that it's specific to > directly-connected-UART-based serial ports - something similar to I2C. SPI is a simple 2 line (clock and data) plus slave select bi-directional, full duplex data transfer mechanism. It has nothing to do, directly with serial ports, but could be implemented using serial port signalling lines. > I'm starting to think that I'm opposed to having hardware definitions > (transport layer?) in the JavaComm spec., but then what's left? Jim, there are multiple conversations going on, on the list. There is a group of people that just want a standard serial port mechanism in Java, apparently NOW! They are going back and forth about that. There is another conversation about doing a JSR to make the serial port interfaces a standard, since Sun's original implementation was never a Java standard. There is a small group saying if you're going to do a JSR for serial ports, why not provide a nice foundation for serial ports which might also support other kinds of "ports" and associated protocols. And there are a couple of other conversations about Pascal's stuff. It's this last group that I am the most interested in. I think that it is possible to create a simple Service Provider Interface for 'hardware interfacing' that covers serial ports and also includes expandability to cover other types of hardware. We want to find the level of abstraction that the most number of OSes provide in their user level APIs, and create a matching SPI at that level which will allow a JVM vendor to provide access to the types of hardware that is common on their OSes/hardware. Then, third parties might add some value by providing some good abstrations for particular types of protocols or particular vendors' hardware (ports which can be switched between RS232 and RS485 for example). Finally, we can create an implementation of the javax.comm API which uses this SPI to provide exactly the same API as today, but with an approved foundation for hardware access from java using 100% java code. Gregg Wonderly From mark at mdsh.com Mon Jul 24 16:03:38 2006 From: mark at mdsh.com (Mark Himsley) Date: Mon, 24 Jul 2006 23:03:38 +0100 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: I don't see how any Java app is going to know the difference between an RS232, RS422, or RS485 port. I regularly use RXTX controlling RS422 devices (controlling VTRs) and I can use an RS232 port with bodged wiring (for short distances) or RS232 port with a media converted - either of which may be built into the PC or may be a USB device - or an RS422 USB device. They are just 'serial port' devices. Please don't get hung up on higher layer stuff - that's for application developers to add on top of a rock-solid multi platform 'serial port' driver implementations. On 24 July 2006 08:44 -0600 Trent Jarvi wrote: > > A JSR/JCP would not just involve RXTX. In fact it would be very nice to > have others with expertise in various areas like I2C, IrDA, RS485, RS422, > ... involved. > > Within the RXTX community, I do not think we have enough depth to tackle > RS485 alone. I'm aware of some of the low level issues but to be honest, > I've never actually used it. The RS485 classes in RXTX are more like > notes to myself about the issues involved without hardware solutions. In > operating systems like Linux, this may be much less of an issue in the > future. Linux is putting realtime patches now in the kernels which could > make RS485 over EIA232 possible. > > This is probably the last chance RS485 has to get into a published spec > for a long time though. Right now, I do not think its reasonable to > include it in the process. Others could make that less of a problem. > > On Mon, 24 Jul 2006, Christo Malan wrote: > > > Hi > > > > I don't think RS-485 belong in rxtx, the scope of the spec is not wide > > enough as it only specify the electrical layer. Their is no data > > protocol recommended or defined. This mean that we have no idea when to > > sample for a bit, how long is a bit and how many bits before we can say > > new data is available. > > > > Christo > > > > Dr. Douglas Lyon wrote: > >> Hi All, > >> There has been a lot of discussion regarding RS485. > >> > >> Let me see if I can summarize this, please correct me if I am wrong; > >> I am deliberately ignoring connector and electrical issues, focusing, > >> instead, on protocol and software issues. Also, I have never used > >> RS485, and I don't know much about it. > >> > >> 1. Serial ports that claim RS232 are typically used in > >> the data link layer of the OSI model of networking. Basically, this > >> means that they work with a point-to-point protocol and are meant to > >> connect two devices. > >> > >> 2. Within the RS232 standard there are framing bits (start and stop > >> bits) and error control bits (parity). The flow control is xon-xoff or > >> DTR, CTS, RTS. Thats' it. > >> > >> 3. If you want more than that from RS232 (forward error correction, > >> ARQ, etc.) you do it in software, not in the RS232 standard. > >> > >> 4. RS485 is different from RS232 in that it is in the Network Layer of > >> the OSI model of networking. > >> > >> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > >> a factory). > >> RS-485 is similar to RS-422, but RS-422 allows just one driver with > >> multiple receivers whereas RS-485 supports multiple drivers and > >> receivers. > >> > >> 6. RS-485 is a serial bus with multiple nodes and thus must handle > >> network link layer protocols. By using high-impedance receivers, you > >> can have as many as 256 nodes. > >> > >> 7. The RS-485 can be implemented with RXTX in the core and a layer of > >> software on top to handle media access control (MAC sublayer). There > >> are also hardware converters. > >> http://www.rs485.com/pconverters.html for example. However, some of > >> these require software control. There is some support in the form of > >> the Rs485.java class, > >> in RXTX. > >> > >> 8. The RS-485 specification will add to the size of the JSR > >> > >> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > >> This version of the Java communications API contains support for > >> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > >> mentioned. > >> > >> 10. DO people want to add RS485 to a new JSR? > >> > >> Would it make sense for the RS-485 people to speak up now? > >> Please let me know if you think my summary is wrong. > >> > >> Thanks! > >> - Doug > >> > >> > >> > >> > >> > >> > >>> At 18:31 20/07/2006, Trent Jarvi wrote: > >>> > >>>> > PROJECT SCOPE: > >>>> > ------------- > >>>> > > >>>> > Also, we should think carefully about what the scope of > >>>> > this project would be. Should it be javax."comm" which > >>>> > handles both serial and parallel (is parallel going by the > >>>> > wayside). Should it be split into two project: > >>>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > >>>> > > >>>> > Should we differentiate between single-ended serial > >>>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > >>>> > quasi-multidrop and full multidrop busses such as > >>>> > EIA422, EIA432 and EIA485? If we really were to > >>>> > add I2C support to the API, we'd have to delve into > >>>> > the semantics more, because there could be some > >>>> > implicit decoding of the bus the API users would > >>>> > want to see. > >>>> > > >>>> > >>>> Hi Paul > >>>> > >>>> The way RXTX works, which is a fair representation of the people > >>>> using the API, is complete support for RIA232, minimal support for > >>>> IEEE1284. From what I understand, Sun was going along the same > >>>> lines. If we combined both projects, we would have half a parallel > >>>> port implementation. I see maybe 4 requests for features not in the > >>>> parallel support a year. > >>>> > >>>> The other protocols should not be limited by a JSR which is going to > >>>> be focused upon serial port interests. The IEA485 hacks in RXTX > >>>> along with I2C and Raw should _not_ be considered a strong basis for > >>>> extending the API to cover these protocols. If people want to do > >>>> real implementations, they should not face a 'standard' which wasnt > >>>> really focused upon their interests. I think we understand the > >>>> parallel port issues fairly well but have not implemented many > >>>> features and I don't know if we would. > >>>> > >>> I agree with all of this. API requirements for I2C, SPI, etc. are very > >>> different from those for RS232/485/422. Our embedded Java platform has > >>> APIs for all of these and more and they don't share a lot apart from > >>> the fact that they all use Input/OutputStreams (and in the case of > >>> SPI you still need to cater with the fact that every time you want to > >>> read you must also write to the device.) > >>> > >>> If I was to design javax.comm from scratch, I think I would focus on > >>> serial ports exclusively (== whatever the underlying OS represents as > >>> serial ports). Even parallel is a bit out of place IMHO, although I > >>> understand it needs to stay for backwards compatibility. > >>> > >>> > >>> > >>>> So a versatile API is favorable but I do not think we have the proper > >>>> community to represent much more than Serial. > >>>> > >>> Yes, I think the same. > >>> > >>> Guillermo > >>> -- > >>> Guillermo Rodriguez Garcia > >>> > >>> Snijder Micro Systems phone +31-493-351020 > >>> G. Rodriguez Garcia fax +31-493-351530 > >>> Visser 25 email guille at sms.nl > >>> NL5751 BL Deurne > >>> The Netherlands http://www.snijder.com > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> > >> > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Mark Himsley From berkland at spamcop.net Mon Jul 24 16:55:18 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 24 Jul 2006 18:55:18 -0400 Subject: [Rxtx] jcp and jsr In-Reply-To: <44C5083A.6090902@ergotech.com> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> <44C5083A.6090902@ergotech.com> Message-ID: <269e40090607241555g281c7f24s5577b86e35d27eab@mail.gmail.com> I'm sorry, I keep reading SPI as "Service Provider Interface" instead of "Serial Peripheral Interface". (See http://en.wikipedia.org/wiki/Serial_Peripheral_Interface.) What I thought was being suggested was a pluggable implementation like that found in javax.security. (The SPI there actually stands for "Security Provider Interface" not "Service Provider Interface" like I had thought.) I guess that might be a CPI (Comm Provider Interface) or PPI (Port Provider Interface.) At any rate what I would like to see is a JSR with (in order of priority) - compatible API for code written against current javax.comm 2.0 classes - ability to register or "force" a port by providing a name and implementation (not have to rely completely on the "auto-discovery") - nothing precluding the use of a portmapping in a given implementation - ability to register port implementations On 7/24/06, Jim Redman wrote: > > A thought for later since we haven't really reached this level of > detail, but since this type of approach seems likely... > > If a configuration file is mandatory, can we specify what the file is > called and what the format of the options are (mandatory?, and optional) > without limiting extensions. > > This just adds consistency across platforms/implementations. > > Jim > > Doug Berkland wrote: > > Gregg Wonderly wrote: > > > That there could be a low level port/device SPI > > > that could be put in place once, and then overtime > > > we could layer other APIs, including an updated > > > javax.comm which would make use of this SPI. > > > > I think there is great merit in this suggestion. I would like to see > > the ability to register a new "port" along with a custom handler in the > > Java client code before attempting to access the port. > > e.g . > > CommManager.getInstance().registerPortImpl("USB1:", new > > HidPortAdapter(/*vendorId=*/ "1234", /*deviceId=*/ "4321"); > > CommManager.getInstance().registerPortImpl("Ether1:", new > > InetPortAdapter(/*ipAndPort=*/ " 192.168.1.101:8088 > > "); > > > > It would allow other protocols that this group doesn't have depth in to > > be developed by someone who does on an "as needed" basis. > > > > Additionally, the value of this would be with some devices that > > implement basically the same protocol that was initially used over RS232 > > for a USB (via an HID) or Ethernet interface. There are a number of > > these in POS hardware. The existing JavaPOS driver written against > > JavaCOMM 2.0 could be reused by plugging in an HID or IP adapter before > > attempting to access the device. > > > > It might also be valuable to use something like an extended version of > > the portmapping file found in JavaCOMM 3.0. A configuration file could > > allow this definition to take place outside of any Java client code. > > Such a mapping file wouldn't even need to be part of the JSR API or > > reference implementation. It could be handled in a specific > > implementation. > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060724/02c50e6a/attachment-0341.html From tjarvi at qbang.org Mon Jul 24 18:44:54 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 24 Jul 2006 18:44:54 -0600 (MDT) Subject: [Rxtx] Serial Read/Write Details In-Reply-To: <44C508AC.7060103@yahoo.com.br> References: <44C508AC.7060103@yahoo.com.br> Message-ID: On Mon, 24 Jul 2006, mtnvega wrote: > Hello, > > I'm have being flirting with RXTX for a while since I'm working on a > college project where I will > need to communicate with a microcontroller using USART. > > Now is the time to start using it! But I have some doubts and I hope you > can help-me. > > I will need to both send and receive data from the serial port. First I > will need to send some command > bytes then wait for some data that will be returned from the > microcontroller. And I would like > to know which is the best way to do that. I'm mean, of course send and > receive data is the purpose > of the serial port and RXTX but I'm looking for some details since there > will be no package control > but just a fixed command format and confirmation messages from the > microcontroller side. > > I would like to know if I should open and close the port or if I can > just open it once. > I read that upon writing to output the input buffer are filled with the > same data, is it right? > If yes, isn't it a problem since I'm waiting for data back in a very > small time? > Hi Luiz Unless you want to use the port with a second application, just open the port once and close it when you exit the application. The input will not be filled with the data you write. The API has events to let you know when data is available and when your data has gone out the port. You can look in the contrib directory that comes with the source for crude examples of event notification. I think there is an example on the wiki too. I don't think you will have any problems. -- Trent Jarvi tjarvi at qbang.org From guille at sms.nl Tue Jul 25 00:26:12 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 08:26:12 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C50488.1040508@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> Message-ID: <7.0.1.0.0.20060725082124.036309e0@sms.nl> At 19:34 24/07/2006, Gregg Wonderly wrote: >Guillermo Rodriguez wrote: > > As an embedded Java vendor, SNIJDER Micro Systems certainly sees the > > value of standardized APIs to talk to different types of communication > > buses including SPI, I2C, 1-Wire, etc., for embedded applications. > > However we think this has nothing to do with javax.comm. > >I don't think this is only about javax.comm. Certainly that's >important. I'm >just wading into this conversation mainstream and trying to say: > >If you are going to do anything about "fixing" javax.comm to work on all >platforms, please, please, please start with a hardware port SPI >definition that >lets you get to serial ports, and then provide the existing javax.com API and >whatever new API you think is necessary (I don't have any really >issues with the >existing API directly). > >Then, there will be a place for others interesting in SPI, i2C, USB and other >things to get started with providing access to devices that are also >interesting >in Java applications, and directly, in embedded Java applications. I do agree that the best a hardware port SPI definition (where SPI = Service Provider Interface, not the SPI protocol) is a good thing to have to support serial ports layered over other transports. However these are still serial ports at the end. I still don't think the javax.comm API is well suited to "any" serial bus such as I2C, SPI, etc. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 00:41:46 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 08:41:46 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C5065F.3060802@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> Message-ID: <7.0.1.0.0.20060725082630.036d2d10@sms.nl> At 19:41 24/07/2006, Paul Klissner wrote: >Guillermo Rodriguez wrote: >>Quoting Paul Klissner : >> >>>>>None of this is of any particular relevance to the basic underlying >>>>>question: >>>>> >>>>>Should the next JSR attempt to address the multi-drop abilities of >>>RS-485? >>>>What I would suggest is to just add a new 'ioctlex'-like method >>>>to the SerialPort API: A method that you'd use to pass platform- >>>>or implementation-specific info to the underlying driver or OS >>>>to do things such as "enabling RS485 mode" or "disable FIFOs" or >>>>"poll the TSR register". >>>> >>>>No need to define any function codes. This is for stuff that is >>>>platform- or implementation-specific and as such cannot be easily >>>>abstracted anyway. >>>Detrimental to platform independence. >>Yes, it is. But as you go closer and closer to the hardware level some >>things are by nature platform-dependent, and sometimes just cannot be >>solved in a platform-independent way. In these cases, is it better to >>have no solution at all than having one that is less than perfect? >>Put it another way, would you prefer having people say "I just cannot >>do this in Java; I'll go somewhere else" rather than "I can do this >>in Java -- only not in a platform-independent way" ? > >If there isn't a reasonable way to abstract it out, then >why use Java? If an application can be 99% platform independent with small bits being not portable, why *not* use Java? I'd prefer to see people using Java to write non-portable applications than having them use C instead. I believe that Java should promote platform neutrality, but that does not necessarily mean precluding the use of anything that is NOT platform independent. And let's face it, if you are using javax.comm to talk to some serial device directly, then chances are you are already tied to some specific hardware anyway. Also, some people (myself included) think that Java can also be used as a systems programming language, not only for applications. For many embedded platforms this is certainly the case. In our platform we even write device drivers directly in Java. I would imagine the Sun SPOT team (www.sunspotworld.com) supports a similar view. If people needs to do non-portable stuff and wants to do it in Java I'd rather have them do it in Java than tell them to do it in C instead. >The whole idea is platform neutrality, otherwise, what is the >huge advantage of adopting a standardized Java API? I think >it is wrong to subvert the API. I think we have to arrive at >some sort of consensus about the scope of the API and do our >best to engineer a robust API in terms of that scope using >abstraction. > >There may be outliers, but the outliers probably aren't portable, >and probably would do just as well to not use java for that >particular application. The cases I have in mind is more like portable applications with very small bits of non portable code. I can imagine lots of portable applications that need access to RS485, specially in the industrial process control and factory automation fields. As I said in an earlier mail RS485 is half- duplex, but there is standard way to do RS485 direction control from software. Does it mean that the whole application should not be written in Java, only because some small bits of code related to RS485 direction control are not completely portable? > If this was a JSR, if we found some >compelling problem that kept cropping up the API could be >reved so as not to just orphan cases with legitimate requests. > >If someone really needs to do funky things with the hardware, >why wouldn't that be put in the native back end? But nobody said the functionality can't be implemented in the native back end. However you still need an application level API to enable/disable it. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 00:44:43 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 08:44:43 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <269e40090607241555g281c7f24s5577b86e35d27eab@mail.gmail.co m> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> <44C5083A.6090902@ergotech.com> <269e40090607241555g281c7f24s5577b86e35d27eab@mail.gmail.com> Message-ID: <7.0.1.0.0.20060725084431.036d0700@sms.nl> At 00:55 25/07/2006, Doug Berkland wrote: >I'm sorry, I keep reading SPI as "Service Provider Interface" >instead of "Serial Peripheral Interface". (See >http://en.wikipedia.org/wiki/Serial_Peripheral_Interface. >) > >What I thought was being suggested was a pluggable implementation >like that found in javax.security. (The SPI there actually stands >for "Security Provider Interface" not "Service Provider Interface" >like I had thought.) I guess that might be a CPI (Comm Provider >Interface) or PPI (Port Provider Interface.) > >At any rate what I would like to see is a JSR with (in order of priority) >- compatible API for code written against current javax.comm 2.0 classes >- ability to register or "force" a port by providing a name and >implementation (not have to rely completely on the "auto-discovery") >- nothing precluding the use of a portmapping in a given implementation >- ability to register port implementations That sounds very good to me. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From tjarvi at qbang.org Tue Jul 25 01:21:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 01:21:53 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725082124.036309e0@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> Message-ID: On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: > At 19:34 24/07/2006, Gregg Wonderly wrote: >> Guillermo Rodriguez wrote: >>> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the >>> value of standardized APIs to talk to different types of communication >>> buses including SPI, I2C, 1-Wire, etc., for embedded applications. >>> However we think this has nothing to do with javax.comm. >> >> I don't think this is only about javax.comm. Certainly that's >> important. I'm >> just wading into this conversation mainstream and trying to say: >> >> If you are going to do anything about "fixing" javax.comm to work on all >> platforms, please, please, please start with a hardware port SPI >> definition that >> lets you get to serial ports, and then provide the existing javax.com API and >> whatever new API you think is necessary (I don't have any really >> issues with the >> existing API directly). >> >> Then, there will be a place for others interesting in SPI, i2C, USB and other >> things to get started with providing access to devices that are also >> interesting >> in Java applications, and directly, in embedded Java applications. > > I do agree that the best a hardware port SPI definition (where SPI = Service > Provider Interface, not the SPI protocol) is a good thing to have to support > serial ports layered over other transports. However these are still serial > ports at the end. I still don't think the javax.comm API is well suited to > "any" serial bus such as I2C, SPI, etc. > Perhaps the javax.com namespace is just wrong. I think thats a larger issue we are not well prepared to answer. We do have a larger group participating so there is interest beyond our current solution. My concern is getting into blue sky efforts that never materialize. We have a very concrete solution that just needs a few modifications to make current java users happy. This solution is more or less supporting POSIX termios on all platforms including windows. This solution does not ask deep questions like is it USB or RS485 or IrDA. Smart kernel people worry about that. Thats what works. When the fun goes away and I'm fixing spam on slow mail-lists, thats what will continue to work. Thats what will be tested on hundreds of machines every six months. I don't want to remind people of JSR80 windows support but you should keep that in mind while getting too far from the crusty roman roads. I'd love to move off to the side in the namespace and leave javax.com for a great effort unifying the time space continuum to be announced at a later date. Beyond that, we would need serious commitment from people in the community to get more working. Both rxtx.org and Sun are about maxed out right now. -- Trent Jarvi tjarvi at qbang.org From martin at jopdesign.com Tue Jul 25 01:32:22 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 09:32:22 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> Message-ID: <005b01c6afbc$794fc060$0202a8c0@luna> >>> None of this is of any particular relevance to the basic underlying >>> question: >>> >>> Should the next JSR attempt to address the multi-drop abilities of RS-485? I would vote for a strong yes. >> >> What I would suggest is to just add a new 'ioctlex'-like method >> to the SerialPort API: A method that you'd use to pass platform- >> or implementation-specific info to the underlying driver or OS >> to do things such as "enabling RS485 mode" or "disable FIFOs" or >> "poll the TSR register". >> >> No need to define any function codes. This is for stuff that is >> platform- or implementation-specific and as such cannot be easily >> abstracted anyway. > > Detrimental to platform independence. We can model it platform independent with two methods: enterTransmit() and extiTransmit() to do whatever is necessary on the underlying platform to switch to RS485 transmit mode and back. Martin From guille at sms.nl Tue Jul 25 01:45:53 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 09:45:53 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <005b01c6afbc$794fc060$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> Message-ID: <7.0.1.0.0.20060725094317.0363b390@sms.nl> Hi Martin, At 09:32 25/07/2006, Martin Schoeberl wrote: > >>> None of this is of any particular relevance to the basic underlying > >>> question: > >>> > >>> Should the next JSR attempt to address the multi-drop abilities > of RS-485? > >I would vote for a strong yes. > > >> > >> What I would suggest is to just add a new 'ioctlex'-like method > >> to the SerialPort API: A method that you'd use to pass platform- > >> or implementation-specific info to the underlying driver or OS > >> to do things such as "enabling RS485 mode" or "disable FIFOs" or > >> "poll the TSR register". > >> > >> No need to define any function codes. This is for stuff that is > >> platform- or implementation-specific and as such cannot be easily > >> abstracted anyway. > > > > Detrimental to platform independence. > >We can model it platform independent with two methods: > >enterTransmit() and extiTransmit() to do whatever is necessary >on the underlying platform to switch to RS485 transmit mode and >back. Tempting as it is, I don't think this covers all cases. For example, in those cases where RS485 direction control must be done 100% in software, the software needs to have a way to flush (sync) software buffers, poll the hardware FIFOs and TSR (not THR), etc. Or, for example, for those UARTs that do automatic RS485 direction control with a configurable turnaround delay, how would you configure this turnaround delay from the application? Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 01:48:10 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 09:48:10 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> Message-ID: <7.0.1.0.0.20060725094602.036cec00@sms.nl> Hi Trent, At 09:21 25/07/2006, Trent Jarvi wrote: >On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: > > > At 19:34 24/07/2006, Gregg Wonderly wrote: > >> Guillermo Rodriguez wrote: > >>> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the > >>> value of standardized APIs to talk to different types of communication > >>> buses including SPI, I2C, 1-Wire, etc., for embedded applications. > >>> However we think this has nothing to do with javax.comm. > >> > >> I don't think this is only about javax.comm. Certainly that's > >> important. I'm > >> just wading into this conversation mainstream and trying to say: > >> > >> If you are going to do anything about "fixing" javax.comm to work on all > >> platforms, please, please, please start with a hardware port SPI > >> definition that > >> lets you get to serial ports, and then provide the existing > javax.com API and > >> whatever new API you think is necessary (I don't have any really > >> issues with the > >> existing API directly). > >> > >> Then, there will be a place for others interesting in SPI, i2C, > USB and other > >> things to get started with providing access to devices that are also > >> interesting > >> in Java applications, and directly, in embedded Java applications. > > > > I do agree that the best a hardware port SPI definition (where > SPI = Service > > Provider Interface, not the SPI protocol) is a good thing to have > to support > > serial ports layered over other transports. However these are still serial > > ports at the end. I still don't think the javax.comm API is well suited to > > "any" serial bus such as I2C, SPI, etc. > > > >Perhaps the javax.com namespace is just wrong. I think thats a larger >issue we are not well prepared to answer. We do have a larger group >participating so there is interest beyond our current solution. My concern was not about the name specifically, but about the idea that a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, IrDA, etc. Looking from a distance all of these may look similar but the fact is, they have little to do with each other (apart from being 'communication protocols' or 'buses') Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From Paul.Klissner at Sun.COM Tue Jul 25 01:51:26 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Tue, 25 Jul 2006 00:51:26 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725082630.036d2d10@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> Message-ID: <44C5CD7E.9030903@sun.com> Guillermo Rodriguez Garcia wrote: > At 19:41 24/07/2006, Paul Klissner wrote: >> Guillermo Rodriguez wrote: >>> Quoting Paul Klissner : >>> >>>>>> None of this is of any particular relevance to the basic underlying >>>>>> question: >>>>>> >>>>>> Should the next JSR attempt to address the multi-drop abilities of >>>> RS-485? >>>>> What I would suggest is to just add a new 'ioctlex'-like method >>>>> to the SerialPort API: A method that you'd use to pass platform- >>>>> or implementation-specific info to the underlying driver or OS >>>>> to do things such as "enabling RS485 mode" or "disable FIFOs" or >>>>> "poll the TSR register". >>>>> >>>>> No need to define any function codes. This is for stuff that is >>>>> platform- or implementation-specific and as such cannot be easily >>>>> abstracted anyway. >>>> Detrimental to platform independence. >>> Yes, it is. But as you go closer and closer to the hardware level some >>> things are by nature platform-dependent, and sometimes just cannot be >>> solved in a platform-independent way. In these cases, is it better to >>> have no solution at all than having one that is less than perfect? >>> Put it another way, would you prefer having people say "I just cannot >>> do this in Java; I'll go somewhere else" rather than "I can do this >>> in Java -- only not in a platform-independent way" ? >> If there isn't a reasonable way to abstract it out, then >> why use Java? > > If an application can be 99% platform independent with small bits > being not portable, why *not* use Java? I'd prefer to see people > using Java to write non-portable applications than having them > use C instead. > > I believe that Java should promote platform neutrality, but that > does not necessarily mean precluding the use of anything that is > NOT platform independent. And let's face it, if you are using > javax.comm to talk to some serial device directly, then chances > are you are already tied to some specific hardware anyway. > > Also, some people (myself included) think that Java can also be > used as a systems programming language, not only for applications. > For many embedded platforms this is certainly the case. In our > platform we even write device drivers directly in Java. I would > imagine the Sun SPOT team (www.sunspotworld.com) supports a > similar view. > > If people needs to do non-portable stuff and wants to do it in > Java I'd rather have them do it in Java than tell them to do it > in C instead. That sounds a bit evangelizing. I think C is perfectly viable for some jobs, and might even be preferable in some cases, for example in some cases where performance or space is a factor. I feel it isn't right to corrupt an API with hacks for the goal of enticing users to Java, even for all the 'right' reasons. >> If someone really needs to do funky things with the hardware, >> why wouldn't that be put in the native back end? > > But nobody said the functionality can't be implemented in the > native back end. However you still need an application level API > to enable/disable it. Sure, but the functions, if really along the lines of the defined standard, can be abstracted, rather than cheat with a general purpose hack-all ioctl-like interface that just begs to be abused, lending itself to a litany of non-portable applications. I maintain we should scope the project appropriately, then take our best shot at a reasonably complete set of abstract functions, and improve it if necessary over time (alpha and beta, release candidates? And then update the API in a backward-compatible way based on feedback after FCS if necessary), rather than add an everything-but-the-kitchen-sink escape clause method. A determined programmer facing a corner case can figure out a way to accomplish the goal in most cases. Even if the API doesn't provide an ioctl call, it is possible to create implementation classes that mak methods visible outsidethe scope of the API-defined methods. For example, if I am implementing class Foo in FooImpl.java, And Foo.java defines interface methods a(), b() and c(), FooImpl.java can also have public methods d(), e() and f(), which can be accessed from the application by casting a Foo object into a FooImpl object. This is one way to provide a back door without compromising the core API itself to do it. This puts the responsibility of breaking platform independence on the developers and not on the designers. Paul From tjarvi at qbang.org Tue Jul 25 02:57:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 02:57:28 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725094602.036cec00@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> Message-ID: On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: > Hi Trent, > > At 09:21 25/07/2006, Trent Jarvi wrote: >> On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: >> >>> At 19:34 24/07/2006, Gregg Wonderly wrote: >>>> Guillermo Rodriguez wrote: >>>>> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the >>>>> value of standardized APIs to talk to different types of communication >>>>> buses including SPI, I2C, 1-Wire, etc., for embedded applications. >>>>> However we think this has nothing to do with javax.comm. >>>> >>>> I don't think this is only about javax.comm. Certainly that's >>>> important. I'm >>>> just wading into this conversation mainstream and trying to say: >>>> >>>> If you are going to do anything about "fixing" javax.comm to work on all >>>> platforms, please, please, please start with a hardware port SPI >>>> definition that >>>> lets you get to serial ports, and then provide the existing >> javax.com API and >>>> whatever new API you think is necessary (I don't have any really >>>> issues with the >>>> existing API directly). >>>> >>>> Then, there will be a place for others interesting in SPI, i2C, >> USB and other >>>> things to get started with providing access to devices that are also >>>> interesting >>>> in Java applications, and directly, in embedded Java applications. >>> >>> I do agree that the best a hardware port SPI definition (where >> SPI = Service >>> Provider Interface, not the SPI protocol) is a good thing to have >> to support >>> serial ports layered over other transports. However these are still serial >>> ports at the end. I still don't think the javax.comm API is well suited to >>> "any" serial bus such as I2C, SPI, etc. >>> >> >> Perhaps the javax.com namespace is just wrong. I think thats a larger >> issue we are not well prepared to answer. We do have a larger group >> participating so there is interest beyond our current solution. > > My concern was not about the name specifically, but about the idea that > a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, > IrDA, etc. Looking from a distance all of these may look similar but > the fact is, they have little to do with each other (apart from being > 'communication protocols' or 'buses') > Hi Guillermo Interesting name. Fair enough. My thoughts are that if it can't be unified in the kernel we are out of our skulls trying to do it in user space. Hacks trying to do such will sure to be in open solaris or linux symposiums about why user space sucks. But there is a minimal bit that overlapps that is what most users want. If we limit the scope, it isnt that hard of a problem. By limiting the scope we also limit our deliverables. If you have an interest in a specific area it will probably not be enough. -- Trent Jarvi tjarvi at qbang.org From martin at jopdesign.com Tue Jul 25 03:25:38 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 11:25:38 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> Message-ID: <001901c6afcc$4bcf64f0$0c28a8c0@luna> >> >> >> >> What I would suggest is to just add a new 'ioctlex'-like method >> >> to the SerialPort API: A method that you'd use to pass platform- >> >> or implementation-specific info to the underlying driver or OS >> >> to do things such as "enabling RS485 mode" or "disable FIFOs" or >> >> "poll the TSR register". >> >> >> >> No need to define any function codes. This is for stuff that is >> >> platform- or implementation-specific and as such cannot be easily >> >> abstracted anyway. >> > >> > Detrimental to platform independence. >> >>We can model it platform independent with two methods: >> >>enterTransmit() and extiTransmit() to do whatever is necessary >>on the underlying platform to switch to RS485 transmit mode and >>back. > > Tempting as it is, I don't think this covers all cases. For example, > in those cases where RS485 direction control must be done 100% in > software, the software needs to have a way to flush (sync) software > buffers, poll the hardware FIFOs and TSR (not THR), etc. I just meant to hide those low-level issues you mention in the enter/exitTransmit modes. > > Or, for example, for those UARTs that do automatic RS485 direction > control with a configurable turnaround delay, how would you configure > this turnaround delay from the application? Mmh, perhaps in a similar way as you configure timeouts? Isn't this 'just' a timeout value? Martin From guille at sms.nl Tue Jul 25 04:05:29 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 12:05:29 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <001901c6afcc$4bcf64f0$0c28a8c0@luna> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> Message-ID: <7.0.1.0.0.20060725115736.03706a38@sms.nl> At 11:25 25/07/2006, Martin Schoeberl wrote: > >> >> > >> >> What I would suggest is to just add a new 'ioctlex'-like method > >> >> to the SerialPort API: A method that you'd use to pass platform- > >> >> or implementation-specific info to the underlying driver or OS > >> >> to do things such as "enabling RS485 mode" or "disable FIFOs" or > >> >> "poll the TSR register". > >> >> > >> >> No need to define any function codes. This is for stuff that is > >> >> platform- or implementation-specific and as such cannot be easily > >> >> abstracted anyway. > >> > > >> > Detrimental to platform independence. > >> > >>We can model it platform independent with two methods: > >> > >>enterTransmit() and extiTransmit() to do whatever is necessary > >>on the underlying platform to switch to RS485 transmit mode and > >>back. > > > > Tempting as it is, I don't think this covers all cases. For example, > > in those cases where RS485 direction control must be done 100% in > > software, the software needs to have a way to flush (sync) software > > buffers, poll the hardware FIFOs and TSR (not THR), etc. > >I just meant to hide those low-level issues you mention in the >enter/exitTransmit modes. If the system has dedicated RS485 hardware then the underlying kernel or device driver may know about it and all of the hassle can be conveniently encapsulated in some enter/exitTransmit methods -- but in this case you can also skip these and just have the driver enable transmit mode as long as it has data to transmit, and stay in receive mode otherwise. If the system has a UART that can be configured as RS232 or RS485 then you may need to tell the kernel or device driver to enter RS485 mode explicitly. Your approach may work there as well. If the system does not have dedicated RS485 hardware and you are using an external RS232-RS485 protocol converter (a very common case) then the driver and kernel probably don't know about that and you have to take care at the application level (javax.comm doesn't even need to know this converter exists), and in order to that you may need to do different things depending on the specific converter you're using. > > > > Or, for example, for those UARTs that do automatic RS485 direction > > control with a configurable turnaround delay, how would you configure > > this turnaround delay from the application? > >Mmh, perhaps in a similar way as you configure timeouts? >Isn't this 'just' a timeout value? Yes, but this is just a specific parameter that you can configure in a specific type of UART (an EXAR UART). Other UARTs might be different. The point I'm trying to make is that there are just too many parameters to have an API for each specific case. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 04:12:31 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 12:12:31 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C5CD7E.9030903@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> <44C5CD7E.9030903@sun.com> Message-ID: <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> At 09:51 25/07/2006, Paul Klissner wrote: >Guillermo Rodriguez Garcia wrote: > > At 19:41 24/07/2006, Paul Klissner wrote: > >> Guillermo Rodriguez wrote: > >>> Quoting Paul Klissner : > >>> > >>>>>> None of this is of any particular relevance to the basic underlying > >>>>>> question: > >>>>>> > >>>>>> Should the next JSR attempt to address the multi-drop abilities of > >>>> RS-485? > >>>>> What I would suggest is to just add a new 'ioctlex'-like method > >>>>> to the SerialPort API: A method that you'd use to pass platform- > >>>>> or implementation-specific info to the underlying driver or OS > >>>>> to do things such as "enabling RS485 mode" or "disable FIFOs" or > >>>>> "poll the TSR register". > >>>>> > >>>>> No need to define any function codes. This is for stuff that is > >>>>> platform- or implementation-specific and as such cannot be easily > >>>>> abstracted anyway. > >>>> Detrimental to platform independence. > >>> Yes, it is. But as you go closer and closer to the hardware level some > >>> things are by nature platform-dependent, and sometimes just cannot be > >>> solved in a platform-independent way. In these cases, is it better to > >>> have no solution at all than having one that is less than perfect? > >>> Put it another way, would you prefer having people say "I just cannot > >>> do this in Java; I'll go somewhere else" rather than "I can do this > >>> in Java -- only not in a platform-independent way" ? > >> If there isn't a reasonable way to abstract it out, then > >> why use Java? > > > > If an application can be 99% platform independent with small bits > > being not portable, why *not* use Java? I'd prefer to see people > > using Java to write non-portable applications than having them > > use C instead. > > > > I believe that Java should promote platform neutrality, but that > > does not necessarily mean precluding the use of anything that is > > NOT platform independent. And let's face it, if you are using > > javax.comm to talk to some serial device directly, then chances > > are you are already tied to some specific hardware anyway. > > > > Also, some people (myself included) think that Java can also be > > used as a systems programming language, not only for applications. > > For many embedded platforms this is certainly the case. In our > > platform we even write device drivers directly in Java. I would > > imagine the Sun SPOT team (www.sunspotworld.com) supports a > > similar view. > > > > If people needs to do non-portable stuff and wants to do it in > > Java I'd rather have them do it in Java than tell them to do it > > in C instead. > >That sounds a bit evangelizing. Could be, but then what's wrong with that? As I said there is people that thinks that Java can be perfectly adequate for system level programming -- especially for embedded platforms. I guess the whole issue is whether it is better to have no solution at all for a specific problem than a solution that is not perfect (in this context a "perfect" solution is one that is portable and platform-independent). I think a solution that is not perfect is better than no solution. If I understand correctly you say that you prefer to have no Java solution (and have people use C) rather than one that is not portable. >I think C is perfectly viable >for some jobs, and might even be preferable in some cases, for example >in some cases where performance or space is a factor. I feel it isn't >right to corrupt an API with hacks for the goal of enticing users >to Java, even for all the 'right' reasons. > > >> If someone really needs to do funky things with the hardware, > >> why wouldn't that be put in the native back end? > > > > But nobody said the functionality can't be implemented in the > > native back end. However you still need an application level API > > to enable/disable it. > >Sure, but the functions, if really along the lines of the defined >standard, can be abstracted, rather than cheat with a general >purpose hack-all ioctl-like interface that just begs to be abused, >lending itself to a litany of non-portable applications. Well, I didn't specifically say there's no way to abstract these functions. I only said that it is not easy, and that I don't know of any reasonable way to do it. But if others can find a way, that is fine of course. >I maintain we should scope the project appropriately, then take >our best shot at a reasonably complete set of abstract functions, >and improve it if necessary over time (alpha and beta, release >candidates? And then update the API in a backward-compatible way >based on feedback after FCS if necessary), rather than add an >everything-but-the-kitchen-sink escape clause method. > >A determined programmer facing a corner case can figure out a way >to accomplish the goal in most cases. Even if the API doesn't provide >an ioctl call, it is possible to create implementation classes that >mak methods visible outsidethe scope of the API-defined methods. > >For example, if I am implementing class Foo in FooImpl.java, >And Foo.java defines interface methods a(), b() and c(), >FooImpl.java can also have public methods d(), e() and f(), which can >be accessed from the application by casting a Foo object into >a FooImpl object. This is one way to provide a back door without >compromising the core API itself to do it. This puts the >responsibility of breaking platform independence on the developers >and not on the designers. Yes, that may be a good way to do it. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 04:21:31 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 12:21:31 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> Message-ID: <7.0.1.0.0.20060725121958.03714668@sms.nl> Hi Trent, At 10:57 25/07/2006, Trent Jarvi wrote: > >> Perhaps the javax.com namespace is just wrong. I think thats a larger > >> issue we are not well prepared to answer. We do have a larger group > >> participating so there is interest beyond our current solution. > > > > My concern was not about the name specifically, but about the idea that > > a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, > > IrDA, etc. Looking from a distance all of these may look similar but > > the fact is, they have little to do with each other (apart from being > > 'communication protocols' or 'buses') > > > >Hi Guillermo > >Interesting name. > >Fair enough. My thoughts are that if it can't be unified in the kernel we >are out of our skulls trying to do it in user space. Hacks trying to do >such will sure to be in open solaris or linux symposiums about why user >space sucks. > >But there is a minimal bit that overlapps that is what most users want. >If we limit the scope, it isnt that hard of a problem. By limiting the >scope we also limit our deliverables. If you have an interest in a >specific area it will probably not be enough. Yes, you are right. But isn't this 'minimal bit that overlaps' what we have already? (basically support for UART-based serial ports plus minimal support for parallel ports) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From lyon at docjava.com Tue Jul 25 05:44:43 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 25 Jul 2006 07:44:43 -0400 Subject: [Rxtx] 7 RS485 questions... In-Reply-To: <7.0.1.0.0.20060725115736.03706a38@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: Hi All, 1. Does anyone have a sense for how much larger the JSR would be if it embraced a multi-drop protocol, like RS485? 2. Do we address collision detection and addressing in RS485? 3. How would collision detection and addressing impact the size of the specification? 4. Would JSR80 (and, perhaps a RS485-USB converter) be the more appropriate place for RS485 support? 5. Is RS485 Transmission controlled by RTS, and the TxD line? 6. How tight is the windows timing on control of the RTS line? 7. Does an RTS controlled RS485 converter work well at high baud rates under windows? Thanks! - Doug From naranjo.manuel at gmail.com Tue Jul 25 06:29:45 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Tue, 25 Jul 2006 09:29:45 -0300 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725094602.036cec00@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> Message-ID: <44C60EB9.5000803@gmail.com> Guillermo Rodriguez Garcia escribi?: > My concern was not about the name specifically, but about the idea that > a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, > IrDA, etc. Looking from a distance all of these may look similar but > the fact is, they have little to do with each other (apart from being > 'communication protocols' or 'buses') > I think Guillermo is right, all ports has in common that they are buses. A stupid idea but why don't declarate the package javax.bus and make javax.comm a dedicated namespace to rs232 and parallell to mantain backward compatibility, obviously the classes at javax.comm should extend classes from javax.bus. Regards, Manuel From j.a.horsmeier at wanadoo.nl Tue Jul 25 07:00:17 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Tue, 25 Jul 2006 15:00:17 +0200 Subject: [Rxtx] 7 RS485 questions... In-Reply-To: Message-ID: <05a701c6afea$47002e00$0a01a8c0@CALVIN> Douglas Lyon wrote: > 1. Does anyone have a sense for how much larger the JSR would > be if it embraced a multi-drop protocol, like RS485? The RS485 multidrop capability all resides on top of the communication layer, i.e. all transmitters but one are disabled (all devices are just listening). When the message has been sent at most one device answers (see 2) > 2. Do we address collision detection and addressing in RS485? Addressing a device is also implemented on top of the communication layer. If/when two devices happen to have the same address it would be disastrous. An address is defined by the protocol, e.g. modbus allows for 250 or so different addresses but another protocol might allow for 2^32 different devices hooked up on one two wire cable. > 3. How would collision detection and addressing impact the size of > the specification? IMHO it's none of rxtx's business, it's a configuration error on the devices if that happens. > 4. Would JSR80 (and, perhaps a RS485-USB converter) be the > more appropriate place for RS485 support? Don't know. > 5. Is RS485 Transmission controlled by RTS, and the TxD line? Two wire RS485 doesn't have a RTS line. It's all in the timing. The half duplex protocol is extremely simple: one master sends, all devices listen, after that at most one device enables its transmitter and sends something back. > 6. How tight is the windows timing on control of the RTS line? Before a device enables its transmitter it should wait a bit because of cable lengths and the other device that must *disable* its transmitter. It's all up to the devices and rxtx can do nothing about it. > 7. Does an RTS controlled RS485 converter work well at high baud > rates under windows? Baud rates aren't the problem; cable lengths are the problem, sensitivity for distortion are the problem. The wait time between en/disabling transmitters can be configured in the devices and can be software controlled on the pc. kind regards, Jos From tjarvi at qbang.org Tue Jul 25 07:08:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 07:08:53 -0600 (MDT) Subject: [Rxtx] 7 RS485 questions... In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: > 5. Is RS485 Transmission controlled by RTS, and the TxD line? This is done when using EIA232 to drive RS485 with no adaptor. This is the RS485 hack that is in RXTX 2.1 that never went anyplace. I discovered no typical kernel will openly support this line of thought. It is not maintainable. There are hardware solutions. Off the top of my head it required < 10 ms responses and typical kernels + java do 10 ms responses. Realtime kernels or special kernel drivers are required. It is possible but not supportable. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Tue Jul 25 07:46:52 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 08:46:52 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <005b01c6afbc$794fc060$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> Message-ID: <44C620CC.6090901@cox.net> Martin Schoeberl wrote: > We can model it platform independent with two methods: > > enterTransmit() and extiTransmit() to do whatever is necessary > on the underlying platform to switch to RS485 transmit mode and > back. Or, do what is typically done, and use a single write operation as the indication of a 'packet' that will let the underlying RS-485/422 driver assert the appropriate signalling. Gregg Wonderly From guille at sms.nl Tue Jul 25 07:48:04 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 15:48:04 +0200 Subject: [Rxtx] 7 RS485 questions... In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: <7.0.1.0.0.20060725154329.036deb18@sms.nl> Hi Doug, Some answers below. At 13:44 25/07/2006, Dr. Douglas Lyon wrote: >Hi All, > >1. Does anyone have a sense for how much larger the JSR would be >if it embraced a multi-drop protocol, like RS485? As I've said in other mails RS485 is in essence just a UART-based serial port interface just like RS232. The only functional difference is that it is multi-drop and half-duplex so there must be a way for nodes to switch between transmit and receive modes but then the RS485 standard does not tell you when or how you should do that -- this depends on the upper layer protocols (for example Modbus) >2. Do we address collision detection and addressing in RS485? Collision detection and addressing are not defined by the RS485 standard. Upper layer protocols such as Modbus take care of that. >3. How would collision detection and addressing impact the size of >the specification? See above. >4. Would JSR80 (and, perhaps a RS485-USB converter) be the more appropriate >place for RS485 support? I don't think so. As I said RS485 is just a serial port like RS232 is. >5. Is RS485 Transmission controlled by RTS, and the TxD line? Some RS232-RS485 protocol converters use the RTS line as a control signal to switch between transmit and receive modes. Others use DTR. Others do not use any of them. >6. How tight is the windows timing on control of the RTS line? Depends on the upper layer protocols, e.g. Modbus. Not defined by RS485. >7. Does an RTS controlled RS485 converter work well at high baud >rates under windows? Depends on how tight the timing is. For some applications it may work well but for many probably won't. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 09:22:09 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Tue, 25 Jul 2006 17:22:09 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C620CC.6090901@cox.net> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> Message-ID: <1153840929.44c6372186f67@webmail.eatserver.nl> Hi Gregg, Quoting Gregg Wonderly : > Martin Schoeberl wrote: > > We can model it platform independent with two methods: > > > > enterTransmit() and extiTransmit() to do whatever is necessary > > on the underlying platform to switch to RS485 transmit mode and > > back. > > Or, do what is typically done, and use a single write operation as the > indication of a 'packet' that will let the underlying RS-485/422 driver > assert > the appropriate signalling. The problem with this is that there is no guarantee that a single call to the write method of the OutputStream associated with a javax.comm SerialPort will translate to a single write to the underlying device driver -- this depends on the javax.comm implementation. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From Paul.Klissner at Sun.COM Tue Jul 25 09:35:19 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Tue, 25 Jul 2006 08:35:19 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C60EB9.5000803@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> <44C60EB9.5000803@gmail.com> Message-ID: <44C63A37.8080406@sun.com> Manuel Francisco Naranjo wrote: > Guillermo Rodriguez Garcia escribi?: >> My concern was not about the name specifically, but about the idea that >> a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, >> IrDA, etc. Looking from a distance all of these may look similar but >> the fact is, they have little to do with each other (apart from being >> 'communication protocols' or 'buses') >> > I think Guillermo is right, all ports has in common that they are buses. > A stupid idea but why don't declarate the package javax.bus and make > javax.comm a dedicated namespace to rs232 and parallell to mantain > backward compatibility, obviously the classes at javax.comm should > extend classes from javax.bus. I like the initial sound of that idea too and was starting to think along those lines myself. But what would be the points of commonality to extend? Device mapping, ownership? Read, write, type, status? Too late for javax.usb (JSR80) very complex Bus and for the most part cast in stone. And 'bus' has such a wide scope. Also that would imply two downloads to install any given bus support, which might not be the end of the world. And maybe two JSRs? Paul From martin at jopdesign.com Tue Jul 25 09:37:12 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 17:37:12 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> Message-ID: <00c801c6b000$33a68f00$0c28a8c0@luna> >> Martin Schoeberl wrote: >> > We can model it platform independent with two methods: >> > >> > enterTransmit() and extiTransmit() to do whatever is necessary >> > on the underlying platform to switch to RS485 transmit mode and >> > back. >> >> Or, do what is typically done, and use a single write operation as the >> indication of a 'packet' that will let the underlying RS-485/422 driver >> assert >> the appropriate signalling. > > The problem with this is that there is no guarantee that a single call > to the write method of the OutputStream associated with a javax.comm > SerialPort will translate to a single write to the underlying device > driver -- this depends on the javax.comm implementation. > I completely agree - it's still a stream and not a packet. This is similar to a single write to a TCP/IP socket. There is no guarantee that you get this data as a single packet/single read on the other side. However, I've seen a lot of programs assuming that this happens ;-) Martin From gergg at cox.net Tue Jul 25 10:15:41 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 11:15:41 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725082124.036309e0@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> Message-ID: <44C643AD.6020604@cox.net> Guillermo Rodriguez Garcia wrote: > At 19:34 24/07/2006, Gregg Wonderly wrote: >>Then, there will be a place for others interesting in SPI, i2C, USB and other >>things to get started with providing access to devices that are also >>interesting >>in Java applications, and directly, in embedded Java applications. > > I do agree that the best a hardware port SPI definition (where SPI = Service > Provider Interface, not the SPI protocol) is a good thing to have to support > serial ports layered over other transports. However these are still serial > ports at the end. I still don't think the javax.comm API is well suited to > "any" serial bus such as I2C, SPI, etc. Yes, absolutely these other wire protocols are different. As I tried to say before, I think that the javax.comm API works fine for my needs. I think that we need to keep it around, no matter what else happens. So, for me, there are a few choices. 1. Create a new JSR to formalize the existing API and include some hardwired JNI code to provide port enumeration and access. 2. Create a new JSR to create a port abstraction SPI to allow JVM providers to enumerate all kinds of port/circuit based hardware to the JVM. Create an implementation of the existing javax.comm API that uses this SPI. 3. Just implement some JNI and Java libraries post them on sourceforge/java.net and let people have at them. For 1 and 2, you'll have to get the JCP to approve that the JSR is worth making a standard. Option 3 doesn't really solve a problem as much as it creates a new way to deal with an existing problem. I think 2 is the most desireable way to go. It really will open the door for more access to hardware from Java! Gregg Wonderly From joachim at buechse.de Tue Jul 25 10:17:07 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 25 Jul 2006 18:17:07 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <00c801c6b000$33a68f00$0c28a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: Just trigger writing on flush(). It is perfectly legal for an Outputstream implementation to do do nothing until flush is called and the documentation of OutputStream.flush reads: "Flushes this output stream and forces any buffered output bytes to be written out. The general contract of flush is that calling it is an indication that, if any bytes previously written have been buffered by the implementation of the output stream, such bytes should immediately be written to their intended destination." As RS485 is a "dont speak up unless requested" protocol, a mandatory flush after write seems like the way to go to me No client can prevent another client from writing, so there is no point in keeping the output-drivers enabled after all data currently buffered has been written. So flush() should trigger "enterTransmit, writePacket[s], exitTransmit". If the service provider (ie concrete implementation of the flush method) decides that the write is inapropriate at the moment (ie because of a higher level arbitration protocol that might be implemented by the service provider) it will simply block the flush or throw an IOException (preferably after some sort of timeout). Regards, Joachim PS: It is great to see all the motivation that is brought forward on this list regarding the future. It would be great if only 10% of that motivation could be transformed into a cleanup and extension of the existing code. The current code access model seems rather inappropriate for the prototyping of the ideas beeing presented. Trent can we get a "contributions" branch with "free" access. On 25.07.2006, at 17:37, Martin Schoeberl wrote: >>> Martin Schoeberl wrote: >>>> We can model it platform independent with two methods: >>>> >>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>> on the underlying platform to switch to RS485 transmit mode and >>>> back. >>> >>> Or, do what is typically done, and use a single write operation >>> as the >>> indication of a 'packet' that will let the underlying RS-485/422 >>> driver >>> assert >>> the appropriate signalling. >> >> The problem with this is that there is no guarantee that a single >> call >> to the write method of the OutputStream associated with a javax.comm >> SerialPort will translate to a single write to the underlying device >> driver -- this depends on the javax.comm implementation. >> > I completely agree - it's still a stream and not a packet. > > This is similar to a single write to a TCP/IP socket. There > is no guarantee that you get this data as a single packet/single > read on the other side. However, I've seen a lot of programs > assuming that this happens ;-) > > Martin > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Tue Jul 25 10:34:59 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Tue, 25 Jul 2006 18:34:59 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <1153845299.44c64833920bd@webmail.eatserver.nl> Hi Joachim, That is a very nice approach which I think would work well as far as the underlying device driver knows about RS485. However it still does not solve the problem with external protocol converters where the device driver only knows about regular UARTs and RTS or DTR must be used to toggle direction of the converter. Guillermo Quoting Joachim Buechse : > Just trigger writing on flush(). It is perfectly legal for an > Outputstream implementation to do do nothing until flush is called > and the documentation of OutputStream.flush reads: > > "Flushes this output stream and forces any buffered output bytes to > be written out. The general contract of flush is that calling it is > an indication that, if any bytes previously written have been > buffered by the implementation of the output stream, such bytes > should immediately be written to their intended destination." > > As RS485 is a "dont speak up unless requested" protocol, a mandatory > flush after write seems like the way to go to me > > No client can prevent another client from writing, so there is no > point in keeping the output-drivers enabled after all data currently > buffered has been written. So flush() should trigger "enterTransmit, > writePacket[s], exitTransmit". If the service provider (ie concrete > implementation of the flush method) decides that the write is > inapropriate at the moment (ie because of a higher level arbitration > protocol that might be implemented by the service provider) it will > simply block the flush or throw an IOException (preferably after some > sort of timeout). > > Regards, > Joachim > > PS: It is great to see all the motivation that is brought forward on > this list regarding the future. It would be great if only 10% of that > motivation could be transformed into a cleanup and extension of the > existing code. The current code access model seems rather > inappropriate for the prototyping of the ideas beeing presented. > Trent can we get a "contributions" branch with "free" access. > > > On 25.07.2006, at 17:37, Martin Schoeberl wrote: > > >>> Martin Schoeberl wrote: > >>>> We can model it platform independent with two methods: > >>>> > >>>> enterTransmit() and extiTransmit() to do whatever is necessary > >>>> on the underlying platform to switch to RS485 transmit mode and > >>>> back. > >>> > >>> Or, do what is typically done, and use a single write operation > >>> as the > >>> indication of a 'packet' that will let the underlying RS-485/422 > >>> driver > >>> assert > >>> the appropriate signalling. > >> > >> The problem with this is that there is no guarantee that a single > >> call > >> to the write method of the OutputStream associated with a javax.comm > >> SerialPort will translate to a single write to the underlying device > >> driver -- this depends on the javax.comm implementation. > >> > > I completely agree - it's still a stream and not a packet. > > > > This is similar to a single write to a TCP/IP socket. There > > is no guarantee that you get this data as a single packet/single > > read on the other side. However, I've seen a lot of programs > > assuming that this happens ;-) > > > > Martin > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- http://www.snijder.com/ SNIJDER Micro Systems From guille at sms.nl Tue Jul 25 10:44:56 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Tue, 25 Jul 2006 18:44:56 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C643AD.6020604@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <44C643AD.6020604@cox.net> Message-ID: <1153845896.44c64a8890968@webmail.eatserver.nl> Hi Gregg, Quoting Gregg Wonderly : > Guillermo Rodriguez Garcia wrote: > > At 19:34 24/07/2006, Gregg Wonderly wrote: > >>Then, there will be a place for others interesting in SPI, i2C, USB and > other > >>things to get started with providing access to devices that are also > >>interesting > >>in Java applications, and directly, in embedded Java applications. > > > > I do agree that the best a hardware port SPI definition (where SPI = > Service > > Provider Interface, not the SPI protocol) is a good thing to have to > support > > serial ports layered over other transports. However these are still serial > > ports at the end. I still don't think the javax.comm API is well suited to > > "any" serial bus such as I2C, SPI, etc. > > Yes, absolutely these other wire protocols are different. As I tried to say > > before, I think that the javax.comm API works fine for my needs. I think > that > we need to keep it around, no matter what else happens. So, for me, there > are a > few choices. > > 1. Create a new JSR to formalize the existing API and include some hardwired > JNI > code to provide port enumeration and access. > > 2. Create a new JSR to create a port abstraction SPI to allow JVM providers > to > enumerate all kinds of port/circuit based hardware to the JVM. Create an > implementation of the existing javax.comm API that uses this SPI. As an embedded Java vendor we work very close to the hardware level and have to deal daily with dozens of different types of ports and communication buses and protocols. Based on our experience I think that a SPI for "all kinds of port/circuit based hardware" is just too generic and not really practical. I think having a Service Provider Interface within javax.comm so that custom serial port implementations can be plugged in is a very good idea. However I don't think it is convenient to have it as a separate JSR and then with such a broad scope. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From joachim at buechse.de Tue Jul 25 10:56:12 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 25 Jul 2006 18:56:12 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <1153845299.44c64833920bd@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> <1153845299.44c64833920bd@webmail.eatserver.nl> Message-ID: In this case you need to configure your port with a different device driver. You may optionally take an existing port, wrap it up in a "wrapping device driver" implemented in Java and add it to the list of ports as a new port... In any case the core application should not care. On 25.07.2006, at 18:34, Guillermo Rodriguez wrote: > Hi Joachim, > > That is a very nice approach which I think would work well as far > as the underlying device driver knows about RS485. > > However it still does not solve the problem with external protocol > converters where the device driver only knows about regular UARTs > and RTS or DTR must be used to toggle direction of the converter. > > Guillermo > > Quoting Joachim Buechse : > >> Just trigger writing on flush(). It is perfectly legal for an >> Outputstream implementation to do do nothing until flush is called >> and the documentation of OutputStream.flush reads: >> >> "Flushes this output stream and forces any buffered output bytes to >> be written out. The general contract of flush is that calling it is >> an indication that, if any bytes previously written have been >> buffered by the implementation of the output stream, such bytes >> should immediately be written to their intended destination." >> >> As RS485 is a "dont speak up unless requested" protocol, a mandatory >> flush after write seems like the way to go to me >> >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). >> >> Regards, >> Joachim >> >> PS: It is great to see all the motivation that is brought forward on >> this list regarding the future. It would be great if only 10% of that >> motivation could be transformed into a cleanup and extension of the >> existing code. The current code access model seems rather >> inappropriate for the prototyping of the ideas beeing presented. >> Trent can we get a "contributions" branch with "free" access. >> >> >> On 25.07.2006, at 17:37, Martin Schoeberl wrote: >> >>>>> Martin Schoeberl wrote: >>>>>> We can model it platform independent with two methods: >>>>>> >>>>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>>>> on the underlying platform to switch to RS485 transmit mode and >>>>>> back. >>>>> >>>>> Or, do what is typically done, and use a single write operation >>>>> as the >>>>> indication of a 'packet' that will let the underlying RS-485/422 >>>>> driver >>>>> assert >>>>> the appropriate signalling. >>>> >>>> The problem with this is that there is no guarantee that a single >>>> call >>>> to the write method of the OutputStream associated with a >>>> javax.comm >>>> SerialPort will translate to a single write to the underlying >>>> device >>>> driver -- this depends on the javax.comm implementation. >>>> >>> I completely agree - it's still a stream and not a packet. >>> >>> This is similar to a single write to a TCP/IP socket. There >>> is no guarantee that you get this data as a single packet/single >>> read on the other side. However, I've seen a lot of programs >>> assuming that this happens ;-) >>> >>> Martin >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > > -- > http://www.snijder.com/ > SNIJDER Micro Systems > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From martin at jopdesign.com Tue Jul 25 11:13:10 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 19:13:10 +0200 Subject: [Rxtx] JSR Direction; packetizing writes References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com><005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net><1153840929.44c6372186f67@webmail.eatserver.nl><00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <000f01c6b00d$9bcc51c0$0202a8c0@luna> > No client can prevent another client from writing, so there is no > point in keeping the output-drivers enabled after all data currently > buffered has been written. So flush() should trigger "enterTransmit, > writePacket[s], exitTransmit". If the service provider (ie concrete > implementation of the flush method) decides that the write is > inapropriate at the moment (ie because of a higher level arbitration > protocol that might be implemented by the service provider) it will > simply block the flush or throw an IOException (preferably after some > sort of timeout). Not only flush() would mean enterTransmit(). With your idea each write should enable the driver, but only flush() can disable the driver after the last byte is written. RS485 is a beast. E.g. some driver chips need a few us (100us for a Maxim 1480B!) from output enable till output low/high. On a different application we had to wait a little bit before disabling the output driver to have a clear '1' on the bus as it took too long for the termination resistors to force the bus to 1. I can imagine that this is not really funny with general RS232/RS485 converters. Martin From joachim at buechse.de Tue Jul 25 11:42:18 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 25 Jul 2006 19:42:18 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <000f01c6b00d$9bcc51c0$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com><005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net><1153840929.44c6372186f67@webmail.eatserver.nl><00c801c6b000$33a68f00$0c28a8c0@luna> <000f01c6b00d$9bcc51c0$0202a8c0@luna> Message-ID: Simple answer: NO. You can not control the timing of the Java VM (especially not on ME) and hence you do not want to enable the outputs before you have all data collected. The timings you mention are all in the implementation space of the device driver. The core application should not care, neither should the javax.comm api in my opinion. Should I happen to be the pour soul that tries to implement an RS485 device driver reference implementation I will try to remember your email and add appropriate properties. Regards, Joachim On 25.07.2006, at 19:13, Martin Schoeberl wrote: >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). > > Not only flush() would mean enterTransmit(). With your idea each > write should enable the driver, but only flush() can disable > the driver after the last byte is written. > > RS485 is a beast. E.g. some driver chips need a few us (100us > for a Maxim 1480B!) from output enable till output low/high. > > On a different application we had to wait a little bit before > disabling the output driver to have a clear '1' on the bus as it took > too long for the termination resistors to force the bus to 1. > > I can imagine that this is not really funny with general > RS232/RS485 converters. > > Martin > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Tue Jul 25 12:50:20 2006 From: jredman at ergotech.com (Jim Redman) Date: Tue, 25 Jul 2006 12:50:20 -0600 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <44C667EC.2070602@ergotech.com> The horror! This would be terribly inefficient. Especially in serial protocols you need to start getting bits on the wire as soon as possible. It could also have some timeout implications. Jim Joachim Buechse wrote: > Just trigger writing on flush(). It is perfectly legal for an > Outputstream implementation to do do nothing until flush is called > and the documentation of OutputStream.flush reads: > > "Flushes this output stream and forces any buffered output bytes to > be written out. The general contract of flush is that calling it is > an indication that, if any bytes previously written have been > buffered by the implementation of the output stream, such bytes > should immediately be written to their intended destination." > > As RS485 is a "dont speak up unless requested" protocol, a mandatory > flush after write seems like the way to go to me > > No client can prevent another client from writing, so there is no > point in keeping the output-drivers enabled after all data currently > buffered has been written. So flush() should trigger "enterTransmit, > writePacket[s], exitTransmit". If the service provider (ie concrete > implementation of the flush method) decides that the write is > inapropriate at the moment (ie because of a higher level arbitration > protocol that might be implemented by the service provider) it will > simply block the flush or throw an IOException (preferably after some > sort of timeout). > > Regards, > Joachim > > PS: It is great to see all the motivation that is brought forward on > this list regarding the future. It would be great if only 10% of that > motivation could be transformed into a cleanup and extension of the > existing code. The current code access model seems rather > inappropriate for the prototyping of the ideas beeing presented. > Trent can we get a "contributions" branch with "free" access. > > > On 25.07.2006, at 17:37, Martin Schoeberl wrote: > >>>> Martin Schoeberl wrote: >>>>> We can model it platform independent with two methods: >>>>> >>>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>>> on the underlying platform to switch to RS485 transmit mode and >>>>> back. >>>> Or, do what is typically done, and use a single write operation >>>> as the >>>> indication of a 'packet' that will let the underlying RS-485/422 >>>> driver >>>> assert >>>> the appropriate signalling. >>> The problem with this is that there is no guarantee that a single >>> call >>> to the write method of the OutputStream associated with a javax.comm >>> SerialPort will translate to a single write to the underlying device >>> driver -- this depends on the javax.comm implementation. >>> >> I completely agree - it's still a stream and not a packet. >> >> This is similar to a single write to a TCP/IP socket. There >> is no guarantee that you get this data as a single packet/single >> read on the other side. However, I've seen a lot of programs >> assuming that this happens ;-) >> >> Martin >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From jredman at ergotech.com Tue Jul 25 12:53:02 2006 From: jredman at ergotech.com (Jim Redman) Date: Tue, 25 Jul 2006 12:53:02 -0600 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <000f01c6b00d$9bcc51c0$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com><005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net><1153840929.44c6372186f67@webmail.eatserver.nl><00c801c6b000$33a68f00$0c28a8c0@luna> <000f01c6b00d$9bcc51c0$0202a8c0@luna> Message-ID: <44C6688E.8040202@ergotech.com> Since we now seem to have entered a discussion of how to switch receive/transmit on 485 lines, I can tell you from experience that you cannot reliably do this from Java. Java just is not fast enough. I spend some time trying to get this to work with RXTX and it would work _most_ of the time, but you need to be able to guarantee ms level response which you can't do in any system that doesn't have real-time capabilities. Jim Martin Schoeberl wrote: >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). > > Not only flush() would mean enterTransmit(). With your idea each > write should enable the driver, but only flush() can disable > the driver after the last byte is written. > > RS485 is a beast. E.g. some driver chips need a few us (100us > for a Maxim 1480B!) from output enable till output low/high. > > On a different application we had to wait a little bit before > disabling the output driver to have a clear '1' on the bus as it took > too long for the termination resistors to force the bus to 1. > > I can imagine that this is not really funny with general > RS232/RS485 converters. > > Martin > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Tue Jul 25 13:37:14 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 14:37:14 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725115736.03706a38@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: <44C672EA.1080604@cox.net> Guillermo Rodriguez Garcia wrote: > At 11:25 25/07/2006, Martin Schoeberl wrote: >>Mmh, perhaps in a similar way as you configure timeouts? >>Isn't this 'just' a timeout value? > > Yes, but this is just a specific parameter that you can configure in a > specific type of UART (an EXAR UART). Other UARTs might be different. The > point I'm trying to make is that there are just too many parameters to > have an API for each specific case. In my earlier example/proposal, I included the ability for attributes of a port to be expressed as a collection of enumeration values for standard things. That would be fine for simple things like Input, Output, Sync, Async etc. When there are specific attributes of specific hardware, the vendor is going to have to provide a way to configure those attributes. One of the primary mechanisms in Java to do this is the JavaBean pattern that can be manifested in a Map type object when an API needs to preexist. So, we can provide an mechanism for propagating random attributes using a Map argument to a method such as public void setConfig( Map params ) throws IOException; public Map getConfig() throws IOException; Then, there is a conduit in and out of the driver that the user can use without needing more standards/spec'd code/API. This isn't much different than an ioctl(2) like mechanism, but it feels more Java like. A URL like mechanism, such as that which JDBC drivers use, could also be attractive. I've also wanted to replace java.net with the J2ME connection based mechanism as well. We might consider looking at the J2ME connector architecture to see if there is any gain in using some of that experience. Gregg Wonderly From gergg at cox.net Tue Jul 25 13:38:42 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 14:38:42 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> <44C5CD7E.9030903@sun.com> <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> Message-ID: <44C67342.9020402@cox.net> Guillermo Rodriguez Garcia wrote: > At 09:51 25/07/2006, Paul Klissner wrote: >>For example, if I am implementing class Foo in FooImpl.java, >>And Foo.java defines interface methods a(), b() and c(), >>FooImpl.java can also have public methods d(), e() and f(), which can >>be accessed from the application by casting a Foo object into >>a FooImpl object. This is one way to provide a back door without >>compromising the core API itself to do it. This puts the >>responsibility of breaking platform independence on the developers >>and not on the designers. > > Yes, that may be a good way to do it. The J2ME connector architecture is an example of a place where this is done. Gregg Wonderly From Paul.Klissner at Sun.COM Tue Jul 25 14:02:40 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Tue, 25 Jul 2006 13:02:40 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C67342.9020402@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> <44C5CD7E.9030903@sun.com> <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> <44C67342.9020402@cox.net> Message-ID: <44C678E0.90209@sun.com> Gregg Wonderly wrote: > Guillermo Rodriguez Garcia wrote: >> At 09:51 25/07/2006, Paul Klissner wrote: >>> For example, if I am implementing class Foo in FooImpl.java, >>> And Foo.java defines interface methods a(), b() and c(), >>> FooImpl.java can also have public methods d(), e() and f(), which can >>> be accessed from the application by casting a Foo object into >>> a FooImpl object. This is one way to provide a back door without >>> compromising the core API itself to do it. This puts the >>> responsibility of breaking platform independence on the developers >>> and not on the designers. >> Yes, that may be a good way to do it. > > The J2ME connector architecture is an example of a place where this is done. It's how I debugged my javax.usb implementations. Paul From Pawan.Kharbanda at dot.state.co.us Tue Jul 25 14:02:53 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 25 Jul 2006 14:02:53 -0600 Subject: [Rxtx] Strange error (show stopper) Message-ID: <939A619A756047469C41EE9BA51890FB0429DFA4@hqexchange3.dot.state.co.us> Joachim, I believe it's the same problem that I reported earlier (Thread deadlocks/Locked Ports), I am not a C person so don't know exactly whatz going in the native code but was able to find a workaround for right now by synchronizing the "interruptEventLoop" and "eventLoop" methods in the RXTXPort class. It helped but is not the right solution, I still find the deadlocks but not as often as I used too. A fix for this will be highly appreciated. I have some Test Classes that I have posted earlier to simulate the problem. ~pk -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Joachim Buechse Sent: Monday, July 24, 2006 2:13 AM To: RXTX Developers and Users Subject: Re: [Rxtx] Strange error (show stopper) The pthread_kill is followed by a sleep. When the sleep returns the structure is damaged. I did not find the source that overwrites the closing field - it is correctly set by the exiting drain thread. But something overwrites it afterwards. I currently believe that this existed for some time but was never seen because the previous versions did not rely on the structure to be in good shape when tearing down connections. However I may be completely wrong and it is an OSX problem. To help me find the source, it would be nice to get some indications what the 2 debug lines I suggested return on other platforms. Joachim On 24.07.2006, at 05:27, Trent Jarvi wrote: > On Sat, 22 Jul 2006, Joachim Buechse wrote: > >> I just discovered a strange error in RXTX on OSX. SerialDemo.java >> manages to corrupt the event_info_structure by a simple >> OpenPort,ClosePort - this could be in relation to the deadlock >> problem that was reported recently. >> >> Could anyone try to reproduce this on Solaris or some other system >> which is neither WIN32 nor Linux (ie which uses a drain thread). >> >> In SerialImp.c : RXTXPort(interruptEventLoop) >> >> Apparently the event_info_structure gets corrupted shortly after >> >> pthread_kill(index->drain_tid, SIGABRT); >> >> In particular, the index->closing flag gets overwritten by a pointer >> value. > > Hi Joachim > > Interesting. I did run many tests with that code on may OSs. To be > fair, the tests are just starting to get into good shape again. I'm > still tagging releases with a bit of feel and not enough process. > I'll look at this some more tomorrow night. > > The SIGABRT was added recently as part of the close speedups. > Thats from > memory. I can provide the exact patch that introduced that tomorrow. > > -- > Trent Jarvi > tjarvi at qbang.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Jul 25 17:42:23 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 18:42:23 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153840929.44c6372186f67@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> Message-ID: <44C6AC5F.3060107@cox.net> Guillermo Rodriguez wrote: > The problem with this is that there is no guarantee that a single call > to the write method of the OutputStream associated with a javax.comm > SerialPort will translate to a single write to the underlying device > driver -- this depends on the javax.comm implementation. More specifically, it depends on a software layer that would targeted specifically at solving this problem for RS-485 and other transports which have blocking or packetizing issues. There are many. In amatuer radio, we have TNCs (radio modems) which will block things using newline separators in some modes, and 0xc0 in others. Gregg Wonderly From gergg at cox.net Tue Jul 25 17:46:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 18:46:11 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C63A37.8080406@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> <44C60EB9.5000803@gmail.com> <44C63A37.8080406@sun.com> Message-ID: <44C6AD43.1090302@cox.net> Paul Klissner wrote: > Also that would imply two downloads to install any given > bus support, which might not be the end of the world. > And maybe two JSRs? Why are we hovering around this "downloads" issue? If we create a JSR that covers everything needed for javax.comm compatibility, does that still imply that it would be an unincluded, optional part of the JVM? If that is still something that people will tolerate, I'm a little lost for words. Still today, I can use the old javax.comm support. If we're just going to recreate the same concerns, issues and limitations, then what's the point? Gregg Wonderly From gergg at cox.net Tue Jul 25 17:48:42 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 18:48:42 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <00c801c6b000$33a68f00$0c28a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <44C6ADDA.5040208@cox.net> Martin Schoeberl wrote: > I completely agree - it's still a stream and not a packet. > > This is similar to a single write to a TCP/IP socket. There > is no guarantee that you get this data as a single packet/single > read on the other side. However, I've seen a lot of programs > assuming that this happens ;-) For nearly forever, serialport drivers have operated in the mode that they send either everything up to the divider char, or a single char. This was specifically done for protocols such as modbus which have 1 1/2 bit time delays indicating end of packet. This kind of thing is something that needs to be maintained for serial protocols to work. A user has to have a way to send a single "packet" of data and make sure that it flows out of the uart uninterrupted. Gregg Wonderly From gergg at cox.net Tue Jul 25 18:03:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 19:03:11 -0500 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <939A619A756047469C41EE9BA51890FB0429DFA4@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB0429DFA4@hqexchange3.dot.state.co.us> Message-ID: <44C6B13F.1000306@cox.net> Kharbanda, Pawan wrote: > Joachim, > I believe it's the same problem that I reported earlier (Thread > deadlocks/Locked Ports), I am not a C person so don't know exactly whatz > going in the native code but was able to find a workaround for right now > by synchronizing the "interruptEventLoop" and "eventLoop" methods in the > RXTXPort class. It helped but is not the right solution, I still find > the deadlocks but not as often as I used too. > > A fix for this will be highly appreciated. I have some Test Classes that > I have posted earlier to simulate the problem. You can send SIGQUIT (signal #3) to unix JVMs to get a stacktrace of where all the threads are at and who owns what locks. Also, on windows, you can run the JVM in a DOS window and use CTRL-BREAK to get the stack trace. This won't go beyond the native level, but it might expose what you need to know. Gregg Wonderly From tjarvi at qbang.org Tue Jul 25 22:21:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 22:21:22 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6AC5F.3060107@cox.net> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: On Tue, 25 Jul 2006, Gregg Wonderly wrote: > Guillermo Rodriguez wrote: >> The problem with this is that there is no guarantee that a single call >> to the write method of the OutputStream associated with a javax.comm >> SerialPort will translate to a single write to the underlying device >> driver -- this depends on the javax.comm implementation. > > More specifically, it depends on a software layer that would targeted > specifically at solving this problem for RS-485 and other transports which have > blocking or packetizing issues. There are many. In amatuer radio, we have TNCs > (radio modems) which will block things using newline separators in some modes, > and 0xc0 in others. > I had looked into RS-485 some. It is daunting without proper hardware. One option is to do a native local tcpip/udp server to remove most of the the 'java issues.' Realtime patches comming down the pipe make it tempting to jump into the tarpit of failures. Beyond that, we should be very explicit about what type of RS-485 hardware we do support and it should not involve things that we have to control DTR/RTS in almost realtime (<20 ms). There are going to be people wanting < $5/EURO winmodem type solutions that will be nothing but problems. Thats doable by hacking kernel drivers but it will never get into mainstream kernels. I do not think thats reasonable from java and is even questionable in typical C. It will work fine until you start oracle... It would be nice to get RS-485 support in. Things like controlling low cost devices in houses, ... But cutting out the hardware isn't a viable solution in java. -- Trent Jarvi tjarvi From tjarvi at qbang.org Tue Jul 25 22:40:36 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 22:40:36 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6AD43.1090302@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> <44C60EB9.5000803@gmail.com> <44C63A37.8080406@sun.com> <44C6AD43.1090302@cox.net> Message-ID: On Tue, 25 Jul 2006, Gregg Wonderly wrote: > Paul Klissner wrote: >> Also that would imply two downloads to install any given >> bus support, which might not be the end of the world. >> And maybe two JSRs? > > Why are we hovering around this "downloads" issue? If we create a JSR that > covers everything needed for javax.comm compatibility, does that still imply > that it would be an unincluded, optional part of the JVM? If that is still > something that people will tolerate, I'm a little lost for words. Still today, > I can use the old javax.comm support. If we're just going to recreate the same > concerns, issues and limitations, then what's the point? > I don't have a problem with Sun shipping rxtx or whatever it becomes. They may have some legacy issues :) Just poking fun. The current state does not work for java users. Not having w32 support means about 80+% of the users do not have support. The rxtx w32 support is heavily influenced by cygwin so it wont change license out of respect for that project. If you really hate life and the LGPL, you can do a w32 port and the rest will just fall into place while you chase windows bugs for 5 years. Anything that dances around w32 support is just an academic waste of time. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Tue Jul 25 22:41:21 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 23:41:21 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: <44C6F271.2020604@cox.net> Trent Jarvi wrote: > I had looked into RS-485 some. It is daunting without proper hardware. > One option is to do a native local tcpip/udp server to remove most of the > the 'java issues.' Realtime patches comming down the pipe make it tempting > to jump into the tarpit of failures. Trent, there is not a way for a non-realtime OS to drive 485 hardware without the hardware taking care of the timing issues. But, a non-realtime OS can support software APIs which let the developer express in an API the types of things that a piece of hardware is capable of. Then we can have an API, and the hardware people and the OS people will provide the solutions where possible. > It would be nice to get RS-485 support in. Things like controlling > low cost devices in houses, ... But cutting out the hardware isn't a > viable solution in java. The 485 hardware devices will have to have non-realtime requirements associated with the controlling mechanisms. There are some of those. I'm mostly interested in having a 485 API for realtime java and/or the aJile and other uC environments which can provide realtime environments. Gregg Wonderly From tjarvi at qbang.org Tue Jul 25 22:54:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 22:54:44 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6F271.2020604@cox.net> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <44C6F271.2020604@cox.net> Message-ID: On Tue, 25 Jul 2006, Gregg Wonderly wrote: > Trent Jarvi wrote: >> I had looked into RS-485 some. It is daunting without proper hardware. >> One option is to do a native local tcpip/udp server to remove most of the >> the 'java issues.' Realtime patches comming down the pipe make it tempting >> to jump into the tarpit of failures. > > Trent, there is not a way for a non-realtime OS to drive 485 hardware without > the hardware taking care of the timing issues. But, a non-realtime OS can > support software APIs which let the developer express in an API the types of > things that a piece of hardware is capable of. Then we can have an API, and the > hardware people and the OS people will provide the solutions where possible. > >> It would be nice to get RS-485 support in. Things like controlling >> low cost devices in houses, ... But cutting out the hardware isn't a >> viable solution in java. > > The 485 hardware devices will have to have non-realtime requirements associated > with the controlling mechanisms. There are some of those. I'm mostly > interested in having a 485 API for realtime java and/or the aJile and other uC > environments which can provide realtime environments. > Hi Gregg I do not disagree with you but I have a problem with this (realtime java and/or the aJile and other Uc environements) being something I may be hearing bugs about 5 years from now. Is this really something that should be in the API or is it something that would make a nice niche market for support and services? Do the two really go together? If you like that market and I think there is a niche market there, great. This is a good area for SPI type interfaces where you could support it but it was not provided by default. -- Trent Jarvi tjarvi at qbang.org From guille at sms.nl Wed Jul 26 00:39:47 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 08:39:47 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C672EA.1080604@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> Message-ID: <7.0.1.0.0.20060726083751.03633188@sms.nl> At 21:37 25/07/2006, Gregg Wonderly wrote: >Guillermo Rodriguez Garcia wrote: > > At 11:25 25/07/2006, Martin Schoeberl wrote: > >>Mmh, perhaps in a similar way as you configure timeouts? > >>Isn't this 'just' a timeout value? > > > > Yes, but this is just a specific parameter that you can configure in a > > specific type of UART (an EXAR UART). Other UARTs might be different. The > > point I'm trying to make is that there are just too many parameters to > > have an API for each specific case. > >In my earlier example/proposal, I included the ability for >attributes of a port >to be expressed as a collection of enumeration values for standard >things. That >would be fine for simple things like Input, Output, Sync, Async >etc. When there >are specific attributes of specific hardware, the vendor is going to have to >provide a way to configure those attributes. One of the primary >mechanisms in >Java to do this is the JavaBean pattern that can be manifested in a Map type >object when an API needs to preexist. So, we can provide an mechanism for >propagating random attributes using a Map argument to a method such as > >public void setConfig( Map params ) throws IOException; >public Map getConfig() throws IOException; > >Then, there is a conduit in and out of the driver that the user can >use without >needing more standards/spec'd code/API. > >This isn't much different than an ioctl(2) like mechanism, This is exactly what I was thinking while reading your mail :) >but it feels more Java like. It would do the job as well and I would be happy with that. However Paul's proposal where implementation classes extend the core API as necessary might be more elegant (for the same reason that it is more elegant than ioctl) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Wed Jul 26 00:41:40 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 08:41:40 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6AC5F.3060107@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: <7.0.1.0.0.20060726084016.03633040@sms.nl> At 01:42 26/07/2006, Gregg Wonderly wrote: >Guillermo Rodriguez wrote: > > The problem with this is that there is no guarantee that a single call > > to the write method of the OutputStream associated with a javax.comm > > SerialPort will translate to a single write to the underlying device > > driver -- this depends on the javax.comm implementation. > >More specifically, it depends on a software layer that would targeted >specifically at solving this problem for RS-485 and other transports >which have >blocking or packetizing issues. There are many. In amatuer radio, >we have TNCs >(radio modems) which will block things using newline separators in >some modes, >and 0xc0 in others. Right. I meant that in general one cannot assume that writes to a stream will translate 1:1 to writes in every layer of the protocol stack (this is most often not the case.) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Wed Jul 26 00:44:57 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 08:44:57 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6ADDA.5040208@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> <44C6ADDA.5040208@cox.net> Message-ID: <7.0.1.0.0.20060726084203.036cd2b8@sms.nl> At 01:48 26/07/2006, Gregg Wonderly wrote: >Martin Schoeberl wrote: > > I completely agree - it's still a stream and not a packet. > > > > This is similar to a single write to a TCP/IP socket. There > > is no guarantee that you get this data as a single packet/single > > read on the other side. However, I've seen a lot of programs > > assuming that this happens ;-) > >For nearly forever, serialport drivers have operated in the mode >that they send >either everything up to the divider char, or a single char. This was >specifically done for protocols such as modbus which have 1 1/2 bit >time delays >indicating end of packet. This kind of thing is something that needs to be >maintained for serial protocols to work. A user has to have a way to send a >single "packet" of data and make sure that it flows out of the uart >uninterrupted. Even that is sometimes difficult to achieve. If the whole packet does not fit in the UART FIFOs, then the driver may have a hard time making sure that all of the data flows out uninterrupted, unless 1/ you have a RTOS with a response time that is fast enough to refill the FIFO before it empties, and/or 2/ you can tolerate a 'stop the world' approach where ints are globally disabled while the packet is being sent (not nice) (just a side comment) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From tjarvi at qbang.org Wed Jul 26 00:48:29 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 26 Jul 2006 00:48:29 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060726084016.03633040@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <7.0.1.0.0.20060726084016.03633040@sms.nl> Message-ID: On Wed, 26 Jul 2006, Guillermo Rodriguez Garcia wrote: > At 01:42 26/07/2006, Gregg Wonderly wrote: >> Guillermo Rodriguez wrote: >>> The problem with this is that there is no guarantee that a single call >>> to the write method of the OutputStream associated with a javax.comm >>> SerialPort will translate to a single write to the underlying device >>> driver -- this depends on the javax.comm implementation. >> >> More specifically, it depends on a software layer that would targeted >> specifically at solving this problem for RS-485 and other transports >> which have >> blocking or packetizing issues. There are many. In amatuer radio, >> we have TNCs >> (radio modems) which will block things using newline separators in >> some modes, >> and 0xc0 in others. > > Right. I meant that in general one cannot assume that writes to a stream > will translate 1:1 to writes in every layer of the protocol stack (this is > most often not the case.) > Hi Guillermo This sounds like a dead end to me. People using commapi want a a write, an interrupt and data. The kernel being a big problem these days. There are _much_ better ways to do things like protocol stacks. This is not how EIA232 works in the real world. -- Trent Jarvi tjarvi From guille at sms.nl Wed Jul 26 01:02:09 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 09:02:09 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <7.0.1.0.0.20060726084016.03633040@sms.nl> Message-ID: <7.0.1.0.0.20060726090154.036dd708@sms.nl> At 08:48 26/07/2006, Trent Jarvi wrote: >On Wed, 26 Jul 2006, Guillermo Rodriguez Garcia wrote: > > > At 01:42 26/07/2006, Gregg Wonderly wrote: > >> Guillermo Rodriguez wrote: > >>> The problem with this is that there is no guarantee that a single call > >>> to the write method of the OutputStream associated with a javax.comm > >>> SerialPort will translate to a single write to the underlying device > >>> driver -- this depends on the javax.comm implementation. > >> > >> More specifically, it depends on a software layer that would targeted > >> specifically at solving this problem for RS-485 and other transports > >> which have > >> blocking or packetizing issues. There are many. In amatuer radio, > >> we have TNCs > >> (radio modems) which will block things using newline separators in > >> some modes, > >> and 0xc0 in others. > > > > Right. I meant that in general one cannot assume that writes to a stream > > will translate 1:1 to writes in every layer of the protocol stack (this is > > most often not the case.) > > > >Hi Guillermo > >This sounds like a dead end to me. People using commapi want a a write, >an interrupt and data. The kernel being a big problem these days. > >There are _much_ better ways to do things like protocol stacks. This is >not how EIA232 works in the real world. Yes, this is exactly what I'm saying. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From Luis.Moreira at jet.uk Wed Jul 26 01:34:42 2006 From: Luis.Moreira at jet.uk (Luis Moreira) Date: Wed, 26 Jul 2006 08:34:42 +0100 Subject: [Rxtx] Portability Message-ID: Hi Guys, I managed to get the RXTX package to work on my PC, but the question is, if I need to distribute my program to someone that does not know much about java how do I get the program to work on their System? Best regards Luis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/3e3c2058/attachment-0340.html From joachim at buechse.de Wed Jul 26 02:18:19 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 26 Jul 2006 10:18:19 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <44C667EC.2070602@ergotech.com> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> <44C667EC.2070602@ergotech.com> Message-ID: I may not have been very clear with my suggestion: The "mandatory" flush after write was only regarding RS485. If an application does not use flush after write (today), it is damned to fail anyway. The Outputstream interface makes no guarentee what so ever, that any data will be writen before you call flush. So in fact flush is already mandatory unless you dont care if your data is ever transmitted. I don't see how sending on flush for RS485 would be less efficient. If you are concerned about the additional function call you may want to specify on which platform/VM you are working. A function call in java even on slow PCs is in the microsecond range. So if your concern is, that writes should be forwarded as soon as possible, well then follow any write by a flush. I haven't done any JavaME serial programming, but from my experience with implementing Ymodem over RS232+USB, all I can say is this: Either you have your data ready when it is demanded and you can write it with a single write(+flush) or your application will be slow. So yes, you need to get data on the wire as quick as possible, the solutions are manyfold but an additional (flush) function call will hardly make your application slower. Regards, Joachim On 25.07.2006, at 20:50, Jim Redman wrote: > The horror! This would be terribly inefficient. Especially in serial > protocols you need to start getting bits on the wire as soon as > possible. It could also have some timeout implications. > > Jim > > Joachim Buechse wrote: >> Just trigger writing on flush(). It is perfectly legal for an >> Outputstream implementation to do do nothing until flush is called >> and the documentation of OutputStream.flush reads: >> >> "Flushes this output stream and forces any buffered output bytes to >> be written out. The general contract of flush is that calling it is >> an indication that, if any bytes previously written have been >> buffered by the implementation of the output stream, such bytes >> should immediately be written to their intended destination." >> >> As RS485 is a "dont speak up unless requested" protocol, a mandatory >> flush after write seems like the way to go to me >> >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). >> >> Regards, >> Joachim >> >> PS: It is great to see all the motivation that is brought forward on >> this list regarding the future. It would be great if only 10% of that >> motivation could be transformed into a cleanup and extension of the >> existing code. The current code access model seems rather >> inappropriate for the prototyping of the ideas beeing presented. >> Trent can we get a "contributions" branch with "free" access. >> >> >> On 25.07.2006, at 17:37, Martin Schoeberl wrote: >> >>>>> Martin Schoeberl wrote: >>>>>> We can model it platform independent with two methods: >>>>>> >>>>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>>>> on the underlying platform to switch to RS485 transmit mode and >>>>>> back. >>>>> Or, do what is typically done, and use a single write operation >>>>> as the >>>>> indication of a 'packet' that will let the underlying RS-485/422 >>>>> driver >>>>> assert >>>>> the appropriate signalling. >>>> The problem with this is that there is no guarantee that a single >>>> call >>>> to the write method of the OutputStream associated with a >>>> javax.comm >>>> SerialPort will translate to a single write to the underlying >>>> device >>>> driver -- this depends on the javax.comm implementation. >>>> >>> I completely agree - it's still a stream and not a packet. >>> >>> This is similar to a single write to a TCP/IP socket. There >>> is no guarantee that you get this data as a single packet/single >>> read on the other side. However, I've seen a lot of programs >>> assuming that this happens ;-) >>> >>> Martin >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Wed Jul 26 04:28:33 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 26 Jul 2006 06:28:33 -0400 Subject: [Rxtx] Should we defer JSR support of RS485? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: Hi All, Would it make sense to focus the JSR on rock solid serial and parallel port support? Can the RS485 people live with unofficial support, at least until we get the JSR accepted and the implementation rock solid? Thanks! - Doug From gergg at cox.net Wed Jul 26 08:49:21 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 26 Jul 2006 09:49:21 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <44C6F271.2020604@cox.net> Message-ID: <44C780F1.8020506@cox.net> Trent Jarvi wrote: > I do not disagree with you but I have a problem with this (realtime java > and/or the aJile and other Uc environements) being something I may be > hearing bugs about 5 years from now. Is this really something that should > be in the API or is it something that would make a nice niche market for > support and services? Do the two really go together? The question is whether there needs to be two, three or five ways to do the same thing, or can we distill it down to one so that software working in one environment can work in all. > If you like that market and I think there is a niche market there, great. > This is a good area for SPI type interfaces where you could support it but > it was not provided by default. SPI is supported natively on the aJile processors. Systronix provides an API for using the SPI lines defined for that use. Adding extra slave selects is not part of their API. There are plenty of places where this stuff is getting used. In the C world of uC, there are 500 ways to do the same thing because everyone wants to be as close to the hardware as possible. The trumpet of the Java platform proclaims write once, run anywhere. Thats been a powerful impetus to me and others to use the language. I really do appreciate that I don't have to think about non-application related programming tasks as much as I did in C and C++. It's possible to pick a reasonable level of abstraction that provide opportunity to expand in the future while accounting for the small in the present. But, we have to all get together with a desire to accomplish this, have good constructive conversation and feedback, and get it done. Gregg Wonderly From gergg at cox.net Wed Jul 26 08:56:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Wed, 26 Jul 2006 09:56:11 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060726083751.03633188@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> Message-ID: <44C7828B.7040904@cox.net> Guillermo Rodriguez Garcia wrote: > It would do the job as well and I would be happy with that. However > Paul's proposal where implementation classes extend the core API as > necessary might be more elegant (for the same reason that it is more > elegant than ioctl) Right, but my argument was that this demanded that the classes preexist at the time I am writing the software. I have to be able to compile against them. The Map mechanism would allow me to write software that worked with any hardware. The person deploying my software into their environment with their hardware would then just provide a set of configuration values that my software would pass into the API. That's the point I'm trying to make. I'm on the fence about a Map vs a subclass with methods. I can see it both ways. But, as a JDBC user, I've learned to appreciate a single API with Properties passed in. As a Jini user I've learned to appreciate the Configuration mechanisms that Jini 2.x has. I can write code in my configuration file to instantiate and configure the system at deployment time! Gregg Wonderly From joachim at buechse.de Wed Jul 26 09:37:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 26 Jul 2006 17:37:27 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C7828B.7040904@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> <44C7828B.7040904@cox.net> Message-ID: <08E356DB-AC3F-46FC-952B-82D5ABB15926@buechse.de> Unless you are working with J2ME, you can just as well do what you describe using reflection (ie a JavaBean strategy). A Map can change at runtime, an interface can not. Regards, Joachim On 26.07.2006, at 16:56, Gregg Wonderly wrote: > Guillermo Rodriguez Garcia wrote: >> It would do the job as well and I would be happy with that. However >> Paul's proposal where implementation classes extend the core API as >> necessary might be more elegant (for the same reason that it is more >> elegant than ioctl) > > Right, but my argument was that this demanded that the classes > preexist at the > time I am writing the software. I have to be able to compile > against them. > > The Map mechanism would allow me to write software that worked with > any > hardware. The person deploying my software into their environment > with their > hardware would then just provide a set of configuration values that > my software > would pass into the API. > > That's the point I'm trying to make. I'm on the fence about a Map > vs a subclass > with methods. I can see it both ways. But, as a JDBC user, I've > learned to > appreciate a single API with Properties passed in. As a Jini user > I've learned > to appreciate the Configuration mechanisms that Jini 2.x has. I > can write code > in my configuration file to instantiate and configure the system at > deployment > time! > > config/ConfigurationFile.html> > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Paul.Klissner at Sun.COM Wed Jul 26 12:11:37 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 26 Jul 2006 11:11:37 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C780F1.8020506@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <44C6F271.2020604@cox.net> <44C780F1.8020506@cox.net> Message-ID: <44C7B059.1060302@sun.com> Gregg Wonderly wrote: > Trent Jarvi wrote: >> I do not disagree with you but I have a problem with this (realtime java >> and/or the aJile and other Uc environements) being something I may be >> hearing bugs about 5 years from now. Is this really something that should >> be in the API or is it something that would make a nice niche market for >> support and services? Do the two really go together? > > The question is whether there needs to be two, three or five ways to do the same > thing, or can we distill it down to one so that software working in one > environment can work in all. > >> If you like that market and I think there is a niche market there, great. >> This is a good area for SPI type interfaces where you could support it but >> it was not provided by default. > > SPI is supported natively on the aJile processors. Systronix provides an API > for using the SPI lines defined for that use. Adding extra slave selects is not > part of their API. > > There are plenty of places where this stuff is getting used. In the C world of > uC, there are 500 ways to do the same thing because everyone wants to be as > close to the hardware as possible. > > The trumpet of the Java platform proclaims write once, run anywhere. Thats been > a powerful impetus to me and others to use the language. I really do appreciate > that I don't have to think about non-application related programming tasks as > much as I did in C and C++. > > It's possible to pick a reasonable level of abstraction that provide opportunity > to expand in the future while accounting for the small in the present. > > But, we have to all get together with a desire to accomplish this, have good > constructive conversation and feedback, and get it done. I agree that whatever approach we take should involve settling on the scope and then seeking to create a reasonably complete set of abstractions to generalize and make platform independent, and then refine that list as corner cases appear. For whichever bus(ses) we support, it will be standards-based functionality we're trying to support, with device-specific functionality hidden in the driver and not passed through as direct driver-oriented commands via the API. Paul > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Paul.Klissner at Sun.COM Wed Jul 26 12:23:56 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 26 Jul 2006 11:23:56 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C7828B.7040904@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> <44C7828B.7040904@cox.net> Message-ID: <44C7B33C.8090005@sun.com> Gregg Wonderly wrote: > Guillermo Rodriguez Garcia wrote: >> It would do the job as well and I would be happy with that. However >> Paul's proposal where implementation classes extend the core API as >> necessary might be more elegant (for the same reason that it is more >> elegant than ioctl) > > Right, but my argument was that this demanded that the classes preexist at the > time I am writing the software. I have to be able to compile against them. > > The Map mechanism would allow me to write software that worked with any > hardware. The person deploying my software into their environment with their > hardware would then just provide a set of configuration values that my software > would pass into the API. > > That's the point I'm trying to make. I'm on the fence about a Map vs a subclass > with methods. I can see it both ways. But, as a JDBC user, I've learned to > appreciate a single API with Properties passed in. As a Jini user I've learned > to appreciate the Configuration mechanisms that Jini 2.x has. I can write code > in my configuration file to instantiate and configure the system at deployment > time! I don't think this is a problem as long as the implementation specific stuff is handled by controlling through vehicles outside the API. The application code layered over the API should be written such that it can run on any platform and with any generic device of the class the API claims to support. The problem with the ioctl is it's proneness for abuse and invitation to proliferate the space with non-portable applications. If the implementation requires a configuration file to be passed through the API then the application can run on platform A, B and C, which all have the same type of device, fine, and then with a different configuration file, could run on D, E and F with other hardware, that seems reasonable. What if there are multiple devices on a system of different types? There needs to be a way to get the right configuration file to associate with the right device, and the application should seamlessly work with either. The application code layered over the API should not have to be aware of the configuration file or the programmatic peculiarities of the underlying hardware. Paul From joachim at buechse.de Wed Jul 26 12:59:06 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 26 Jul 2006 20:59:06 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C7B33C.8090005@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> <44C7828B.7040904@cox.net> <44C7B33C.8090005@sun.com> Message-ID: <1A34B6D0-43B2-4F73-A39F-004B3D100CE9@buechse.de> Paul honestly I think you are to extreme - Often enough a USER is very well capable of indentifying which "config file" needs to be choosen to set up the device he owns. This file can be accepted from the application as a "configuration parameter" and passed on to the driver. One very typical example are AT-command sequences. Terminal programs know nothing about their meaning - still they happily pass them on to do their magic. Best regards, Joachim On 26.07.2006, at 20:23, Paul Klissner wrote: > Gregg Wonderly wrote: >> Guillermo Rodriguez Garcia wrote: >>> It would do the job as well and I would be happy with that. However >>> Paul's proposal where implementation classes extend the core API as >>> necessary might be more elegant (for the same reason that it is more >>> elegant than ioctl) >> >> Right, but my argument was that this demanded that the classes >> preexist at the >> time I am writing the software. I have to be able to compile >> against them. >> >> The Map mechanism would allow me to write software that worked >> with any >> hardware. The person deploying my software into their environment >> with their >> hardware would then just provide a set of configuration values >> that my software >> would pass into the API. >> >> That's the point I'm trying to make. I'm on the fence about a Map >> vs a subclass >> with methods. I can see it both ways. But, as a JDBC user, I've >> learned to >> appreciate a single API with Properties passed in. As a Jini user >> I've learned >> to appreciate the Configuration mechanisms that Jini 2.x has. I >> can write code >> in my configuration file to instantiate and configure the system >> at deployment >> time! > > I don't think this is a problem as long as the implementation specific > stuff is handled by controlling through vehicles outside the API. > The application code layered over the API should be written such that > it can run on any platform and with any generic device of the class > the API claims to support. > > The problem with the ioctl is it's proneness for abuse and invitation > to proliferate the space with non-portable applications. > > If the implementation requires a configuration file to be passed > through > the API then the application can run on platform A, B and C, which all > have the same type of device, fine, and then with a different > configuration > file, could run on D, E and F with other hardware, that seems > reasonable. > > What if there are multiple devices on a system of different types? > There needs to be a way to get the right configuration file to > associate > with the right device, and the application should seamlessly work > with either. > The application code layered over the API should not have to be aware > of the configuration file or the programmatic peculiarities of the > underlying hardware. > > Paul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From savagobr at yahoo.com Wed Jul 26 13:15:13 2006 From: savagobr at yahoo.com (Adenilson Cavalcanti) Date: Wed, 26 Jul 2006 12:15:13 -0700 (PDT) Subject: [Rxtx] Strange error (show stopper) - Fedora Core 5 is ok! Message-ID: <20060726191513.28407.qmail@web53802.mail.yahoo.com> Dear Joachim Buechse I'm pretty new to this list (actually, first post) but got curious about the issue that you reported. If a undertood the code correctly, SerialImp.c -> interruptEventLoop only calls pthread_kill when compiled for MacOSX. Anyway, I changed the code to print field values of structure object 'index' and got this results: 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 CLOSING=0 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 CLOSING=1 Which I think seems to be o.k. (I must also comment that I'm running FC5, kernel 2.6.15, gcc 4.1.1, jdk 1.5.0_06). Bellow you will find where in source code I printed the debug information. I was wondering why in Linux is not necessary to call pthread_kill (of course I did read the comments about "output buffer empty" but don't get it...). Any comments? Best regards Savago //---------------------------------------------------------------------------------------------- Changed code. //---------------------------------------------------------------------------------------------- /** XXX: DEBUG INFO*/ snprintf(message, sizeof(message), "1 interrupted thread for FD=%i PTR=%i CLOSING=%i\n", index->fd, index, index->closing ); report(message); #ifdef TIOCSERGETLSR index->closing=1; #endif /* TIOCSERGETLSR */ #ifdef WIN32 termios_interrupt_event_loop( index->fd, 1 ); #endif /* WIN32 */ #if !defined(TIOCSERGETLSR) && !defined(WIN32) . . . #endif /** XXX: DEBUG INFO*/ snprintf(message, sizeof(message), "2 interrupted thread for FD=%i PTR=%i CLOSING=%i\n", index->fd, index, index->closing ); report(message); report("interruptEventLoop: interrupted\n"); //---------------------------------------------------------------------------------------------- OUTPUT: 15:00:24:******* report_serial_events: sending DATA_AVAILABLE 15:00:24:******* reporting data available 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 CLOSING=0 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 CLOSING=1 15:00:24:******* interruptEventLoop: interrupted 15:00:24:******* eventLoop: got interrupt 15:00:24:******* setDTR( 0 ) 15:00:24:******* setDSR( 0 ) 15:00:24:******* >nativeClose pid 15:00:24:******* nativeClose: pid 15:00:24:******* nativeClose: discarding remaining datai (tcflush) 15:00:24:******* nativeClose: calling close 15:00:24:******* fhs_unlock: Removing LockFile 15:00:24:******* nativeClose: Delete jclazz 15:00:24:******* nativeClose: release filename 15:00:24:******* fhs_unlock: Removing LockFile //---------------------------------------------------------------------------------------------- --------------------------------- How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone call rates. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/ad116f14/attachment-0339.html From savagobr at yahoo.com Wed Jul 26 13:23:05 2006 From: savagobr at yahoo.com (Adenilson Cavalcanti) Date: Wed, 26 Jul 2006 12:23:05 -0700 (PDT) Subject: [Rxtx] Locked ports - to Kharbanda Message-ID: <20060726192305.23957.qmail@web53807.mail.yahoo.com> Dear Kharbanda I'm trying to reproduce the bug that you reported (the deadlock one) but dont get it. What I did was write a java app that continuously open/close a port (/dev/ttyS0) within 1 second for this operation. The program keeps running fine, no lock until now. I'm wondering if you could send me a sample app that could help me to reproduce this bug? Best regards Savago --------------------------------- Yahoo! Music Unlimited - Access over 1 million songs.Try it free. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/c56bc64a/attachment-0339.html From Pawan.Kharbanda at dot.state.co.us Wed Jul 26 13:41:13 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Wed, 26 Jul 2006 13:41:13 -0600 Subject: [Rxtx] Locked ports - to Kharbanda Message-ID: <939A619A756047469C41EE9BA51890FB0429E08B@hqexchange3.dot.state.co.us> Savago, I have attached the Test class that i wrote to replicate the locking/threading problem with RXTX in Redhat Linux. Please follow the following instructions to replicate the problem. I don't know if you will be able to replicate using one Serial port or not, i was able to reproduced it using 3 or 4 ports constantly. Instructions: In the TestOpenClosePort.java please change the Serial Ports names(Add the ports installed on your machine). Then compile your java file and run as "java TestOpenClosePort 100" (100 is the no of times you want to open and close the port in one single thread). I have tested this with the Digi Boxes and able to replicate this over and over in Single JVM. Thanks ~pk ________________________________ From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Adenilson Cavalcanti Sent: Wednesday, July 26, 2006 1:23 PM To: rxtx at qbang.org Subject: [Rxtx] Locked ports - to Kharbanda Dear Kharbanda I'm trying to reproduce the bug that you reported (the deadlock one) but dont get it. What I did was write a java app that continuously open/close a port (/dev/ttyS0) within 1 second for this operation. The program keeps running fine, no lock until now. I'm wondering if you could send me a sample app that could help me to reproduce this bug? Best regards Savago ________________________________ Yahoo! Music Unlimited - Access over 1 million songs. Try it free. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/c581de54/attachment-0339.html -------------- next part -------------- A non-text attachment was scrubbed... Name: TestOpenClosePort.java Type: application/octet-stream Size: 6038 bytes Desc: TestOpenClosePort.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060726/c581de54/TestOpenClosePort-0339.obj From joachim at buechse.de Wed Jul 26 16:01:31 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 27 Jul 2006 00:01:31 +0200 Subject: [Rxtx] Strange error (show stopper) - Fedora Core 5 is ok! In-Reply-To: <20060726191513.28407.qmail@web53802.mail.yahoo.com> References: <20060726191513.28407.qmail@web53802.mail.yahoo.com> Message-ID: Linux offers a feature (TIOCSERGETLSR) that allows to check if all data has been sent. This feature does not exist on OSX, BSD, Solaris and probably some other systems. For these systems RXTX uses a separate thread that calls tc_drain() - on return of this call all data has been written. The pthread_kill is used to guarantee that the drain thread has been canceled. On Linux there is no forced "wait" between the setting of the "closing" flag and the end of the procedure. The test should to be done on a BSD or Solaris system. But maybe you could add a usleep (50000) just before the second sprintf. This might in fact be helpful to see if the problem exists on Linux as well. Thanks, Joachim On 26.07.2006, at 21:15, Adenilson Cavalcanti wrote: > Dear Joachim Buechse > > I'm pretty new to this list (actually, first post) but got curious > about the issue that you reported. > > If a undertood the code correctly, SerialImp.c -> > interruptEventLoop only calls pthread_kill when compiled for MacOSX. > > Anyway, I changed the code to print field values of structure > object 'index' and got this results: > > 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 > CLOSING=0 > 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 > CLOSING=1 > > Which I think seems to be o.k. (I must also comment that I'm > running FC5, kernel 2.6.15, gcc 4.1.1, jdk 1.5.0_06). > > Bellow you will find where in source code I printed the debug > information. > > I was wondering why in Linux is not necessary to call pthread_kill > (of course I did read the comments about "output buffer empty" but > don't get it...). Any comments? > > Best regards > > Savago > > //-------------------------------------------------------------------- > -------------------------- > Changed code. > //-------------------------------------------------------------------- > -------------------------- > /** XXX: DEBUG INFO*/ > snprintf(message, sizeof(message), "1 interrupted thread for FD= > %i PTR=%i CLOSING=%i\n", > index->fd, index, index->closing ); > report(message); > > #ifdef TIOCSERGETLSR > index->closing=1; > #endif /* TIOCSERGETLSR */ > #ifdef WIN32 > termios_interrupt_event_loop( index->fd, 1 ); > #endif /* WIN32 */ > #if !defined(TIOCSERGETLSR) && !defined(WIN32) > . > . > . > #endif > /** XXX: DEBUG INFO*/ > snprintf(message, sizeof(message), "2 interrupted thread for FD= > %i PTR=%i CLOSING=%i\n", > index->fd, index, index->closing ); > report(message); > > report("interruptEventLoop: interrupted\n"); > > //-------------------------------------------------------------------- > -------------------------- > OUTPUT: > > 15:00:24:******* report_serial_events: sending DATA_AVAILABLE > 15:00:24:******* reporting data available > 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 > CLOSING=0 > 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 > CLOSING=1 > 15:00:24:******* interruptEventLoop: interrupted > 15:00:24:******* eventLoop: got interrupt > 15:00:24:******* setDTR( 0 ) > 15:00:24:******* setDSR( 0 ) > 15:00:24:******* >nativeClose pid > 15:00:24:******* nativeClose: pid > 15:00:24:******* nativeClose: discarding remaining datai (tcflush) > 15:00:24:******* nativeClose: calling close > 15:00:24:******* fhs_unlock: Removing LockFile > 15:00:24:******* nativeClose: Delete jclazz > 15:00:24:******* nativeClose: release filename > 15:00:24:******* fhs_unlock: Removing LockFile > //-------------------------------------------------------------------- > -------------------------- > > How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone > call rates. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jul 26 19:34:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 26 Jul 2006 19:34:11 -0600 (MDT) Subject: [Rxtx] Strange error (show stopper) - Fedora Core 5 is ok! In-Reply-To: References: <20060726191513.28407.qmail@web53802.mail.yahoo.com> Message-ID: It is also possible to undefine TIOCSERGETLSR on Linux. It would be nice if BSD and Solaris made the line status register available but it isn't really a standard. On Thu, 27 Jul 2006, Joachim Buechse wrote: > Linux offers a feature (TIOCSERGETLSR) that allows to check if all > data has been sent. This feature does not exist on OSX, BSD, Solaris > and probably some other systems. For these systems RXTX uses a > separate thread that calls tc_drain() - on return of this call all > data has been written. The pthread_kill is used to guarantee that the > drain thread has been canceled. > > On Linux there is no forced "wait" between the setting of the > "closing" flag and the end of the procedure. The test should to be > done on a BSD or Solaris system. But maybe you could add a usleep > (50000) just before the second sprintf. This might in fact be helpful > to see if the problem exists on Linux as well. > > Thanks, > Joachim > > > On 26.07.2006, at 21:15, Adenilson Cavalcanti wrote: > >> Dear Joachim Buechse >> >> I'm pretty new to this list (actually, first post) but got curious >> about the issue that you reported. >> >> If a undertood the code correctly, SerialImp.c -> >> interruptEventLoop only calls pthread_kill when compiled for MacOSX. >> >> Anyway, I changed the code to print field values of structure >> object 'index' and got this results: >> >> 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 >> CLOSING=0 >> 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 >> CLOSING=1 >> >> Which I think seems to be o.k. (I must also comment that I'm >> running FC5, kernel 2.6.15, gcc 4.1.1, jdk 1.5.0_06). >> >> Bellow you will find where in source code I printed the debug >> information. >> >> I was wondering why in Linux is not necessary to call pthread_kill >> (of course I did read the comments about "output buffer empty" but >> don't get it...). Any comments? >> >> Best regards >> >> Savago >> >> //-------------------------------------------------------------------- >> -------------------------- >> Changed code. >> //-------------------------------------------------------------------- >> -------------------------- >> /** XXX: DEBUG INFO*/ >> snprintf(message, sizeof(message), "1 interrupted thread for FD= >> %i PTR=%i CLOSING=%i\n", >> index->fd, index, index->closing ); >> report(message); >> >> #ifdef TIOCSERGETLSR >> index->closing=1; >> #endif /* TIOCSERGETLSR */ >> #ifdef WIN32 >> termios_interrupt_event_loop( index->fd, 1 ); >> #endif /* WIN32 */ >> #if !defined(TIOCSERGETLSR) && !defined(WIN32) >> . >> . >> . >> #endif >> /** XXX: DEBUG INFO*/ >> snprintf(message, sizeof(message), "2 interrupted thread for FD= >> %i PTR=%i CLOSING=%i\n", >> index->fd, index, index->closing ); >> report(message); >> >> report("interruptEventLoop: interrupted\n"); >> >> //-------------------------------------------------------------------- >> -------------------------- >> OUTPUT: >> >> 15:00:24:******* report_serial_events: sending DATA_AVAILABLE >> 15:00:24:******* reporting data available >> 15:00:24:******* 1 interrupted thread for FD=6 PTR=-1308369708 >> CLOSING=0 >> 15:00:24:******* 2 interrupted thread for FD=6 PTR=-1308369708 >> CLOSING=1 >> 15:00:24:******* interruptEventLoop: interrupted >> 15:00:24:******* eventLoop: got interrupt >> 15:00:24:******* setDTR( 0 ) >> 15:00:24:******* setDSR( 0 ) >> 15:00:24:******* >nativeClose pid >> 15:00:24:******* nativeClose: pid >> 15:00:24:******* nativeClose: discarding remaining datai (tcflush) >> 15:00:24:******* nativeClose: calling close >> 15:00:24:******* fhs_unlock: Removing LockFile >> 15:00:24:******* nativeClose: Delete jclazz >> 15:00:24:******* nativeClose: release filename >> 15:00:24:******* fhs_unlock: Removing LockFile >> //-------------------------------------------------------------------- >> -------------------------- >> >> How low will we go? Check out Yahoo! Messengers low PC-to-Phone >> call rates. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From guille at sms.nl Thu Jul 27 00:30:47 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 27 Jul 2006 08:30:47 +0200 Subject: [Rxtx] more RS485 (was: Strange error (show stopper) - Fedora Core 5 is ok!) In-Reply-To: References: <20060726191513.28407.qmail@web53802.mail.yahoo.com> Message-ID: <7.0.1.0.0.20060727082321.036f10d0@sms.nl> At 00:01 27/07/2006, Joachim Buechse wrote: >Linux offers a feature (TIOCSERGETLSR) that allows to check if all >data has been sent. Just a side note: This is one of the things that is useful when one needs to control external RS232 to RS485 converters with the RTS or DTR lines. The above lets you look at the transmit shift register to know if/when the last character has been completely shifted out ('transmit shift register empty' is a different thing than 'output FIFO empty' and than 'software output buffer empty'). This is something you currently cannot do from your application using rxtx. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From gergg at cox.net Thu Jul 27 11:08:32 2006 From: gergg at cox.net (Gregg Wonderly) Date: Thu, 27 Jul 2006 12:08:32 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C7B33C.8090005@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> <7.0.1.0.0.20060726083751.03633188@sms.nl> <44C7828B.7040904@cox.net> <44C7B33C.8090005@sun.com> Message-ID: <44C8F310.2040107@cox.net> Paul Klissner wrote: > What if there are multiple devices on a system of different types? > There needs to be a way to get the right configuration file to associate > with the right device, and the application should seamlessly work with either. > The application code layered over the API should not have to be aware > of the configuration file or the programmatic peculiarities of the > underlying hardware. If the configuration mechanism is the standard and must be supported, then every device will have to have such a configuration object. The configuration object would be the per device mechanism with a real API on that object. I'll use the Jini ConfigurationFile syntax here as an example: com2 { driver = "name.of.device.driver.class"; config = new com.deviceco.rs485.Parameters( ... arguments to parameter construction ... ); } then the API would ask for the driver and configuration for device com2, and have all the things needed to make the correct device used with the correct configuration. Gregg Wonderly From fredm at alum.mit.edu Fri Jul 28 04:32:56 2006 From: fredm at alum.mit.edu (Fred G. Martin) Date: Fri, 28 Jul 2006 06:32:56 -0400 Subject: [Rxtx] precompiled for Intel Mac? Message-ID: Dear RXTX'ers, Would there be a precompiled binary of the older 2.0-7pre1 version (javax.comm namespace) rxtx for the Intel Mac platform? Would I just need the libSerial.jnilib file? Thank you, Fred From savagobr at yahoo.com Fri Jul 28 09:34:35 2006 From: savagobr at yahoo.com (Adenilson Cavalcanti) Date: Fri, 28 Jul 2006 08:34:35 -0700 (PDT) Subject: [Rxtx] Strange error (show stopper) - FC5 still ok! Message-ID: <20060728153435.41645.qmail@web53815.mail.yahoo.com> Friends I repeated the test, both undefining TIOCSERGETLSR in SerialImp.h as also adding a sleep in function 'interruptEventLoop' and it still is working fine. Later I can test it in pcbsd (based on FreeBSD 6) on my notebook. So far, I think that we can say that in Linux this error doesn't happen. Best regards Savago //------------------------------------------------------------------------ Result with #undef TIOCSERGETLSR 11:08:11:******* 1 interrupted thread for FD=51 PTR=-1321354040 CLOSING=0 11:08:11:******* 2 interrupted thread for FD=51 PTR=-1321354040 CLOSING=1 Result with usleep(50000) 11:14:57:******* 1 interrupted thread for FD=51 PTR=-1322914604 CLOSING=0 11:14:57:******* 2 interrupted thread for FD=51 PTR=-1322914604 CLOSING=1 --------------------------------- How low will we go? Check out Yahoo! Messenger?s low PC-to-Phone call rates. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060728/acd6aec1/attachment-0337.html From joachim at buechse.de Fri Jul 28 12:48:33 2006 From: joachim at buechse.de (Joachim Buechse) Date: Fri, 28 Jul 2006 20:48:33 +0200 Subject: [Rxtx] precompiled for Intel Mac? In-Reply-To: References: Message-ID: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> There will be. However not before we have figured out some remaining issues. Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 28.07.2006, at 12:32, Fred G. Martin wrote: > Dear RXTX'ers, > > Would there be a precompiled binary of the older 2.0-7pre1 version > (javax.comm namespace) rxtx for the Intel Mac platform? > > Would I just need the libSerial.jnilib file? > > Thank you, > Fred > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From fredm at alum.mit.edu Fri Jul 28 15:30:38 2006 From: fredm at alum.mit.edu (Fred G. Martin) Date: Fri, 28 Jul 2006 17:30:38 -0400 Subject: [Rxtx] precompiled for Intel Mac? In-Reply-To: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> References: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> Message-ID: <4616ED35-24BC-4FD3-90FB-81CAA851FB08@alum.mit.edu> May I ask another way--- can it [easily] be built from the 2.0-7pre1 sources? Fred On Jul 28, 2006, at 2:48 PM, Joachim Buechse wrote: > There will be. However not before we have figured out some remaining > issues. > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 28.07.2006, at 12:32, Fred G. Martin wrote: > >> Dear RXTX'ers, >> >> Would there be a precompiled binary of the older 2.0-7pre1 version >> (javax.comm namespace) rxtx for the Intel Mac platform? >> >> Would I just need the libSerial.jnilib file? >> >> Thank you, >> Fred >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Fri Jul 28 21:04:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 28 Jul 2006 21:04:45 -0600 (MDT) Subject: [Rxtx] precompiled for Intel Mac? In-Reply-To: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> References: <214D47A5-5058-4C3C-A8B0-1A9576F94643@buechse.de> Message-ID: On Fri, 28 Jul 2006, Joachim Buechse wrote: > There will be. However not before we have figured out some remaining > issues. > Joachim > Joachim and I are trying to get together to work out the remaining issues. I'll be looking at some w32 issues this weekend - a lovely job everyone should do exactly once. There are a few details that need attention. The summer vacation schedual is keeping things at a slow pace. This will be the first free weekend I've had in a while. I'm also gathering a list of things to do on Linux and Solaris which so far isn't too big but there are some that can be problems depending upon your use. Bugzilla is also your friend for bugs that are not getting attention right away. All bugs are interesting but sometimes forgotten on the mail list. I do go through all the bugs in bugzilla one by one now and then. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sat Jul 29 05:18:25 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 29 Jul 2006 07:18:25 -0400 Subject: [Rxtx] The new JSR and RS485 - Moderator Ruling In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: Hi All, It has been several days since I asked the below question. There has not been much in the way of response. Therefore, I am using my new-age radioactive mutant moderator super-powers to make a (non-final) decision that: 1. We can live with unofficial RS485 support for a while, 2. The JSR specification that we embark upon will focus on serial and parallel ports and 3. We may revisit the RS485 question, in the future. Thanks! - Doug Date: Wed, 26 Jul 2006 06:28:33 -0400 From: "Dr. Douglas Lyon" Subject: Should we defer JSR support of RS485? To: RXTX Developers and Users , lyon at docjava.com Original-recipient: rfc822;dlyon at optonline.net Hi All, Would it make sense to focus the JSR on rock solid serial and parallel port support? Can the RS485 people live with unofficial support, at least until we get the JSR accepted and the implementation rock solid? Thanks! - Doug From naranjo.manuel at gmail.com Sat Jul 29 07:59:10 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Sat, 29 Jul 2006 10:59:10 -0300 Subject: [Rxtx] The new JSR and RS485 - Moderator Ruling In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: <44CB69AE.8030104@gmail.com> +1 Totally agree, Manuel > Hi All, > > It has been several days since I asked the below question. > There has not been much in the way of response. > Therefore, I am using my new-age radioactive > mutant moderator super-powers to > make a (non-final) decision that: > 1. We can live with unofficial RS485 support for a while, > 2. The JSR specification that we embark upon will focus on > serial and parallel ports and > 3. We may revisit the RS485 question, in the future. > > Thanks! > - Doug > > > Date: Wed, 26 Jul 2006 06:28:33 -0400 > From: "Dr. Douglas Lyon" > Subject: Should we defer JSR support of RS485? > To: RXTX Developers and Users , lyon at docjava.com > Original-recipient: rfc822;dlyon at optonline.net > > Hi All, > > Would it make sense to focus the JSR on rock solid > serial and parallel port support? > > Can the RS485 people live with unofficial support, at least until > we get the JSR accepted and the implementation rock solid? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Sat Jul 29 14:21:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 29 Jul 2006 14:21:32 -0600 (MDT) Subject: [Rxtx] The new JSR and RS485 - Moderator Ruling In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: Hi Doug At this time, I agree. RS485 is interesting and I would be intested in participating in future discussions/plans with RS485. On Sat, 29 Jul 2006, Dr. Douglas Lyon wrote: > Hi All, > > It has been several days since I asked the below question. > There has not been much in the way of response. > Therefore, I am using my new-age radioactive > mutant moderator super-powers to > make a (non-final) decision that: > 1. We can live with unofficial RS485 support for a while, > 2. The JSR specification that we embark upon will focus on > serial and parallel ports and > 3. We may revisit the RS485 question, in the future. > > Thanks! > - Doug > > > Date: Wed, 26 Jul 2006 06:28:33 -0400 > From: "Dr. Douglas Lyon" > Subject: Should we defer JSR support of RS485? > To: RXTX Developers and Users , lyon at docjava.com > Original-recipient: rfc822;dlyon at optonline.net > > Hi All, > > Would it make sense to focus the JSR on rock solid > serial and parallel port support? > > Can the RS485 people live with unofficial support, at least until > we get the JSR accepted and the implementation rock solid? > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Sun Jul 30 04:28:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 30 Jul 2006 06:28:49 -0400 Subject: [Rxtx] interfaces vs. abstract classes Message-ID: Hi All, I was thinking that the new JSR might be more interface oriented and less abstract class oriented. For example, instead of subclassing CommPort, perhaps we should implement a CommPortInterface. How would this look? I don't know. But, perhaps, it would look something like this: package gnu.io; import java.io.InputStream; import java.io.IOException; import java.io.OutputStream; /** * User: lyon * Date: Jul 30, 2006 * Time: 5:19:55 AM * Copyright DocJava, Inc. 2005. */ public interface CommPortInterface { void enableReceiveFraming(int f) throws UnsupportedCommOperationException; void disableReceiveFraming(); boolean isReceiveFramingEnabled(); int getReceiveFramingByte(); void disableReceiveTimeout(); void enableReceiveTimeout(int time) throws UnsupportedCommOperationException; boolean isReceiveTimeoutEnabled(); int getReceiveTimeout(); void enableReceiveThreshold(int thresh) throws UnsupportedCommOperationException; void disableReceiveThreshold(); int getReceiveThreshold(); boolean isReceiveThresholdEnabled(); void setInputBufferSize(int size); int getInputBufferSize(); void setOutputBufferSize(int size); int getOutputBufferSize(); void close(); InputStream getInputStream() throws IOException; OutputStream getOutputStream() throws IOException; String getName(); } Then, we can use: /** * CommPort */ public abstract class CommPort implements CommPortInterface And replace uses of CommPort with uses of CommPortInterface.... package gnu.io; import java.io.FileDescriptor; /** * User: lyon * Date: Jul 30, 2006 * Time: 5:40:20 AM * Copyright DocJava, Inc. 2005. */ public interface CommPortIdentifierInterface { int PORT_SERIAL = 1; int PORT_PARALLEL = 2; int PORT_I2C = 3; int PORT_RS485 = 4; int PORT_RAW = 5; void addPortOwnershipListener(CommPortOwnershipListener c); String getCurrentOwner(); String getName(); int getPortType(); boolean isCurrentlyOwned(); CommPortInterface open(FileDescriptor f) throws UnsupportedCommOperationExce ption; CommPortInterface open(String TheOwner, int i) throws PortInUseException; void removePortOwnershipListener(CommPortOwnershipListener c); } If we continue in this vain, the SerialPort should have an interface that it implements, called (due to my lack of imagination) the SerialPortInterface package gnu.io; import java.util.TooManyListenersException; /** * User: lyon * Date: Jul 30, 2006 * Time: 5:56:35 AM * Copyright DocJava, Inc. 2005. */ public interface SerialPortInterface extends CommPortInterface { int DATABITS_5 = 5; int DATABITS_6 = 6; int DATABITS_7 = 7; int DATABITS_8 = 8; int PARITY_NONE = 0; int PARITY_ODD = 1; int PARITY_EVEN = 2; int PARITY_MARK = 3; int PARITY_SPACE = 4; int STOPBITS_1 = 1; int STOPBITS_2 = 2; int STOPBITS_1_5 = 3; int FLOWCONTROL_NONE = 0; int FLOWCONTROL_RTSCTS_IN = 1; int FLOWCONTROL_RTSCTS_OUT = 2; int FLOWCONTROL_XONXOFF_IN = 4; int FLOWCONTROL_XONXOFF_OUT = 8; void setSerialPortParams(int b, int d, int s, int p) throws UnsupportedCommOperationException; int getBaudRate(); int getDataBits(); int getStopBits(); int getParity(); void setFlowControlMode(int flowcontrol) throws UnsupportedCommOperationException; int getFlowControlMode(); boolean isDTR(); void setDTR(boolean state); void setRTS(boolean state); boolean isCTS(); boolean isDSR(); boolean isCD(); boolean isRI(); boolean isRTS(); void sendBreak(int duration); void addEventListener(SerialPortEventListener lsnr) throws TooManyListenersException; void removeEventListener(); void notifyOnDataAvailable(boolean enable); void notifyOnOutputEmpty(boolean enable); void notifyOnCTS(boolean enable); void notifyOnDSR(boolean enable); void notifyOnRingIndicator(boolean enable); void notifyOnCarrierDetect(boolean enable); void notifyOnOverrunError(boolean enable); void notifyOnParityError(boolean enable); void notifyOnFramingError(boolean enable); void notifyOnBreakInterrupt(boolean enable); byte getParityErrorChar() throws UnsupportedCommOperationException; boolean setParityErrorChar(byte b) throws UnsupportedCommOperationException; byte getEndOfInputChar() throws UnsupportedCommOperationException; boolean setEndOfInputChar(byte b) throws UnsupportedCommOperationException; boolean setUARTType(String type, boolean test) throws UnsupportedCommOperationException; String getUARTType() throws UnsupportedCommOperationException; boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException; int getBaudBase() throws UnsupportedCommOperationException; boolean setDivisor(int Divisor) throws UnsupportedCommOperationException; int getDivisor() throws UnsupportedCommOperationException; boolean setLowLatency() throws UnsupportedCommOperationException; boolean getLowLatency() throws UnsupportedCommOperationException; boolean setCallOutHangup(boolean NoHup) throws UnsupportedCommOperationException; boolean getCallOutHangup() throws UnsupportedCommOperationException; } And, of course, you need a parallel port: package gnu.io; import java.util.TooManyListenersException; /** * User: lyon * Date: Jul 30, 2006 * Time: 6:14:02 AM * Copyright DocJava, Inc. 2005. */ public interface ParallelPortInterface extends CommPortInterface { int LPT_MODE_ANY = 0; int LPT_MODE_SPP = 1; int LPT_MODE_PS2 = 2; int LPT_MODE_EPP = 3; int LPT_MODE_ECP = 4; int LPT_MODE_NIBBLE = 5; int getMode(); int setMode(int mode) throws UnsupportedCommOperationException; void restart(); void suspend(); boolean isPaperOut(); boolean isPrinterBusy(); boolean isPrinterError(); boolean isPrinterSelected(); boolean isPrinterTimedOut(); int getOutputBufferFree(); void addEventListener(ParallelPortEventListener lsnr) throws TooManyListenersException; void removeEventListener(); void notifyOnError(boolean enable); void notifyOnBuffer(boolean enable); } Now, I have refactored my code to take advantage of these interfaces. And have done very limited testing. The problem is that we have some static methods in classes like CommPortIdentifier that don't refactor into interfaces cleanly. I don't know what to do about that... What do people think about the idea of using interfaces rather than abstract classes for making the system a little more component oriented? Thanks! - Doug From tjarvi at qbang.org Sun Jul 30 10:13:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 30 Jul 2006 10:13:06 -0600 (MDT) Subject: [Rxtx] interfaces vs. abstract classes In-Reply-To: References: Message-ID: Hi Doug, I don't see a big advantage one way or another for the interfaces. One thing that should be added but not supported initially on all platforms is event notification of devices becomming physically available and vanishing. This is not the same as digging into USB. If the OS can provide a clean event driven method and provides a proper interface, it is of great use to people dealing with USB and Serial and Parallel Dongles. On Sun, 30 Jul 2006, Dr. Douglas Lyon wrote: > Hi All, > I was thinking that the new JSR might be more > interface oriented and less abstract class oriented. > > For example, instead of subclassing CommPort, perhaps > we should implement a CommPortInterface. > > How would this look? > > I don't know. But, perhaps, it would look something like this: > package gnu.io; > > import java.io.InputStream; > import java.io.IOException; > import java.io.OutputStream; > > /** > * User: lyon > * Date: Jul 30, 2006 > * Time: 5:19:55 AM > * Copyright DocJava, Inc. 2005. > */ > public interface CommPortInterface { > void enableReceiveFraming(int f) > throws UnsupportedCommOperationException; > > void disableReceiveFraming(); > > boolean isReceiveFramingEnabled(); > > int getReceiveFramingByte(); > > void disableReceiveTimeout(); > > void enableReceiveTimeout(int time) > throws UnsupportedCommOperationException; > > boolean isReceiveTimeoutEnabled(); > > int getReceiveTimeout(); > > void enableReceiveThreshold(int thresh) > throws UnsupportedCommOperationException; > > void disableReceiveThreshold(); > > int getReceiveThreshold(); > > boolean isReceiveThresholdEnabled(); > > void setInputBufferSize(int size); > > int getInputBufferSize(); > > void setOutputBufferSize(int size); > > int getOutputBufferSize(); > > void close(); > > InputStream getInputStream() throws IOException; > > OutputStream getOutputStream() throws IOException; > > String getName(); > } > > Then, we can use: > /** > * CommPort > */ > public abstract class CommPort implements CommPortInterface > > And replace uses of CommPort with uses of CommPortInterface.... > package gnu.io; > > import java.io.FileDescriptor; > > /** > * User: lyon > * Date: Jul 30, 2006 > * Time: 5:40:20 AM > * Copyright DocJava, Inc. 2005. > */ > public interface CommPortIdentifierInterface { > int PORT_SERIAL = 1; > int PORT_PARALLEL = 2; > int PORT_I2C = 3; > int PORT_RS485 = 4; > int PORT_RAW = 5; > > void addPortOwnershipListener(CommPortOwnershipListener c); > > String getCurrentOwner(); > > String getName(); > > int getPortType(); > > boolean isCurrentlyOwned(); > > CommPortInterface open(FileDescriptor f) throws > UnsupportedCommOperationExce > ption; > > CommPortInterface open(String TheOwner, int i) > throws PortInUseException; > > void removePortOwnershipListener(CommPortOwnershipListener c); > } > > If we continue in this vain, the SerialPort should have an interface that > it implements, called (due to my lack of imagination) the SerialPortInterface > > package gnu.io; > > import java.util.TooManyListenersException; > > /** > * User: lyon > * Date: Jul 30, 2006 > * Time: 5:56:35 AM > * Copyright DocJava, Inc. 2005. > */ > public interface SerialPortInterface extends CommPortInterface { > int DATABITS_5 = 5; > int DATABITS_6 = 6; > int DATABITS_7 = 7; > int DATABITS_8 = 8; > int PARITY_NONE = 0; > int PARITY_ODD = 1; > int PARITY_EVEN = 2; > int PARITY_MARK = 3; > int PARITY_SPACE = 4; > int STOPBITS_1 = 1; > int STOPBITS_2 = 2; > int STOPBITS_1_5 = 3; > int FLOWCONTROL_NONE = 0; > int FLOWCONTROL_RTSCTS_IN = 1; > int FLOWCONTROL_RTSCTS_OUT = 2; > int FLOWCONTROL_XONXOFF_IN = 4; > int FLOWCONTROL_XONXOFF_OUT = 8; > > void setSerialPortParams(int b, int d, int s, int p) > throws UnsupportedCommOperationException; > > int getBaudRate(); > > int getDataBits(); > > int getStopBits(); > > int getParity(); > > void setFlowControlMode(int flowcontrol) > throws UnsupportedCommOperationException; > > int getFlowControlMode(); > > boolean isDTR(); > > void setDTR(boolean state); > > void setRTS(boolean state); > > boolean isCTS(); > > boolean isDSR(); > > boolean isCD(); > > boolean isRI(); > > boolean isRTS(); > > void sendBreak(int duration); > > void addEventListener(SerialPortEventListener lsnr) > throws TooManyListenersException; > > void removeEventListener(); > > void notifyOnDataAvailable(boolean enable); > > void notifyOnOutputEmpty(boolean enable); > > void notifyOnCTS(boolean enable); > > void notifyOnDSR(boolean enable); > > void notifyOnRingIndicator(boolean enable); > > void notifyOnCarrierDetect(boolean enable); > > void notifyOnOverrunError(boolean enable); > > void notifyOnParityError(boolean enable); > > void notifyOnFramingError(boolean enable); > > void notifyOnBreakInterrupt(boolean enable); > > byte getParityErrorChar() > throws UnsupportedCommOperationException; > > boolean setParityErrorChar(byte b) > throws UnsupportedCommOperationException; > > byte getEndOfInputChar() > throws UnsupportedCommOperationException; > > boolean setEndOfInputChar(byte b) > throws UnsupportedCommOperationException; > > boolean setUARTType(String type, boolean test) > throws UnsupportedCommOperationException; > > String getUARTType() > throws UnsupportedCommOperationException; > > boolean setBaudBase(int BaudBase) > throws UnsupportedCommOperationException; > > int getBaudBase() > throws UnsupportedCommOperationException; > > boolean setDivisor(int Divisor) > throws UnsupportedCommOperationException; > > int getDivisor() > throws UnsupportedCommOperationException; > > boolean setLowLatency() > throws UnsupportedCommOperationException; > > boolean getLowLatency() > throws UnsupportedCommOperationException; > > boolean setCallOutHangup(boolean NoHup) > throws UnsupportedCommOperationException; > > boolean getCallOutHangup() > throws UnsupportedCommOperationException; > } > > And, of course, you need a parallel port: > package gnu.io; > > import java.util.TooManyListenersException; > > /** > * User: lyon > * Date: Jul 30, 2006 > * Time: 6:14:02 AM > * Copyright DocJava, Inc. 2005. > */ > public interface ParallelPortInterface extends CommPortInterface { > int LPT_MODE_ANY = 0; > int LPT_MODE_SPP = 1; > int LPT_MODE_PS2 = 2; > int LPT_MODE_EPP = 3; > int LPT_MODE_ECP = 4; > int LPT_MODE_NIBBLE = 5; > > int getMode(); > > int setMode(int mode) > throws UnsupportedCommOperationException; > > void restart(); > > void suspend(); > > boolean isPaperOut(); > > boolean isPrinterBusy(); > > boolean isPrinterError(); > > boolean isPrinterSelected(); > > boolean isPrinterTimedOut(); > > int getOutputBufferFree(); > > void addEventListener(ParallelPortEventListener lsnr) > throws TooManyListenersException; > > void removeEventListener(); > > void notifyOnError(boolean enable); > > void notifyOnBuffer(boolean enable); > } > > Now, I have refactored my code to take advantage of these interfaces. > And have done very limited testing. The problem is that we have some > static methods in > classes like CommPortIdentifier that don't refactor into interfaces cleanly. > > I don't know what to do about that... > > What do people think about the idea of using interfaces rather than > abstract classes for making the system a little more component oriented? > > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From berkland at spamcop.net Sun Jul 30 15:15:59 2006 From: berkland at spamcop.net (Doug Berkland) Date: Sun, 30 Jul 2006 17:15:59 -0400 Subject: [Rxtx] interfaces vs. abstract classes In-Reply-To: <269e40090607301408q41759906k6e45f0dd33618655@mail.gmail.com> References: <269e40090607301408q41759906k6e45f0dd33618655@mail.gmail.com> Message-ID: <269e40090607301415p3238e51eyce4b124f385c1918@mail.gmail.com> I think the interfaces are a good idea. They will allow more flexibility if someone needs to create a modified implementation. I just hope that all of this will end up in the javax.comm package instead of gnu.io. From gergg at cox.net Sun Jul 30 16:30:37 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 30 Jul 2006 17:30:37 -0500 Subject: [Rxtx] interfaces vs. abstract classes In-Reply-To: <269e40090607301415p3238e51eyce4b124f385c1918@mail.gmail.com> References: <269e40090607301408q41759906k6e45f0dd33618655@mail.gmail.com> <269e40090607301415p3238e51eyce4b124f385c1918@mail.gmail.com> Message-ID: <44CD330D.20608@cox.net> Doug Berkland wrote: > I think the interfaces are a good idea. They will allow more > flexibility if someone needs to create a modified implementation. I > just hope that all of this will end up in the javax.comm package > instead of gnu.io. You can provide an abstract class that implements the interface, but defers on the implementation details to allow porting parties the ability to reuse common code with less variations on the behavior that users experience. Please don't include anything in the interface that can't be described in 100% accuracy and perform identically on all possible ports, or throw a well described compatibility exception. Gregg Wonderly From lyon at docjava.com Sun Jul 30 17:27:13 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 30 Jul 2006 19:27:13 -0400 Subject: [Rxtx] interfaces vs abstract classes Message-ID: Hi All, If you ever want to use serial ports with RMI, a nice set of interfaces will be required. On the other hand, perhaps nobody wants that. On the other, other hand, there are some areas where we could really use some API clean-up. This could be a chance to shape the JSR with really clean interfaces with well defined semantics and some good Javadoc. For example: I2CPort, RS485Port and SerialPort all begin with duplicate code. We can put all the constants in a nice interface, as appears below. I have added a little Javadoc. Would someone like to finish it up? So far, I have not added any new features, other than documentation and refactoring. >More importantly is the philosophical start point for a >specification in a JSR; >that is speaking to the future: >Interfaces describe capabilities; >Classes implement capabilities; Methods execute capabilities. >In the long run, a plug-in based system can be used to substitute >implementation >but retain the use of the interface. > >So, use inheritance for internal code reuse and interfaces for >contract definition. > >As the famous GoF book says: > >Prefer interfaces over inheritance. > >Use interfaces as a design-time resource when you are planning your system. >It is almost always useful to define a contract of functionality for >a given set of features. Clients of such a contract should never >have to bother with details of actual implementations. - DL public interface SerialPortInterface extends CommPortInterface { int DATABITS_5 = 5; int DATABITS_6 = 6; int DATABITS_7 = 7; int DATABITS_8 = 8; int PARITY_NONE = 0; int PARITY_ODD = 1; int PARITY_EVEN = 2; int PARITY_MARK = 3; int PARITY_SPACE = 4; int STOPBITS_1 = 1; int STOPBITS_2 = 2; int STOPBITS_1_5 = 3; int FLOWCONTROL_NONE = 0; int FLOWCONTROL_RTSCTS_IN = 1; int FLOWCONTROL_RTSCTS_OUT = 2; int FLOWCONTROL_XONXOFF_IN = 4; int FLOWCONTROL_XONXOFF_OUT = 8; /** * @return true if the DTR bit is set. * * @see #setDTR */ boolean isCTS(); /** * @return true if the DTR bit is set. * */ boolean isDSR(); /** * @return true if the CD bit is set. * */ boolean isCD(); /** * @return true if the RI bit is set. * */ boolean isRI(); /** * @return true if the RTS bit is set. * * @see #setRTS */ boolean isRTS(); /** would someone like to write some nice javadoc for the following? */ void addEventListener(SerialPortEventListener lsnr) throws TooManyListenersException; void removeEventListener(); void notifyOnDataAvailable(boolean enable); void notifyOnOutputEmpty(boolean enable); void notifyOnCTS(boolean enable); void notifyOnDSR(boolean enable); void notifyOnRingIndicator(boolean enable); void notifyOnCarrierDetect(boolean enable); void notifyOnOverrunError(boolean enable); void notifyOnParityError(boolean enable); void notifyOnFramingError(boolean enable); void notifyOnBreakInterrupt(boolean enable); byte getParityErrorChar() throws UnsupportedCommOperationException; boolean setParityErrorChar(byte b) throws UnsupportedCommOperationException; byte getEndOfInputChar() throws UnsupportedCommOperationException; boolean setEndOfInputChar(byte b) throws UnsupportedCommOperationException; boolean setUARTType(String type, boolean test) throws UnsupportedCommOperationException; String getUARTType() throws UnsupportedCommOperationException; boolean setBaudBase(int BaudBase) throws UnsupportedCommOperationException; int getBaudBase() throws UnsupportedCommOperationException; boolean setDivisor(int Divisor) throws UnsupportedCommOperationException; int getDivisor() throws UnsupportedCommOperationException; boolean setLowLatency() throws UnsupportedCommOperationException; boolean getLowLatency() throws UnsupportedCommOperationException; boolean setCallOutHangup(boolean NoHup) throws UnsupportedCommOperationException; boolean getCallOutHangup() throws UnsupportedCommOperationException; /** * @return the current baud rate */ int getBaudRate(); /** * @return the current number of data bits: DATABITS_5, DATABITS_6, * DATABITS_7, or DATABITS_8. */ int getDataBits(); /** * @return the current number of stop bits: STOPBITS_1, STOPBITS_2, or * STOPBITS_1_5. */ int getStopBits(); /** * @return the current parity scheme: PARITY_NONE, PARITY_ODD, * PARITY_EVEN, PARITY_MARK or PARITY_SPACE. */ int getParity(); /** * Sends a break of the specified duration. * * @param millis the duration in milliseconds */ void sendBreak(int millis); /** * Sets the flow control mode. * * @param flowcontrol a bitmask combination of FLOWCONTROL_NONE, * FLOWCONTROL_RTSCTS_IN, FLOWCONTROL_RTSCTS_OUT, * FLOWCONTROL_XONXOFF_IN, and/or FLOWCONTROL_XONXOFF_OUT. */ void setFlowControlMode(int flowcontrol); /** * @return the current flow control mode as a bitmask of * FLOWCONTROL_NONE, FLOWCONTROL_RTSCTS_IN, FLOWCONTROL_RTSCTS_OUT, * FLOWCONTROL_XONXOFF_IN, and/or FLOWCONTROL_XONXOFF_OUT. */ int getFlowControlMode(); /** * Set the Receive Fifo trigger level. * If the UART has a FIFO and if it can have programmable trigger * levels, then this method will cause the UART to raise an interrupt * after trigger bytes have been received. * * @param trigger the trigger level * @deprecated */ void setRcvFifoTrigger(int trigger); /** * Sets the serial port parameters. * * @param baudRate the baud rate * @param dataBits the number of data bits: DATABITS_5, * DATABITS_6, DATABITS_7, or DATABITS_8 * @param stopBits the number of stop bits: STOPBITS_1, * STOPBITS_2, or STOPBITS_1_5 * @param parity the parity schema: PARITY_NONE, PARITY_ODD, * PARITY_EVEN, PARITY_MARK or PARITY_SPACE * @throws UnsupportedCommOperationException */ void setSerialPortParams(int baudRate, int dataBits, int stopBits, int parity) throws UnsupportedCommOperationException; /** * Sets or clears the DTR bit in the UART. * * @param dtr the Data Terminal Ready bit value * @see #isDTR */ void setDTR(boolean dtr); /** * @return true if the DTR bit is set. * * @see #setDTR */ boolean isDTR(); /** * Sets or clears the RTS bit in the UART. * * @param rts the Request To Send bit value */ void setRTS(boolean rts); } Here is the CommPortInterface: public interface CommPortInterface { /** * @return the name of this port. * */ String getName(); /** * @return a string representation of this port. */ String toString(); /** * @return an input stream that can be used to read data from the * communications port. If the port doesn't support reading data, this * method returns null. *

* The blocking behaviour of this input stream depends on the threshold * and timeout values, as shown below for a read buffer size of n * bytes: * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ThresholdTimeoutBlocking behaviour
StateValueStateValue
disableddisabledblock until data is available
enabledm bytesdisabledblock until min(m, n) bytes are available
disabledenabledt msblock for t ms or until data is available
enabledm bytesenabledt msblock for t ms or until min(m, n) bytes are * available
* @throws java.io.IOException */ InputStream getInputStream() throws IOException; /** * @return an output stream that can be used to send data to the * communications port. If the port doesn't support sending data, this * method returns null. * @throws java.io.IOException */ OutputStream getOutputStream() throws IOException; /** * Closes this communications port. Further methods on this object will * throw IllegalStateException. All PortOwnershipListeners will be * notified of this change of ownership. */ void close(); /** * Enables receive threshold. * When the specified threshold number of bytes are retrieved, read will * return immediately. * * @param thresh the number of bytes in the input buffer * @throws UnsupportedCommOperationException * if receive threshold is * not supported by the driver * @see #disableReceiveThreshold */ void enableReceiveThreshold(int thresh) throws UnsupportedCommOperationException; /** * Disables receive threshold. * * @see #enableReceiveThreshold */ void disableReceiveThreshold(); /** * @return true if receive threshold is enabled. * * @see #enableReceiveThreshold */ boolean isReceiveThresholdEnabled(); /** * @return the receive threshold value. If receive threshold is diabled * or not supported, this value is meaningless. * * @see #enableReceiveThreshold */ int getReceiveThreshold(); /** * Enables receive timeout. * When the specified number of milliseconds have elapsed, read will * return immediately. * * @param rcvTimeout the number of milliseconds to block for * @throws UnsupportedCommOperationException * if receive timeout is * not supported by the driver * @see #disableReceiveTimeout */ void enableReceiveTimeout(int rcvTimeout) throws UnsupportedCommOperationException; /** * Disables receive timeout. * * @see #enableReceiveTimeout */ void disableReceiveTimeout(); /** * @return true if receive timeout is enabled. * * @see #enableReceiveTimeout */ boolean isReceiveTimeoutEnabled(); /** * @return the receive timeout value. If receive timeout is diabled * or not supported, this value is meaningless. * * @see #enableReceiveTimeout */ int getReceiveTimeout(); /** * Enables receive framing. * The supplied byte value in the input suggests the end of the received * frame, and read returns immediately. Only the low 8 bits of the * supplied value are significant. * * @param framingByte the frame delimiter * @throws UnsupportedCommOperationException * if receive framing is * not supported by the driver * @see #disableReceiveFraming */ void enableReceiveFraming(int framingByte) throws UnsupportedCommOperationException; /** * Disables receive framing. * * @see #enableReceiveFraming */ void disableReceiveFraming(); /** * @return true if receive framing is enabled. * * @see #enableReceiveFraming */ boolean isReceiveFramingEnabled(); /** * @return true if receive framing byte. If receive framing is disabled * or not supported, this value is meaningless. * * @see #enableReceiveFraming */ int getReceiveFramingByte(); /** * Sets the input buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setInputBufferSize(int size); /** * @return the input buffer size. * The driver may choose not to report correct values. */ int getInputBufferSize(); /** * Sets the output buffer size. * The driver may choose to ignore this method. * @param size in bytes */ void setOutputBufferSize(int size); /** * @return the output buffer size. * The driver may choose not to report correct values. */ int getOutputBufferSize(); } From tjarvi at qbang.org Sun Jul 30 17:43:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 30 Jul 2006 17:43:13 -0600 (MDT) Subject: [Rxtx] RMI In-Reply-To: References: Message-ID: On Sun, 30 Jul 2006, Dr. Douglas Lyon wrote: > Hi All, > > If you ever want to use serial ports with RMI, > a nice set of interfaces will be required. > So this would eventually lead to j2ee beans and such. The security model would have to be examined for this. Often there are tens of thousands of dollars in instrumentation or even cash drawers/POS sitting on the other end of the cable. A serial port should be no less secure than a hard drive. I think security is going to be OK but then we are opening up for a bunch of questions about how to get it working. That puts us in a position of answering how to bypass security with RMI to access hard drives [or serial ports]. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Sun Jul 30 21:48:01 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 30 Jul 2006 22:48:01 -0500 Subject: [Rxtx] RMI In-Reply-To: References: Message-ID: <44CD7D71.2080306@cox.net> Trent Jarvi wrote: > On Sun, 30 Jul 2006, Dr. Douglas Lyon wrote: >>If you ever want to use serial ports with RMI, >>a nice set of interfaces will be required. > > So this would eventually lead to j2ee beans and such. > > The security model would have to be examined for this. Often there are > tens of thousands of dollars in instrumentation or even cash drawers/POS > sitting on the other end of the cable. > > A serial port should be no less secure than a hard drive. I think > security is going to be OK but then we are opening up for a bunch of > questions about how to get it working. > > That puts us in a position of answering how to bypass security with RMI to > access hard drives [or serial ports]. This really depends on whether you want those streams to be visible remotely, directly or not. I think that it is poor engineering practice for any Remote access to directly expose the raw hardware/stream/data. You need to have choices on how to transport and encapsulate data streams. This is the power of the RMI programming model. Mobile code can put computational activities on the client instead of the server. The next generation of RMI, with all of the security features you need was developed by the original RMI team and some others, and is the Jini Extensible Remote Invocation (JERI) stack that is available in Jini 2.0 and later versions (http://www.jini.org and http://starterkit.dev.java.net). One of the primary things that JERI provides is an authentication and authorization mechanism that is activated at deployment time, instead of being coded into the libraries. Gregg Wonderly From guille at sms.nl Mon Jul 31 03:17:29 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Mon, 31 Jul 2006 11:17:29 +0200 Subject: [Rxtx] interfaces vs. abstract classes In-Reply-To: References: Message-ID: <7.0.1.0.0.20060731111659.0363b620@sms.nl> At 12:28 30/07/2006, Dr. Douglas Lyon wrote: >Hi All, >I was thinking that the new JSR might be more >interface oriented and less abstract class oriented. > >For example, instead of subclassing CommPort, perhaps >we should implement a CommPortInterface. > >How would this look? Will it break backwards compatibility? Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From lyon at docjava.com Mon Jul 31 04:57:39 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 31 Jul 2006 06:57:39 -0400 Subject: [Rxtx] Rxtx RMI/SSL In-Reply-To: <44CD7D71.2080306@cox.net> References: <44CD7D71.2080306@cox.net> Message-ID: Hi All, Networked based serial ports are a nice option for java clients that do not need (or want) native method drivers installed. Applications include web-controlled robotics, network-based modems, auto-dialing addressbooks (remote dialers), remote sensing, etc. If you are behind a firewall, you may not feel the need for RMI/SSL security. After all, hacking into a serial port behind a firewall does seem a bit over-the-top. On the other hand, for those who feel they want to go over the Internet; I have been playing around with RMI over SSL. Here is a paper on the topic: http://show.docjava.com:8086/pub/document/jot/rjs.pdf Remote Job Submission Security by Pawel Krepstzul and Douglas A. Lyon, in Journal of Object Technology, vol. 5, no. 1, Janurary-February 2006, pp. 13-29. From the programmer point-of-view the SSL part is not quite transparent, but, given proper diligence, can be made somewhat secure. Naturally, you can put the exchange in a high-level of abstraction. I guess it really depends on the application. The question of how level-of-abstraction impacts security, remains open. You may observe a trend toward RMI based API's by looking at JAI (Java Advanced Imaging). Cheers! - Doug >Trent Jarvi wrote: >> On Sun, 30 Jul 2006, Dr. Douglas Lyon wrote: >>>If you ever want to use serial ports with RMI, >>>a nice set of interfaces will be required. >> >> So this would eventually lead to j2ee beans and such. >> >> The security model would have to be examined for this. Often there are >> tens of thousands of dollars in instrumentation or even cash drawers/POS >> sitting on the other end of the cable. >> >> A serial port should be no less secure than a hard drive. I think >> security is going to be OK but then we are opening up for a bunch of >> questions about how to get it working. >> >> That puts us in a position of answering how to bypass security with RMI to >> access hard drives [or serial ports]. > >This really depends on whether you want those streams to be visible remotely, >directly or not. I think that it is poor engineering practice for any Remote >access to directly expose the raw hardware/stream/data. You need to have >choices on how to transport and encapsulate data streams. This is >the power of >the RMI programming model. Mobile code can put computational >activities on the >client instead of the server. > >The next generation of RMI, with all of the security features you need was >developed by the original RMI team and some others, and is the Jini Extensible >Remote Invocation (JERI) stack that is available in Jini 2.0 and >later versions >(http://www.jini.org and http://starterkit.dev.java.net). > >One of the primary things that JERI provides is an authentication and >authorization mechanism that is activated at deployment time, instead of being >coded into the libraries. > >Gregg Wonderly >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Mon Jul 31 07:16:51 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 31 Jul 2006 15:16:51 +0200 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> Message-ID: <1154351811.44ce02c3a5539@webmail.eatserver.nl> Hi Doug, I understand. Note that we are not only concerned about source compatibility, but also about binary compatibility (which would be preserved as well with this approach if I understood correctly) Best regards, Guillermo Quoting "Dr. Douglas Lyon" : > Hi All, > At present I have a prototype version of the libraries that I am > testing that contains the Interfaces, with growing Javadoc. > I have been refactoring my code to take advantage of these > interfaces, but, in the interest of backward compatibility, > have left the abstract classes, for those who want to continue > to use and test them. So there is 100% backward compatibility. > > My goal is to identify the features of the class specification and > provide good documentation for them. I think this is seen most clearly in > the below code. This has ZERO impact on existing code that > seeks to make use of the CommPort class. > > I am adding interfaces and documentation to arrive at a specification. > Abstract methods and constants move from the abstract class into the > interface, but then the abstract class implements the interface. > > To the API user, it should have no effect. > > Cheers! > - Doug > > > public interface CommPortIdentifierInterface { > > int PORT_I2C = 3; > int PORT_RS485 = 4; > int PORT_RAW = 5; > /** > * RS-232 serial port. > */ > int PORT_SERIAL = 1; > /** > * IEEE 1284 parallel port. > */ > int PORT_PARALLEL = 2; > > > > /** > * @return the port name, typically an OS-dependent hardware label. > * > */ > String getName(); > > /** > * @return the port type, PORT_SERIAL or PORT_PARALLEL. > */ > int getPortType() > ; > > /** > * @return the current owner of this port. > */ > String getCurrentOwner() > ; > > /** > * @return true if this port is currently owned. > */ > boolean isCurrentlyOwned() ; > > /** > * @return communications port. > * If the port is in use by another application, it will be notified > * with a PORT_OWNERSHIP_REQUESTED event. If the current owner closes > * the port, then this method will succeed. Otherwise a > * PortInUseException will be thrown. > * @param appName the name of the application requesting the port > * @param timeout number of miliseconds to wait for the port to open > * @throws PortInUseException > */ > CommPortInterface open(String appName, int timeout) > throws PortInUseException; > > /** > * @return a port using a file descriptor. > * @param fd the file descriptor > * @exception UnsupportedCommOperationException if the platform does > not > * support this functionality > */ > CommPortInterface open(FileDescriptor fd) > throws UnsupportedCommOperationException; > > /** > * Adds the specified listener to the list of ownership listeners for > * this port. > * @param listener the ownership listener to add > */ > void addPortOwnershipListener(CommPortOwnershipListener listener); > > /** > * Removes the specified listener from the list of ownership listeners > for > * this port. > * @param listener the ownership listener to remove > */ > void removePortOwnershipListener(CommPortOwnershipListener listener); > } > public abstract class CommPort implements CommPortInterface { > protected String name; > private final static boolean debug = false; > > public void close() { > if (debug) System.out.println("CommPort:close()"); > > try { > CommPortIdentifierInterface cp = > CommPortIdentifier.getPortIdentifier(this); > if (cp != null) > > CommPortIdentifier.getPortIdentifier(this).internalClosePort(); > } > catch (NoSuchPortException e) { > e.printStackTrace(); > } > } > > public String getName() { > if (debug) System.out.println("CommPort:getName()"); > return (name); > } > > public String toString() { > if (debug) System.out.println("CommPort:toString()"); > return (name); > } > } > >At 12:28 30/07/2006, Dr. Douglas Lyon wrote: > >>Hi All, > >>I was thinking that the new JSR might be more > >>interface oriented and less abstract class oriented. > >> > >>For example, instead of subclassing CommPort, perhaps > >>we should implement a CommPortInterface. > >> > >>How would this look? > > > >Will it break backwards compatibility? > > > >Guillermo > >-- > >Guillermo Rodriguez Garcia > > > >Snijder Micro Systems phone +31-493-351020 > >G. Rodriguez Garcia fax +31-493-351530 > >Visser 25 email guille at sms.nl > >NL5751 BL Deurne > >The Netherlands http://www.snijder.com > > -- http://www.snijder.com/ SNIJDER Micro Systems From lyon at docjava.com Mon Jul 31 07:44:29 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 31 Jul 2006 09:44:29 -0400 Subject: [Rxtx] Do interfaces break backwards BINARY compatibility? Welcome to the serial ports of tomorrow! In-Reply-To: <1154351811.44ce02c3a5539@webmail.eatserver.nl> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> Message-ID: Hi All, The jar file, comm.jar, will change in the sense that there will be new byte codes for Interfaces and the abstract classes byte codes will change. However, the native methods are left unchanged. The goal is to specify "what is" via interfaces, minimizing the impact on the API. This enables RXTX to be a reference implementation of the interface specification. If the JSR is accepted and the interfaces become a part of the javax.comm package, then rxtx could implement the javax.comm specification. Thus, my VISION of the FUTURE (ta da): javax.comm programmers code to the javax.comm interfaces and use a factory method to get an RXTX-based driver. Does that sort of make sense? Thanks! - Doug >Hi Doug, > >I understand. Note that we are not only concerned about source >compatibility, but also about binary compatibility (which would be >preserved as well with this approach if I understood correctly) > >Best regards, >Guillermo > >Quoting "Dr. Douglas Lyon" : > >> Hi All, >> At present I have a prototype version of the libraries that I am >> testing that contains the Interfaces, with growing Javadoc. >> I have been refactoring my code to take advantage of these >> interfaces, but, in the interest of backward compatibility, >> have left the abstract classes, for those who want to continue >> to use and test them. So there is 100% backward compatibility. >> >> My goal is to identify the features of the class specification and >> provide good documentation for them. I think this is seen most clearly in >> the below code. This has ZERO impact on existing code that >> seeks to make use of the CommPort class. >> >> I am adding interfaces and documentation to arrive at a specification. >> Abstract methods and constants move from the abstract class into the >> interface, but then the abstract class implements the interface. >> >> To the API user, it should have no effect. >> >> Cheers! >> - Doug >> >> >> public interface CommPortIdentifierInterface { >> >> int PORT_I2C = 3; >> int PORT_RS485 = 4; >> int PORT_RAW = 5; >> /** >> * RS-232 serial port. >> */ >> int PORT_SERIAL = 1; >> /** >> * IEEE 1284 parallel port. >> */ >> int PORT_PARALLEL = 2; >> >> >> >> /** >> * @return the port name, typically an OS-dependent hardware label. >> * >> */ >> String getName(); >> >> /** >> * @return the port type, PORT_SERIAL or PORT_PARALLEL. >> */ >> int getPortType() >> ; >> >> /** >> * @return the current owner of this port. >> */ >> String getCurrentOwner() >> ; >> >> /** >> * @return true if this port is currently owned. >> */ >> boolean isCurrentlyOwned() ; >> >> /** >> * @return communications port. >> * If the port is in use by another application, it will be notified >> * with a PORT_OWNERSHIP_REQUESTED event. If the current owner closes >> * the port, then this method will succeed. Otherwise a >> * PortInUseException will be thrown. >> * @param appName the name of the application requesting the port >> * @param timeout number of miliseconds to wait for the port to open >> * @throws PortInUseException >> */ >> CommPortInterface open(String appName, int timeout) >> throws PortInUseException; >> >> /** >> * @return a port using a file descriptor. >> * @param fd the file descriptor >> * @exception UnsupportedCommOperationException if the platform does >> not >> * support this functionality >> */ >> CommPortInterface open(FileDescriptor fd) >> throws UnsupportedCommOperationException; >> >> /** >> * Adds the specified listener to the list of ownership listeners for >> * this port. >> * @param listener the ownership listener to add >> */ >> void addPortOwnershipListener(CommPortOwnershipListener listener); > > >> /** >> * Removes the specified listener from the list of ownership listeners >> for >> * this port. >> * @param listener the ownership listener to remove >> */ >> void removePortOwnershipListener(CommPortOwnershipListener listener); >> } >> public abstract class CommPort implements CommPortInterface { >> protected String name; >> private final static boolean debug = false; >> >> public void close() { >> if (debug) System.out.println("CommPort:close()"); >> >> try { >> CommPortIdentifierInterface cp = >> CommPortIdentifier.getPortIdentifier(this); >> if (cp != null) >>???????????????? >> CommPortIdentifier.getPortIdentifier(this).internalClosePort(); >> } >> catch (NoSuchPortException e) { >> e.printStackTrace(); >> } >> } >> >> public String getName() { >> if (debug) System.out.println("CommPort:getName()"); >> return (name); >> } >> >> public String toString() { >> if (debug) System.out.println("CommPort:toString()"); >> return (name); >> } >> } >> >At 12:28 30/07/2006, Dr. Douglas Lyon wrote: >> >>Hi All, >> >>I was thinking that the new JSR might be more >> >>interface oriented and less abstract class oriented. >> >> >> >>For example, instead of subclassing CommPort, perhaps >> >>we should implement a CommPortInterface. >> >> >> >>How would this look? >> > >> >Will it break backwards compatibility? >> > >> >Guillermo >> >-- >> >Guillermo Rodriguez Garcia >> > >> >Snijder Micro Systems phone +31-493-351020 >> >G. Rodriguez Garcia fax +31-493-351530 >> >Visser 25 email guille at sms.nl >> >NL5751 BL Deurne >> >The Netherlands http://www.snijder.com >> >> > > >-- >http://www.snijder.com/ >SNIJDER Micro Systems From berkland at spamcop.net Mon Jul 31 07:57:50 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 31 Jul 2006 09:57:50 -0400 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <1154351811.44ce02c3a5539@webmail.eatserver.nl> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> Message-ID: <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> Adding interfaces does not break any kind of compatibility. Java is more forgiving when it comes to this kind of change than languages that are compiled into native code. As long as the implementing class has the same name, same package, and all of the same methods (with the same signatures) you can add on anything you wish, including implementing additional interfaces. On 7/31/06, Guillermo Rodriguez wrote: > Hi Doug, > > I understand. Note that we are not only concerned about source > compatibility, but also about binary compatibility (which would be > preserved as well with this approach if I understood correctly) > > Best regards, > Guillermo From gergg at cox.net Mon Jul 31 08:12:20 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 31 Jul 2006 09:12:20 -0500 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> Message-ID: <44CE0FC4.9010307@cox.net> Doug Berkland wrote: > Adding interfaces does not break any kind of compatibility. Java is > more forgiving when it comes to this kind of change than languages > that are compiled into native code. As long as the implementing class > has the same name, same package, and all of the same methods (with the > same signatures) you can add on anything you wish, including > implementing additional interfaces. Check the Serialization compatibility guidelines for more information on exactly what binary compatibility requires, and what things can change in an interface and/or class which won't break things. Gregg Wonderly From berkland at spamcop.net Mon Jul 31 09:13:00 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 31 Jul 2006 11:13:00 -0400 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <44CE0FC4.9010307@cox.net> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> <44CE0FC4.9010307@cox.net> Message-ID: <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> As far as I can tell, nothing in either RXTX or Sun's JavaCOMM implements Serializable. Therefore, there are no worries from that either. (I can't think of a reason anything in JavaCOMM should implement Serializable either.) On 7/31/06, Gregg Wonderly wrote: > Doug Berkland wrote: > > Adding interfaces does not break any kind of compatibility. Java is > > more forgiving when it comes to this kind of change than languages > > that are compiled into native code. As long as the implementing class > > has the same name, same package, and all of the same methods (with the > > same signatures) you can add on anything you wish, including > > implementing additional interfaces. > > Check the Serialization compatibility guidelines for more information on exactly > what binary compatibility requires, and what things can change in an interface > and/or class which won't break things. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From berkland at spamcop.net Mon Jul 31 09:20:48 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 31 Jul 2006 11:20:48 -0400 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> <44CE0FC4.9010307@cox.net> <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> Message-ID: <269e40090607310820s15f2eee8j903e077917d7fc72@mail.gmail.com> Correction: Nothing except the classes extending Exception and Event implement Serializable. On 7/31/06, Doug Berkland wrote: > As far as I can tell, nothing in either RXTX or Sun's JavaCOMM > implements Serializable. Therefore, there are no worries from that > either. (I can't think of a reason anything in JavaCOMM should > implement Serializable either.) > > On 7/31/06, Gregg Wonderly wrote: > > Doug Berkland wrote: > > > Adding interfaces does not break any kind of compatibility. Java is > > > more forgiving when it comes to this kind of change than languages > > > that are compiled into native code. As long as the implementing class > > > has the same name, same package, and all of the same methods (with the > > > same signatures) you can add on anything you wish, including > > > implementing additional interfaces. > > > > Check the Serialization compatibility guidelines for more information on exactly > > what binary compatibility requires, and what things can change in an interface > > and/or class which won't break things. > > > > Gregg Wonderly > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > From gergg at cox.net Mon Jul 31 11:21:19 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 31 Jul 2006 12:21:19 -0500 Subject: [Rxtx] Do interfaces break backwards compatibility? In-Reply-To: <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> References: <7.0.1.0.0.20060731111659.0363b620@sms.nl> <1154351811.44ce02c3a5539@webmail.eatserver.nl> <269e40090607310657o3373b966o36f971586f1455ec@mail.gmail.com> <44CE0FC4.9010307@cox.net> <269e40090607310813y3dda307eh9e35ec3f050d1dbe@mail.gmail.com> Message-ID: <44CE3C0F.3080408@cox.net> Doug Berkland wrote: > As far as I can tell, nothing in either RXTX or Sun's JavaCOMM > implements Serializable. Therefore, there are no worries from that > either. (I can't think of a reason anything in JavaCOMM should > implement Serializable either.) Any interface in javax.comm can become implemented by a serializable object. Thus, if someone wants to provide remote access to a serial port, then they might (and I think this is not wise) choose to subclass and add Serializable to the interface list. It's that kind of Serialization compatibility that I'm talking about. Gregg Wonderly From rwelty at suespammers.org Mon Jul 31 19:53:12 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Mon, 31 Jul 2006 21:53:12 -0400 Subject: [Rxtx] Application Name? Message-ID: <44CEB408.7040407@suespammers.org> trying to get my app running on a Mac OS X powerbook, when the following is executed as the first thing inside the run method of a Thread: try { port = (SerialPort) selectedPort.open( this.getClass().getName(), 2000); } catch ( PortInUseException ex){ ex.printStackTrace(); return; } i get the following: gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at com.krusty_motorsports.scale.monitor.ScaleWatcher.run(ScaleWatcher.java:143) i've not seen any documentation suggesting that rxtx would be finicky about application names... thanks for any suggestions, richard From stevebeemonkey at monkey-media.co.uk Wed Jul 5 05:59:02 2006 From: stevebeemonkey at monkey-media.co.uk (steve@monkey-media.co.uk) Date: Wed, 5 Jul 2006 04:59:02 -0700 Subject: [Rxtx] No output on WinXP Message-ID: <1152100742.44aba986565e7@www.webmail.ezpublishing.com> Hi there, I've installed RXTX 2.1.7 under Win XP, copying the .jar and .dll files according to the instructions given. I've changed the javax.comm import to gnu.io, but when I run the following code the only output I get is: Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Then the program ends, without listing any of the ports. What am I doing wrong? Cheers, Steve Here's my code: ---------------------------------------- import gnu.io.*; import java.util.*; public class PortList { public static void main(String [] args) { Enumeration portList = CommPortIdentifier.getPortIdentifiers(); while(portList.hasMoreElements()) { CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); if( portId.getPortType() == CommPortIdentifier.PORT_SERIAL) { System.out.println("Serial port: " + portId.getName()); } else if (portId.getPortType() == CommPortIdentifier.PORT_PARALLEL) { System.out.println("Parallel port: " + portId.getName()); } else System.out.println("Other port: " + portId.getName()); } } } ------------------------------- From tjarvi at qbang.org Wed Jul 5 07:57:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 5 Jul 2006 07:57:22 -0600 (MDT) Subject: [Rxtx] No output on WinXP In-Reply-To: <1152100742.44aba986565e7@www.webmail.ezpublishing.com> References: <1152100742.44aba986565e7@www.webmail.ezpublishing.com> Message-ID: On Wed, 5 Jul 2006, steve at monkey-media.co.uk wrote: > > > Hi there, > > I've installed RXTX 2.1.7 under Win XP, copying the .jar and .dll files > according to the instructions given. > > I've changed the javax.comm import to gnu.io, but when I run the following code > the only output I get is: > > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > Then the program ends, without listing any of the ports. > > What am I doing wrong? > > Cheers, > > Steve > > Here's my code: > > ---------------------------------------- > > import gnu.io.*; > import java.util.*; > > public class PortList > { > public static void main(String [] args) > { > Enumeration portList = CommPortIdentifier.getPortIdentifiers(); > > while(portList.hasMoreElements()) { > CommPortIdentifier portId = (CommPortIdentifier)portList.nextElement(); > if( portId.getPortType() == > CommPortIdentifier.PORT_SERIAL) > { > System.out.println("Serial port: " + > portId.getName()); > } else if (portId.getPortType() == > CommPortIdentifier.PORT_PARALLEL) > { > System.out.println("Parallel port: " + > portId.getName()); > } else > System.out.println("Other port: " + > portId.getName()); > } > } > } > > ------------------------------- > If you have a port open with another terminal such as hyperterminal or even another copy of your application using rxtx, the port will not be enumerated. rxtx enumerates ports by opening prospective ports and doing a timed out read. If the port is open by another application, the open will fail. -- Trent Jarvi tjarvi at qbang.org From Pawan.Kharbanda at dot.state.co.us Wed Jul 5 15:44:05 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Wed, 5 Jul 2006 15:44:05 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EA89@hqexchange3.dot.state.co.us> Trent, I did put some debug statements and the "index" returned to me in the while loop is "0" (see the code below) and it gets into the infinite loop, I can put a break statement but don't know the ramifications of it. Can you explain in what scenarios the index can be "0" or are we somehow in the native code loosing refrences to the indexes? Thanks Again Pawan Kharbanda while( searching ) { index = master_index; if( index ) { while( index->fd != fd && index->next ) index = index->next; if ( index->fd == fd ) searching = 0; } else report("Index"+index"x"); <<<<<< The code gets to this statement and index is returned as "0" and I don't see anyway to break out of this looop after. if( searching ) { report("@"); usleep(1000); } } -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, June 29, 2006 6:21 AM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports > Here is how you can test if you have resources/ test environment. > Write a program and try to open/close different ports(I will say have > a minimum of four) randomly and very frequently(may be 30 seconds), I > am pretty sure you will see the deadlocks and it happens in the native > call to interrptEventLoop in RXTXPort.java in removeEventListener() > method call. Hi Pawan I'll try to find a way to reproduce this. One thing to note is that you are using different kernel drivers (digi) to perform this task. So I probably will not be able to reproduce the exact same environment. In general, multiport kernel drivers have been tested far less than typical serial drivers. This may or may not be an issue. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From Pawan.Kharbanda at dot.state.co.us Wed Jul 5 18:50:01 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Wed, 5 Jul 2006 18:50:01 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EA96@hqexchange3.dot.state.co.us> Trent, Sorry for so many emails, but as I mentioned earlier I will write a test to replicate the Locking problem. I am attaching a Java file to replicate the problem. You need atleast 4-5 ports to simulate the problem. Here is how to run the program. In the TestOpenClosePort.java please change the Serial Ports names(Add the ports installed on your machine). Then compile your java file and run as "java TestOpenClosePort 100" (100 is the no of times you want to open and close the port in one single thread). I have tested this with the Digi Boxes and able to replicate this over and over in Single JVM. Hope this test helps track down the problem. Thanks Pawan Kharbanda -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, June 29, 2006 6:21 AM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports > Here is how you can test if you have resources/ test environment. > Write a program and try to open/close different ports(I will say have > a minimum of four) randomly and very frequently(may be 30 seconds), I > am pretty sure you will see the deadlocks and it happens in the native > call to interrptEventLoop in RXTXPort.java in removeEventListener() > method call. Hi Pawan I'll try to find a way to reproduce this. One thing to note is that you are using different kernel drivers (digi) to perform this task. So I probably will not be able to reproduce the exact same environment. In general, multiport kernel drivers have been tested far less than typical serial drivers. This may or may not be an issue. -- Trent Jarvi tjarvi at qbang.org _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- A non-text attachment was scrubbed... Name: TestOpenClosePort.java Type: application/octet-stream Size: 6038 bytes Desc: TestOpenClosePort.java Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060705/82f8488f/TestOpenClosePort-0361.obj From tjarvi at qbang.org Wed Jul 5 22:48:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 5 Jul 2006 22:48:52 -0600 (MDT) Subject: [Rxtx] Locked Ports In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3EA89@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03F3EA89@hqexchange3.dot.state.co.us> Message-ID: On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did put some debug statements and the "index" returned to me in > the while loop is "0" (see the code below) and it gets into the infinite > loop, I can put a break statement but don't know the ramifications of > it. Can you explain in what scenarios the index can be "0" or are we > somehow in the native code loosing refrences to the indexes? > > Thanks Again > Pawan Kharbanda > > while( searching ) > { > index = master_index; > > if( index ) > { > while( index->fd != fd && > index->next ) index = index->next; > if ( index->fd == fd ) searching = 0; > } > else > report("Index"+index"x"); <<<<<< The code gets > to this statement and index is returned as "0" and I don't see anyway to > break out of this looop after. > if( searching ) > { > report("@"); > usleep(1000); > } > } > Hi Pawan I am reading with interest :) So it sounds like this is a thread safe problem. The thing I don't understand here is open and close are synchronized in RXTXPort.java. I thought that would prevent any thread problems with the linked list. Looking closer, the linked list is actually populated in eventLoop/MonitorThread which is not synchronized. So you may be able to synchronize on an object in RXTXPort.java. A seperate native call would probably be required for the initalization to prevent a deadlock. A solution might involve making finalize_event_info_struct() and initialise_event_info_struct() [uk spelling?] thread safe with glib. http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads.html#id2786034 glib also has more robust linked lists which could be used. Thats the indirectly the problem found in termios.c for windows. The disadvantage is we would require linking to glib which is another step for systems that don't come with it. The advantage would be reduced code size we have to maintain. We could borrow bits of glib as the licenses are the same. Another solution might be to just use pthread_mutex_lock and unlock. http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html I don't think that would work on windows though. It would require linking cygwin.dll which would not work with nonGPL projects in practice. -- Trent Jarvi tjarvi From neville_seed at yahoo.com Thu Jul 6 06:42:29 2006 From: neville_seed at yahoo.com (neville seed) Date: Thu, 6 Jul 2006 05:42:29 -0700 (PDT) Subject: [Rxtx] port to palm OS? Message-ID: <20060706124230.55790.qmail@web51015.mail.yahoo.com> hello. Has rxtx been ported to PalmOS? regards neville __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From neville_seed at yahoo.com Thu Jul 6 06:43:44 2006 From: neville_seed at yahoo.com (neville seed) Date: Thu, 6 Jul 2006 05:43:44 -0700 (PDT) Subject: [Rxtx] example code Message-ID: <20060706124344.5063.qmail@web51013.mail.yahoo.com> hello. Could anyone provide me with example code of how to read from the serial port. regards neville __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From naranjo.manuel at gmail.com Thu Jul 6 06:48:20 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Thu, 06 Jul 2006 09:48:20 -0300 Subject: [Rxtx] port to palm OS? In-Reply-To: <20060706124230.55790.qmail@web51015.mail.yahoo.com> References: <20060706124230.55790.qmail@web51015.mail.yahoo.com> Message-ID: <44AD0694.1090703@gmail.com> neville seed wrote: > hello. > > Has rxtx been ported to PalmOS? > > regards > neville > I'm interested on this. Do you need rxtx ported to J2ME or to Superwaba?. Superwaba has it owns implementation of a serial port, but it is not rxtx. Regards, Manuel From joachim at buechse.de Thu Jul 6 07:20:57 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 6 Jul 2006 15:20:57 +0200 Subject: [Rxtx] port to palm OS? In-Reply-To: <20060706124230.55790.qmail@web51015.mail.yahoo.com> References: <20060706124230.55790.qmail@web51015.mail.yahoo.com> Message-ID: Which version of PalmOS are you targeting? I have been doing some Java on PalmOS programming for the Palm Vx using the JVM from Esmertec. The problem there was, that PalmOS can only process one kernel call at a time (it is (was?) not a multithreading OS). Threads were implemented by the VM. In a situation like this, any kind of "abort" mechanism is very difficult to handle - from what I know about the RXTX code and the way close() would have to be implemented it's the same as rewriting RXTX. Newer versions of PalmOS might have improved in this respect... Best regards, Joachim On 06.07.2006, at 14:42, neville seed wrote: > hello. > > Has rxtx been ported to PalmOS? > > regards > neville > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From neville_seed at yahoo.com Thu Jul 6 08:23:29 2006 From: neville_seed at yahoo.com (neville seed) Date: Thu, 6 Jul 2006 07:23:29 -0700 (PDT) Subject: [Rxtx] port to palm OS? In-Reply-To: Message-ID: <20060706142329.91625.qmail@web51005.mail.yahoo.com> The palmOS would be version 5.x however i am new to both palm and java. As such I would have to find out any questions. --- Joachim Buechse wrote: > Which version of PalmOS are you targeting? > > I have been doing some Java on PalmOS programming > for the Palm Vx > using the JVM from Esmertec. The problem there was, > that PalmOS can > only process one kernel call at a time (it is (was?) > not a > multithreading OS). Threads were implemented by the > VM. In a > situation like this, any kind of "abort" mechanism > is very difficult > to handle - from what I know about the RXTX code and > the way close() > would have to be implemented it's the same as > rewriting RXTX. Newer > versions of PalmOS might have improved in this > respect... > > Best regards, > Joachim > > On 06.07.2006, at 14:42, neville seed wrote: > > > hello. > > > > Has rxtx been ported to PalmOS? > > > > regards > > neville > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From jhaysonn at gmail.com Thu Jul 6 08:58:07 2006 From: jhaysonn at gmail.com (jhaysonn pathak) Date: Thu, 6 Jul 2006 10:58:07 -0400 Subject: [Rxtx] RXTX install (jhaysonn pathak) Message-ID: Thanks for the install tip. I figured out how to do the cvs update, but in my MACOSX_IDE dir I didn't have any Xcode folders and searching my computer, I only have 3 Xcode folders (one for application support, one for Max/MSP and one in developer tools). I have tried building each of the different *.xcodeproj files and in eachone they have little toolbox looking items that are in red (i assume that means it can't find them). Some of them I manage to locate but some of them just aren't on my computer. In any event, I still can't find the libserial.jnilib. After the update I read the README.OSX and it did make it seem a lot easier, but for the future, if I finally create a libserial.jnilib I don't know what the 'JavaVM' is in reference to this line "Put libSerial.jnilib in the directory of the application (the JavaVM will find it there). Add RXTXComm.jar to the application classpath or include the classes in the application jar. (Some applications already include the RXTX classes in their application jar, in which case only the file libSerial.jnilib is required)." PS - How do I uninstall everything RXTX so that I can try and re-download and re-install everything? From joachim at buechse.de Thu Jul 6 09:12:24 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 6 Jul 2006 17:12:24 +0200 Subject: [Rxtx] RXTX install (jhaysonn pathak) In-Reply-To: References: Message-ID: <98F15662-544D-41B5-8229-BB1DB6B6FD43@buechse.de> The Java VM ist the Java Virtual Machine. It runs your application. For the rest of your message ... your description is much to unprecise to help. To start, you could describe what IS in the MACOSX_IDE folder and its subfolders. On 06.07.2006, at 16:58, jhaysonn pathak wrote: > Thanks for the install tip. I figured out how to do the cvs update, > but in my MACOSX_IDE dir I didn't have any Xcode folders and searching > my computer, I only have 3 Xcode folders (one for application support, > one for Max/MSP and one in developer tools). I have tried building > each of the different *.xcodeproj files and in eachone they have > little toolbox looking items that are in red (i assume that means it > can't find them). Some of them I manage to locate but some of them > just aren't on my computer. In any event, I still can't find the > libserial.jnilib. > > After the update I read the README.OSX and it did make it seem a lot > easier, but for the future, if I finally create a libserial.jnilib I > don't know what the 'JavaVM' is in reference to this line > > "Put > libSerial.jnilib > in the directory of the application (the JavaVM will find it > there). Add > RXTXComm.jar > to the application classpath or include the classes in the > application jar. > (Some applications already include the RXTX classes in their > application jar, > in which case only the file libSerial.jnilib is required)." > > PS - How do I uninstall everything RXTX so that I can try and > re-download and re-install everything? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jul 6 09:20:16 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 6 Jul 2006 17:20:16 +0200 Subject: [Rxtx] RXTX install (jhaysonn pathak) In-Reply-To: References: Message-ID: <8F03CA0E-44F4-434F-AA7E-3A8B5054AA6F@buechse.de> Rethinking about your problem... I think you should try a cvs up -d Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 06.07.2006, at 16:58, jhaysonn pathak wrote: > Thanks for the install tip. I figured out how to do the cvs update, > but in my MACOSX_IDE dir I didn't have any Xcode folders and searching > my computer, I only have 3 Xcode folders (one for application support, > one for Max/MSP and one in developer tools). I have tried building > each of the different *.xcodeproj files and in eachone they have > little toolbox looking items that are in red (i assume that means it > can't find them). Some of them I manage to locate but some of them > just aren't on my computer. In any event, I still can't find the > libserial.jnilib. > > After the update I read the README.OSX and it did make it seem a lot > easier, but for the future, if I finally create a libserial.jnilib I > don't know what the 'JavaVM' is in reference to this line > > "Put > libSerial.jnilib > in the directory of the application (the JavaVM will find it > there). Add > RXTXComm.jar > to the application classpath or include the classes in the > application jar. > (Some applications already include the RXTX classes in their > application jar, > in which case only the file libSerial.jnilib is required)." > > PS - How do I uninstall everything RXTX so that I can try and > re-download and re-install everything? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Thu Jul 6 10:19:17 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Thu, 06 Jul 2006 13:19:17 -0300 Subject: [Rxtx] port to palm OS? In-Reply-To: <20060706142329.91625.qmail@web51005.mail.yahoo.com> References: <20060706142329.91625.qmail@web51005.mail.yahoo.com> Message-ID: <44AD3805.3010609@gmail.com> neville seed wrote: > The palmOS would be version 5.x however i am new to > both palm and java. As such I would have to find out > any questions. > Hello if you are new you could use Superwaba, url: www.superwaba.com, which is not exactly Java but works great, and has a serial port. If you need any more info please let me know. Manuel From Pawan.Kharbanda at dot.state.co.us Thu Jul 6 12:49:50 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 6 Jul 2006 12:49:50 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EB11@hqexchange3.dot.state.co.us> Trent, I did made the eventLoop() call in the Monitor Thread synchronized, it improved but still see the same problem. Your comment > A solution might involve making finalize_event_info_struct() and > initialise_event_info_struct() [uk spelling?] thread safe with glib. I didn't follow this how I can implement this. I am not a C guy, can you help me understand how I can implement this? Thanks Pawan Kharbanda -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Wednesday, July 05, 2006 10:49 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did put some debug statements and the "index" returned to me in > the while loop is "0" (see the code below) and it gets into the > infinite loop, I can put a break statement but don't know the > ramifications of it. Can you explain in what scenarios the index can > be "0" or are we somehow in the native code loosing refrences to the indexes? > > Thanks Again > Pawan Kharbanda > > while( searching ) > { > index = master_index; > > if( index ) > { > while( index->fd != fd && > index->next ) index = index->next; > if ( index->fd == fd ) searching = 0; > } > else > report("Index"+index"x"); <<<<<< The code gets to this statement > and index is returned as "0" and I don't see anyway to break out of > this looop after. > if( searching ) > { > report("@"); > usleep(1000); > } > } > Hi Pawan I am reading with interest :) So it sounds like this is a thread safe problem. The thing I don't understand here is open and close are synchronized in RXTXPort.java. I thought that would prevent any thread problems with the linked list. Looking closer, the linked list is actually populated in eventLoop/MonitorThread which is not synchronized. So you may be able to synchronize on an object in RXTXPort.java. A seperate native call would probably be required for the initalization to prevent a deadlock. A solution might involve making finalize_event_info_struct() and initialise_event_info_struct() [uk spelling?] thread safe with glib. http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. html#id2786034 glib also has more robust linked lists which could be used. Thats the indirectly the problem found in termios.c for windows. The disadvantage is we would require linking to glib which is another step for systems that don't come with it. The advantage would be reduced code size we have to maintain. We could borrow bits of glib as the licenses are the same. Another solution might be to just use pthread_mutex_lock and unlock. http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html I don't think that would work on windows though. It would require linking cygwin.dll which would not work with nonGPL projects in practice. -- Trent Jarvi tjarvi _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From zhanglong at adventnet.com Wed Jul 5 20:44:18 2006 From: zhanglong at adventnet.com (zhanglong) Date: Thu, 06 Jul 2006 10:44:18 +0800 Subject: [Rxtx] rxtx can not read data from serialport Message-ID: <44AC7902.8070407@adventnet.com> Dear sir, When I use rxrx2.1-7-bin-r2?I can write data into serialport,But can not read data from serialport on windowsXP. I can not write and read data from serialport on Redhat Linux9.0. I can get serialport list on my machine.And no error with open serialport. I can get and read data from serialport on windowsXP with SUN's javacomm20-win32.zip. How can I read data on windows and write,read data on Linux with rxtx? Best Regards, Zhanglong From tjarvi at qbang.org Thu Jul 6 19:07:13 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 19:07:13 -0600 (MDT) Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: <44AC7902.8070407@adventnet.com> References: <44AC7902.8070407@adventnet.com> Message-ID: On Thu, 6 Jul 2006, zhanglong wrote: > Dear sir, > > When I use rxrx2.1-7-bin-r2??I can write data into serialport,But can > not read data from serialport on windowsXP. > I can not write and read data from serialport on Redhat Linux9.0. > I can get serialport list on my machine.And no error with open serialport. > > I can get and read data from serialport on windowsXP with SUN's > javacomm20-win32.zip. > > How can I read data on windows and write,read data on Linux with rxtx? > > Hi Zhanglong Make sure that you specify the flow control, timeout and threshold that you want. The defaults may vary between rxtx and Sun. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jul 6 19:10:25 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 19:10:25 -0600 (MDT) Subject: [Rxtx] Controlling Individual Signals DTR and RTS In-Reply-To: References: Message-ID: On Thu, 29 Jun 2006, Chris Pine wrote: > Dear Moussa Ba, > I hope I am not being too forward, but we are having the exact same > issue with needing to control DTR from RXTX in Linux. Did you ever have any > luck figuring it out? > > Thank you very much for your time, > Hi Chris Are you using an unusual serial port? It could be that the port does not support DTR/RTS. Especially if its an inexpensive USB->Serial dongle. I'll double check Linux tomorrow but I'm fairly sure it works. I have verified windows after a questions like yours. Some multiport cards and usb dongles do not support everything. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Thu Jul 6 19:17:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 19:17:09 -0600 (MDT) Subject: [Rxtx] Locked Ports In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3EB11@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03F3EB11@hqexchange3.dot.state.co.us> Message-ID: Hi Pawan There is an example of doing this in the link I provided below. They make a pointer to the function they want to be thread safe and then use that with the glib functions. I'm not ready to just toss out a quick hack because I'd like to think through this a bit to make sure I understand what types of problems we may run into. The code still hung in the same place after synchronizing the eventLoop? I think that eventLoop needs to be refactored to pull out the initialization code so people do not need to run the monitor. On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did made the eventLoop() call in the Monitor Thread synchronized, it > improved but still see the same problem. > > Your comment >> A solution might involve making finalize_event_info_struct() and >> initialise_event_info_struct() [uk spelling?] thread safe with glib. > > I didn't follow this how I can implement this. I am not a C guy, can you > help me understand how I can implement this? > > Thanks > Pawan Kharbanda > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Wednesday, July 05, 2006 10:49 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] Locked Ports > > On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > >> Trent, >> I did put some debug statements and the "index" returned to me in >> the while loop is "0" (see the code below) and it gets into the >> infinite loop, I can put a break statement but don't know the >> ramifications of it. Can you explain in what scenarios the index can >> be "0" or are we somehow in the native code loosing refrences to the > indexes? >> >> Thanks Again >> Pawan Kharbanda >> >> while( searching ) >> { >> index = master_index; >> >> if( index ) >> { >> while( index->fd != fd && >> index->next ) index = index->next; >> if ( index->fd == fd ) searching = 0; >> } >> else >> report("Index"+index"x"); <<<<<< The code gets > to this statement >> and index is returned as "0" and I don't see anyway to break out of >> this looop after. >> if( searching ) >> { >> report("@"); >> usleep(1000); >> } >> } >> > > Hi Pawan > > I am reading with interest :) > > So it sounds like this is a thread safe problem. > > The thing I don't understand here is open and close are synchronized in > RXTXPort.java. I thought that would prevent any thread problems with > the linked list. Looking closer, the linked list is actually populated > in eventLoop/MonitorThread which is not synchronized. > > So you may be able to synchronize on an object in RXTXPort.java. A > seperate native call would probably be required for the initalization to > prevent a deadlock. > > A solution might involve making finalize_event_info_struct() and > initialise_event_info_struct() [uk spelling?] thread safe with glib. > > http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. > html#id2786034 > > glib also has more robust linked lists which could be used. Thats the > indirectly the problem found in termios.c for windows. The disadvantage > is we would require linking to glib which is another step for systems > that don't come with it. The advantage would be reduced code size we > have to maintain. We could borrow bits of glib as the licenses are the > same. > > Another solution might be to just use pthread_mutex_lock and unlock. > > http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html > > I don't think that would work on windows though. It would require > linking cygwin.dll which would not work with nonGPL projects in > practice. > > -- > Trent Jarvi > tjarvi > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Pawan.Kharbanda at dot.state.co.us Thu Jul 6 21:46:08 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Thu, 6 Jul 2006 21:46:08 -0600 Subject: [Rxtx] Locked Ports Message-ID: <939A619A756047469C41EE9BA51890FB03F3EB35@hqexchange3.dot.state.co.us> Trent, Just curious to know if you were able to replicate the problem with my example? Pawan -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Trent Jarvi Sent: Thursday, July 06, 2006 7:17 PM To: RXTX Developers and Users Subject: Re: [Rxtx] Locked Ports Hi Pawan There is an example of doing this in the link I provided below. They make a pointer to the function they want to be thread safe and then use that with the glib functions. I'm not ready to just toss out a quick hack because I'd like to think through this a bit to make sure I understand what types of problems we may run into. The code still hung in the same place after synchronizing the eventLoop? I think that eventLoop needs to be refactored to pull out the initialization code so people do not need to run the monitor. On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > Trent, > I did made the eventLoop() call in the Monitor Thread synchronized, > it improved but still see the same problem. > > Your comment >> A solution might involve making finalize_event_info_struct() and >> initialise_event_info_struct() [uk spelling?] thread safe with glib. > > I didn't follow this how I can implement this. I am not a C guy, can > you help me understand how I can implement this? > > Thanks > Pawan Kharbanda > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Wednesday, July 05, 2006 10:49 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] Locked Ports > > On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: > >> Trent, >> I did put some debug statements and the "index" returned to me in >> the while loop is "0" (see the code below) and it gets into the >> infinite loop, I can put a break statement but don't know the >> ramifications of it. Can you explain in what scenarios the index can >> be "0" or are we somehow in the native code loosing refrences to the > indexes? >> >> Thanks Again >> Pawan Kharbanda >> >> while( searching ) >> { >> index = master_index; >> >> if( index ) >> { >> while( index->fd != fd && >> index->next ) index = index->next; >> if ( index->fd == fd ) searching = 0; >> } >> else >> report("Index"+index"x"); <<<<<< The code gets > to this statement >> and index is returned as "0" and I don't see anyway to break out of >> this looop after. >> if( searching ) >> { >> report("@"); >> usleep(1000); >> } >> } >> > > Hi Pawan > > I am reading with interest :) > > So it sounds like this is a thread safe problem. > > The thing I don't understand here is open and close are synchronized > in RXTXPort.java. I thought that would prevent any thread problems > with the linked list. Looking closer, the linked list is actually > populated in eventLoop/MonitorThread which is not synchronized. > > So you may be able to synchronize on an object in RXTXPort.java. A > seperate native call would probably be required for the initalization > to prevent a deadlock. > > A solution might involve making finalize_event_info_struct() and > initialise_event_info_struct() [uk spelling?] thread safe with glib. > > http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. > html#id2786034 > > glib also has more robust linked lists which could be used. Thats the > indirectly the problem found in termios.c for windows. The > disadvantage is we would require linking to glib which is another step > for systems that don't come with it. The advantage would be reduced > code size we have to maintain. We could borrow bits of glib as the > licenses are the same. > > Another solution might be to just use pthread_mutex_lock and unlock. > > http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html > > I don't think that would work on windows though. It would require > linking cygwin.dll which would not work with nonGPL projects in > practice. > > -- > Trent Jarvi > tjarvi > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Thu Jul 6 21:53:49 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 6 Jul 2006 21:53:49 -0600 (MDT) Subject: [Rxtx] Locked Ports In-Reply-To: <939A619A756047469C41EE9BA51890FB03F3EB35@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB03F3EB35@hqexchange3.dot.state.co.us> Message-ID: Pawan: I'm sure I can reproduce the problem. What you have described makes very good sense and has changed how I think about rxtx. 64 ports. Take your design specs and write 'open source' on them. On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > Trent, > Just curious to know if you were able to replicate the problem > with my example? > > Pawan > > -----Original Message----- > From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > Of Trent Jarvi > Sent: Thursday, July 06, 2006 7:17 PM > To: RXTX Developers and Users > Subject: Re: [Rxtx] Locked Ports > > > Hi Pawan > > There is an example of doing this in the link I provided below. They > make a pointer to the function they want to be thread safe and then use > that with the glib functions. > > I'm not ready to just toss out a quick hack because I'd like to think > through this a bit to make sure I understand what types of problems we > may run into. > > The code still hung in the same place after synchronizing the eventLoop? > > > > > I think that eventLoop needs to be refactored to pull out the > initialization code so people do not need to run the monitor. > > On Thu, 6 Jul 2006, Kharbanda, Pawan wrote: > >> Trent, >> I did made the eventLoop() call in the Monitor Thread synchronized, >> it improved but still see the same problem. >> >> Your comment >>> A solution might involve making finalize_event_info_struct() and >>> initialise_event_info_struct() [uk spelling?] thread safe with glib. >> >> I didn't follow this how I can implement this. I am not a C guy, can >> you help me understand how I can implement this? >> >> Thanks >> Pawan Kharbanda >> >> -----Original Message----- >> From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf > >> Of Trent Jarvi >> Sent: Wednesday, July 05, 2006 10:49 PM >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] Locked Ports >> >> On Wed, 5 Jul 2006, Kharbanda, Pawan wrote: >> >>> Trent, >>> I did put some debug statements and the "index" returned to me in >>> the while loop is "0" (see the code below) and it gets into the >>> infinite loop, I can put a break statement but don't know the >>> ramifications of it. Can you explain in what scenarios the index can >>> be "0" or are we somehow in the native code loosing refrences to the >> indexes? >>> >>> Thanks Again >>> Pawan Kharbanda >>> >>> while( searching ) >>> { >>> index = master_index; >>> >>> if( index ) >>> { >>> while( index->fd != fd && >>> index->next ) index = index->next; >>> if ( index->fd == fd ) searching = 0; >>> } >>> else >>> report("Index"+index"x"); <<<<<< The code gets >> to this statement >>> and index is returned as "0" and I don't see anyway to break out of >>> this looop after. >>> if( searching ) >>> { >>> report("@"); >>> usleep(1000); >>> } >>> } >>> >> >> Hi Pawan >> >> I am reading with interest :) >> >> So it sounds like this is a thread safe problem. >> >> The thing I don't understand here is open and close are synchronized >> in RXTXPort.java. I thought that would prevent any thread problems >> with the linked list. Looking closer, the linked list is actually >> populated in eventLoop/MonitorThread which is not synchronized. >> >> So you may be able to synchronize on an object in RXTXPort.java. A >> seperate native call would probably be required for the initalization >> to prevent a deadlock. >> >> A solution might involve making finalize_event_info_struct() and >> initialise_event_info_struct() [uk spelling?] thread safe with glib. >> >> > http://www.mhatt.aps.anl.gov/dohn/programming/gtk-2.0/glib/glib-Threads. >> html#id2786034 >> >> glib also has more robust linked lists which could be used. Thats the > >> indirectly the problem found in termios.c for windows. The >> disadvantage is we would require linking to glib which is another step > >> for systems that don't come with it. The advantage would be reduced >> code size we have to maintain. We could borrow bits of glib as the >> licenses are the same. >> >> Another solution might be to just use pthread_mutex_lock and unlock. >> >> http://yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html >> >> I don't think that would work on windows though. It would require >> linking cygwin.dll which would not work with nonGPL projects in >> practice. >> >> -- >> Trent Jarvi >> tjarvi >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pascal at quies.net Fri Jul 7 08:45:59 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Fri, 7 Jul 2006 16:45:59 +0200 Subject: [Rxtx] Java installer Message-ID: <200607071645.59765.pascal@quies.net> Hello everybody, We need a *simple* installer for the RXTX extension. I'm working on a pure Java installer right now. Let's get this thing working over the weekend. The license of choise is the modified BSD license. My plan is to make a JAR with: * the RXTX binaries * a simple API to detect any installed version * a simple Swing installer * a executeable detector: java -jar communicationapi.jar detect javax.comm * a executable installer: java -jar communicationapi.jar install gnu.io * Java 1.2 compatible Comments? _The Java API_: class CommunicationAPI { CommunicationAPI() CommunicationAPI(String path) boolean available() boolean supportsRS232() boolean supportsRS485() boolean supportsI2C() boolean supportsIEEE1280() static void main(String[] args) static boolean installRXTX(boolean headless) } Comments? To get this working we need binaries. Who is having what? The package from the official site has the following: * Linux: i686, x86_64, ia64 * Solaris: sparc32, sparc64 * Windows: i386 Now that's a start. I had to modify the code (what a mess!) to get it working on OpenBSD but I don't have the time to get it working for every platform. Any help here? From j.a.horsmeier at wanadoo.nl Fri Jul 7 09:11:24 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Fri, 7 Jul 2006 17:11:24 +0200 Subject: [Rxtx] Java installer In-Reply-To: <200607071645.59765.pascal@quies.net> Message-ID: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> > Pascal S. de Kloe wrote: > We need a *simple* installer for the RXTX extension. > I'm working on a pure Java installer right now. Let's get > this thing working > over the weekend. The license of choise is the modified BSD license. > > My plan is to make a JAR with: > * the RXTX binaries > * a simple API to detect any installed version > * a simple Swing installer > * a executeable detector: java -jar communicationapi.jar > detect javax.comm > * a executable installer: java -jar communicationapi.jar > install gnu.io > * Java 1.2 compatible > > Comments? Have a look at IzPack: http://www.izforge.com/izpack/ I use it all the time to install rxtx as part of our application. kind regards, Jos From brian at mbari.org Fri Jul 7 10:01:27 2006 From: brian at mbari.org (Brian Schlining) Date: Fri, 7 Jul 2006 09:01:27 -0700 Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: <44AC7902.8070407@adventnet.com> References: <44AC7902.8070407@adventnet.com> Message-ID: On Jul 5, 2006, at 7:44 PM, zhanglong wrote: > Dear sir, > > When I use rxrx2.1-7-bin-r2?I can write data into serialport,But can > not read data from serialport on windowsXP. > I can not write and read data from serialport on Redhat Linux9.0. > I can get serialport list on my machine.And no error with open > serialport. > > I can get and read data from serialport on windowsXP with SUN's > javacomm20-win32.zip. > > How can I read data on windows and write,read data on Linux with rxtx? On windows, if all else fails you may need to use this flow control: serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_IN); Also, for some command/response applications that I've tried with RXTX, I find that if I write to the serialport and then immediately try to read from it I get byte arrays filled with zeros, no matter what I set the recieveTimeout to (this has occurred on both Mac OS X and Windows). The workaround that I found was to very briefly put the I/O thread to sleep, like so: // DO set up and get I/O streams //in = serialPort.getInputStream(); //out = serialPort.getOutputStream(); out.write(someByteArray); try { Thread.sleep(10); catch (InterruptedException e) { // handle exception } in.read(anotherByteArray); Note: I've never had to put the thread to sleep using Java comm, only with RXTX. Anyone know why this might be? Cheers B Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060707/f0799573/attachment-0359.html From pascal at quies.net Fri Jul 7 16:55:03 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 00:55:03 +0200 Subject: [Rxtx] Java installer In-Reply-To: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> Message-ID: <200607080055.04501.pascal@quies.net> Op vrijdag 7 juli 2006 17:11, schreef Jos A. Horsmeier: > > Pascal S. de Kloe wrote: > > > > We need a *simple* installer for the RXTX extension. > > I'm working on a pure Java installer right now. Let's get > > this thing working > > over the weekend. The license of choise is the modified BSD license. > > > > My plan is to make a JAR with: > > * the RXTX binaries > > * a simple API to detect any installed version > > * a simple Swing installer > > * a executeable detector: java -jar communicationapi.jar > > detect javax.comm > > * a executable installer: java -jar communicationapi.jar > > install gnu.io > > * Java 1.2 compatible > > > > Comments? > > Have a look at IzPack: http://www.izforge.com/izpack/ > I use it all the time to install rxtx as part of our application. Hello Jos, Thanks for the idea. Could you publish the IzPack configuration and the binaries? That would be very helpful since the current installation procedure is somewhat "unprofessional". ;) IzPack is great but this API is a little more than that. It allows java applications who require the extension to detect available versions and install RXTX on the fly if needed. Is Izpack: * able to install binaries for the right platform (os + hardware architecture)? * Java 1.2 compatible * able to run from the command line? I need as many pre-compiled binaries as possible. Could you help me with that? The detection system already works. Thanks again, Pascal PS Is the gnu.io namespace still necessary? I couldn't find the problem. From naranjo.manuel at gmail.com Fri Jul 7 17:04:31 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 07 Jul 2006 20:04:31 -0300 Subject: [Rxtx] Java installer In-Reply-To: <200607080055.04501.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: <44AEE87F.60202@gmail.com> Pascal: I will be a little short with my answer but very informative :) > Could you publish the IzPack configuration and the binaries? That would be > very helpful since the current installation procedure is > somewhat "unprofessional". ;) > > IzPack is great but this API is a little more than that. It allows java > applications who require the extension to detect available versions and > install RXTX on the fly if needed. > > Is Izpack: > * able to install binaries for the right platform (os + hardware > architecture)? Yes. > * Java 1.2 compatible Yes of course > * able to run from the command line? Yes, and can run from command line detecting which is the underlaying os. I have attached an old version of one of my installer, I can't find the last one, but it is like this one. In this you will see how to detect the OS and architecture and install binaries for that plataform. Regards, Manuel -------------- next part -------------- A non-text attachment was scrubbed... Name: installer.xml Type: text/xml Size: 4683 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060707/fbc3be3c/installer-0359.xml From pascal at quies.net Fri Jul 7 18:35:29 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 02:35:29 +0200 Subject: [Rxtx] Java installer In-Reply-To: <44AEE87F.60202@gmail.com> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <44AEE87F.60202@gmail.com> Message-ID: <200607080235.29486.pascal@quies.net> Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: > > Is Izpack: > > * able to install binaries for the right platform (os + hardware > > architecture)? > > Yes. > > > * Java 1.2 compatible > > Yes of course > > > * able to run from the command line? > > Yes, and can run from command line detecting which is the underlaying os. > I have attached an old version of one of my installer, I can't find the > last one, but it is like this one. In this you will see how to detect > the OS and architecture and install binaries for that plataform. > Regards, > Manuel You are right. IzPack looks like the right tool for this job. As far as I can see there is no commandline support but I'll get over it. ;) I'll link my detection system to the IzPack installation procedure and publish the results. From tjarvi at qbang.org Fri Jul 7 19:00:56 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 7 Jul 2006 19:00:56 -0600 (MDT) Subject: [Rxtx] Controlling Individual Signals DTR and RTS In-Reply-To: References: Message-ID: On Thu, 6 Jul 2006, Trent Jarvi wrote: > On Thu, 29 Jun 2006, Chris Pine wrote: > >> Dear Moussa Ba, >> I hope I am not being too forward, but we are having the exact same >> issue with needing to control DTR from RXTX in Linux. Did you ever have any >> luck figuring it out? >> >> Thank you very much for your time, >> > > Hi Chris > > Are you using an unusual serial port? It could be that the port does not > support DTR/RTS. Especially if its an inexpensive USB->Serial dongle. > > I'll double check Linux tomorrow but I'm fairly sure it works. I have > verified windows after a questions like yours. Some multiport cards and > usb dongles do not support everything. > I double checked that DTR and RTS are working. The system was a 64 bit opteron with an inexexpensive dual port serial card. Suse 9.3 rxtx 2.1-7 (final). I just used the demo SerialBlackBox that used to come with commapi modified to use rxtx 2.1. The serial card was a NetMos PCI NM9835CV with a 16C550 high speed UART dual port. These are not expensive cards. Everything worked fine. I could see the voltage flipping back and forth on the scope for both DTR(pin 4) and CTS(pin 7). You are not the first to report problems. But everytime I try to reproduce the problem, it appears to work. I suspect it is either hardware or kernel driver related and not specific to RXTX. Note that playing with RTS and DTR with hardware flow control enabled does not make sense as those pins are used for the flow control. I've not looked at many USB serial dongles but I have noticed that some are not as good as others. I think one lacked DTR/CTS support. Another one appeared to be fully functional. The one I noticed no issues with was the Hawking Tech HUC232S on windows. I did not test it on Mac OS X or Linux. The same variability can be observed with multiport serial cards. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jul 7 19:15:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 7 Jul 2006 19:15:06 -0600 (MDT) Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: References: <44AC7902.8070407@adventnet.com> Message-ID: On Fri, 7 Jul 2006, Brian Schlining wrote: > Also, for some command/response applications that I've tried with RXTX, I > find that if I write to the serialport and then immediately try to read from > it I get byte arrays filled with zeros, no matter what I set the > recieveTimeout to (this has occurred on both Mac OS X and Windows). The > workaround that I found was to very briefly put the I/O thread to sleep, like > so: > > // DO set up and get I/O streams > //in = serialPort.getInputStream(); > //out = serialPort.getOutputStream(); > > out.write(someByteArray); > try { > Thread.sleep(10); > catch (InterruptedException e) { > // handle exception > } > in.read(anotherByteArray); > > Note: I've never had to put the thread to sleep using Java comm, only with > RXTX. Anyone know why this might be? Hi Brian Interesting. Is this something that can be reproduced with a loopback connection or something commonly available? I was unaware of this behavior. Is it restricted to something that quickly opens, writes, reads and closes the port by chance? -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Fri Jul 7 19:39:37 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Fri, 7 Jul 2006 19:39:37 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607080055.04501.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > Is the gnu.io namespace still necessary? I couldn't find the problem. Hi Pascal CommAPI is a little different in that it was grandfathered into the javax namespace with its own license at the time. It is my understanding that if CommAPI went through the JSR process, anyone would _clearly_ be able to implement a javax.comm package and RXTX would then be one of the first to do so. I believe Doug has expressed some interest in RXTX trying to work with the JSR process. Besides the license questions, there is the fact that RXTX has extensions to CommAPI which could cause confusion in the namespace. Not being a lawyer and *really* not liking to talk to lawyers in my free time, it is better to be safe than sorry. The lawyers tend to come in wolf packs when they do come. There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay there as long as we are just geeks trying to figure out if a license does or does not allow us to implement in the javax.comm namespace. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Sat Jul 8 05:30:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 13:30:24 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: <200607081330.24381.pascal@quies.net> Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > > Is the gnu.io namespace still necessary? I couldn't find the problem. > > Hi Pascal > > CommAPI is a little different in that it was grandfathered into the javax > namespace with its own license at the time. > > It is my understanding that if CommAPI went through the JSR process, > anyone would _clearly_ be able to implement a javax.comm package and RXTX > would then be one of the first to do so. I believe Doug has expressed > some interest in RXTX trying to work with the JSR process. > > Besides the license questions, there is the fact that RXTX has extensions > to CommAPI which could cause confusion in the namespace. Not being a > lawyer and *really* not liking to talk to lawyers in my free time, it is > better to be safe than sorry. The lawyers tend to come in wolf packs > when they do come. > > There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay > there as long as we are just geeks trying to figure out if a license does > or does not allow us to implement in the javax.comm namespace. Nicely said. :) The whole point of namespaces is to create a universal registry of, in this case, classes. This gnu.io namespace is very inconvenient. We feel the same way about lawyers. However I'd like to go into the details of the license (see attachment) if you don't mind? The first license does not apply since RXTX does not use the software. The second one at point 3 specifies our options. > 3. You may not modify the Java Platform Interface ("JPI", identified as > classes contained within the "java" package or any subpackages of the > "java" package), by creating additional classes within the JPI or otherwise > causing the addition to or modification of the classes in the JPI. RXTX is a extension. > In the event that you create an additional class and associated API(s) > which (i) extends the functionality of the Java platform, and (ii) is > exposed to third party software developers for the purpose of developing > additional software which invokes such additional API, you must promptly > publish broadly an accurate specification for such API for free use by all > developers. That's the way we operate. :) > You may not create, or authorize your licensees to create additional > classes, interfaces, or subpackages that are in any way identified as > "java", "javax", "sun" or similar convention as specified by Sun in any > naming convention designation. They don't want additional components in the Communication API since they don't want a mess in theire namespace. So we *can* use javax.comm for the core: javax.comm.CommDriver javax.comm.CommPort javax.comm.CommPortIdentifier javax.comm.CommPortOwnershipListener javax.comm.NoSuchPortException javax.comm.PortInUseException javax.comm.UnsupportedCommOperationException ...and for the default hardware support: javax.comm.SerialPort javax.comm.SerialPortEvent javax.comm.SerialPortEventListener javax.comm.ParralelPort javax.comm.ParralelPortEvent javax.comm.ParralelPortEventListener ...but RXTX aditional hardware support has to go somewhere else like: org.rxtx.RS485Port org.rxtx.RS485PortEvent org.rxtx.RS485PortEventListener org.rxtx.I2CPort org.rxtx.I2CPortEvent org.rxtx.I2CPortEventListener Right? -------------- next part -------------- Sun Microsystems, Inc. Binary Code License Agreement READ THE TERMS OF THIS AGREEMENT AND ANY PROVIDED SUPPLEMENTAL LICENSE TERMS (COLLECTIVELY "AGREEMENT") CAREFULLY BEFORE OPENING THE SOFTWARE MEDIA PACKAGE. BY OPENING THE SOFTWARE MEDIA PACKAGE, YOU AGREE TO THE TERMS OF THIS AGREEMENT. IF YOU ARE ACCESSING THE SOFTWARE ELECTRONICALLY, INDICATE YOUR ACCEPTANCE OF THESE TERMS BY SELECTING THE "ACCEPT" BUTTON AT THE END OF THIS AGREEMENT. IF YOU DO NOT AGREE TO ALL THESE TERMS, PROMPTLY RETURN THE UNUSED SOFTWARE TO YOUR PLACE OF PURCHASE FOR A REFUND OR, IF THE SOFTWARE IS ACCESSED ELECTRONICALLY, SELECT THE "DECLINE" BUTTON AT THE END OF THIS AGREEMENT. 1. LICENSE TO USE. Sun grants you a non-exclusive and non-transferable license for the internal use only of the accompanying software and documentation and any error corrections provided by Sun (collectively "Software"), by the number of users and the class of computer hardware for which the corresponding fee has been paid. 2. RESTRICTIONS. Software is confidential and copyrighted. Title to Software and all associated intellectual property rights is retained by Sun and/or its licensors. Except as specifically authorized in any Supplemental License Terms, you may not make copies of Software, other than a single copy of Software for archival purposes. Unless enforcement is prohibited by applicable law, you may not modify, decompile, or reverse engineer Software. Licensee acknowledges that Licensed Software is not designed or intended for use in the design, construction, operation or maintenance of any nuclear facility. Sun Microsystems, Inc. disclaims any express or implied warranty of fitness for such uses. No right, title or interest in or to any trademark, service mark, logo or trade name of Sun or its licensors is granted under this Agreement. 3. LIMITED WARRANTY. Sun warrants to you that for a period of ninety (90) days from the date of purchase, as evidenced by a copy of the receipt, the media on which Software is furnished (if any) will be free of defects in materials and workmanship under normal use. Except for the foregoing, Software is provided "AS IS". Your exclusive remedy and Sun's entire liability under this limited warranty will be at Sun's option to replace Software media or refund the fee paid for Software. 4. DISCLAIMER OF WARRANTY. UNLESS SPECIFIED IN THIS AGREEMENT, ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT THESE DISCLAIMERS ARE HELD TO BE LEGALLY INVALID. 5.LIMITATION OF LIABILITY. TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF OR RELATED TO THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. In no event will Sun's liability to you, whether in contract, tort (including negligence), or otherwise, exceed the amount paid by you for Software under this Agreement. The foregoing limitations will apply even if the above stated warranty fails of its essential purpose. 6. TERMINATION. This Agreement is effective until terminated. You may terminate this Agreement at any time by destroying all copies of Software. This Agreement will terminate immediately without notice from Sun if you fail to comply with any provision of this Agreement. Upon Termination, you must destroy all copies of Software. 7. EXPORT REGULATIONS. All Software and technical data delivered under this Agreement are subject to US export control laws and may be subject to export or import regulations in other countries. You agree to comply strictly with all such laws and regulations and acknowledge that you have the responsibility to obtain such licenses to export, re-export, or import as may be required after delivery to you. 8. U.S. GOVERNMENT RESTRICTED RIGHTS. If Software is being acquired by or on behalf of the U.S. Government or by a U.S. Government prime contractor or subcontractor (at any tier), then the Government's rights in Software and accompanying documentation will be only as set forth in this Agreement; this is in accordance with 48 CFR 227.7201 through 227.7202-4 (for Department of Defense (DOD) acquisitions) and with 48 CFR 2.101 and 12.212 (for non-DOD acquisitions). 9. GOVERNING LAW. Any action related to this Agreement will be governed by California law and controlling U.S. federal law. No choice of law rules of any jurisdiction will apply. 10, SEVERABILITY. If any provision of this Agreement is held to be unenforceable, this Agreement will remain in effect with the provision omitted, unless omission would frustrate the intent of the parties, in which case this Agreement will immediately terminate. 11. INTEGRATION This Agreement is the entire agreement between you and Sun relating to its subject matter. It supersedes all prior or contemporaneous oral or written communications, proposals, representations and warranties and prevails over any conflicting or additional terms of any quote, order, acknowledgment, or other communication between the parties relating to its subject matter during the term of this Agreement. No modification of this Agreement will be binding, unless in writing and signed by an authorized representative of each party. JAVA OPTIONAL PACKAGE JAVAX.COMM 3.0 SUPPLEMENTAL LICENSE TERMS These supplemental license terms ("Supplemental Terms") add to or modify the terms of the Binary Code License Agreement (collectively, the "Agreement"). Capitalized terms not defined in these Supplemental Terms shall have the same meanings ascribed to them in the Agreement. These Supplemental Terms shall supersede any inconsistent or conflicting terms in the Agreement, or in any license contained within the Software. 1. Software Internal Use and Development License Grant. Subject to the terms and conditions of this Agreement, including, but not limited to Section 3 (Java(TM) Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce internally and use internally the binary form of the Software, complete and unmodified, for the sole purpose of designing, developing and testing your Java applets and applications ("Programs"). 2. License to Distribute Software. In addition to the license granted in Section 1 (Software Internal Use and Development License Grant) of these Supplemental Terms, subject to the terms and conditions of this Agreement, including but not limited to, Section 3 (Java Technology Restrictions) of these Supplemental Terms, Sun grants you a non-exclusive, non-transferable, limited license to reproduce and distribute the Software in binary code form only, provided that you (i) distribute the Software complete and unmodified and only bundled as part of your Programs, (ii) do not distribute additional software intended to replace any component(s) of the Software, (iii) do not remove or alter any proprietary legends or notices contained in the Software, (iv) only distribute the Software subject to a license agreement that protects Sun's interests consistent with the terms contained in this Agreement, and (v) agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from the use or distribution of any and all Programs and/or Software. 3. Java Technology Restrictions. You may not modify the Java Platform Interface ("JPI", identified as classes contained within the "java" package or any subpackages of the "java" package), by creating additional classes within the JPI or otherwise causing the addition to or modification of the classes in the JPI. In the event that you create an additional class and associated API(s) which (i) extends the functionality of the Java platform, and (ii) is exposed to third party software developers for the purpose of developing additional software which invokes such additional API, you must promptly publish broadly an accurate specification for such API for free use by all developers. You may not create, or authorize your licensees to create additional classes, interfaces, or subpackages that are in any way identified as "java", "javax", "sun" or similar convention as specified by Sun in any naming convention designation. 4. Trademarks and Logos. You acknowledge and agree as between you and Sun that Sun owns the SUN, SOLARIS, JAVA, JINI, FORTE, and iPLANET trademarks and all SUN, SOLARIS, JAVA, JINI, FORTE, and iPLANET-related trademarks, service marks, logos and other brand designations ("Sun Marks"), and you agree to comply with the Sun Trademark and Logo Usage Requirements currently located at http://www.sun.com/policies/trademarks. Any use you make of the Sun Marks inures to Sun's benefit. 5. Source Code. Software may contain source code that is provided solely for reference purposes pursuant to the terms of this Agreement. Source code may not be redistributed unless expressly provided for in this Agreement. 6. Termination for Infringement. Either party may terminate this Agreement immediately should any Software become, or in either party's opinion be likely to become, the subject of a claim of infringement of any intellectual property right. For inquiries please contact: Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, California 95054. (LFI#143217/Form ID#011801) From tjarvi at qbang.org Sat Jul 8 10:12:55 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 10:12:55 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607081330.24381.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <200607081330.24381.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> Is the gnu.io namespace still necessary? I couldn't find the problem. >> >> Hi Pascal >> >> CommAPI is a little different in that it was grandfathered into the javax >> namespace with its own license at the time. >> >> It is my understanding that if CommAPI went through the JSR process, >> anyone would _clearly_ be able to implement a javax.comm package and RXTX >> would then be one of the first to do so. I believe Doug has expressed >> some interest in RXTX trying to work with the JSR process. >> >> Besides the license questions, there is the fact that RXTX has extensions >> to CommAPI which could cause confusion in the namespace. Not being a >> lawyer and *really* not liking to talk to lawyers in my free time, it is >> better to be safe than sorry. The lawyers tend to come in wolf packs >> when they do come. >> >> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay >> there as long as we are just geeks trying to figure out if a license does >> or does not allow us to implement in the javax.comm namespace. > > Nicely said. :) > > The whole point of namespaces is to create a universal registry of, in this > case, classes. This gnu.io namespace is very inconvenient. > > We feel the same way about lawyers. However I'd like to go into the details of > the license (see attachment) if you don't mind? > > The first license does not apply since RXTX does not use the software. The > second one at point 3 specifies our options. > >> 3. You may not modify the Java Platform Interface ("JPI", identified as >> classes contained within the "java" package or any subpackages of the >> "java" package), by creating additional classes within the JPI or otherwise >> causing the addition to or modification of the classes in the JPI. > > RXTX is a extension. > >> In the event that you create an additional class and associated API(s) >> which (i) extends the functionality of the Java platform, and (ii) is >> exposed to third party software developers for the purpose of developing >> additional software which invokes such additional API, you must promptly >> publish broadly an accurate specification for such API for free use by all >> developers. > > That's the way we operate. :) > >> You may not create, or authorize your licensees to create additional >> classes, interfaces, or subpackages that are in any way identified as >> "java", "javax", "sun" or similar convention as specified by Sun in any >> naming convention designation. > > They don't want additional components in the Communication API since they > don't want a mess in theire namespace. > > So we *can* use javax.comm for the core: > javax.comm.CommDriver > javax.comm.CommPort > javax.comm.CommPortIdentifier > javax.comm.CommPortOwnershipListener > javax.comm.NoSuchPortException > javax.comm.PortInUseException > javax.comm.UnsupportedCommOperationException > > ...and for the default hardware support: > javax.comm.SerialPort > javax.comm.SerialPortEvent > javax.comm.SerialPortEventListener > javax.comm.ParralelPort > javax.comm.ParralelPortEvent > javax.comm.ParralelPortEventListener > > ...but RXTX aditional hardware support has to go somewhere else like: > org.rxtx.RS485Port > org.rxtx.RS485PortEvent > org.rxtx.RS485PortEventListener > org.rxtx.I2CPort > org.rxtx.I2CPortEvent > org.rxtx.I2CPortEventListener > > Right? > I do not disagree with anything you said :) RXTX and Sun agree with each other almost completely but not exactly. I think there are three uses of CommAPI and Sun is mainly interested in one. 1) Point of sale. This is the direction Sun is going with limited resources thats causing some problems. They would obviously cause fewer problems with more resources just like rxtx would work with them better with more resources. I'm sure if you talk to people in this area they are very optimitsic about what CommAPI could be. 2) Instrument Control. This is my area of interest as its my job too. I'm still formulating opinions here and it is far to early to say much but I'm very optimistic about what CommAPI could be. 3) Hobby and other hardware control. Circuts, road signs, rxtx in cell phones controlling TVs, you name it. People asking about palm, wince, embeded hardware. This is why I thought it was important to open source rxtx in the beginning and still find it my primary motive to read rxtx email every morning and evening. The optimism here is abundant and self explained. Nothing would make me happier than having someone get a working demo of controlling LEDs with parallel ports that could be used by people learning. So everyone agrees with almost everything. Nobody is looking for conflicts. But these various interests have not been _clearly_ formalized. Licenses are tools for manipulating behavior. Until the above is clearly in line with each other, the license will be a tool for lawyers to cause problems for people working for free. This is why I support a move to go through the JSR process and formalize the relationship. My concern is not really Sun comming after RXTX with Lawyers. I have a great deal of respect for Sun going back to their sunsite project. My concern is how lawyers think. They look at the intent which is not all in line. Then I get what feels like insane conference calls that cost companies over $2000 an hour which pisses me off to no end. Companies paying lawyers to take time from developers for free. This really does happen when a fortune 50 company developer asks their legal department if they can use rxtx. I don't have enough bullets for that. The way you avoid this is formalize everones intent so lawyers don't make conference call meetings in outlook. I want to put those lawyers out of work and if it takes a little discomfort, thats perfectly fine. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Sat Jul 8 11:44:40 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 19:44:40 +0200 Subject: [Rxtx] Fwd: Re: Java installer Message-ID: <200607081944.41123.pascal@quies.net> For some reason the first mail failed... ---------- Doorgestuurd bericht ---------- Subject: Re: [Rxtx] Java installer Date: zaterdag 8 juli 2006 17:18 From: "Pascal S. de Kloe" To: RXTX Developers and Users Hello Manuel, In case of a JDK the installation goes into the "jre" directory. I can't find a simple way to get this information into a variable of IzPack. (see attachment) Do you have a idea? Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: > Pascal: > I will be a little short with my answer but very informative :) > > > Could you publish the IzPack configuration and the binaries? That would > > be very helpful since the current installation procedure is > > somewhat "unprofessional". ;) > > > > IzPack is great but this API is a little more than that. It allows java > > applications who require the extension to detect available versions and > > install RXTX on the fly if needed. > > > > Is Izpack: > > * able to install binaries for the right platform (os + hardware > > architecture)? > > Yes. > > > * Java 1.2 compatible > > Yes of course > > > * able to run from the command line? > > Yes, and can run from command line detecting which is the underlaying os. > I have attached an old version of one of my installer, I can't find the > last one, but it is like this one. In this you will see how to detect > the OS and architecture and install binaries for that plataform. > Regards, > Manuel ------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: izpack.xml Type: text/xml Size: 1401 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060708/413315d2/izpack-0358.xml From joachim at buechse.de Sat Jul 8 10:02:18 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 8 Jul 2006 18:02:18 +0200 Subject: [Rxtx] Java installer In-Reply-To: <200607080055.04501.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> Message-ID: <7D4FA261-44FA-4A6E-8EB9-7A7B0116BB2C@buechse.de> Hello Pascal, as soon as the 2.1.8 version is "released" I'll happily provide you with a precompiled library for Mac OSX. The currently tagged version is 2.17 which has a non standard implementation for OSX. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 08.07.2006, at 00:55, Pascal S. de Kloe wrote: > > I need as many pre-compiled binaries as possible. > Could you help me with that? > > The detection system already works. > > Thanks again, > > Pascal > > > PS > Is the gnu.io namespace still necessary? I couldn't find the problem. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 8 09:18:09 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 17:18:09 +0200 Subject: [Rxtx] Java installer In-Reply-To: <44AEE87F.60202@gmail.com> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <44AEE87F.60202@gmail.com> Message-ID: <200607081718.09605.pascal@quies.net> Hello Manuel, In case of a JDK the installation goes into the "jre" directory. I can't find a simple way to get this information into a variable of IzPack. (see attachment) Do you have a idea? Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: > Pascal: > I will be a little short with my answer but very informative :) > > > Could you publish the IzPack configuration and the binaries? That would > > be very helpful since the current installation procedure is > > somewhat "unprofessional". ;) > > > > IzPack is great but this API is a little more than that. It allows java > > applications who require the extension to detect available versions and > > install RXTX on the fly if needed. > > > > Is Izpack: > > * able to install binaries for the right platform (os + hardware > > architecture)? > > Yes. > > > * Java 1.2 compatible > > Yes of course > > > * able to run from the command line? > > Yes, and can run from command line detecting which is the underlaying os. > I have attached an old version of one of my installer, I can't find the > last one, but it is like this one. In this you will see how to detect > the OS and architecture and install binaries for that plataform. > Regards, > Manuel -------------- next part -------------- A non-text attachment was scrubbed... Name: izpack.xml Type: text/xml Size: 1401 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060708/fa6f5a81/izpack-0358.xml From naranjo.manuel at gmail.com Sat Jul 8 12:52:23 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 15:52:23 -0300 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607081944.41123.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> Message-ID: <44AFFEE7.3090306@gmail.com> Pascal: I can't get exactly your point, but my installer was to avoid modifying the users JDK or JRE. Download this app made by me, and you will get my point: http://www.aircable.net/downloads/AIRcable_Configuration_Utility_v0.2_ALPHA_1.zip, this app bundles RXTX library inside the zip file, and does not need RXTX installed on the Users system. Manuel > For some reason the first mail failed... > > > ---------- Doorgestuurd bericht ---------- > > Subject: Re: [Rxtx] Java installer > Date: zaterdag 8 juli 2006 17:18 > From: "Pascal S. de Kloe" > To: RXTX Developers and Users > > Hello Manuel, > > In case of a JDK the installation goes into the "jre" directory. > I can't find a simple way to get this information into a variable of IzPack. > (see attachment) > > Do you have a idea? > > Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: >> Pascal: >> I will be a little short with my answer but very informative :) >> >>> Could you publish the IzPack configuration and the binaries? That would >>> be very helpful since the current installation procedure is >>> somewhat "unprofessional". ;) >>> >>> IzPack is great but this API is a little more than that. It allows java >>> applications who require the extension to detect available versions and >>> install RXTX on the fly if needed. >>> >>> Is Izpack: >>> * able to install binaries for the right platform (os + hardware >>> architecture)? >> Yes. >> >>> * Java 1.2 compatible >> Yes of course >> >>> * able to run from the command line? >> Yes, and can run from command line detecting which is the underlaying os. >> I have attached an old version of one of my installer, I can't find the >> last one, but it is like this one. In this you will see how to detect >> the OS and architecture and install binaries for that plataform. >> Regards, >> Manuel > > ------------------------------------------------------- > > > ------------------------------------------------------------------------ > > > > > RXTX > 2... > http://www.rxtx.org/ > 1.2 > uninstallRXTX > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Jul 8 12:53:32 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 15:53:32 -0300 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607081944.41123.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> Message-ID: <44AFFF2C.8090005@gmail.com> Even more, the variable ${CURRENT_JRE} referees to the actuall JVM as far as I know, so you will have no difference in installing towards a JDK. > For some reason the first mail failed... > > > ---------- Doorgestuurd bericht ---------- > > Subject: Re: [Rxtx] Java installer > Date: zaterdag 8 juli 2006 17:18 > From: "Pascal S. de Kloe" > To: RXTX Developers and Users > > Hello Manuel, > > In case of a JDK the installation goes into the "jre" directory. > I can't find a simple way to get this information into a variable of IzPack. > (see attachment) > > Do you have a idea? > > Op zaterdag 8 juli 2006 01:04, schreef Manuel Naranjo: >> Pascal: >> I will be a little short with my answer but very informative :) >> >>> Could you publish the IzPack configuration and the binaries? That would >>> be very helpful since the current installation procedure is >>> somewhat "unprofessional". ;) >>> >>> IzPack is great but this API is a little more than that. It allows java >>> applications who require the extension to detect available versions and >>> install RXTX on the fly if needed. >>> >>> Is Izpack: >>> * able to install binaries for the right platform (os + hardware >>> architecture)? >> Yes. >> >>> * Java 1.2 compatible >> Yes of course >> >>> * able to run from the command line? >> Yes, and can run from command line detecting which is the underlaying os. >> I have attached an old version of one of my installer, I can't find the >> last one, but it is like this one. In this you will see how to detect >> the OS and architecture and install binaries for that plataform. >> Regards, >> Manuel > > ------------------------------------------------------- > > > ------------------------------------------------------------------------ > > > > > RXTX > 2... > http://www.rxtx.org/ > 1.2 > uninstallRXTX > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Jul 8 12:54:22 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 15:54:22 -0300 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <200607081330.24381.pascal@quies.net> Message-ID: <44AFFF5E.50603@gmail.com> > > I do not disagree with anything you said :) > > RXTX and Sun agree with each other almost completely but not exactly. I > think there are three uses of CommAPI and Sun is mainly interested in one. > > 1) Point of sale. This is the direction Sun is going with limited > resources thats causing some problems. They would obviously cause fewer > problems with more resources just like rxtx would work with them better > with more resources. I'm sure if you talk to people in this area they are > very optimitsic about what CommAPI could be. > > 2) Instrument Control. This is my area of interest as its my job too. I'm > still formulating opinions here and it is far to early to say much but I'm > very optimistic about what CommAPI could be. > > 3) Hobby and other hardware control. Circuts, road signs, rxtx in cell > phones controlling TVs, you name it. People asking about palm, wince, > embeded hardware. This is why I thought it was important to open source > rxtx in the beginning and still find it my primary motive to read rxtx > email every morning and evening. The optimism here is abundant and self > explained. Nothing would make me happier than having someone get a > working demo of controlling LEDs with parallel ports that could be used by > people learning. > > So everyone agrees with almost everything. Nobody is looking for > conflicts. But these various interests have not been _clearly_ > formalized. Licenses are tools for manipulating behavior. Until the > above is clearly in line with each other, the license will be a tool for > lawyers to cause problems for people working for free. This is why I > support a move to go through the JSR process and formalize the > relationship. > > My concern is not really Sun comming after RXTX with Lawyers. I have a > great deal of respect for Sun going back to their sunsite project. My > concern is how lawyers think. They look at the intent which is not all in > line. Then I get what feels like insane conference calls that cost > companies over $2000 an hour which pisses me off to no end. Companies > paying lawyers to take time from developers for free. This really does > happen when a fortune 50 company developer asks their legal department if > they can use rxtx. I don't have enough bullets for that. > > The way you avoid this is formalize everones intent so lawyers don't > make conference call meetings in outlook. I want to put those lawyers out > of work and if it takes a little discomfort, thats perfectly fine. > > -- > Trent Jarvi > tjarvi at qbang.org > > Trent: GREAT MAIL, I hate lawyers too. From naranjo.manuel at gmail.com Sat Jul 8 07:52:47 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 10:52:47 -0300 Subject: [Rxtx] Java installer In-Reply-To: <200607080235.29486.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <44AEE87F.60202@gmail.com> <200607080235.29486.pascal@quies.net> Message-ID: <44AFB8AF.50403@gmail.com> > > You are right. IzPack looks like the right tool for this job. > > As far as I can see there is no commandline support but I'll get over it. ;) Actually there is a way to execute native app in the Underlaying OS. Check out the JavaDOC and all the documentation given by them. If you need to also generate warper around the jar files, check this projects out: http://launch4j.sourceforge.net and http://jsmooth.sourceforge.net/ I have been able to make and exe with jsmooth that does not need to have RXTX installed if you want I can send the source of it. But it is simple. Do not put the jar inside the exe file, and add to the classpath relative paths to rxtx jar and then your jar file, and then add to the JVM command line (I can't remeber the actual name of it :P) -Djava.library.path=bin\ (Or were ever you installed the binary package). I have tryied doing the same with Java Comm from Sun but it actually is imposible, the main difference to me that make me move to RXTX, was that there is no need to have the javax.comm.properties file, which gave me lot of headaches. Regards, Manuel. From naranjo.manuel at gmail.com Sat Jul 8 08:03:58 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 08 Jul 2006 11:03:58 -0300 Subject: [Rxtx] License question. Message-ID: <44AFBB4E.70808@gmail.com> Hi: I have a question, haven't you ever thought about changing RXTX license from GNU/GPL to a more open license like Apache v2 or BSD like?. As far as I understand if I make an application that uses RXTX libraries, I must release my app under the GNU/GPL. I have no problem with that in fact I'm an Open Source user and defender. The fact is that in same cases the applications made by one, could get into hands of a company that needs to release a Closed Source app. I understand that using GNU/GPL do not give you the power to do this, but a more "open" license like Apache does. By "open" I mean that the license respects the Open Source license, but also lives the user the opportunity to use the library in closed source programs. I have seen that there is an exception to the license that applies to RXTX v2.0-5 and above, the only problem with it is that Java Comm Api (the jar file) needs the file javax.comm.properties installed correctly, which in lot of cases is a headache. RXTX jar does not need this, actually I think that RXTX is more user friendly than Java Comm. Maybe there has been a discussion like this before, but I just wanted to ask, and to get an answer that is adequate to our time. Regards, Manuel From pascal at quies.net Sat Jul 8 14:03:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:03:13 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <44AFFF2C.8090005@gmail.com> References: <200607081944.41123.pascal@quies.net> <44AFFF2C.8090005@gmail.com> Message-ID: <200607082203.13696.pascal@quies.net> Op zaterdag 8 juli 2006 20:53, schreef Manuel Naranjo: > Even more, the variable ${CURRENT_JRE} referees to the actuall JVM as > far as I know, so you will have no difference in installing towards a JDK. As far as the installation instructions go the location of the libraries is the following. Windows * JRE: $JAVA_HOME/bin/ * JDK: $JAVA_HOME/jre/bin/ UNIX * JRE: $JAVA_HOME/lib/ * JRE: $JAVA_HOME/jre/lib/ From pascal at quies.net Sat Jul 8 14:04:50 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:04:50 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <44AFFEE7.3090306@gmail.com> References: <200607081944.41123.pascal@quies.net> <44AFFEE7.3090306@gmail.com> Message-ID: <200607082204.50712.pascal@quies.net> Op zaterdag 8 juli 2006 20:52, schreef Manuel Naranjo: > Pascal: > I can't get exactly your point, but my installer was to avoid modifying > the users JDK or JRE. Download this app made by me, and you will get my > point: > http://www.aircable.net/downloads/AIRcable_Configuration_Utility_v0.2_ALPHA >_1.zip, this app bundles RXTX library inside the zip file, and does not need > RXTX installed on the Users system. > Manuel I didn't get the point indeed and I still don't get it. :$ The installation instructions state that RXTX.jar must be in the classpath and the libraries should go as my previous mail stated. Do you have another way? I don't have Windows so i can't run that EXE. From pascal at quies.net Sat Jul 8 14:05:40 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:05:40 +0200 Subject: [Rxtx] Java installer In-Reply-To: <7D4FA261-44FA-4A6E-8EB9-7A7B0116BB2C@buechse.de> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <7D4FA261-44FA-4A6E-8EB9-7A7B0116BB2C@buechse.de> Message-ID: <200607082205.40527.pascal@quies.net> Op zaterdag 8 juli 2006 18:02, schreef Joachim Buechse: > as soon as the 2.1.8 version is "released" I'll happily provide you ? > with a precompiled library for Mac OSX. The currently tagged version ? > is 2.17 which has a non standard implementation for OSX. Perfect! :) Do you have a idea when that will be? Like this month? From pascal at quies.net Sat Jul 8 14:14:44 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:14:44 +0200 Subject: [Rxtx] Java installer In-Reply-To: <44AFB8AF.50403@gmail.com> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080235.29486.pascal@quies.net> <44AFB8AF.50403@gmail.com> Message-ID: <200607082214.45115.pascal@quies.net> Op zaterdag 8 juli 2006 15:52, schreef Manuel Naranjo: > > You are right. IzPack looks like the right tool for this job. > > > > As far as I can see there is no commandline support but I'll get over it. > > ;) > > Actually there is a way to execute native app in the Underlaying OS. > Check out the JavaDOC and all the documentation given by them. > If you need to also generate warper around the jar files, check this > projects out: > http://launch4j.sourceforge.net and http://jsmooth.sourceforge.net/ > I have been able to make and exe with jsmooth that does not need to > have RXTX installed if you want I can send the source of it. But it is > simple. > Do not put the jar inside the exe file, and add to the classpath > relative paths to rxtx jar and then your jar file, and then add to the > JVM command line (I can't remeber the actual name of it :P) > -Djava.library.path=bin\ (Or were ever you installed the binary package). > I have tryied doing the same with Java Comm from Sun but it actually is > imposible, the main difference to me that make me move to RXTX, was that > there is no need to have the javax.comm.properties file, which gave me > lot of headaches. > Regards, > Manuel. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx Those are verry interresting and impressive tools for Windows. However, I wanted (and still do) a universal installer for all supported platforms as a single JAR. IzPack seemed quite suitable but it is limited and not well written so I'me still searching... Thanks for the help though. :) From pascal at quies.net Sat Jul 8 14:19:59 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 8 Jul 2006 22:19:59 +0200 Subject: [Rxtx] License question. In-Reply-To: <44AFBB4E.70808@gmail.com> References: <44AFBB4E.70808@gmail.com> Message-ID: <200607082219.59514.pascal@quies.net> I thought of the same thing. The modified BSD license would certainly make it more eazy and acceptable for Sun to include RXTX in theire products. Unfortunately in general people who chose GPL don't like other licenses. ;) Op zaterdag 8 juli 2006 16:03, schreef Manuel Naranjo: > Hi: > I have a question, haven't you ever thought about changing RXTX license > from GNU/GPL to a more open license like Apache v2 or BSD like?. > As far as I understand if I make an application that uses RXTX > libraries, I must release my app under the GNU/GPL. I have no problem > with that in fact I'm an Open Source user and defender. > The fact is that in same cases the applications made by one, could get > into hands of a company that needs to release a Closed Source app. I > understand that using GNU/GPL do not give you the power to do this, but > a more "open" license like Apache does. By "open" I mean that the > license respects the Open Source license, but also lives the user the > opportunity to use the library in closed source programs. > I have seen that there is an exception to the license that applies to > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > (the jar file) needs the file javax.comm.properties installed correctly, > which in lot of cases is a headache. RXTX jar does not need this, > actually I think that RXTX is more user friendly than Java Comm. > Maybe there has been a discussion like this before, but I just wanted to > ask, and to get an answer that is adequate to our time. > Regards, > Manuel > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sat Jul 8 15:30:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 15:30:31 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <44AFBB4E.70808@gmail.com> References: <44AFBB4E.70808@gmail.com> Message-ID: On Sat, 8 Jul 2006, Manuel Naranjo wrote: > Hi: > I have a question, haven't you ever thought about changing RXTX license > from GNU/GPL to a more open license like Apache v2 or BSD like?. > As far as I understand if I make an application that uses RXTX > libraries, I must release my app under the GNU/GPL. I have no problem > with that in fact I'm an Open Source user and defender. > The fact is that in same cases the applications made by one, could get > into hands of a company that needs to release a Closed Source app. I > understand that using GNU/GPL do not give you the power to do this, but > a more "open" license like Apache does. By "open" I mean that the > license respects the Open Source license, but also lives the user the > opportunity to use the library in closed source programs. > I have seen that there is an exception to the license that applies to > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > (the jar file) needs the file javax.comm.properties installed correctly, > which in lot of cases is a headache. RXTX jar does not need this, > actually I think that RXTX is more user friendly than Java Comm. > Maybe there has been a discussion like this before, but I just wanted to > ask, and to get an answer that is adequate to our time. > Regards, > Manuel Hi Manuel As one of the primary copyright 'owners' and a representative of all the people who have worked on RXTX I feel very compelled to comment on this. I often observe this misconception and just ignore it. RXTX is very commercial friendly both in open and closed source. The license is LGPL not GPL. This allows for linking to any application you like without sharing yoru application code. It is not unlike Apache or BSD in that sense. I like the BSD license but not in this case. The difference is you can not keep your changes to rxtx itself if your product is distributed in practice. To me this makes no sense and is a basic flaw in BSD licensing for libraries. I have _no_ intentions of "competing" with various incarnations of RXTX. If you use RXTX in your commercial application, I hope for two things. First I want you to do well for using rxtx even if you somehow compete with me in the commercial world. Second I want to see changes to RXTX come back to RXTX so we all do well for choosing RXTX. This is not possible with the BSD, MIT ... licenses. They result in multiple forks from the code and this is used to disrupt 'standards' by companies you would recognize (I no longer mention any company when saying bad things without fair notice). Your code is your code. Thats how the LGPL works. But don't take RXTX and fork it where I or anyone else that has worked on RXTX can see it. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Sat Jul 8 16:06:17 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 00:06:17 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> Message-ID: <200607090006.18197.pascal@quies.net> Op zaterdag 8 juli 2006 23:30, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Manuel Naranjo wrote: > > Hi: > > I have a question, haven't you ever thought about changing RXTX license > > from GNU/GPL to a more open license like Apache v2 or BSD like?. > > As far as I understand if I make an application that uses RXTX > > libraries, I must release my app under the GNU/GPL. I have no problem > > with that in fact I'm an Open Source user and defender. > > The fact is that in same cases the applications made by one, could get > > into hands of a company that needs to release a Closed Source app. I > > understand that using GNU/GPL do not give you the power to do this, but > > a more "open" license like Apache does. By "open" I mean that the > > license respects the Open Source license, but also lives the user the > > opportunity to use the library in closed source programs. > > I have seen that there is an exception to the license that applies to > > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > > (the jar file) needs the file javax.comm.properties installed correctly, > > which in lot of cases is a headache. RXTX jar does not need this, > > actually I think that RXTX is more user friendly than Java Comm. > > Maybe there has been a discussion like this before, but I just wanted to > > ask, and to get an answer that is adequate to our time. > > Regards, > > Manuel > > Hi Manuel > > As one of the primary copyright 'owners' and a representative of all the > people who have worked on RXTX I feel very compelled to comment on this. > I often observe this misconception and just ignore it. > > RXTX is very commercial friendly both in open and closed source. The > license is LGPL not GPL. This allows for linking to any application you > like without sharing yoru application code. It is not unlike Apache or > BSD in that sense. I like the BSD license but not in this case. > > The difference is you can not keep your changes to rxtx itself if your > product is distributed in practice. To me this makes no sense and is a > basic flaw in BSD licensing for libraries. I have _no_ intentions of > "competing" with various incarnations of RXTX. If you use RXTX in your > commercial application, I hope for two things. First I want you to do > well for using rxtx even if you somehow compete with me in the commercial > world. Second I want to see changes to RXTX come back to RXTX so we all > do well for choosing RXTX. > > This is not possible with the BSD, MIT ... licenses. They result in > multiple forks from the code and this is used to disrupt 'standards' by > companies you would recognize (I no longer mention any company when > saying bad things without fair notice). > > Your code is your code. Thats how the LGPL works. But don't take RXTX > and fork it where I or anyone else that has worked on RXTX can see it. > > -- > Trent Jarvi Hallo Trent, The BSD license wants to give and GPL wants to improve the public available content. What do you prefer? If you build the code to provide everyone a better experience then the BSD license would be suitable since the business acceptance is much higher. If you see this as a crucial component to build a complete free Java infrastructure that has no place for commerce then the GPL would be better In both situations RXTX will be free. I say that the chance a company would not contribute does not outweight the chance that the API is less available to the users. The entire API is a dead end. Mustang has USB support. Please let's make this as good as it gets. From tjarvi at qbang.org Sat Jul 8 16:09:31 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 16:09:31 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <200607082219.59514.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > I thought of the same thing. The modified BSD license would certainly make it > more eazy and acceptable for Sun to include RXTX in theire products. > > Unfortunately in general people who chose GPL don't like other licenses. ;) > If Sun can not accept the license, thats their problem. I have no problem with Sun distributing RXTX and working with the community. I've even stepped down as then primary and given that power to Doug to facilitate different opinions. For licensing changes, I am the primary copyright owner and have very strong opinions though I have a great deal of respect for everyone that has contributed to RXTX. Sun has their process and we have our process - screwy but a process and real. RXTX is not going to rubber stamp into any company without process that gives major power to the contributors to RXTX. There is a community here and it is not Sun's. (It isn't "gnu" either; the license is closest) This isn't about Trent. He is a wierd guy you should fear. That said, I'm not fundamentally against Sun distributing RXTX and changing package names. What I am fundametally against is multiple RXTXs. There isnt enough space for that game. -- Trent Jarvi tarvi at qbang.org From pascal at quies.net Sat Jul 8 16:25:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 00:25:24 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> Message-ID: <200607090025.24884.pascal@quies.net> Op zondag 9 juli 2006 00:09, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > > I thought of the same thing. The modified BSD license would certainly > > make it more eazy and acceptable for Sun to include RXTX in theire > > products. > > > > Unfortunately in general people who chose GPL don't like other licenses. > > ;) > > If Sun can not accept the license, thats their problem. > > I have no problem with Sun distributing RXTX and working with the > community. I've even stepped down as then primary and given that power to > Doug to facilitate different opinions. For licensing changes, I am the > primary copyright owner and have very strong opinions though I have a > great deal of respect for everyone that has contributed to RXTX. > > Sun has their process and we have our process - screwy but a process and > real. RXTX is not going to rubber stamp into any company without process > that gives major power to the contributors to RXTX. There is a community > here and it is not Sun's. (It isn't "gnu" either; the license is closest) > This isn't about Trent. He is a wierd guy you should fear. Hahaha, I found him very reasonable. The LGPL is not going to prevent forks. Any company which would take the code and keep little improvements to theirselves is stupid since they throw away a great deal of support and they know it. RXTX works. It needs a huge cleanup and more strict platform definitions but that's just a matter of time. What do you have to loose? From tjarvi at qbang.org Sat Jul 8 16:33:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 16:33:32 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <200607090025.24884.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> <200607090025.24884.pascal@quies.net> Message-ID: On Sun, 9 Jul 2006, Pascal S. de Kloe wrote: > Op zondag 9 juli 2006 00:09, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> I thought of the same thing. The modified BSD license would certainly >>> make it more eazy and acceptable for Sun to include RXTX in theire >>> products. >>> >>> Unfortunately in general people who chose GPL don't like other licenses. >>> ;) >> >> If Sun can not accept the license, thats their problem. >> >> I have no problem with Sun distributing RXTX and working with the >> community. I've even stepped down as then primary and given that power to >> Doug to facilitate different opinions. For licensing changes, I am the >> primary copyright owner and have very strong opinions though I have a >> great deal of respect for everyone that has contributed to RXTX. >> >> Sun has their process and we have our process - screwy but a process and >> real. RXTX is not going to rubber stamp into any company without process >> that gives major power to the contributors to RXTX. There is a community >> here and it is not Sun's. (It isn't "gnu" either; the license is closest) >> This isn't about Trent. He is a wierd guy you should fear. > > Hahaha, I found him very reasonable. > > The LGPL is not going to prevent forks. No it will not, but it will allow for you or me to view forks and absorb them. It renders forks of RXTX useless at the price of whatever product is shipped. I would ask that you consider the larger picture here. Termios and DCB are almost dead but almost being used like a VISA interface. Everyone just wants it to work but it does not always. So your proposal is to make mulitiple deal protocols? -- Trent Jarvi tjarvi at qbang.org From naranjo.manuel at gmail.com Sat Jul 8 17:20:44 2006 From: naranjo.manuel at gmail.com (Naranjo Manuel Francisco) Date: Sat, 8 Jul 2006 20:20:44 -0300 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> Message-ID: <360bc8300607081620x4e5d0f23h88fef8d81e6b6a0b@mail.gmail.com> Sorry, my mistake then, I thought the license was GPL not LGPL, I guess I readed some thing badly. I have readed all the emails, and you are right, there is no need for a Fork of RXTX, I think it works right as it is. So I can make my app Apache v2 with out any worry, because RXTX is LGPL :), great then. From tjarvi at qbang.org Sat Jul 8 17:57:05 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 17:57:05 -0600 (MDT) Subject: [Rxtx] License question ver2. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> <200607090025.24884.pascal@quies.net> Message-ID: Are there any more questions relating to this subject? From tjarvi at qbang.org Sat Jul 8 21:14:09 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sat, 8 Jul 2006 21:14:09 -0600 (MDT) Subject: [Rxtx] License question. In-Reply-To: <200607090006.18197.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607090006.18197.pascal@quies.net> Message-ID: On Sun, 9 Jul 2006, Pascal S. de Kloe wrote: > Op zaterdag 8 juli 2006 23:30, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Manuel Naranjo wrote: >>> Hi: >>> I have a question, haven't you ever thought about changing RXTX license >>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>> As far as I understand if I make an application that uses RXTX >>> libraries, I must release my app under the GNU/GPL. I have no problem >>> with that in fact I'm an Open Source user and defender. >>> The fact is that in same cases the applications made by one, could get >>> into hands of a company that needs to release a Closed Source app. I >>> understand that using GNU/GPL do not give you the power to do this, but >>> a more "open" license like Apache does. By "open" I mean that the >>> license respects the Open Source license, but also lives the user the >>> opportunity to use the library in closed source programs. >>> I have seen that there is an exception to the license that applies to >>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>> (the jar file) needs the file javax.comm.properties installed correctly, >>> which in lot of cases is a headache. RXTX jar does not need this, >>> actually I think that RXTX is more user friendly than Java Comm. >>> Maybe there has been a discussion like this before, but I just wanted to >>> ask, and to get an answer that is adequate to our time. >>> Regards, >>> Manuel >> >> Hi Manuel >> >> As one of the primary copyright 'owners' and a representative of all the >> people who have worked on RXTX I feel very compelled to comment on this. >> I often observe this misconception and just ignore it. >> >> RXTX is very commercial friendly both in open and closed source. The >> license is LGPL not GPL. This allows for linking to any application you >> like without sharing yoru application code. It is not unlike Apache or >> BSD in that sense. I like the BSD license but not in this case. >> >> The difference is you can not keep your changes to rxtx itself if your >> product is distributed in practice. To me this makes no sense and is a >> basic flaw in BSD licensing for libraries. I have _no_ intentions of >> "competing" with various incarnations of RXTX. If you use RXTX in your >> commercial application, I hope for two things. First I want you to do >> well for using rxtx even if you somehow compete with me in the commercial >> world. Second I want to see changes to RXTX come back to RXTX so we all >> do well for choosing RXTX. >> >> This is not possible with the BSD, MIT ... licenses. They result in >> multiple forks from the code and this is used to disrupt 'standards' by >> companies you would recognize (I no longer mention any company when >> saying bad things without fair notice). >> >> Your code is your code. Thats how the LGPL works. But don't take RXTX >> and fork it where I or anyone else that has worked on RXTX can see it. >> >> -- >> Trent Jarvi > > Hallo Trent, > > The BSD license wants to give and GPL wants to improve the public available > content. What do you prefer? > > If you build the code to provide everyone a better experience then the BSD > license would be suitable since the business acceptance is much higher. > If you see this as a crucial component to build a complete free Java > infrastructure that has no place for commerce then the GPL would be better > In both situations RXTX will be free. > > I say that the chance a company would not contribute does not outweight the > chance that the API is less available to the users. > The entire API is a dead end. Mustang has USB support. Please let's make this > as good as it gets. Hi Pascal I can not speak for any company here. I just happen to have become interesting to companies. With RXTX, the intent has always been to improve functionality. I don't play between the two worlds except for borrowing a scope at late in the evening. Thats rxtx and there is nothing else going on. Note that the RXTX library is LGPL. I would be interested in knowing where the GPL confusion comes from. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Jul 9 04:46:49 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 09 Jul 2006 06:46:49 -0400 Subject: [Rxtx] Java installer In-Reply-To: <200607082214.45115.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080235.29486.pascal@quies.net> <44AFB8AF.50403@gmail.com> <200607082214.45115.pascal@quies.net> Message-ID: Hi All, The problem of improving Java's ability to install and configure applications is a topic of current research. Configuration is a loaded word. When I think of configuration, I think, discover the properties of the operating environment and configure the software to work within that environment. Properties may include, but are not limited to, number and kind of monitors, serial ports, JVM versions, native method libs, graphics cards, graphics libs, write access to directories, changing the default screen saver (a new research topic) etc. There are two deployment solutions I can think of, please correct me, if I have left something out: 1. A source code distro with build tools (i.e., make and or ant) that enable the user to do a build for the target platform. 2. A binary distro built for each platform. Now, Java (in theory), is compile once, run anywhere. This assumes you don't use native methods. Once you start using native methods, you end up with many builds of the libs (one for each supported platform). Assuming you want binary distros for each platform, then you are faced with how to deploy them. Here are two basic approaches I know: 1. Build an application installer 2. Build a web-start distribution Some would argue for the application installer, as this is what many people are used to. Others will argue for a web-start distro. For a JNI-based application, like one that makes use of RXTX, I don't know which approach is "better". To know, one must first establish what "better" means. I think there must be (at least) two properties here: 1. Minimal installation effort 2. Trust. For minimal installation effort, I think that I should be able to download software, on demand, and just run it. Updates are obtained with minimal effort. Everything just works. And on all platforms that I use. For trust, I want to make sure I know the author and am able to hold someone accountable for application creation. I need to be able to thwart man-in-the-middle attacks and assure my user-base that I have signed off on my software. I have been making use of web-start, as a multi-year experiment. I have had mixed results. Particularly with more complex installs that make use of Java3d. In my view, several open problems remain. And cross-platform testing is needed for each major new application, platform, or major native method revision. On the other hand, I have had some good results with Java web start and RXTX. I can cite: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp Which is an address book program that should identify your serial port and enable dialing via the modem. The web start system seems to be able to adapt to multiple operating environments. The question of how well this deploys remains open. It should work on mac, windows and linux. If people want to try it and give me feedback, I would appreciate it. Deployment is semi-automatic using Project Initium. This is described in: http://show.docjava.com:8086/pub/document/jot/web.pdf and http://show.docjava.com:8086/pub/document/jot/initium.pdf Thanks! - Doug >Op zaterdag 8 juli 2006 15:52, schreef Manuel Naranjo: >> > You are right. IzPack looks like the right tool for this job. >> > >> > As far as I can see there is no commandline support but I'll get over it. >> > ;) >> >> Actually there is a way to execute native app in the Underlaying OS. >> Check out the JavaDOC and all the documentation given by them. >> If you need to also generate warper around the jar files, check this > > projects out: > > http://launch4j.sourceforge.net and http://jsmooth.sourceforge.net/ > > I have been able to make and exe with jsmooth that does not need to >> have RXTX installed if you want I can send the source of it. But it is >> simple. >> Do not put the jar inside the exe file, and add to the classpath >> relative paths to rxtx jar and then your jar file, and then add to the >> JVM command line (I can't remeber the actual name of it :P) > > -Djava.library.path=bin\ (Or were ever you installed the binary package). >> I have tryied doing the same with Java Comm from Sun but it actually is >> imposible, the main difference to me that make me move to RXTX, was that >> there is no need to have the javax.comm.properties file, which gave me >> lot of headaches. >> Regards, >> Manuel. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >Those are verry interresting and impressive tools for Windows. >However, I wanted (and still do) a universal installer for all supported >platforms as a single JAR. IzPack seemed quite suitable but it is limited and >not well written so I'me still searching... > >Thanks for the help though. :) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 9 05:15:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 13:15:13 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607090006.18197.pascal@quies.net> Message-ID: <200607091315.14053.pascal@quies.net> Op zondag 9 juli 2006 05:14, schreef Trent Jarvi: > Hi Pascal > > I can not speak for any company here. I just happen to have become > interesting to companies. > > With RXTX, the intent has always been to improve functionality. > > I don't play between the two worlds except for borrowing a scope at late > in the evening. Thats rxtx and there is nothing else going on. > > Note that the RXTX library is LGPL. I would be interested in knowing > where the GPL confusion comes from. Hi Trent, The license is stated clearly everywhere so don't worry. You are right that the LGPL should not be a problem for companies. The problem is, especially in larger companies, that the people who take the decissions think differend. When they hear about the demands of the license they rather spend "some" money on a commercial solution just to be sure because the trouble it might cause is not worth it. From pascal at quies.net Sun Jul 9 05:15:41 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 13:15:41 +0200 Subject: [Rxtx] License question. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <200607090025.24884.pascal@quies.net> Message-ID: <200607091315.41848.pascal@quies.net> Op zondag 9 juli 2006 00:33, schreef Trent Jarvi: > I would ask that you consider the larger picture here. Termios and DCB > are almost dead but almost being used like a VISA interface. Everyone > just wants it to work but it does not always. > > So your proposal is to make mulitiple deal protocols? No, nothing like that. Just use native calls where possible. I'll send you some things this week anyway. From pascal at quies.net Sun Jul 9 05:52:11 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 13:52:11 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607082214.45115.pascal@quies.net> Message-ID: <200607091352.11696.pascal@quies.net> Op zondag 9 juli 2006 12:46, schreef Dr. Douglas Lyon: > Hi All, > The problem of improving Java's ability to > install and configure applications is a topic of current research. > > Configuration is a loaded word. When I think of configuration, > I think, discover the properties of the operating environment and > configure the software to work within that environment. > > Properties may include, but are not limited to, number and > kind of monitors, serial ports, JVM versions, native method libs, > graphics cards, graphics libs, write access to directories, > changing the default screen saver (a new research topic) etc. > > There are two deployment solutions I can think of, > please correct me, if I have left something out: > 1. A source code distro with build tools (i.e., make and or ant) that > enable the user to do a build for the target platform. > 2. A binary distro built for each platform. > > Now, Java (in theory), is compile once, run anywhere. This assumes you > don't use native methods. Once you start using native methods, > you end up with many builds of the libs (one for each supported platform). > > Assuming you want binary distros for each platform, then you are faced with > how to deploy them. Here are two basic approaches I know: > 1. Build an application installer > 2. Build a web-start distribution > > Some would argue for the application installer, as this is what > many people are used to. Others will argue for a web-start distro. > > For a JNI-based application, like one that makes use of RXTX, > I don't know which approach is "better". To know, one must > first establish what "better" means. I think there must be (at least) two > properties here: > 1. Minimal installation effort > 2. Trust. > > For minimal installation effort, I think that I should be able to download > software, on demand, and just run it. Updates are obtained with minimal > effort. Everything just works. And on all platforms that I use. > > For trust, I want to make sure I know the author and am able to hold > someone accountable for application creation. I need to be able to thwart > man-in-the-middle > attacks and assure my user-base that I have signed off on my software. > > I have been making > use of web-start, as a multi-year experiment. > > I have had mixed results. Particularly with more complex installs > that make use of Java3d. In my view, several open problems remain. > And cross-platform testing is needed for each major new application, > platform, or major native method revision. > > On the other hand, I have had some good results with Java web start > and RXTX. I can cite: > http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jn >lp Which is an address book program that should identify your > serial port and enable dialing via the modem. > > The web start system seems to be able to adapt to multiple operating > environments. The question of how well this deploys remains open. > > It should work on mac, windows and linux. If people want to try it > and give me feedback, I would appreciate it. > > Deployment is semi-automatic using Project Initium. This is described in: > http://show.docjava.com:8086/pub/document/jot/web.pdf > and > http://show.docjava.com:8086/pub/document/jot/initium.pdf > > Thanks! > - Doug Hello Dough, We are bumping into the same problems. Youre web-based plan is definitely the way to go. I still didn't find a way to get around two IzPack problems without hacking into the code and it's taking too long so I started again on the inital plan. The CommunicationAPI class does leave the trust thing up to the implementation. This means that users can download and run the JAR and other applications can include the jar to install things if needed. If you could "Initum" this process then RXTX has no installating limits anymore. From joachim at buechse.de Sun Jul 9 07:13:34 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 9 Jul 2006 15:13:34 +0200 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44AFBB4E.70808@gmail.com> References: <44AFBB4E.70808@gmail.com> Message-ID: <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> Manuel, a simple way to avoid the javax.comm.properties file is to include a class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } into your application jar file and make sure, that you include the javax.comm jar after it. That's all you need. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 08.07.2006, at 16:03, Manuel Naranjo wrote: > Hi: > I have a question, haven't you ever thought about changing RXTX > license > from GNU/GPL to a more open license like Apache v2 or BSD like?. > As far as I understand if I make an application that uses RXTX > libraries, I must release my app under the GNU/GPL. I have no problem > with that in fact I'm an Open Source user and defender. > The fact is that in same cases the applications made by one, could get > into hands of a company that needs to release a Closed Source app. I > understand that using GNU/GPL do not give you the power to do this, > but > a more "open" license like Apache does. By "open" I mean that the > license respects the Open Source license, but also lives the user the > opportunity to use the library in closed source programs. > I have seen that there is an exception to the license that applies to > RXTX v2.0-5 and above, the only problem with it is that Java Comm Api > (the jar file) needs the file javax.comm.properties installed > correctly, > which in lot of cases is a headache. RXTX jar does not need this, > actually I think that RXTX is more user friendly than Java Comm. > Maybe there has been a discussion like this before, but I just > wanted to > ask, and to get an answer that is adequate to our time. > Regards, > Manuel > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Sun Jul 9 07:19:43 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 9 Jul 2006 15:19:43 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607082203.13696.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> <44AFFF2C.8090005@gmail.com> <200607082203.13696.pascal@quies.net> Message-ID: <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> Pascal, I would strongly suggest NOT to follow these installation instructions for OSX. It "poisons" the global Java VM with a specific implementation of RXTX. Plus: there is not one, but several Java VMs installed on every version of OSX. An application specific file and global preference pane defines which VM launches which application. There is really no good reason to install RXTX globally. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 08.07.2006, at 22:03, Pascal S. de Kloe wrote: > > As far as the installation instructions go the location of the > libraries is > the following. > > Windows > * JRE: $JAVA_HOME/bin/ > * JDK: $JAVA_HOME/jre/bin/ > > UNIX > * JRE: $JAVA_HOME/lib/ > * JRE: $JAVA_HOME/jre/lib/ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 9 09:01:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 9 Jul 2006 17:01:24 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> References: <200607081944.41123.pascal@quies.net> <200607082203.13696.pascal@quies.net> <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> Message-ID: <200607091701.24661.pascal@quies.net> Op zondag 9 juli 2006 15:19, schreef Joachim Buechse: > Pascal, > > I would strongly suggest NOT to follow these installation > instructions for OSX. It "poisons" the global Java VM with a specific > implementation of RXTX. Plus: there is not one, but several Java VMs > installed on every version of OSX. An application specific file and > global preference pane defines which VM launches which application. > There is really no good reason to install RXTX globally. I see your points. How can you use the extension non-globally? I asked the same thing for Windows to Manuel. The system will allow you to detect any implementation. So the "poison" becomes a alternative. Applications can install the extension if needed to the current runtime with something like: CommunicationAPI comm = new CommunicationAPI(); if (! comm.available()) { if (comm.installRXTX()) restart(); else handleError("I need the extension!"); } From naranjo.manuel at gmail.com Sun Jul 9 10:36:21 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 09 Jul 2006 13:36:21 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> Message-ID: <44B13085.2000805@gmail.com> Joachim, Does that really work???? I will try it later, thanks :) Manuel > Manuel, > > a simple way to avoid the javax.comm.properties file is to include a > class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > into your application jar file and make sure, that you include the > javax.comm jar after it. That's all you need. > > Regards, > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 08.07.2006, at 16:03, Manuel Naranjo wrote: > >> Hi: >> I have a question, haven't you ever thought about changing RXTX >> license >> from GNU/GPL to a more open license like Apache v2 or BSD like?. >> As far as I understand if I make an application that uses RXTX >> libraries, I must release my app under the GNU/GPL. I have no problem >> with that in fact I'm an Open Source user and defender. >> The fact is that in same cases the applications made by one, could get >> into hands of a company that needs to release a Closed Source app. I >> understand that using GNU/GPL do not give you the power to do this, >> but >> a more "open" license like Apache does. By "open" I mean that the >> license respects the Open Source license, but also lives the user the >> opportunity to use the library in closed source programs. >> I have seen that there is an exception to the license that applies to >> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >> (the jar file) needs the file javax.comm.properties installed >> correctly, >> which in lot of cases is a headache. RXTX jar does not need this, >> actually I think that RXTX is more user friendly than Java Comm. >> Maybe there has been a discussion like this before, but I just >> wanted to >> ask, and to get an answer that is adequate to our time. >> Regards, >> Manuel >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jul 9 10:50:11 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Jul 2006 10:50:11 -0600 (MDT) Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44B13085.2000805@gmail.com> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> Message-ID: I won't prevent people from discussing this hack. You can discuss anything on the list including things I do not agree with. But I do not agree with that hack. That is not in line with the history of RXTX respecting all that contribute including Sun. If you do this, it is your own thing. Agreeing to disagree is fine and usually the default here :). I just want to make it clear I do disagree. On Sun, 9 Jul 2006, Manuel Naranjo wrote: > Joachim, > Does that really work???? I will try it later, thanks :) > Manuel > >> Manuel, >> >> a simple way to avoid the javax.comm.properties file is to include a >> class >> >> package com.sun.comm; >> public class SolarisDriver extends gnu.io.RXTXCommDriver { >> } >> >> into your application jar file and make sure, that you include the >> javax.comm jar after it. That's all you need. >> >> Regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> On 08.07.2006, at 16:03, Manuel Naranjo wrote: >> >>> Hi: >>> I have a question, haven't you ever thought about changing RXTX >>> license >>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>> As far as I understand if I make an application that uses RXTX >>> libraries, I must release my app under the GNU/GPL. I have no problem >>> with that in fact I'm an Open Source user and defender. >>> The fact is that in same cases the applications made by one, could get >>> into hands of a company that needs to release a Closed Source app. I >>> understand that using GNU/GPL do not give you the power to do this, >>> but >>> a more "open" license like Apache does. By "open" I mean that the >>> license respects the Open Source license, but also lives the user the >>> opportunity to use the library in closed source programs. >>> I have seen that there is an exception to the license that applies to >>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>> (the jar file) needs the file javax.comm.properties installed >>> correctly, >>> which in lot of cases is a headache. RXTX jar does not need this, >>> actually I think that RXTX is more user friendly than Java Comm. >>> Maybe there has been a discussion like this before, but I just >>> wanted to >>> ask, and to get an answer that is adequate to our time. >>> Regards, >>> Manuel >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From naranjo.manuel at gmail.com Sun Jul 9 11:43:33 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 09 Jul 2006 14:43:33 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> Message-ID: <44B14045.9030601@gmail.com> Trent: Do you know any other way, to use Java Comm API with RXTX with out the javax.comm.properties?. Have any information about how is the JSR going? Regards, Manuel > > I won't prevent people from discussing this hack. You can discuss > anything on the list including things I do not agree with. > > But I do not agree with that hack. That is not in line with the history > of RXTX respecting all that contribute including Sun. If you do this, > it is your own thing. > > Agreeing to disagree is fine and usually the default here :). I just > want to make it clear I do disagree. > > On Sun, 9 Jul 2006, Manuel Naranjo wrote: > >> Joachim, >> Does that really work???? I will try it later, thanks :) >> Manuel >> >>> Manuel, >>> >>> a simple way to avoid the javax.comm.properties file is to include a >>> class >>> >>> package com.sun.comm; >>> public class SolarisDriver extends gnu.io.RXTXCommDriver { >>> } >>> >>> into your application jar file and make sure, that you include the >>> javax.comm jar after it. That's all you need. >>> >>> Regards, >>> Joachim >>> >>> --- >>> Joachim B?chse >>> Softwarel?sungen und Beratung >>> Hadlaubsteig 2 >>> CH-8006 Z?rich >>> >>> >>> On 08.07.2006, at 16:03, Manuel Naranjo wrote: >>> >>>> Hi: >>>> I have a question, haven't you ever thought about changing RXTX >>>> license >>>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>>> As far as I understand if I make an application that uses RXTX >>>> libraries, I must release my app under the GNU/GPL. I have no problem >>>> with that in fact I'm an Open Source user and defender. >>>> The fact is that in same cases the applications made by one, could get >>>> into hands of a company that needs to release a Closed Source app. I >>>> understand that using GNU/GPL do not give you the power to do this, >>>> but >>>> a more "open" license like Apache does. By "open" I mean that the >>>> license respects the Open Source license, but also lives the user the >>>> opportunity to use the library in closed source programs. >>>> I have seen that there is an exception to the license that applies to >>>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>>> (the jar file) needs the file javax.comm.properties installed >>>> correctly, >>>> which in lot of cases is a headache. RXTX jar does not need this, >>>> actually I think that RXTX is more user friendly than Java Comm. >>>> Maybe there has been a discussion like this before, but I just >>>> wanted to >>>> ask, and to get an answer that is adequate to our time. >>>> Regards, >>>> Manuel >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Jul 9 11:53:19 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Jul 2006 11:53:19 -0600 (MDT) Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44B14045.9030601@gmail.com> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> Message-ID: Hi Manuel I do not know of another way. If you look at rxtx.org, even the compiled version is hard to find, always late and not what you want. At rxtx.org we just worry about the source and do a minimal effort to provide binaries. I'd love nothing more than someone to start selling RXTX binaries or working with us like Doug is to deliver the problems solved to users. The Free here is Freedom. Not price. There is a need for services rxtx.org is not able to provide well. That said I do not ever expect to recieve anything. It just makes sense for everyone to work together and compete outside of the source. On Sun, 9 Jul 2006, Manuel Naranjo wrote: > Trent: > Do you know any other way, to use Java Comm API with RXTX with out the > javax.comm.properties?. > Have any information about how is the JSR going? > Regards, > Manuel >> >> I won't prevent people from discussing this hack. You can discuss >> anything on the list including things I do not agree with. >> >> But I do not agree with that hack. That is not in line with the history >> of RXTX respecting all that contribute including Sun. If you do this, >> it is your own thing. >> >> Agreeing to disagree is fine and usually the default here :). I just >> want to make it clear I do disagree. >> >> On Sun, 9 Jul 2006, Manuel Naranjo wrote: >> >>> Joachim, >>> Does that really work???? I will try it later, thanks :) >>> Manuel >>> >>>> Manuel, >>>> >>>> a simple way to avoid the javax.comm.properties file is to include a >>>> class >>>> >>>> package com.sun.comm; >>>> public class SolarisDriver extends gnu.io.RXTXCommDriver { >>>> } >>>> >>>> into your application jar file and make sure, that you include the >>>> javax.comm jar after it. That's all you need. >>>> >>>> Regards, >>>> Joachim >>>> >>>> --- >>>> Joachim B?chse >>>> Softwarel?sungen und Beratung >>>> Hadlaubsteig 2 >>>> CH-8006 Z?rich >>>> >>>> >>>> On 08.07.2006, at 16:03, Manuel Naranjo wrote: >>>> >>>>> Hi: >>>>> I have a question, haven't you ever thought about changing RXTX >>>>> license >>>>> from GNU/GPL to a more open license like Apache v2 or BSD like?. >>>>> As far as I understand if I make an application that uses RXTX >>>>> libraries, I must release my app under the GNU/GPL. I have no problem >>>>> with that in fact I'm an Open Source user and defender. >>>>> The fact is that in same cases the applications made by one, could get >>>>> into hands of a company that needs to release a Closed Source app. I >>>>> understand that using GNU/GPL do not give you the power to do this, >>>>> but >>>>> a more "open" license like Apache does. By "open" I mean that the >>>>> license respects the Open Source license, but also lives the user the >>>>> opportunity to use the library in closed source programs. >>>>> I have seen that there is an exception to the license that applies to >>>>> RXTX v2.0-5 and above, the only problem with it is that Java Comm Api >>>>> (the jar file) needs the file javax.comm.properties installed >>>>> correctly, >>>>> which in lot of cases is a headache. RXTX jar does not need this, >>>>> actually I think that RXTX is more user friendly than Java Comm. >>>>> Maybe there has been a discussion like this before, but I just >>>>> wanted to >>>>> ask, and to get an answer that is adequate to our time. >>>>> Regards, >>>>> Manuel >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From naranjo.manuel at gmail.com Sun Jul 9 12:04:28 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sun, 09 Jul 2006 15:04:28 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> Message-ID: <44B1452C.60208@gmail.com> Trent Jarvi wrote: > > Hi Manuel > > I do not know of another way. If you look at rxtx.org, even the > compiled version is hard to find, always late and not what you want. At > rxtx.org we just worry about the source and do a minimal effort to > provide binaries. Then that probes my theory, RXTX is much better than Java comm :) > I'd love nothing more than someone to start selling RXTX binaries or > working with us like Doug is to deliver the problems solved to users. > The Free here is Freedom. Not price. There is a need for services > rxtx.org is not able to provide well. That said I do not ever expect to > recieve anything. It just makes sense for everyone to work together and > compete outside of the source. I would like to contribute with the project giving support, I have worked using JSmooth and IzPack, and been able to make things that make RXTX easier to use and install. I will try to debug them, and send them to the mailing list, so you can do what ever you want with this :). Regards, Manuel From tjarvi at qbang.org Sun Jul 9 22:15:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 9 Jul 2006 22:15:28 -0600 (MDT) Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: <44B1452C.60208@gmail.com> References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> <44B1452C.60208@gmail.com> Message-ID: On Sun, 9 Jul 2006, Manuel Naranjo wrote: > Trent Jarvi wrote: >> >> Hi Manuel >> >> I do not know of another way. If you look at rxtx.org, even the >> compiled version is hard to find, always late and not what you want. At >> rxtx.org we just worry about the source and do a minimal effort to >> provide binaries. > Then that probes my theory, RXTX is much better than Java comm :) > >> I'd love nothing more than someone to start selling RXTX binaries or >> working with us like Doug is to deliver the problems solved to users. >> The Free here is Freedom. Not price. There is a need for services >> rxtx.org is not able to provide well. That said I do not ever expect to >> recieve anything. It just makes sense for everyone to work together and >> compete outside of the source. > I would like to contribute with the project giving support, I have > worked using JSmooth and IzPack, and been able to make things that make > RXTX easier to use and install. I will try to debug them, and send them > to the mailing list, so you can do what ever you want with this :). > Regards, Hi Manuel This is interesting. There are some checks and balances that we do at rxtx.org to make sure random material does not get in. It isn't personal just a low bar that must be crossed. After you get your changes in, you will know that others must cross the same bar. The basic question asked is "Does this change reflect the intent and work of those that have contributed to RXTX." Perhaps Doug is the best person to be the bar here. I'm more than willing to admit my limitations and obviously this is a limitation I face. If Doug is willing to take this task, I'd be glad to give him CVS write access which is more than overdue as he is the official maintainer now :) He then could optionally give you write access if your changes are fine and you represent a bar for new changes. I trust Doug. We do take the bar seriously as you can see. But it is not intended to prevent fair use of RXTX or prevent facilitating new uses. If we don't manage expectations here, there will be all sorts of problems and issues. -- Trent Jarvi tjarvi at qbang.org From zhanglong at adventnet.com Mon Jul 10 02:02:20 2006 From: zhanglong at adventnet.com (zhanglong) Date: Mon, 10 Jul 2006 16:02:20 +0800 Subject: [Rxtx] rxtx can not read data from serialport Message-ID: <44B2098C.6050407@adventnet.com> Dear brian and tjarvi, Thank you! After I set flowcontrol as FLOWCONTROL_RTSCTS_IN serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_IN); Then I can read and write data from serial port on Windows. But On linux9.0,No response,no data. I can get serialport list on my machine.And no error when I open serialport. I use Wevecom GSM modem device.I install Linux in VWware Workstation. And VWware Workstation install on windowsXP,So windowsXP and redhat Linux9.0 are on the same PC. On windows,I use COM1 serialport. On Linux,I use /dev/ttyS0 serialport. I hava test with SerialPort.FLOWCONTROL_XONXOFF_IN flow control,But still no data. How to set flow control,timeout and threshold on linux9.0? Thanks & Regards, Zhanglong -------------- next part -------------- A non-text attachment was scrubbed... Name: ListPort.java Type: text/x-java Size: 1659 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060710/334802b0/ListPort-0357.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: listport return on Windows and Linux.txt Url: http://mailman.qbang.org/pipermail/rxtx/attachments/20060710/334802b0/listportreturnonWindowsandLinux-0357.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: TwoWaySerialComm.java Type: text/x-java Size: 3516 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060710/334802b0/TwoWaySerialComm-0357.bin From joachim at buechse.de Mon Jul 10 02:53:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 10 Jul 2006 10:53:09 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <200607091701.24661.pascal@quies.net> References: <200607081944.41123.pascal@quies.net> <200607082203.13696.pascal@quies.net> <0629536F-907F-41AF-A761-4443F7D8BA1B@buechse.de> <200607091701.24661.pascal@quies.net> Message-ID: <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> The problem is, that once the libraries are installed in JAVA_HOME/ lib they will be loaded in preference to classes in your application classpath. If all you want is to use RXTX, then: - put the native lib in your application directory - include the javax.comm classes and RXTX classes in your application classpath - add the little stub class package com.sun.comm; public class SolarisDriver extends gnu.io.RXTXCommDriver { } before the javax.comm classes in your application classpath. Alternatively you could also include the native lib in your application jar, extract it at runtime to a temp file, load it with System.load(). This will work on Windows and OSX. I didn't test it on Linux, but it should work. Regards, Joachim On 09.07.2006, at 17:01, Pascal S. de Kloe wrote: > Op zondag 9 juli 2006 15:19, schreef Joachim Buechse: >> Pascal, >> >> I would strongly suggest NOT to follow these installation >> instructions for OSX. It "poisons" the global Java VM with a specific >> implementation of RXTX. Plus: there is not one, but several Java VMs >> installed on every version of OSX. An application specific file and >> global preference pane defines which VM launches which application. >> There is really no good reason to install RXTX globally. > > I see your points. > How can you use the extension non-globally? I asked the same thing > for Windows > to Manuel. > > The system will allow you to detect any implementation. So the > "poison" > becomes a alternative. Applications can install the extension if > needed to > the current runtime with something like: > > CommunicationAPI comm = new CommunicationAPI(); > if (! comm.available()) { > if (comm.installRXTX()) > restart(); > else > handleError("I need the extension!"); > } > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jul 10 06:07:23 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 10 Jul 2006 06:07:23 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607081330.24381.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607080055.04501.pascal@quies.net> <200607081330.24381.pascal@quies.net> Message-ID: On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> Is the gnu.io namespace still necessary? I couldn't find the problem. >> >> Hi Pascal >> >> CommAPI is a little different in that it was grandfathered into the javax >> namespace with its own license at the time. >> >> It is my understanding that if CommAPI went through the JSR process, >> anyone would _clearly_ be able to implement a javax.comm package and RXTX >> would then be one of the first to do so. I believe Doug has expressed >> some interest in RXTX trying to work with the JSR process. >> >> Besides the license questions, there is the fact that RXTX has extensions >> to CommAPI which could cause confusion in the namespace. Not being a >> lawyer and *really* not liking to talk to lawyers in my free time, it is >> better to be safe than sorry. The lawyers tend to come in wolf packs >> when they do come. >> >> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay >> there as long as we are just geeks trying to figure out if a license does >> or does not allow us to implement in the javax.comm namespace. > > Nicely said. :) > > The whole point of namespaces is to create a universal registry of, in this > case, classes. This gnu.io namespace is very inconvenient. > > We feel the same way about lawyers. However I'd like to go into the details of > the license (see attachment) if you don't mind? > > The first license does not apply since RXTX does not use the software. The > second one at point 3 specifies our options. > >> 3. You may not modify the Java Platform Interface ("JPI", identified as >> classes contained within the "java" package or any subpackages of the >> "java" package), by creating additional classes within the JPI or otherwise >> causing the addition to or modification of the classes in the JPI. > > RXTX is a extension. > >> In the event that you create an additional class and associated API(s) >> which (i) extends the functionality of the Java platform, and (ii) is >> exposed to third party software developers for the purpose of developing >> additional software which invokes such additional API, you must promptly >> publish broadly an accurate specification for such API for free use by all >> developers. > > That's the way we operate. :) > >> You may not create, or authorize your licensees to create additional >> classes, interfaces, or subpackages that are in any way identified as >> "java", "javax", "sun" or similar convention as specified by Sun in any >> naming convention designation. > > They don't want additional components in the Communication API since they > don't want a mess in theire namespace. > > So we *can* use javax.comm for the core: > javax.comm.CommDriver > javax.comm.CommPort > javax.comm.CommPortIdentifier > javax.comm.CommPortOwnershipListener > javax.comm.NoSuchPortException > javax.comm.PortInUseException > javax.comm.UnsupportedCommOperationException > > ...and for the default hardware support: > javax.comm.SerialPort > javax.comm.SerialPortEvent > javax.comm.SerialPortEventListener > javax.comm.ParralelPort > javax.comm.ParralelPortEvent > javax.comm.ParralelPortEventListener > > ...but RXTX aditional hardware support has to go somewhere else like: > org.rxtx.RS485Port > org.rxtx.RS485PortEvent > org.rxtx.RS485PortEventListener > org.rxtx.I2CPort > org.rxtx.I2CPortEvent > org.rxtx.I2CPortEventListener > > Right? > The one thing this discussion does not cover is in SerialPort.java. See the extensions to commapi listed after the following line: /* ---------------------- end of commapi ------------------------ */ The intent is not to break commapi but it could be perceived as so. The extensions added have been placed there as requested by users of RXTX. It would be nice to discuss these modifications with Sun and perhaps have some added to the final version of CommAPI. Some of them may not make sense while others do. Some can not be implemented in a platform neutral fashion. It would not make sense for RXTX to just bring these into Sun's namespace without due process. This is why I am fundamentally apposed to people "poisoning" Sun's namespace with RXTX 2.1 although I understand that is not their intent. These modifications are not advertised and their use is discouraged. But they are there. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Mon Jul 10 06:47:24 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 10 Jul 2006 14:47:24 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607081330.24381.pascal@quies.net> Message-ID: <200607101447.25071.pascal@quies.net> Op maandag 10 juli 2006 14:07, schreef Trent Jarvi: > On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > > Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: > >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: > >>> Is the gnu.io namespace still necessary? I couldn't find the problem. > >> > >> Hi Pascal > >> > >> CommAPI is a little different in that it was grandfathered into the > >> javax namespace with its own license at the time. > >> > >> It is my understanding that if CommAPI went through the JSR process, > >> anyone would _clearly_ be able to implement a javax.comm package and > >> RXTX would then be one of the first to do so. I believe Doug has > >> expressed some interest in RXTX trying to work with the JSR process. > >> > >> Besides the license questions, there is the fact that RXTX has > >> extensions to CommAPI which could cause confusion in the namespace. Not > >> being a lawyer and *really* not liking to talk to lawyers in my free > >> time, it is better to be safe than sorry. The lawyers tend to come in > >> wolf packs when they do come. > >> > >> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay > >> there as long as we are just geeks trying to figure out if a license > >> does or does not allow us to implement in the javax.comm namespace. > > > > Nicely said. :) > > > > The whole point of namespaces is to create a universal registry of, in > > this case, classes. This gnu.io namespace is very inconvenient. > > > > We feel the same way about lawyers. However I'd like to go into the > > details of the license (see attachment) if you don't mind? > > > > The first license does not apply since RXTX does not use the software. > > The second one at point 3 specifies our options. > > > >> 3. You may not modify the Java Platform Interface ("JPI", identified as > >> classes contained within the "java" package or any subpackages of the > >> "java" package), by creating additional classes within the JPI or > >> otherwise causing the addition to or modification of the classes in the > >> JPI. > > > > RXTX is a extension. > > > >> In the event that you create an additional class and associated API(s) > >> which (i) extends the functionality of the Java platform, and (ii) is > >> exposed to third party software developers for the purpose of developing > >> additional software which invokes such additional API, you must promptly > >> publish broadly an accurate specification for such API for free use by > >> all developers. > > > > That's the way we operate. :) > > > >> You may not create, or authorize your licensees to create additional > >> classes, interfaces, or subpackages that are in any way identified as > >> "java", "javax", "sun" or similar convention as specified by Sun in any > >> naming convention designation. > > > > They don't want additional components in the Communication API since they > > don't want a mess in theire namespace. > > > > So we *can* use javax.comm for the core: > > javax.comm.CommDriver > > javax.comm.CommPort > > javax.comm.CommPortIdentifier > > javax.comm.CommPortOwnershipListener > > javax.comm.NoSuchPortException > > javax.comm.PortInUseException > > javax.comm.UnsupportedCommOperationException > > > > ...and for the default hardware support: > > javax.comm.SerialPort > > javax.comm.SerialPortEvent > > javax.comm.SerialPortEventListener > > javax.comm.ParralelPort > > javax.comm.ParralelPortEvent > > javax.comm.ParralelPortEventListener > > > > ...but RXTX aditional hardware support has to go somewhere else like: > > org.rxtx.RS485Port > > org.rxtx.RS485PortEvent > > org.rxtx.RS485PortEventListener > > org.rxtx.I2CPort > > org.rxtx.I2CPortEvent > > org.rxtx.I2CPortEventListener > > > > Right? > > The one thing this discussion does not cover is in SerialPort.java. See > the extensions to commapi listed after the following line: > > /* ---------------------- end of commapi ------------------------ */ > > The intent is not to break commapi but it could be perceived as so. The > extensions added have been placed there as requested by users of RXTX. It > would be nice to discuss these modifications with Sun and perhaps have > some added to the final version of CommAPI. > > Some of them may not make sense while others do. Some can not be > implemented in a platform neutral fashion. It would not make sense > for RXTX to just bring these into Sun's namespace without due process. > > This is why I am fundamentally apposed to people "poisoning" Sun's > namespace with RXTX 2.1 although I understand that is not their intent. > > These modifications are not advertised and their use is discouraged. But > they are there. Hi Trent, So you are saying that gnu.io.SerialPort has some aditional methods over javax.comm.SerialPort? That does not change the API at all but it would be a problem if people would start using those methods in the javax.comm namespace in the same way like some people use the com.sun namespace. Could wrapper classes at javax.comm do the job? In that way RXTX stays in its namespace, javadoc can notice the aditional methods and the Communication API will be available as expected. From pascal at quies.net Mon Jul 10 06:48:09 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 10 Jul 2006 14:48:09 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> References: <200607081944.41123.pascal@quies.net> <200607091701.24661.pascal@quies.net> <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> Message-ID: <200607101448.09594.pascal@quies.net> Op maandag 10 juli 2006 10:53, schreef Joachim Buechse: > If all you want is to use RXTX, then: > > - put the native lib in your application directory > - include the javax.comm classes and RXTX classes in your application > classpath > - add the little stub class > > package com.sun.comm; > public class SolarisDriver extends gnu.io.RXTXCommDriver { > } > > before the javax.comm classes in your application classpath. > > Alternatively you could also include the native lib in your > application jar, extract it at runtime to a temp file, load it with > System.load(). So java will load the native libraries automaticly if they are in the same directory as the Java application? Why isn't this very interresting information noticed in the documentation or is that too obvious and I simply didn't knew? From naranjo.manuel at gmail.com Mon Jul 10 06:56:10 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Mon, 10 Jul 2006 09:56:10 -0300 Subject: [Rxtx] javax.comm.properties [was License question]. In-Reply-To: References: <44AFBB4E.70808@gmail.com> <99C71E9F-6C93-4D84-8524-664FAC7EA787@buechse.de> <44B13085.2000805@gmail.com> <44B14045.9030601@gmail.com> <44B1452C.60208@gmail.com> Message-ID: <44B24E6A.1010805@gmail.com> Trent Jarvi wrote: > On Sun, 9 Jul 2006, Manuel Naranjo wrote: > >> Trent Jarvi wrote: >>> Hi Manuel >>> >>> I do not know of another way. If you look at rxtx.org, even the >>> compiled version is hard to find, always late and not what you want. At >>> rxtx.org we just worry about the source and do a minimal effort to >>> provide binaries. >> Then that probes my theory, RXTX is much better than Java comm :) >> >>> I'd love nothing more than someone to start selling RXTX binaries or >>> working with us like Doug is to deliver the problems solved to users. >>> The Free here is Freedom. Not price. There is a need for services >>> rxtx.org is not able to provide well. That said I do not ever expect to >>> recieve anything. It just makes sense for everyone to work together and >>> compete outside of the source. >> I would like to contribute with the project giving support, I have >> worked using JSmooth and IzPack, and been able to make things that make >> RXTX easier to use and install. I will try to debug them, and send them >> to the mailing list, so you can do what ever you want with this :). >> Regards, > > > Hi Manuel > > This is interesting. There are some checks and balances that we do at > rxtx.org to make sure random material does not get in. It isn't personal > just a low bar that must be crossed. After you get your changes in, you > will know that others must cross the same bar. The basic question asked > is "Does this change reflect the intent and work of those that have > contributed to RXTX." > > Perhaps Doug is the best person to be the bar here. I'm more than willing > to admit my limitations and obviously this is a limitation I face. > > If Doug is willing to take this task, I'd be glad to give him CVS write > access which is more than overdue as he is the official maintainer now :) > He then could optionally give you write access if your changes are fine > and you represent a bar for new changes. I trust Doug. > > We do take the bar seriously as you can see. But it is not intended to > prevent fair use of RXTX or prevent facilitating new uses. If we don't > manage expectations here, there will be all sorts of problems and issues. > > -- > Trent Jarvi > tjarvi at qbang.org > > Trent, What I want to send you is not a modification to rxtx, it just a developers helper if you want to put a name to it. I have make an IzPack installer, which installs RXTX binaries depending on underlaying OS. And make an JSmooth warper that launches my app with out the need to have rxtx installed on the host JVM folder, it only need the RXTX to be in the bin\ of my app. I think this is more useful for Wiki than to the main project. Another thing I have experience in PalmOS programming, when ever I have time, I will investigate about the JNI of J2ME and try to port RXTX to Palm, I do not know when I will start, because I have a lot of work now. Regards, Manuel From christopher.dawes at the-logic-group.com Mon Jul 10 08:00:15 2006 From: christopher.dawes at the-logic-group.com (christopher.dawes@the-logic-group.com) Date: Mon, 10 Jul 2006 15:00:15 +0100 Subject: [Rxtx] Chris Dawes/Retaillogic/NISABA is out of the office. Message-ID: I will be out of the office starting 10/07/2006 and will not return until 11/07/2008. Hello, unfortunately I no longer work for The Logic Group, if you're trying to contact me on a work related issue please contact Pete Avery (pete.avery at the-logic-group.com) however if it is a personal matter please e-mail root at ants.me.uk or phone 07899 842 759. Thanks Christopher Dawes From tjarvi at qbang.org Mon Jul 10 08:19:52 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 10 Jul 2006 08:19:52 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607101447.25071.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607081330.24381.pascal@quies.net> <200607101447.25071.pascal@quies.net> Message-ID: On Mon, 10 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 10 juli 2006 14:07, schreef Trent Jarvi: >> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>> Op zaterdag 8 juli 2006 03:39, schreef Trent Jarvi: >>>> On Sat, 8 Jul 2006, Pascal S. de Kloe wrote: >>>>> Is the gnu.io namespace still necessary? I couldn't find the problem. >>>> >>>> Hi Pascal >>>> >>>> CommAPI is a little different in that it was grandfathered into the >>>> javax namespace with its own license at the time. >>>> >>>> It is my understanding that if CommAPI went through the JSR process, >>>> anyone would _clearly_ be able to implement a javax.comm package and >>>> RXTX would then be one of the first to do so. I believe Doug has >>>> expressed some interest in RXTX trying to work with the JSR process. >>>> >>>> Besides the license questions, there is the fact that RXTX has >>>> extensions to CommAPI which could cause confusion in the namespace. Not >>>> being a lawyer and *really* not liking to talk to lawyers in my free >>>> time, it is better to be safe than sorry. The lawyers tend to come in >>>> wolf packs when they do come. >>>> >>>> There is no attachment to the gnu.io namespace. But RXTX 2.1 will stay >>>> there as long as we are just geeks trying to figure out if a license >>>> does or does not allow us to implement in the javax.comm namespace. >>> >>> Nicely said. :) >>> >>> The whole point of namespaces is to create a universal registry of, in >>> this case, classes. This gnu.io namespace is very inconvenient. >>> >>> We feel the same way about lawyers. However I'd like to go into the >>> details of the license (see attachment) if you don't mind? >>> >>> The first license does not apply since RXTX does not use the software. >>> The second one at point 3 specifies our options. >>> >>>> 3. You may not modify the Java Platform Interface ("JPI", identified as >>>> classes contained within the "java" package or any subpackages of the >>>> "java" package), by creating additional classes within the JPI or >>>> otherwise causing the addition to or modification of the classes in the >>>> JPI. >>> >>> RXTX is a extension. >>> >>>> In the event that you create an additional class and associated API(s) >>>> which (i) extends the functionality of the Java platform, and (ii) is >>>> exposed to third party software developers for the purpose of developing >>>> additional software which invokes such additional API, you must promptly >>>> publish broadly an accurate specification for such API for free use by >>>> all developers. >>> >>> That's the way we operate. :) >>> >>>> You may not create, or authorize your licensees to create additional >>>> classes, interfaces, or subpackages that are in any way identified as >>>> "java", "javax", "sun" or similar convention as specified by Sun in any >>>> naming convention designation. >>> >>> They don't want additional components in the Communication API since they >>> don't want a mess in theire namespace. >>> >>> So we *can* use javax.comm for the core: >>> javax.comm.CommDriver >>> javax.comm.CommPort >>> javax.comm.CommPortIdentifier >>> javax.comm.CommPortOwnershipListener >>> javax.comm.NoSuchPortException >>> javax.comm.PortInUseException >>> javax.comm.UnsupportedCommOperationException >>> >>> ...and for the default hardware support: >>> javax.comm.SerialPort >>> javax.comm.SerialPortEvent >>> javax.comm.SerialPortEventListener >>> javax.comm.ParralelPort >>> javax.comm.ParralelPortEvent >>> javax.comm.ParralelPortEventListener >>> >>> ...but RXTX aditional hardware support has to go somewhere else like: >>> org.rxtx.RS485Port >>> org.rxtx.RS485PortEvent >>> org.rxtx.RS485PortEventListener >>> org.rxtx.I2CPort >>> org.rxtx.I2CPortEvent >>> org.rxtx.I2CPortEventListener >>> >>> Right? >> >> The one thing this discussion does not cover is in SerialPort.java. See >> the extensions to commapi listed after the following line: >> >> /* ---------------------- end of commapi ------------------------ */ >> >> The intent is not to break commapi but it could be perceived as so. The >> extensions added have been placed there as requested by users of RXTX. It >> would be nice to discuss these modifications with Sun and perhaps have >> some added to the final version of CommAPI. >> >> Some of them may not make sense while others do. Some can not be >> implemented in a platform neutral fashion. It would not make sense >> for RXTX to just bring these into Sun's namespace without due process. >> >> This is why I am fundamentally apposed to people "poisoning" Sun's >> namespace with RXTX 2.1 although I understand that is not their intent. >> >> These modifications are not advertised and their use is discouraged. But >> they are there. > > Hi Trent, > > So you are saying that gnu.io.SerialPort has some aditional methods over > javax.comm.SerialPort? > That does not change the API at all but it would be a problem if people would > start using those methods in the javax.comm namespace in the same way like > some people use the com.sun namespace. > Could wrapper classes at javax.comm do the job? In that way RXTX stays in its > namespace, javadoc can notice the aditional methods and the Communication API > will be available as expected. Hi Pascal Yes. There are additional methods in gnu.io.SerialPort. We clearly mark those as extensions to CommAPI and discourage their use. There just isn't a way to get the intended functionality out of CommAPI without them. I think the right thing to do here may be to remove these methods to avoid unintentional polution of the javax namespace if people are going to be putting these classes in that namespace. The way people are using RXTX 2.1 is not the same as it was originally pictured. Thats fine but we need to be responsible. We need to prevent what could be a problem. -- Trent Jarvi tjarvi at qbang.org From pascal at quies.net Mon Jul 10 08:57:10 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 10 Jul 2006 16:57:10 +0200 Subject: [Rxtx] Java installer In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101447.25071.pascal@quies.net> Message-ID: <200607101657.11223.pascal@quies.net> > Yes. There are additional methods in gnu.io.SerialPort. We clearly mark > those as extensions to CommAPI and discourage their use. There just isn't > a way to get the intended functionality out of CommAPI without them. If you don't want the users to use the methods then make them class protected (remove the word "public" before the method) and if you can't do that we might do the following: ---- SerialPort.java package javax.comm class SerialPort extends gnu.io.SerialPort { public void rxtxOnlyMethod() { throw new Error("Don't use this method here!\nUse gnu.io.SerialPort instead"); } ---- end From neville_seed at yahoo.com Mon Jul 10 10:20:12 2006 From: neville_seed at yahoo.com (neville seed) Date: Mon, 10 Jul 2006 09:20:12 -0700 (PDT) Subject: [Rxtx] writing first application and compiling In-Reply-To: Message-ID: <20060710162012.9888.qmail@web51015.mail.yahoo.com> Can anyone recommend a starting place for writing, compiling and uploading the first app, ie a simple hello world. It seems that the PALM SDK does not have a build environment. I am happy to develop under linux of windows. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From bob_tai2001 at yahoo.com Mon Jul 10 14:48:30 2006 From: bob_tai2001 at yahoo.com (Bob Tai) Date: Mon, 10 Jul 2006 13:48:30 -0700 (PDT) Subject: [Rxtx] Java installer Message-ID: <20060710204830.53745.qmail@web32810.mail.mud.yahoo.com> Hi Manuel, I found your post from the newsletter, hope I am not off topic. You mention there is a IZpack installer for Rxtx? I been waiting for this type of deplyment idea from Rxtx! is this documented in the web site? I am in windows environment but didn't want to create classpath for each workstation. I rather install :) I apologize for cutting into this topic. Bob > >Trent, >What I want to send you is not a modification to rxtx, it just a >developers helper if you want to put a name to it. I have make an IzPack installer, which installs RXTX binaries depending on underlaying OS. And make an JSmooth warper that launches my app with out the need to have rxtx installed on the host JVM folder, it only need the RXTX to be in the bin\ of my app. I think this is more useful for Wiki than to the main project. Another thing I have experience in PalmOS programming, when ever I have time, I will investigate about the JNI of J2ME and try to port RXTX to Palm, I do not know when I will start, because I have a lot of work now. Regards, Manuel __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From naranjo.manuel at gmail.com Mon Jul 10 15:10:21 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Mon, 10 Jul 2006 18:10:21 -0300 Subject: [Rxtx] Java installer In-Reply-To: <20060710204830.53745.qmail@web32810.mail.mud.yahoo.com> References: <20060710204830.53745.qmail@web32810.mail.mud.yahoo.com> Message-ID: <44B2C23D.8050901@gmail.com> Bob, Hi, not this is not a RXTX installer, I have develop an installer with IzPack which actually installs RXTX and my hole app, and I think this can be useful for RXTX users, Regards, Manuel > Hi Manuel, > > I found your post from the newsletter, hope I am not > off topic. You mention there is a IZpack installer > for Rxtx? I been waiting for this type of deplyment > idea from Rxtx! is this documented in the web site? > I am in windows environment but didn't want to create > classpath for each workstation. I rather install :) > > I apologize for cutting into this topic. > > Bob > >> Trent, >> What I want to send you is not a modification to > rxtx, it just a >> developers > helper if you want to put a name to it. I have make an > IzPack > installer, > which installs RXTX binaries depending on underlaying > OS. And make an > JSmooth warper that launches my app with out the need > to have rxtx > installed > on the host JVM folder, it only need the RXTX to be in > the bin\ of my > app. > I think this is more useful for Wiki than to the main > project. > Another thing I have experience in PalmOS programming, > when ever I have > time, > I will investigate about the JNI of J2ME and try to > port RXTX to Palm, > I do not know when I will start, because I have a lot > of work now. > Regards, > Manuel > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From brian at mbari.org Tue Jul 11 11:59:24 2006 From: brian at mbari.org (Brian Schlining) Date: Tue, 11 Jul 2006 10:59:24 -0700 Subject: [Rxtx] rxtx can not read data from serialport In-Reply-To: References: <44AC7902.8070407@adventnet.com> Message-ID: <485C28F0-CA08-4393-9E34-4C8E7F22C125@mbari.org> Hi Trent, On Jul 7, 2006, at 6:15 PM, Trent Jarvi wrote: > On Fri, 7 Jul 2006, Brian Schlining wrote: >> Also, for some command/response applications that I've tried with >> RXTX, I >> find that if I write to the serialport and then immediately try to >> read from >> it I get byte arrays filled with zeros, no matter what I set the >> recieveTimeout to (this has occurred on both Mac OS X and >> Windows). The >> workaround that I found was to very briefly put the I/O thread to >> sleep, like >> so: >> >> // DO set up and get I/O streams >> //in = serialPort.getInputStream(); >> //out = serialPort.getOutputStream(); >> >> out.write(someByteArray); >> try { >> Thread.sleep(10); >> catch (InterruptedException e) { >> // handle exception >> } >> in.read(anotherByteArray); >> >> Note: I've never had to put the thread to sleep using Java comm, >> only with >> RXTX. Anyone know why this might be? > > Hi Brian > > Interesting. Is this something that can be reproduced with a loopback > connection or something commonly available? I was unaware of this > behavior. Is it restricted to something that quickly opens, > writes, reads > and closes the port by chance? I've encountered this while using RXTX to talk to VCR's that support RS422; I've never tried it with a loopback connection. Note that connection setup is: PC[RS232] <---> RS232/422 Converter <---> VCR[RS422] The application I'm using it for opens a connection and keeps it open for the life of the application. It makes a lot of read and writes when running...probably about as fast as the VCR hardware supports; with Javacomm, I think it was on the order of an IO transaction every 40ms. However even if I perform an IO read/write every 2 seconds with RXTX I still encounter the same problem, so it's not a matter of the frequency of the IO transactions. If you want to look at the code a test example can be found at https://svn.sourceforge.net/svnroot/vars/trunk/vars/src/test/java/ test/org/mbari/vcr/SimpleReadRxtx.java. The actual production code is at https://svn.sourceforge.net/svnroot/vars/trunk/vars/src/main/java/ org/mbari/vcr/rs422/VCR.java. The methods that you might be interested in to see how the code is used are initComm(), sendCommand (), getResponse() in VCR.java. You'll notice Thread.sleep(IO_DELAY) sprinkled in the sendCommand() methods and getResponse(). Without that I get arrays of zeros returned. If the IO_DELAY is less than 15ms then sending commands works fine but reading the responses is not reliable; I mostly get problems when trying to read the last few bytes or a response. Again, everything works fine with Sun's Javacomm w/o the Thread.sleep() on windows. Also, FYI, I tried to run this on a Mac using RXTX 2.0, but I ran into thread synchronization issues. These issues went away when I switched to RXTX 2.1. Cheers B ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Brian Schlining MBARI Software Engineer brian at mbari.org (831)775-1855 http://www.mbari.org/staff/brian I went to the woods because I wished to live deliberately, to front only the essential facts of life, and see if I could not learn what it had to teach, and not, when I came to die, discover that I had not lived. ~ Henry Thoreau -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060711/59b607f3/attachment-0355.html From ajmas at sympatico.ca Wed Jul 12 13:46:51 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Wed, 12 Jul 2006 15:46:51 -0400 Subject: [Rxtx] writing first application and compiling Message-ID: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Hi, Take a look in the Wiki. I have added a couple of examples in there: http://rxtx.qbang.org/wiki/index.php/Examples Andre > > From: neville seed > Date: 2006/07/10 Mon PM 12:20:12 EDT > To: RXTX Developers and Users > Subject: [Rxtx] writing first application and compiling > > > Can anyone recommend a starting place for writing, > compiling and uploading the first app, ie a simple > hello world. > > It seems that the PALM SDK does not have a build > environment. I am happy to develop under linux of windows. > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Wed Jul 12 19:22:25 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 12 Jul 2006 19:22:25 -0600 (MDT) Subject: [Rxtx] writing first application and compiling In-Reply-To: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> References: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: Thank you for doing this Andre. I'm sure it will get well used by people learning. I think the old commapi examples are no longer easily available so these are really needed. On Wed, 12 Jul 2006, Andre-John Mas wrote: > Hi, > > Take a look in the Wiki. I have added a couple of examples in there: > > http://rxtx.qbang.org/wiki/index.php/Examples > > Andre > >> >> From: neville seed >> Date: 2006/07/10 Mon PM 12:20:12 EDT >> To: RXTX Developers and Users >> Subject: [Rxtx] writing first application and compiling >> >> >> Can anyone recommend a starting place for writing, >> compiling and uploading the first app, ie a simple >> hello world. >> >> It seems that the PALM SDK does not have a build >> environment. I am happy to develop under linux of windows. >> >> __________________________________________________ >> Do You Yahoo!? >> Tired of spam? Yahoo! Mail has the best spam protection around >> http://mail.yahoo.com >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Thu Jul 13 17:21:26 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Thu, 13 Jul 2006 19:21:26 -0400 Subject: [Rxtx] writing first application and compiling In-Reply-To: References: <20060712194651.JAYS1747.tomts25-srv.bellnexxia.net@smtp1.sympatico.ca> Message-ID: <54D55D35-A143-43AA-AF03-B89ADE9B9246@sympatico.ca> No problems. I would also like to encourage anyone else to contribute other useful stuff they might have. On 12-Jul-06, at 21:22 , Trent Jarvi wrote: > > Thank you for doing this Andre. > > I'm sure it will get well used by people learning. I think the old > commapi examples are no longer easily available so these are really > needed. > > On Wed, 12 Jul 2006, Andre-John Mas wrote: > >> Hi, >> >> Take a look in the Wiki. I have added a couple of examples in there: >> >> http://rxtx.qbang.org/wiki/index.php/Examples >> >> Andre >> >>> >>> From: neville seed >>> Date: 2006/07/10 Mon PM 12:20:12 EDT >>> To: RXTX Developers and Users >>> Subject: [Rxtx] writing first application and compiling >>> >>> >>> Can anyone recommend a starting place for writing, >>> compiling and uploading the first app, ie a simple >>> hello world. >>> >>> It seems that the PALM SDK does not have a build >>> environment. I am happy to develop under linux of windows. >>> >>> __________________________________________________ >>> Do You Yahoo!? >>> Tired of spam? Yahoo! Mail has the best spam protection around >>> http://mail.yahoo.com >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Sat Jul 8 15:05:46 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Sat, 08 Jul 2006 17:05:46 -0400 Subject: [Rxtx] License question. In-Reply-To: <200607082219.59514.pascal@quies.net> References: <44AFBB4E.70808@gmail.com> <200607082219.59514.pascal@quies.net> Message-ID: <44B01E2A.9010207@suespammers.org> Pascal S. de Kloe wrote: > I thought of the same thing. The modified BSD license would certainly make it > more eazy and acceptable for Sun to include RXTX in theire products. > > Unfortunately in general people who chose GPL don't like other licenses. ;) i have a general preference for BSD, but i'll defend RXTX here. RXTX is LGPL, not GPL. they're different, look it up. richard From pascal at quies.net Sun Jul 16 17:40:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 17 Jul 2006 01:40:13 +0200 Subject: [Rxtx] Java installer In-Reply-To: <200607101657.11223.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> Message-ID: <200607170140.14116.pascal@quies.net> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: > > Yes. There are additional methods in gnu.io.SerialPort. We clearly mark > > those as extensions to CommAPI and discourage their use. There just > > isn't a way to get the intended functionality out of CommAPI without > > them. > > If you don't want the users to use the methods then make them class > protected (remove the word "public" before the method) and if you can't do > that we might do the following: > > ---- SerialPort.java > package javax.comm > > class SerialPort extends gnu.io.SerialPort { > > public void > rxtxOnlyMethod() { > throw new Error("Don't use this method here!\nUse gnu.io.SerialPort > instead"); > } > ---- end So how about it, Trent? Can we ship those classes with the next release? From pascal at quies.net Sun Jul 16 17:45:42 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 17 Jul 2006 01:45:42 +0200 Subject: [Rxtx] Fwd: Re: Java installer In-Reply-To: <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> References: <200607081944.41123.pascal@quies.net> <200607091701.24661.pascal@quies.net> <89CE16E2-25E2-475A-A968-DC9B3631FD1B@buechse.de> Message-ID: <200607170145.43156.pascal@quies.net> Op maandag 10 juli 2006 10:53, schreef Joachim Buechse: > Alternatively you could also include the native lib in your > application jar, extract it at runtime to a temp file, load it with > System.load(). That works indeed. :) I'll finish my "detection class" with such a loader and the RXTX package tomorrow. Then one can simply include the JAR in the classpath and run org.rxtx.CommunicationAPI.initialize() to make sure the API is available. From tjarvi at qbang.org Sun Jul 16 18:59:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 16 Jul 2006 18:59:06 -0600 (MDT) Subject: [Rxtx] Java installer In-Reply-To: <200607170140.14116.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> <200607170140.14116.pascal@quies.net> Message-ID: On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>> Yes. There are additional methods in gnu.io.SerialPort. We clearly mark >>> those as extensions to CommAPI and discourage their use. There just >>> isn't a way to get the intended functionality out of CommAPI without >>> them. >> >> If you don't want the users to use the methods then make them class >> protected (remove the word "public" before the method) and if you can't do >> that we might do the following: >> >> ---- SerialPort.java >> package javax.comm >> >> class SerialPort extends gnu.io.SerialPort { >> >> public void >> rxtxOnlyMethod() { >> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >> instead"); >> } >> ---- end > > So how about it, Trent? > > Can we ship those classes with the next release? Hi Pascal I'm not going to say what people can or can not ship. I'm going to propose removing all of the above extensions from SerialPort.java. I think it is the best thing to do after cooling off a bit. But thats all I've considered at this point. I'm in favor of removing the extensions and staying in gnu.io which more importantly means staying at arms length from javax. I can remove the extensions, put a windows fix in, bump the versions and tag the releases without changing packages if everyone agrees to that. If people want to know why CommAPI has not gone through a JSR which makes it clear rxtx can be in javax.comm and explains how conformancy is determined, I do not think this is the right forum though you can freely do so. -- Trent Jarvi tjarvi at qbang.org From phillip at uow.edu.au Sun Jul 16 22:08:30 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Mon, 17 Jul 2006 14:08:30 +1000 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application" in Mac OSX Message-ID: Hi I downloaded RXTX 2.1-7r2 http://rxtx.org/ (latest download), found the MacOSX folder, manually installed RXTXcomm.jar and librxtxSerial.jnilib in / Library/Java/Extensions and manually setup /var/spool/ucp and became a member of it. I have tried two programs (both built in XCode - TwoWaySerialComm and SerialDemo). Both can find the serial ports but throw a 'port in use exception' with the error "Unknown Application" when I try to open the port. The following is part of the code of TwoWaySerialComm void connect ( String portName ) throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier(portName); if ( portIdentifier.isCurrentlyOwned() ) { System.out.println("Error: Port is currently in use"); } else { System.out.println("Current owner is " + portIdentifier.getCurrentOwner()); System.out.println("Name is " + this.getClass().getName()); CommPort commPort = portIdentifier.open(this.getClass ().getName(),2000); //throws exception if ( commPort instanceof SerialPort ) The method connect is called from main: public static void main ( String[] args ) { try { listPorts(); (new TwoWaySerialComm()).connect("/dev/tty.KeySerial1"); The following is the console run log of a program TwoWaySerialComm [Session started at 2006-07-14 14:50:29 +1000.] Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 /dev/tty.modem - Serial /dev/cu.modem - Serial /dev/tty.KeySerial1 - Serial /dev/cu.KeySerial1 - Serial /dev/tty.USA28X2b2P2.2 - Serial /dev/cu.USA28X2b2P2.2 - Serial 6 ports found Current owner is null Name is TwoWaySerialComm gnu.io.PortInUseException: Unknown Application at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) at TwoWaySerialComm.connect(TwoWaySerialComm.java:48) at TwoWaySerialComm.main(TwoWaySerialComm.java:163) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at apple.launcher.LaunchRunner.run(LaunchRunner.java:88) at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:50) at apple.launcher.JavaApplicationLauncher.launch (JavaApplicationLauncher.java:52) TwoWaySerialComm has exited with status 0. I am stuck, Can you help me please. thanks Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From pascal at quies.net Mon Jul 17 06:12:09 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 17 Jul 2006 14:12:09 +0200 Subject: [Rxtx] JSR In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607170140.14116.pascal@quies.net> Message-ID: <200607171412.09571.pascal@quies.net> Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: > On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > > Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: > >>> Yes. There are additional methods in gnu.io.SerialPort. We clearly > >>> mark those as extensions to CommAPI and discourage their use. There > >>> just isn't a way to get the intended functionality out of CommAPI > >>> without them. > >> > >> If you don't want the users to use the methods then make them class > >> protected (remove the word "public" before the method) and if you can't > >> do that we might do the following: > >> > >> ---- SerialPort.java > >> package javax.comm > >> > >> class SerialPort extends gnu.io.SerialPort { > >> > >> public void > >> rxtxOnlyMethod() { > >> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort > >> instead"); > >> } > >> ---- end > > > > So how about it, Trent? > > > > Can we ship those classes with the next release? > > Hi Pascal > > I'm not going to say what people can or can not ship. I'm going to > propose removing all of the above extensions from SerialPort.java. I > think it is the best thing to do after cooling off a bit. > > But thats all I've considered at this point. I'm in favor of removing the > extensions and staying in gnu.io which more importantly means staying at > arms length from javax. > > I can remove the extensions, put a windows fix in, bump the versions and > tag the releases without changing packages if everyone agrees to that. > If people want to know why CommAPI has not gone through a JSR which makes > it clear rxtx can be in javax.comm and explains how conformancy is > determined, I do not think this is the right forum though you can freely > do so. Hi Trent, If I understand it correctly you don't want to put those javax.comm classes in the distribution until a JSR completes. :( Sun wants a JSR too to change the API: > Ultimately the COMMAPI would be better served if a Java > Community Process JSR (http://www.jcp.org) was opened and > the COMMAPI was rearchitected to provide a more pluggable > framework to improve cross-platform support. Such an > architecture would embody a better defined and better > documented SPI interface, including a way for comm. ports > to be revealed to the client application through the API > via platform-aware plugins. Similarly, native code used > to access comm port in general could be handled more > flexibly using a plugin model, whereby on any platform, > multiple native modules could be in use simultaneously. How about it? I can spend 5 hours a week. From tjarvi at qbang.org Mon Jul 17 07:32:06 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 07:32:06 -0600 (MDT) Subject: [Rxtx] JSR In-Reply-To: <200607171412.09571.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607170140.14116.pascal@quies.net> <200607171412.09571.pascal@quies.net> Message-ID: On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: >> On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: >>> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>>> Yes. There are additional methods in gnu.io.SerialPort. We clearly >>>>> mark those as extensions to CommAPI and discourage their use. There >>>>> just isn't a way to get the intended functionality out of CommAPI >>>>> without them. >>>> >>>> If you don't want the users to use the methods then make them class >>>> protected (remove the word "public" before the method) and if you can't >>>> do that we might do the following: >>>> >>>> ---- SerialPort.java >>>> package javax.comm >>>> >>>> class SerialPort extends gnu.io.SerialPort { >>>> >>>> public void >>>> rxtxOnlyMethod() { >>>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>>> instead"); >>>> } >>>> ---- end >>> >>> So how about it, Trent? >>> >>> Can we ship those classes with the next release? >> >> Hi Pascal >> >> I'm not going to say what people can or can not ship. I'm going to >> propose removing all of the above extensions from SerialPort.java. I >> think it is the best thing to do after cooling off a bit. >> >> But thats all I've considered at this point. I'm in favor of removing the >> extensions and staying in gnu.io which more importantly means staying at >> arms length from javax. >> >> I can remove the extensions, put a windows fix in, bump the versions and >> tag the releases without changing packages if everyone agrees to that. >> If people want to know why CommAPI has not gone through a JSR which makes >> it clear rxtx can be in javax.comm and explains how conformancy is >> determined, I do not think this is the right forum though you can freely >> do so. > > Hi Trent, > > If I understand it correctly you don't want to put those javax.comm classes in > the distribution until a JSR completes. :( > > Sun wants a JSR too to change the API: >> Ultimately the COMMAPI would be better served if a Java >> Community Process JSR (http://www.jcp.org) was opened and >> the COMMAPI was rearchitected to provide a more pluggable >> framework to improve cross-platform support. Such an >> architecture would embody a better defined and better >> documented SPI interface, including a way for comm. ports >> to be revealed to the client application through the API >> via platform-aware plugins. Similarly, native code used >> to access comm port in general could be handled more >> flexibly using a plugin model, whereby on any platform, >> multiple native modules could be in use simultaneously. > > How about it? I can spend 5 hours a week. Yes. I'm all in favor of this. Dr. Doug Lyon is our fearless leader in these matters and has final say. He has asked everyone if they have an issue with going through the JSR. I have seen no responses though some may have responeded to him in private. I am now working for The MathWorks in a related field. To best represent the RXTX community, we have asked Doug to be the neutral maintainer. This does not mean he is taking on all the work like making releases. He has the ability to and the power. But thats not really spending his time efficiently. It does mean when there are decisions to be made that may have conflicts, he has final say. The easy solution :) is to bug Trent or Doug and see if they will just go into javax.comm namespace. The right solution is to work with Doug and try to get the JSR process completed. I'm willing to help too as time permits. I'm willing to work with Doug. -- Trent Jarvi tjarvi at qbang.org From ajmas at sympatico.ca Mon Jul 17 09:11:20 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 17 Jul 2006 11:11:20 -0400 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Message-ID: <20060717151120.RSBG13653.tomts36-srv.bellnexxia.net@smtp1.sympatico.ca> I am told that this is an issue that will be resolved in 2.1-8. The changes are already in version control, so you can use that. I have and it resolved the problem for me. Phillip McKerrow wrote: > > Hi > > I downloaded RXTX 2.1-7r2 http://rxtx.org/ (latest download), > found the MacOSX folder, > manually installed RXTXcomm.jar and librxtxSerial.jnilib in / > Library/Java/Extensions and > manually setup /var/spool/ucp and became a member of it. > > I have tried two programs (both built in XCode - TwoWaySerialComm and > SerialDemo). Both can find the serial ports but throw a 'port in use > exception' with the error "Unknown Application" when I try to open > the port. > > The following is part of the code of TwoWaySerialComm > void connect ( String portName ) throws Exception > { > CommPortIdentifier portIdentifier = > CommPortIdentifier.getPortIdentifier(portName); > if ( portIdentifier.isCurrentlyOwned() ) > { > System.out.println("Error: Port is currently in use"); > } > else > { > System.out.println("Current owner is " + > portIdentifier.getCurrentOwner()); > System.out.println("Name is " + this.getClass().getName()); > CommPort commPort = portIdentifier.open(this.getClass > ().getName(),2000); //throws exception > > if ( commPort instanceof SerialPort ) > > > The method connect is called from main: > public static void main ( String[] args ) > { > try > { > listPorts(); > (new TwoWaySerialComm()).connect("/dev/tty.KeySerial1"); > > > The following is the console run log of a program TwoWaySerialComm > [Session started at 2006-07-14 14:50:29 +1000.] > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > /dev/tty.modem - Serial > /dev/cu.modem - Serial > /dev/tty.KeySerial1 - Serial > /dev/cu.KeySerial1 - Serial > /dev/tty.USA28X2b2P2.2 - Serial > /dev/cu.USA28X2b2P2.2 - Serial > 6 ports found > Current owner is null > Name is TwoWaySerialComm > gnu.io.PortInUseException: Unknown Application > at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:354) > at TwoWaySerialComm.connect(TwoWaySerialComm.java:48) > at TwoWaySerialComm.main(TwoWaySerialComm.java:163) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at apple.launcher.LaunchRunner.run(LaunchRunner.java:88) > at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:50) > at apple.launcher.JavaApplicationLauncher.launch > (JavaApplicationLauncher.java:52) > > TwoWaySerialComm has exited with status 0. > > I am stuck, Can you help me please. > > thanks > Phillip > > > ---------------------------------------------------------------------- > Phillip McKerrow http:// > www.uow.edu.au/~phillip/ > School of Information Technology and Computer Science > University of Wollongong * > Northfields Avenue, * * > Wollongong, NSW, 2522. + > AUSTRALIA * the land of the > southern cross > tel : +61 2 4221 3771 fax : +61 2 4221 4170 > > God so loved the world that he gave his one and only Son (Jesus), > that whoever believes in him shall not perish but have eternal life. > John 3:16 > ---------------------------------------------------------------------- > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From lyon at docjava.com Mon Jul 17 10:34:14 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 17 Jul 2006 12:34:14 -0400 Subject: [Rxtx] summary of issues In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607170140.14116.pascal@quies.net> <200607171412.09571.pascal@quies.net> Message-ID: Hi All, As I see it, at this stage of the discussion, I think it would be helpful to summarize the concerns. Let me see if I can get this straight, and please correct me, if I am wrong: 1. Sun is making no progress on improving the CommAPI spec. 2. We are seeking to reinvigorate a JSR for the CommAPI in order to keep sun involved. 3. Meanwhile we are extending the RXTX API, with non- commAPI improvements. 4. People are worried that the improvements will be non-portable, when the commAPI re-activates. 5. I have asked for feedback on the JSR approach and obtained zero response. 6. My limited imagination does not see any drawback to taking the JSR approach (except, possibly, from the overhead of a committee, or some license issue that I do not understand). 7. http://www.jcp.org/en/jsr/detail?id=922 shows the status of the JSR now. Status: Withdrawn The sun contact is: vincent.zhang at sun.com I have written to Vincent at Sun to ask him what would be involved with reactivation of JSR 922. If I hear back I will let you know. If there are any objections or suggestions, please let me know. Thanks! - Doug >On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > >> Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: >>> On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: >>>> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>>>> Yes. There are additional methods in gnu.io.SerialPort. We clearly >>>>>> mark those as extensions to CommAPI and discourage their use. There >>>>>> just isn't a way to get the intended functionality out of CommAPI >>>>>> without them. >>>>> >>>>> If you don't want the users to use the methods then make them class >>>>> protected (remove the word "public" before the method) and if you can't >>>>> do that we might do the following: >>>>> >>>>> ---- SerialPort.java >>>>> package javax.comm >>>>> >>>>> class SerialPort extends gnu.io.SerialPort { >>>>> >>>>> public void >>>>> rxtxOnlyMethod() { >>>>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>>>> instead"); >>>>> } >>>>> ---- end >>>> >>>> So how about it, Trent? >>>> >>>> Can we ship those classes with the next release? >>> >>> Hi Pascal >>> >>> I'm not going to say what people can or can not ship. I'm going to >>> propose removing all of the above extensions from SerialPort.java. I >>> think it is the best thing to do after cooling off a bit. >>> >>> But thats all I've considered at this point. I'm in favor of removing the >>> extensions and staying in gnu.io which more importantly means staying at >>> arms length from javax. >>> >>> I can remove the extensions, put a windows fix in, bump the versions and >>> tag the releases without changing packages if everyone agrees to that. >>> If people want to know why CommAPI has not gone through a JSR which makes >>> it clear rxtx can be in javax.comm and explains how conformancy is >>> determined, I do not think this is the right forum though you can freely >>> do so. >> >> Hi Trent, >> >> If I understand it correctly you don't want to put those >>javax.comm classes in >> the distribution until a JSR completes. :( >> >> Sun wants a JSR too to change the API: >>> Ultimately the COMMAPI would be better served if a Java >>> Community Process JSR (http://www.jcp.org) was opened and >>> the COMMAPI was rearchitected to provide a more pluggable >>> framework to improve cross-platform support. Such an >>> architecture would embody a better defined and better >>> documented SPI interface, including a way for comm. ports >>> to be revealed to the client application through the API >>> via platform-aware plugins. Similarly, native code used >>> to access comm port in general could be handled more >>> flexibly using a plugin model, whereby on any platform, >>> multiple native modules could be in use simultaneously. >> >> How about it? I can spend 5 hours a week. > >Yes. I'm all in favor of this. Dr. Doug Lyon is our fearless leader in >these matters and has final say. He has asked everyone if they have an >issue with going through the JSR. I have seen no responses though some >may have responeded to him in private. > >I am now working for The MathWorks in a related field. To best represent >the RXTX community, we have asked Doug to be the neutral maintainer. >This does not mean he is taking on all the work like making releases. He >has the ability to and the power. But thats not really spending his time >efficiently. It does mean when there are decisions to be made that may >have conflicts, he has final say. > >The easy solution :) is to bug Trent or Doug and see if they will just go >into javax.comm namespace. The right solution is to work with Doug and >try to get the JSR process completed. I'm willing to help too as time >permits. > >I'm willing to work with Doug. > >-- >Trent Jarvi >tjarvi at qbang.org >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From ajmas at sympatico.ca Mon Jul 17 11:31:58 2006 From: ajmas at sympatico.ca (Andre-John Mas) Date: Mon, 17 Jul 2006 13:31:58 -0400 Subject: [Rxtx] JSR Message-ID: <20060717173158.USWI24981.tomts40-srv.bellnexxia.net@smtp1.sympatico.ca> In the meantime could these methods not be added to a child class. This way the extra functionality can be provided, but you would have to explictly check to see of the class is an RXTX specifc interface. For example: class RxTxCommPort extends CommPort { //RxTx specific methods } CommPort port = commPortIdentifierInstance.open(...); if ( port instanceof RxTxCommPort ) { // do RxTx specifc stuff } // continue doing usual stuff Andre > > From: "Pascal S. de Kloe" > Date: 2006/07/17 Mon AM 08:12:09 EDT > To: RXTX Developers and Users > Subject: [Rxtx] JSR > > Op maandag 17 juli 2006 02:59, schreef Trent Jarvi: > > On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > > > Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: > > >>> Yes. There are additional methods in gnu.io.SerialPort. We clearly > > >>> mark those as extensions to CommAPI and discourage their use. There > > >>> just isn't a way to get the intended functionality out of CommAPI > > >>> without them. > > >> > > >> If you don't want the users to use the methods then make them class > > >> protected (remove the word "public" before the method) and if you can't > > >> do that we might do the following: > > >> > > >> ---- SerialPort.java > > >> package javax.comm > > >> > > >> class SerialPort extends gnu.io.SerialPort { > > >> > > >> public void > > >> rxtxOnlyMethod() { > > >> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort > > >> instead"); > > >> } > > >> ---- end > > > > > > So how about it, Trent? > > > > > > Can we ship those classes with the next release? > > > > Hi Pascal > > > > I'm not going to say what people can or can not ship. I'm going to > > propose removing all of the above extensions from SerialPort.java. I > > think it is the best thing to do after cooling off a bit. > > > > But thats all I've considered at this point. I'm in favor of removing the > > extensions and staying in gnu.io which more importantly means staying at > > arms length from javax. > > > > I can remove the extensions, put a windows fix in, bump the versions and > > tag the releases without changing packages if everyone agrees to that. > > If people want to know why CommAPI has not gone through a JSR which makes > > it clear rxtx can be in javax.comm and explains how conformancy is > > determined, I do not think this is the right forum though you can freely > > do so. > > Hi Trent, > > If I understand it correctly you don't want to put those javax.comm classes in > the distribution until a JSR completes. :( > > Sun wants a JSR too to change the API: > > Ultimately the COMMAPI would be better served if a Java > > Community Process JSR (http://www.jcp.org) was opened and > > the COMMAPI was rearchitected to provide a more pluggable > > framework to improve cross-platform support. Such an > > architecture would embody a better defined and better > > documented SPI interface, including a way for comm. ports > > to be revealed to the client application through the API > > via platform-aware plugins. Similarly, native code used > > to access comm port in general could be handled more > > flexibly using a plugin model, whereby on any platform, > > multiple native modules could be in use simultaneously. > > How about it? I can spend 5 hours a week. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From joachim at buechse.de Mon Jul 17 11:59:19 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 17 Jul 2006 19:59:19 +0200 Subject: [Rxtx] Bumping versions In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> <200607170140.14116.pascal@quies.net> Message-ID: <6ABAF770-41AE-4BA0-800D-2DCC8025FCA8@buechse.de> Hello Trent, I would appreciate if we could get to a version 2.1.8. In fact as several recent posting have shown, almost anyone working on OSX would appreciate getting there. Should anything be removed before that? I dont know. There is nothing wrong with having 2.1.9 following shortly after 2.1.8. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 17.07.2006, at 02:59, Trent Jarvi wrote: > On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: > >> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>> Yes. There are additional methods in gnu.io.SerialPort. We >>>> clearly mark >>>> those as extensions to CommAPI and discourage their use. There >>>> just >>>> isn't a way to get the intended functionality out of CommAPI >>>> without >>>> them. >>> >>> If you don't want the users to use the methods then make them class >>> protected (remove the word "public" before the method) and if you >>> can't do >>> that we might do the following: >>> >>> ---- SerialPort.java >>> package javax.comm >>> >>> class SerialPort extends gnu.io.SerialPort { >>> >>> public void >>> rxtxOnlyMethod() { >>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>> instead"); >>> } >>> ---- end >> >> So how about it, Trent? >> >> Can we ship those classes with the next release? > > Hi Pascal > > I'm not going to say what people can or can not ship. I'm going to > propose removing all of the above extensions from SerialPort.java. I > think it is the best thing to do after cooling off a bit. > > But thats all I've considered at this point. I'm in favor of > removing the > extensions and staying in gnu.io which more importantly means > staying at > arms length from javax. > > I can remove the extensions, put a windows fix in, bump the > versions and > tag the releases without changing packages if everyone agrees to that. > If people want to know why CommAPI has not gone through a JSR which > makes > it clear rxtx can be in javax.comm and explains how conformancy is > determined, I do not think this is the right forum though you can > freely > do so. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Mon Jul 17 12:40:32 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 12:40:32 -0600 (MDT) Subject: [Rxtx] Bumping versions In-Reply-To: <6ABAF770-41AE-4BA0-800D-2DCC8025FCA8@buechse.de> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607101657.11223.pascal@quies.net> <200607170140.14116.pascal@quies.net> <6ABAF770-41AE-4BA0-800D-2DCC8025FCA8@buechse.de> Message-ID: Hi Joachim I will work with you towards that. I'm going to the Linux Symposium this week which should mean I have time to tinker. I'll work on rxtx while riding in a carpool to Ottawa. On Mon, 17 Jul 2006, Joachim Buechse wrote: > Hello Trent, > > I would appreciate if we could get to a version 2.1.8. In fact as > several recent posting have shown, almost anyone working on OSX would > appreciate getting there. Should anything be removed before that? I > dont know. There is nothing wrong with having 2.1.9 following shortly > after 2.1.8. > > Regards, > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > On 17.07.2006, at 02:59, Trent Jarvi wrote: > >> On Mon, 17 Jul 2006, Pascal S. de Kloe wrote: >> >>> Op maandag 10 juli 2006 16:57, schreef Pascal S. de Kloe: >>>>> Yes. There are additional methods in gnu.io.SerialPort. We >>>>> clearly mark >>>>> those as extensions to CommAPI and discourage their use. There >>>>> just >>>>> isn't a way to get the intended functionality out of CommAPI >>>>> without >>>>> them. >>>> >>>> If you don't want the users to use the methods then make them class >>>> protected (remove the word "public" before the method) and if you >>>> can't do >>>> that we might do the following: >>>> >>>> ---- SerialPort.java >>>> package javax.comm >>>> >>>> class SerialPort extends gnu.io.SerialPort { >>>> >>>> public void >>>> rxtxOnlyMethod() { >>>> throw new Error("Don't use this method here!\nUse gnu.io.SerialPort >>>> instead"); >>>> } >>>> ---- end >>> >>> So how about it, Trent? >>> >>> Can we ship those classes with the next release? >> >> Hi Pascal >> >> I'm not going to say what people can or can not ship. I'm going to >> propose removing all of the above extensions from SerialPort.java. I >> think it is the best thing to do after cooling off a bit. >> >> But thats all I've considered at this point. I'm in favor of >> removing the >> extensions and staying in gnu.io which more importantly means >> staying at >> arms length from javax. >> >> I can remove the extensions, put a windows fix in, bump the >> versions and >> tag the releases without changing packages if everyone agrees to that. >> If people want to know why CommAPI has not gone through a JSR which >> makes >> it clear rxtx can be in javax.comm and explains how conformancy is >> determined, I do not think this is the right forum though you can >> freely >> do so. >> >> -- >> Trent Jarvi >> tjarvi at qbang.org >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From pascal at quies.net Mon Jul 17 17:54:56 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Tue, 18 Jul 2006 01:54:56 +0200 Subject: [Rxtx] summary of issues In-Reply-To: References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> Message-ID: <200607180154.56359.pascal@quies.net> Op maandag 17 juli 2006 18:34, schreef Dr. Douglas Lyon: > Hi All, > As I see it, at this stage of the discussion, I think it would be helpful > to summarize the concerns. Let me see if I can get this > straight, and please correct me, if I am wrong: Thank you. :) > 1. Sun is making no progress on improving the CommAPI spec. > 2. We are seeking to reinvigorate a JSR for the CommAPI in order > to keep sun involved. Sun wants a JSR becouse they have other concerns than a almost obsolete piece of hardware. > 3. Meanwhile we are extending the RXTX API, with non- > commAPI improvements. > 4. People are worried that the improvements will be non-portable, > when the commAPI re-activates. > 5. I have asked for feedback on the JSR approach and obtained > zero response. > 6. My limited imagination does not see any drawback to taking > the JSR approach (except, possibly, from the overhead of a committee, or > some license issue that I do not understand). > 7. http://www.jcp.org/en/jsr/detail?id=922 shows the status of the JSR now. > Status: Withdrawn > The sun contact is: vincent.zhang at sun.com > I have written to Vincent at Sun to ask him what would be involved with > reactivation of JSR 922. We don't need to communicate with the employees but we need a plan. We need a working implementation with a free license. They have offered us some ideas like in the 2.0.3 README (see attachment). Is there a plan based on the differences of the various platforms? Is there a API purposal? Is there a plan of the JNI? If not I am willing to help. I can write/represent the POSIX part with special interrest of the free UNIX systems. -------------- next part -------------- DISTRIBUTION NOTES: This distribution contains the comm.jar file original part of the COMMAPI 2.0.3 release. The 2.0.3 release itself is no longer distributed. comm.jar, which contains the comm API java class files (eg. Sun's binary implementation of the interface classes), is being made available, unsupported, with no obligation to fix bugs, at the request of the RXTX project. The RxTx project (http://www.rxtx.org), uses the comm.jar class files, but provides their own native library components to provide support for other platforms. The 2.0.3 comm.jar is being provided in this way because as of COMMAPI 3.x, the java binary implementation forked and became incompatible with the RxTx project's native code. Due to the lack of a clear business case, and to resource constraints, no additional resources are being provided to provide an alternative engineering solution at the time of writing. RECOMMENDATIONS FOR THE FUTURE OF COMMAPI: Ultimately the COMMAPI would be better served if a Java Community Process JSR (http://www.jcp.org) was opened and the COMMAPI was rearchitected to provide a more pluggable framework to improve cross-platform support. Such an architecture would embody a better defined and better documented SPI interface, including a way for comm. ports to be revealed to the client application through the API via platform-aware plugins. Similarly, native code used to access comm port in general could be handled more flexibly using a plugin model, whereby on any platform, multiple native modules could be in use simultaneously. Since there are now various ways serial ports can be implemented and accessed, modular comm. port JNI native libraries would be of benefit insofar as removing the burden of over-generalization from any single native component, or inversely, by relieving the implicit constraint that comm. drivers be accessed only via a monolithic mechanism, such as the UNIX vnode interface. paul.klissner at sun.com 6/10/06 From tjarvi at qbang.org Mon Jul 17 18:24:47 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 18:24:47 -0600 (MDT) Subject: [Rxtx] summary of issues In-Reply-To: <200607180154.56359.pascal@quies.net> References: <1dc101c6a1d7$9d109cb0$0a01a8c0@CALVIN> <200607180154.56359.pascal@quies.net> Message-ID: On Tue, 18 Jul 2006, Pascal S. de Kloe wrote: > Op maandag 17 juli 2006 18:34, schreef Dr. Douglas Lyon: >> Hi All, >> As I see it, at this stage of the discussion, I think it would be helpful >> to summarize the concerns. Let me see if I can get this >> straight, and please correct me, if I am wrong: > > Thank you. :) > >> 1. Sun is making no progress on improving the CommAPI spec. >> 2. We are seeking to reinvigorate a JSR for the CommAPI in order >> to keep sun involved. > > Sun wants a JSR becouse they have other concerns than a almost obsolete piece > of hardware. > >> 3. Meanwhile we are extending the RXTX API, with non- >> commAPI improvements. >> 4. People are worried that the improvements will be non-portable, >> when the commAPI re-activates. >> 5. I have asked for feedback on the JSR approach and obtained >> zero response. >> 6. My limited imagination does not see any drawback to taking >> the JSR approach (except, possibly, from the overhead of a committee, or >> some license issue that I do not understand). >> 7. http://www.jcp.org/en/jsr/detail?id=922 shows the status of the JSR now. >> Status: Withdrawn >> The sun contact is: vincent.zhang at sun.com >> I have written to Vincent at Sun to ask him what would be involved with >> reactivation of JSR 922. > > We don't need to communicate with the employees but we need a plan. We need a > working implementation with a free license. They have offered us some ideas > like in the 2.0.3 README (see attachment). > > Is there a plan based on the differences of the various platforms? Is there a > API purposal? Is there a plan of the JNI? > > If not I am willing to help. I can write/represent the POSIX part with special > interrest of the free UNIX systems. > Not to put words in your mouth but it sounds like you would rather not be in javax.comm namespace at all and do something like a VFS for serial ports as suggested in the readme? Maybe call it a VCS for character streams. That sounds like a major version change rather than an incremental change. So a vote for cutting the ropes and floating in the current? rxtx 3.0 or whatever abandoning current application requirements and perhaps largely rewriting rxtx.. Thats possible and could happen at the same time. An email to Vincent sounds polite enough at this stage. -- Trent Jarvi tjarvi at qbang.org From phillip at uow.edu.au Mon Jul 17 19:33:19 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Tue, 18 Jul 2006 11:33:19 +1000 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application in Mac OSX" Message-ID: <7DBE5FEB-EA06-45BC-ABBE-A9990281E32D@uow.edu.au> Hi We found a workaround - Problem fixed by creating /var/lock directory - seems that they changed the directory from /var/spool/uucp for the lock file but didn't update the documentation. audfg5:~ phillip$ sudo mkdir /var/lock Password: audfg5:~ phillip$ ls -ld /var/lock drwxr-xr-x 2 root wheel 68 Jul 18 09:51 /var/lock audfg5:~ phillip$ sudo chmod 775 /var/lock audfg5:~ phillip$ ls -ld /var/lock drwxrwxr-x 2 root wheel 68 Jul 18 09:51 /var/lock audfg5:~ phillip$ sudo chgrp uucp /var/lock audfg5:~ phillip$ ls -ld /var/lock drwxrwxr-x 2 root uucp 68 Jul 18 09:51 /var/lock audfg5:~ phillip$ ls -l /var/lock total 8 -r--r--r-- 1 phillip uucp 11 Jul 18 09:58 LK.003.009.002 Now both programs work and we get a warning on the console: RXTX Warning: Removing stale lock file. /var/lock/LK.003.009.002 Do we still need the /var/spool/uucp directory?? thanks Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From tjarvi at qbang.org Mon Jul 17 19:40:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 17 Jul 2006 19:40:26 -0600 (MDT) Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application in Mac OSX" In-Reply-To: <7DBE5FEB-EA06-45BC-ABBE-A9990281E32D@uow.edu.au> References: <7DBE5FEB-EA06-45BC-ABBE-A9990281E32D@uow.edu.au> Message-ID: On Tue, 18 Jul 2006, Phillip McKerrow wrote: > Hi > We found a workaround - Problem fixed by creating /var/lock directory > - seems that they changed the directory from /var/spool/uucp for the > lock file but didn't update the documentation. > > audfg5:~ phillip$ sudo mkdir /var/lock > Password: > audfg5:~ phillip$ ls -ld /var/lock > drwxr-xr-x 2 root wheel 68 Jul 18 09:51 /var/lock > audfg5:~ phillip$ sudo chmod 775 /var/lock > audfg5:~ phillip$ ls -ld /var/lock > drwxrwxr-x 2 root wheel 68 Jul 18 09:51 /var/lock > audfg5:~ phillip$ sudo chgrp uucp /var/lock > audfg5:~ phillip$ ls -ld /var/lock > drwxrwxr-x 2 root uucp 68 Jul 18 09:51 /var/lock > audfg5:~ phillip$ ls -l /var/lock > total 8 > -r--r--r-- 1 phillip uucp 11 Jul 18 09:58 LK.003.009.002 > > Now both programs work and we get a warning on the console: > RXTX Warning: Removing stale lock file. /var/lock/LK.003.009.002 > > Do we still need the /var/spool/uucp directory?? > [The new code in CVS will not use Lockfiles on Mac OS X.] The above can happen if you did not close the port before exiting the program. The warning is harmless. RXTX notes that the old program is not running and removes the stale lockfile. -- Trent Jarvi tjarvi at qbang.org From phillip at uow.edu.au Tue Jul 18 01:07:40 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Tue, 18 Jul 2006 17:07:40 +1000 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX Message-ID: Hi I am trying to run a precompiled Java program (JavaKit for setting up the TINI processor over a serial link from http://www.maxim-ic.com/ products/tini/software/downloads.cfm). It uses javax.comm for serial communication. 1. I downloaded the Sparc Solaris version of comm.jar and placed it in /Library/Java/Extensions with RXTXcomm.jar and librxtxSerial.jnilib. 2. I added a javax.com.properties file to /System/Library/Frameworks/ JavaVM.framework/Versions/CurrentJDK/Home/lib It is a text file with one line Driver=gnu.io.RXTXCommDriver 3. When I execute JavaKit it crashes with the following console output audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver (CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:109) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Exception in thread "main" java.lang.UnsatisfiedLinkError: isSessionActive at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts (Portmapping.java:155) at com.sun.comm.Portmapping.refreshPortDatabase (Portmapping.java:100) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:138) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ Home/lib/ext instead of /Library/Java/Extensions it makes no difference: If I use the generic version of comm,jar file from Sun, JavaKit brings up a gui but can't find the serial ports: The console output is: audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while loading driver gnu.io.RXTXCommDriver Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no SolarisSerialParallel in java.library.path Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while loading driver com.sun.comm.SolarisDriver Am I doing something wrong in my efforts to get this going? Should I have another file loaded somewhere or have I run into a bug in RXTX?? thanks again for your help. Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From joachim at buechse.de Tue Jul 18 02:53:38 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 18 Jul 2006 10:53:38 +0200 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: References: Message-ID: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> 2.1.7 is the gnu.io.* version. You need 2.0.7 ie the javax.comm.* version. --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich On 18.07.2006, at 09:07, Phillip McKerrow wrote: > Hi > > I am trying to run a precompiled Java program (JavaKit for setting up > the TINI processor over a serial link from http://www.maxim-ic.com/ > products/tini/software/downloads.cfm). It uses javax.comm for serial > communication. > > 1. I downloaded the Sparc Solaris version of comm.jar and placed it > in /Library/Java/Extensions with RXTXcomm.jar and > librxtxSerial.jnilib. > > 2. I added a javax.com.properties file to /System/Library/Frameworks/ > JavaVM.framework/Versions/CurrentJDK/Home/lib > It is a text file with one line > Driver=gnu.io.RXTXCommDriver > > 3. When I execute JavaKit it crashes with the following console output > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver > (CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:109) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > Exception in thread "main" java.lang.UnsatisfiedLinkError: > isSessionActive > at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > at com.sun.comm.Portmapping.registerCommPorts > (Portmapping.java:155) > at com.sun.comm.Portmapping.refreshPortDatabase > (Portmapping.java:100) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:138) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > > If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ > Home/lib/ext > instead of /Library/Java/Extensions it makes no difference: > > If I use the generic version of comm,jar file from Sun, JavaKit > brings up a gui but can't find the serial ports: The console > output is: > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while > loading driver gnu.io.RXTXCommDriver > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no > SolarisSerialParallel in java.library.path > Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while > loading driver com.sun.comm.SolarisDriver > > > Am I doing something wrong in my efforts to get this going? Should I > have another file loaded somewhere or have I run into a bug in RXTX?? > > thanks again for your help. > > Phillip > > > ---------------------------------------------------------------------- > Phillip McKerrow http:// > www.uow.edu.au/~phillip/ > School of Information Technology and Computer Science > University of Wollongong * > Northfields Avenue, * * > Wollongong, NSW, 2522. + > AUSTRALIA * the land of the > southern cross > tel : +61 2 4221 3771 fax : +61 2 4221 > 4170 > > God so loved the world that he gave his one and only Son (Jesus), > that whoever believes in him shall not perish but have eternal life. > John 3:16 > ---------------------------------------------------------------------- > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alex at det.ua.pt Tue Jul 18 03:29:15 2006 From: alex at det.ua.pt (Alexandre Mota) Date: Tue, 18 Jul 2006 10:29:15 +0100 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: Message-ID: Hello Edit the JavaKit.java in order to use the gnu.io and compile everything. If you have the RXTX already installed and working it will work. I am using it on linux and windows with jdk 1.5. Best Regards Alexandre -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Phillip McKerrow Sent: ter?a-feira, 18 de Julho de 2006 8:08 To: rxtx at qbang.org Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX Hi I am trying to run a precompiled Java program (JavaKit for setting up the TINI processor over a serial link from http://www.maxim-ic.com/ products/tini/software/downloads.cfm). It uses javax.comm for serial communication. 1. I downloaded the Sparc Solaris version of comm.jar and placed it in /Library/Java/Extensions with RXTXcomm.jar and librxtxSerial.jnilib. 2. I added a javax.com.properties file to /System/Library/Frameworks/ JavaVM.framework/Versions/CurrentJDK/Home/lib It is a text file with one line Driver=gnu.io.RXTXCommDriver 3. When I execute JavaKit it crashes with the following console output audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver gnu.io.RXTXCommDriver at javax.comm.CommPortIdentifier.loadDriver (CommPortIdentifier.java:239) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:109) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) Exception in thread "main" java.lang.UnsatisfiedLinkError: isSessionActive at com.sun.comm.SunrayInfo.isSessionActive(Native Method) at com.sun.comm.Portmapping.registerCommPorts (Portmapping.java:155) at com.sun.comm.Portmapping.refreshPortDatabase (Portmapping.java:100) at javax.comm.CommPortIdentifier. (CommPortIdentifier.java:138) at JavaKit.(JavaKit.java:435) at JavaKit.main(JavaKit.java:4689) If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ Home/lib/ext instead of /Library/Java/Extensions it makes no difference: If I use the generic version of comm,jar file from Sun, JavaKit brings up a gui but can't find the serial ports: The console output is: audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit Experimental: JNI_OnLoad called. Stable Library ========================================= Native lib Version = RXTX-2.1-7 Java lib Version = RXTX-2.1-7 Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while loading driver gnu.io.RXTXCommDriver Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no SolarisSerialParallel in java.library.path Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while loading driver com.sun.comm.SolarisDriver Am I doing something wrong in my efforts to get this going? Should I have another file loaded somewhere or have I run into a bug in RXTX?? thanks again for your help. Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Tue Jul 18 04:52:02 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 18 Jul 2006 04:52:02 -0600 (MDT) Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: References: Message-ID: On Tue, 18 Jul 2006, Phillip McKerrow wrote: > Hi > > I am trying to run a precompiled Java program (JavaKit for setting up > the TINI processor over a serial link from http://www.maxim-ic.com/ > products/tini/software/downloads.cfm). It uses javax.comm for serial > communication. > > 1. I downloaded the Sparc Solaris version of comm.jar and placed it > in /Library/Java/Extensions with RXTXcomm.jar and > librxtxSerial.jnilib. > > 2. I added a javax.com.properties file to /System/Library/Frameworks/ > JavaVM.framework/Versions/CurrentJDK/Home/lib > It is a text file with one line > Driver=gnu.io.RXTXCommDriver > > 3. When I execute JavaKit it crashes with the following console output > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > > java.io.IOException: Error instantiating class gnu.io.RXTXCommDriver > gnu.io.RXTXCommDriver > at javax.comm.CommPortIdentifier.loadDriver > (CommPortIdentifier.java:239) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:109) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > Exception in thread "main" java.lang.UnsatisfiedLinkError: > isSessionActive > at com.sun.comm.SunrayInfo.isSessionActive(Native Method) > at com.sun.comm.Portmapping.registerCommPorts > (Portmapping.java:155) > at com.sun.comm.Portmapping.refreshPortDatabase > (Portmapping.java:100) > at javax.comm.CommPortIdentifier. > (CommPortIdentifier.java:138) > at JavaKit.(JavaKit.java:435) > at JavaKit.main(JavaKit.java:4689) > > > If I copy comm.jar into /System/Library/Frameworks/JavaVM.framework/ > Home/lib/ext > instead of /Library/Java/Extensions it makes no difference: > > If I use the generic version of comm,jar file from Sun, JavaKit > brings up a gui but can't find the serial ports: The console output is: > > audfg5:/Users/Shared/Jartos/tini1.17/bin phillip$ Java JavaKit > Experimental: JNI_OnLoad called. > Stable Library > ========================================= > Native lib Version = RXTX-2.1-7 > Java lib Version = RXTX-2.1-7 > Caught java.lang.ClassCastException: gnu.io.RXTXCommDriver while > loading driver gnu.io.RXTXCommDriver > Error loading SolarisSerial: java.lang.UnsatisfiedLinkError: no > SolarisSerialParallel in java.library.path > Caught java.lang.UnsatisfiedLinkError: readRegistrySerial while > loading driver com.sun.comm.SolarisDriver > > > Am I doing something wrong in my efforts to get this going? Should I > have another file loaded somewhere or have I run into a bug in RXTX?? > > thanks again for your help. > RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for that. Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Tue Jul 18 16:14:38 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 18 Jul 2006 18:14:38 -0400 Subject: [Rxtx] jcp and jsr In-Reply-To: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> References: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> Message-ID: Hi All, I have been in touch with: Paul Klissner Please read what Paul writes below. I am not sure, but this might be a good chance for the RXTX group to take action. As to what we should write for the JSR, I am thinking about something in the javax.comm namespace. What is the collective feeling about that? Thanks! - Doug Paul writes: "I think a JSR should be opened, but I don't see any point in proceeding with 922, which never formed and expert group, or provided a specification or reference implementation. It was a placeholder, and the title wasn't even relevant. I think we should discuss our ideas about what we'd like to accomplish and javax.comm and see if we can reach an agreement. You would submit a JSR through the Java Community Process, and if you do, I'd like to represent Sun on the expert group, and contribute to the effort. We may want to start with a fresh specification, borrowing what we want from the current javax.com, adding what we need, and creating a reference implementation. Paul" From pascal at quies.net Tue Jul 18 18:12:26 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 02:12:26 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> Message-ID: <200607190212.27131.pascal@quies.net> Hi Dr., The namespace is the last thing we need to worry about. Let's start with the common goals. For instance the current API is not very object oriented. It might be a good idea to have a static set of objects available representing every supported port available on the system in realtime. Each object should clearly know its own state and its capabilities. To get a port there could be a method like synchronized void connect(PortUser) where PortUser is a interface which handles the interaction with a input and a output stream and listers like PortStillAvailableListener, PortBufferListener and a DataAvailableListener. What is the collective feeling about that? Op woensdag 19 juli 2006 00:14, schreef Dr. Douglas Lyon: > Hi All, > I have been in touch with: > Paul Klissner > Please read what Paul writes below. > I am not sure, but this might be a good chance for > the RXTX group to take action. > As to what we should write for the JSR, I am thinking > about something in the javax.comm namespace. > What is the collective feeling about that? > Thanks! > - Doug > > Paul writes: > "I think a JSR should be opened, but I don't see any point > in proceeding with 922, which never formed and expert group, > or provided a specification or reference implementation. > It was a placeholder, and the title wasn't even relevant. > > I think we should discuss our ideas about what we'd like > to accomplish and javax.comm and see if we can reach an > agreement. > > You would submit a JSR through the Java Community Process, > and if you do, I'd like to represent Sun on the expert group, > and contribute to the effort. We may want to start with > a fresh specification, borrowing what we want from the > current javax.com, adding what we need, and creating > a reference implementation. From phillip at uow.edu.au Tue Jul 18 23:44:25 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Wed, 19 Jul 2006 15:44:25 +1000 Subject: [Rxtx] RXTX throws 'port in use exception' with the error "Unknown Application in Mac OSX" Message-ID: <7EEF3F56-A406-4532-BB3D-AA642A4818CA@uow.edu.au> > > Do we still need the /var/spool/uucp directory?? > > >> Trent Jarvi wrote >>[The new code in CVS will not use Lockfiles on Mac OS X.] Great, that should make installation easier. When will the next version be released? Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From phillip at uow.edu.au Wed Jul 19 00:14:26 2006 From: phillip at uow.edu.au (Phillip McKerrow) Date: Wed, 19 Jul 2006 16:14:26 +1000 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: References: Message-ID: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> > > Edit the JavaKit.java in order to use the gnu.io and compile > everything. > > Alexandre > Unfotunately all I have is a .jar that contains it. I haven't found the source on their web site. > From: Joachim Buechse > 2.1.7 is the gnu.io.* version. You need 2.0.7 ie the javax.comm.* > version. > > RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for > that. > > Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. > > Trent Jarv I found the rxtx download page and downloaded rxtx-2.0-7pre1 (source/ Mac) The Install folder in ForPackageMaker has librxtxSerial.jnilib and java.com.properties but instead of RXTXComm.jar it has jcl.jar (I have no idea what is is for - it doesn't seem to be a replacement for RXTXCom.jar) I tried to run the XCode project to build it but there is a syntax error - nativeSetSerialPortParams returns a void not a jboolean. Also, there is no target to make RXTXComm.jar JNIEXPORT void JNICALL Java_gnu_io_RXTXPort_nativeSetSerialPortParams (JNIEnv *, jobject, jint, jint, jint, jint); Can you tell me where to find either a working copy of 2.0 for Mac OSX, or RXTXComm.jar or a working XCode project for Version 2. This is getting very frustrating. thanks Phillip ---------------------------------------------------------------------- Phillip McKerrow http:// www.uow.edu.au/~phillip/ School of Information Technology and Computer Science University of Wollongong * Northfields Avenue, * * Wollongong, NSW, 2522. + AUSTRALIA * the land of the southern cross tel : +61 2 4221 3771 fax : +61 2 4221 4170 God so loved the world that he gave his one and only Son (Jesus), that whoever believes in him shall not perish but have eternal life. John 3:16 ---------------------------------------------------------------------- From joachim at buechse.de Wed Jul 19 01:17:03 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 19 Jul 2006 09:17:03 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607190212.27131.pascal@quies.net> References: <0849299C-7B3F-48B9-BE52-3C215F658A07@buechse.de> <200607190212.27131.pascal@quies.net> Message-ID: <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> The static objects will work for Windows and Linux, however for OSX they will create problems: - ports can appear and disappear at any time with VCP drivers for USB - the port names are not known until the usb-port is "plugged in" Please do not forget that tty ports can be opened by several applications concurrently. All of those will "loose" the port if anyone opens the corresponding cu port. As this naming based mechanism does not exist on Windows (maybe it does via an API) it should probably be reflected in the API. In other words there are "two levels of open": - Open for reading status lines (1) - Open for reading/writing data (2) I am not sure if state (1) should also allow the modification of certain status lines (ie to set a modem ready). I am also not sure if the api should unify corresponding cu. and tty. ports into one single port. Regards, Joachim On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: > For instance the current API is not very object oriented. > It might be a good idea to have a static set of objects available > representing > every supported port available on the system in realtime. Each > object should > clearly know its own state and its capabilities. To get a port > there could be > a method like synchronized void connect(PortUser) where PortUser is a > interface which handles the interaction with a input and a output > stream and > listers like PortStillAvailableListener, PortBufferListener and a > DataAvailableListener. > > What is the collective feeling about that? From joachim at buechse.de Wed Jul 19 01:29:53 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 19 Jul 2006 09:29:53 +0200 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> References: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> Message-ID: <2D32167B-3830-41D6-9FDD-462301F0453F@buechse.de> As you have already downloaded the source, just cd into the main folder and do a "cvs up -d" this will remove some outdated files and create a new XCode project which should compile without problems. You may also want to search the mail archive or checkout README.OSX for my suggestion on how to avoid the javax.comm.properties file by creating a class com.sun.comm.SolarisDriver. Regards, Joachim PS: I can feel your pain... it was the same for me. In fact I never understood why there are different native or java implementations for 2.0 and 2.1. The two versions could easily be unified by using the simplest of OO programing (intermediate abstract classes). But I guess at the time of branching the direction was not clear. Also the licences are not the same... On 19.07.2006, at 08:14, Phillip McKerrow wrote: >> RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for >> that. >> >> Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. >> >> Trent Jarv > > I found the rxtx download page and downloaded rxtx-2.0-7pre1 (source/ > Mac) > > The Install folder in ForPackageMaker has librxtxSerial.jnilib and > java.com.properties but instead of RXTXComm.jar it has jcl.jar (I > have no idea what is is for - it doesn't seem to be a replacement for > RXTXCom.jar) > > I tried to run the XCode project to build it but there is a syntax > error - nativeSetSerialPortParams returns a void not a jboolean. > Also, there is no target to make RXTXComm.jar > > JNIEXPORT void JNICALL Java_gnu_io_RXTXPort_nativeSetSerialPortParams > (JNIEnv *, jobject, jint, jint, jint, jint); > > Can you tell me where to find either a working copy of 2.0 for Mac > OSX, or RXTXComm.jar or a working XCode project for Version 2. This > is getting very frustrating. > > thanks > > Phillip > > ---------------------------------------------------------------------- > Phillip McKerrow http:// > www.uow.edu.au/~phillip/ > School of Information Technology and Computer Science > University of Wollongong * > Northfields Avenue, * * > Wollongong, NSW, 2522. + > AUSTRALIA * the land of the > southern cross > tel : +61 2 4221 3771 fax : +61 2 4221 > 4170 > > God so loved the world that he gave his one and only Son (Jesus), > that whoever believes in him shall not perish but have eternal life. > John 3:16 > ---------------------------------------------------------------------- > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From alex at det.ua.pt Wed Jul 19 03:02:40 2006 From: alex at det.ua.pt (Alexandre Mota) Date: Wed, 19 Jul 2006 10:02:40 +0100 Subject: [Rxtx] Making RXTX look like javax.comm in Mac OSX In-Reply-To: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> References: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> Message-ID: <44BDF530.5080502@det.ua.pt> Phillip McKerrow wrote: >>Edit the JavaKit.java in order to use the gnu.io and compile >>everything. >> >>Alexandre >> >> >> >Unfotunately all I have is a .jar that contains it. I haven't found >the source on their web site. > > > > Download http://files.dalsemi.com/pub/tini/tini1_17.tgz Decompress it and you will find the JavaKiTSrc.jar in the src dir. Decompress it with jar -xf JavaKitSrc.jar and you will get all the source files you need. Alexandre PS: Remenber that puting JavaKit into work is allways a pain... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060719/f5172a01/attachment-0348.html From lyon at docjava.com Wed Jul 19 05:27:47 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Wed, 19 Jul 2006 07:27:47 -0400 Subject: [Rxtx] RXTX binary for mac In-Reply-To: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> References: <5342ECD9-5665-4E17-AA95-E4EE4CA84AA1@uow.edu.au> Message-ID: Hi All, I have some older RXTX binaries that are deployed in a webstart application. You can try it with: http://show.docjava.com:8086/book/cgij/code/jnlp/addbk.JAddressBook.Main.jnlp The libs are signed and packed for webstart disto by me. http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/ Shows them. - DL > > >> Edit the JavaKit.java in order to use the gnu.io and compile? >> everything. >> >> Alexandre >> >Unfotunately all I have is a .jar that contains it. I haven't found? >the source on their web site. > > >> From: Joachim Buechse >> 2.1.7 is the gnu.io.* version. You need 2.0.7 ie the javax.comm.* >> version. >> > >> RXTX 2.0 is for use with Sun's comm.jar. RXTX 2.1 is not made for? >> that. >> >> Be sure to remove RXTX 2.1 from your classpath while trying RXTX 2.0. >> >> Trent Jarv > >I found the rxtx download page and downloaded rxtx-2.0-7pre1 (source/ >Mac) > >The Install folder in ForPackageMaker has librxtxSerial.jnilib and? >java.com.properties but instead of RXTXComm.jar it has jcl.jar (I? >have no idea what is is for - it doesn't seem to be a replacement for? >RXTXCom.jar) > >I tried to run the XCode project to build it but there is a syntax? >error - nativeSetSerialPortParams returns a void not a jboolean.?? >Also, there is no target to make RXTXComm.jar > >JNIEXPORT void JNICALL Java_gnu_io_RXTXPort_nativeSetSerialPortParams > (JNIEnv *, jobject, jint, jint, jint, jint); > >Can you tell me where to find either a working copy of 2.0 for Mac? >OSX, or RXTXComm.jar or a working XCode project for Version 2. This? >is getting very frustrating. > >thanks > >Phillip > >---------------------------------------------------------------------- >Phillip McKerrow http:// >www.uow.edu.au/~phillip/ >School of Information Technology and Computer Science >University of Wollongong * >Northfields Avenue, * * >Wollongong, NSW, 2522. + >AUSTRALIA * the land of the? >southern cross >tel : +61 2 4221 3771 fax : +61 2 4221 4170 > >God so loved the world that he gave his one and only Son (Jesus), >that whoever believes in him shall not perish but have eternal life. >John 3:16 >---------------------------------------------------------------------- > > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Wed Jul 19 06:11:27 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 14:11:27 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> Message-ID: <200607191411.27566.pascal@quies.net> Hi Joachim, Thanks for the constructive critisism. :) Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: > The static objects will work for Windows and Linux, however for OSX > they will create problems: > - ports can appear and disappear at any time with VCP drivers for USB > - the port names are not known until the usb-port is "plugged in" Ports can appear and disappear on *any* OS with USB support. Some Linux distributions even create and remove devicefiles on the fly. With the current API you fetch a list of all available ports and then you try to cast one. What happens if the port is no longer available at that time? What happens if a port vanishes during the data transfer? Of course you can catch exceptions but that makes the code quite messy. The idea was to get a PortStillAvailableListener interface. In that way the implementation is free to handle a cleanup or wait for return routine in a OO way. The I/O streams should just lock. The word static was not ment as persistent but as Java static available. Considder the following: java.lang.hw.HardwareConfiguration { public enum PortType { RS232, I2C, etc. }; /** Gets the currently available ports of type {@code PortType}. */ public static java.lang.hw.Port[] getPorts(PortType); } com.example.Driver implements PortUser, implements PortStillAvailableListener { public portNoLongerAvailable(PortEvent event) { // cleanup & dismiss. } } com.example.Application { public static void main(String[] args) { Driver someDriver = new Driver(); Port radomPort = HardwareConfiguration.getPorts( HardwareConfiguration.PortType.RS232)[1]; myDevice.addStillAvailableListener(someDriver); myDevice.connect(someDriver); } } > Please do not forget that tty ports can be opened by several > applications concurrently. All of those will "loose" the port if > anyone opens the corresponding cu port. Indeed we need a good overview of the differences between the various platforms. Should we create a document or a Wiki for this purpose? FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: http://www.openbsd.org/cgi-bin/man.cgi?query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html Linux uses /var/lock: http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES Is there absolutely no way to get a lock under Windows? > As this naming based > mechanism does not exist on Windows (maybe it does via an API) it > should probably be reflected in the API. In other words there are > "two levels of open": > > - Open for reading status lines (1) > - Open for reading/writing data (2) > > I am not sure if state (1) should also allow the modification of > certain status lines (ie to set a modem ready). I'm not sure I understand. Do you mean canonical and noncanonical mode? How far is Windows with the canonical mode. Is it comparable to POSIX? > I am also not sure if > the api should unify corresponding cu. and tty. ports into one single > port. I think the API should hide low-level details like devicefiles. Who is participating anyway? Is it just the four of us? Cheers, Pascal > On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: > > For instance the current API is not very object oriented. > > It might be a good idea to have a static set of objects available > > representing > > every supported port available on the system in realtime. Each > > object should > > clearly know its own state and its capabilities. To get a port > > there could be > > a method like synchronized void connect(PortUser) where PortUser is a > > interface which handles the interaction with a input and a output > > stream and > > listers like PortStillAvailableListener, PortBufferListener and a > > DataAvailableListener. > > > > What is the collective feeling about that? From joachim at buechse.de Wed Jul 19 07:09:27 2006 From: joachim at buechse.de (Joachim Buechse) Date: Wed, 19 Jul 2006 15:09:27 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191411.27566.pascal@quies.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> Message-ID: <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> Pascal, I think that the PortNoLongerAvailableListener creates more problems than it solves. I think that exceptions are much better suited for this case. There might be an additional method "Port.isOpen" or "Port.isAvailable" which interested applications may call at times best suited. Most implementations will only find out, that a port disappeared when trying to read or write. Anything else would require polling with a high frequency or kernel hooks that do not exist (in POSIX). Any kind of call back like portNoLongerAvailable() creates the risk of deadlocks and races which require an involved implementation as the library does not know what it is calling (ie a user might try to call close from the callback which can block a very long time). Callbacks introduce concurrency which unneccessarily increases the complexity. Regards, Joachim On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: > Hi Joachim, > > Thanks for the constructive critisism. :) > > Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >> The static objects will work for Windows and Linux, however for OSX >> they will create problems: >> - ports can appear and disappear at any time with VCP drivers for USB >> - the port names are not known until the usb-port is "plugged in" > > Ports can appear and disappear on *any* OS with USB support. Some > Linux > distributions even create and remove devicefiles on the fly. > > With the current API you fetch a list of all available ports and > then you try > to cast one. What happens if the port is no longer available at > that time? > What happens if a port vanishes during the data transfer? Of course > you can > catch exceptions but that makes the code quite messy. > > The idea was to get a PortStillAvailableListener interface. In that > way the > implementation is free to handle a cleanup or wait for return > routine in a OO > way. The I/O streams should just lock. > > The word static was not ment as persistent but as Java static > available. > Considder the following: > > java.lang.hw.HardwareConfiguration { > public enum PortType { RS232, I2C, etc. }; > > /** Gets the currently available ports of type {@code PortType}. */ > public static java.lang.hw.Port[] getPorts(PortType); > } > > com.example.Driver implements PortUser, implements > PortStillAvailableListener > { > public portNoLongerAvailable(PortEvent event) { > // cleanup & dismiss. > } > } > > com.example.Application { > public static void main(String[] args) { > Driver someDriver = new Driver(); > Port radomPort = HardwareConfiguration.getPorts( > HardwareConfiguration.PortType.RS232)[1]; > myDevice.addStillAvailableListener(someDriver); > myDevice.connect(someDriver); > } > } > >> Please do not forget that tty ports can be opened by several >> applications concurrently. All of those will "loose" the port if >> anyone opens the corresponding cu port. > > Indeed we need a good overview of the differences between the various > platforms. Should we create a document or a Wiki for this purpose? > > FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: > http://www.openbsd.org/cgi-bin/man.cgi? > query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD > +Current&arch=i386&format=html > > Linux uses /var/lock: > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > Is there absolutely no way to get a lock under Windows? > >> As this naming based >> mechanism does not exist on Windows (maybe it does via an API) it >> should probably be reflected in the API. In other words there are >> "two levels of open": >> >> - Open for reading status lines (1) >> - Open for reading/writing data (2) >> >> I am not sure if state (1) should also allow the modification of >> certain status lines (ie to set a modem ready). > > I'm not sure I understand. Do you mean canonical and noncanonical > mode? > > How far is Windows with the canonical mode. Is it comparable to POSIX? > >> I am also not sure if >> the api should unify corresponding cu. and tty. ports into one single >> port. > > I think the API should hide low-level details like devicefiles. > > > Who is participating anyway? Is it just the four of us? > > Cheers, > > Pascal > > >> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>> For instance the current API is not very object oriented. >>> It might be a good idea to have a static set of objects available >>> representing >>> every supported port available on the system in realtime. Each >>> object should >>> clearly know its own state and its capabilities. To get a port >>> there could be >>> a method like synchronized void connect(PortUser) where PortUser >>> is a >>> interface which handles the interaction with a input and a output >>> stream and >>> listers like PortStillAvailableListener, PortBufferListener and a >>> DataAvailableListener. >>> >>> What is the collective feeling about that? > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Wed Jul 19 08:33:08 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Wed, 19 Jul 2006 11:33:08 -0300 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191411.27566.pascal@quies.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> Message-ID: <44BE42A4.3030203@gmail.com> > Linux uses /var/lock: > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > Is there absolutely no way to get a lock under Windows? Indeed Windows block ports when someone open ones. Java Comm could manage this feature. > Who is participating anyway? Is it just the four of us? I can help too. Regards, Manuel From pascal at quies.net Wed Jul 19 09:01:17 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 17:01:17 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> References: <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> Message-ID: <200607191701.17607.pascal@quies.net> In the POSIX world things are simple. If any transaction fails with ENOTTY we lock the I/O streams and create a PortNoLongerAvailableEvent. We *might* even go so far as to start a thread which polls the tty say once a second afther a PortNoLongerAvailableEvent and kill it if there is succes with a PortAvailableAgainEvent but there won't be anything like deadlocks and races. I promise. ;) Methods like isOpen and isAvailable require polling which is exactly what we both don't want and they can't be reliable since it is a moment. A clean sepparation of the functional code and Listeners for events makes the code better readable and more flexible. PS If OS X has a notification system for changes in the available ports this OS specific functionality is more simple to implement too. Op woensdag 19 juli 2006 15:09, schreef Joachim Buechse: > Pascal, > > I think that the PortNoLongerAvailableListener creates more problems > than it solves. > > I think that exceptions are much better suited for this case. There > might be an additional method "Port.isOpen" or "Port.isAvailable" > which interested applications may call at times best suited. > > Most implementations will only find out, that a port disappeared when > trying to read or write. Anything else would require polling with a > high frequency or kernel hooks that do not exist (in POSIX). Any kind > of call back like portNoLongerAvailable() creates the risk of > deadlocks and races which require an involved implementation as the > library does not know what it is calling (ie a user might try to call > close from the callback which can block a very long time). Callbacks > introduce concurrency which unneccessarily increases the complexity. > > Regards, > Joachim From jredman at ergotech.com Wed Jul 19 09:20:39 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 09:20:39 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191411.27566.pascal@quies.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> Message-ID: <44BE4DC7.7@ergotech.com> Pascal S. de Kloe wrote: >> I am also not sure if >> the api should unify corresponding cu. and tty. ports into one single >> port. > > I think the API should hide low-level details like devicefiles. Not all ports have device files. It's long been my goal to add support for virtual serial ports, that is, serial ports on Ethernet terminal servers, for example integrating RFC2217. This means that the port name is some combination of an IP address and TCP port number. Nothing in /dev. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From brian at mbari.org Wed Jul 19 10:04:51 2006 From: brian at mbari.org (Brian Schlining) Date: Wed, 19 Jul 2006 09:04:51 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BE42A4.3030203@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <44BE42A4.3030203@gmail.com> Message-ID: <5FDA8DB5-FD08-4EAA-81A7-C46A7CF6FA18@mbari.org> >> Who is participating anyway? Is it just the four of us? > I'm not much of a POSIX or C guy. But I do a lot of OO design. I'm happy to throw my 2 cents in too. Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060719/404de230/attachment-0347.html From pascal at quies.net Wed Jul 19 10:16:16 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 18:16:16 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BE4DC7.7@ergotech.com> References: <200607191411.27566.pascal@quies.net> <44BE4DC7.7@ergotech.com> Message-ID: <200607191816.17099.pascal@quies.net> Op woensdag 19 juli 2006 17:20, schreef Jim Redman: > Pascal S. de Kloe wrote: > >> I am also not sure if > >> the api should unify corresponding cu. and tty. ports into one single > >> port. > > > > I think the API should hide low-level details like devicefiles. > > Not all ports have device files. It's long been my goal to add support > for virtual serial ports, that is, serial ports on Ethernet terminal > servers, for example integrating RFC2217. This means that the port name > is some combination of an IP address and TCP port number. Nothing in /dev. > > Jim This idea doesn't need any native calls at all, right? How would you like to realize that? Jini? I'm sure you knew that the server is already there: http://www.viara.cn/en/jts.htm From pascal at quies.net Wed Jul 19 10:17:12 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 18:17:12 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <5FDA8DB5-FD08-4EAA-81A7-C46A7CF6FA18@mbari.org> References: <44BE42A4.3030203@gmail.com> <5FDA8DB5-FD08-4EAA-81A7-C46A7CF6FA18@mbari.org> Message-ID: <200607191817.12769.pascal@quies.net> Op woensdag 19 juli 2006 18:04, schreef Brian Schlining: > >> Who is participating anyway? Is it just the four of us? > > I'm not much of a POSIX or C guy. But I do a lot of OO design. I'm > happy to throw my 2 cents in too. > > Brian Schlining > Software Engineer > http://www.mbari.org Excellent! :) We need a lot of opinions from all kinds of users. From jredman at ergotech.com Wed Jul 19 10:54:18 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 10:54:18 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607191816.17099.pascal@quies.net> References: <200607191411.27566.pascal@quies.net> <44BE4DC7.7@ergotech.com> <200607191816.17099.pascal@quies.net> Message-ID: <44BE63BA.9090905@ergotech.com> Pascal, Pascal S. de Kloe wrote: > Op woensdag 19 juli 2006 17:20, schreef Jim Redman: >> Pascal S. de Kloe wrote: >>>> I am also not sure if >>>> the api should unify corresponding cu. and tty. ports into one single >>>> port. >>> I think the API should hide low-level details like devicefiles. >> Not all ports have device files. It's long been my goal to add support >> for virtual serial ports, that is, serial ports on Ethernet terminal >> servers, for example integrating RFC2217. This means that the port name >> is some combination of an IP address and TCP port number. Nothing in /dev. >> >> Jim > > This idea doesn't need any native calls at all, right? No native calls, it's just a Socket link. > > How would you like to realize that? I keep wondering that myself. I had in mind port names that are, for example, "192.168.0.99:3000". These would need to be added to the properties file (or the -D option). I'm open for suggestion. It's conceptually, it's the same as USB. Instead of USB->Serial it's Ethernet->Serial. The difference is that the USB devices create virtual serial ports within the OS. Some Ethernet devices also do this, but since, unlike USB communications, TCP/IP is supported natively within Java such a driver is unnecessary. > Jini? Is that still alive and kicking? > > I'm sure you knew that the server is already there: > > http://www.viara.cn/en/jts.htm Yes, that library is part of the plan. These devices are real serial ports. Somewhere, out in the Ether there's a DB9/DB25 cable with RS232/485 bits flowing over it. Since these are real ports, I'd like the ports to look like real serial ports (SerialPort) and not have to handle them as special cases. We have a bunch of code that deals with serial devices (PLCs, Barcode, Temperature Controllers, RFID, SECS, etc. etc.) and to rewrite each one of those to handle this case doesn't make much sense when the correct place to encapsulate a serial port is in the SerialPort layer. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From pascal at quies.net Wed Jul 19 12:44:01 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Wed, 19 Jul 2006 20:44:01 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BE63BA.9090905@ergotech.com> References: <200607191816.17099.pascal@quies.net> <44BE63BA.9090905@ergotech.com> Message-ID: <200607192044.01966.pascal@quies.net> Op woensdag 19 juli 2006 18:54, schreef Jim Redman: > I keep wondering that myself. I had in mind port names that are, for > example, "192.168.0.99:3000". These would need to be added to the > properties file (or the -D option). > > I'm open for suggestion. Jini works very well especialy for ethernets like the one you describe. It's a shame that it never got the attention it deserves. > > Jini? > > Is that still alive and kicking? Not that it does matter becouse Java software doesn't need much maintenance. ;) Have a look at http://www.jini.org/. From Paul.Klissner at Sun.COM Wed Jul 19 15:45:38 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 14:45:38 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> Message-ID: <44BEA802.7060508@sun.com> Joachim Buechse wrote: > Pascal, > > I think that the PortNoLongerAvailableListener creates more problems > than it solves. > > I think that exceptions are much better suited for this case. There > might be an additional method "Port.isOpen" or "Port.isAvailable" > which interested applications may call at times best suited. > > Most implementations will only find out, that a port disappeared when > trying to read or write. Anything else would require polling with a > high frequency or kernel hooks that do not exist (in POSIX). Any kind > of call back like portNoLongerAvailable() creates the risk of > deadlocks and races which require an involved implementation as the > library does not know what it is calling (ie a user might try to call > close from the callback which can block a very long time). Callbacks > introduce concurrency which unneccessarily increases the complexity. I think we should find out what are the minimum requirements to get a JSR open, form an expert group, and get that group discussing these things in the JSR. I'm not pushing for Sun to sponsor it, as I think there is a community interest already and that it deserves an independent life and commitment. ACCESS EXCEPTIONS: ----------------- I agree, exceptions of this sort are the way to go. Exceptions are already simpler than having to err check at each function call, so a big improvement. No need to architect a more trouble prone complexity into the API. PROJECT SCOPE: ------------- Also, we should think carefully about what the scope of this project would be. Should it be javax."comm" which handles both serial and parallel (is parallel going by the wayside). Should it be split into two project: javax.EIA232 (or javax.RS232), and javax.IEEE1284? Should we differentiate between single-ended serial protocols, like EIA232, I2C, 2-WIRE, SPI, vs. quasi-multidrop and full multidrop busses such as EIA422, EIA432 and EIA485? If we really were to add I2C support to the API, we'd have to delve into the semantics more, because there could be some implicit decoding of the bus the API users would want to see. At this point, I'm thinking they're all different, and should be their own projects.. perhaps there could be an umbrella layer that abstracted out some of the generic issues like device ownership and access, perhaps not. javax.eia232 javax.eia485 or (javax.EIX4xx?) javax.i2c, javax.spi (or javax.chipbus?) DRIVER PLUGINS: -------------- Taking javax.eia232 for example, I think we need an architecture that allows for multiple plugins to provide multiple simultaneous drivers/adapters to allow for heterogeneous providers on a single system. For example, not only can there be USB based serial devices but networked serial devices, for example accessing devices on thin clients. PORTMAPPING: ----------- For Sun's javax.comm 3.0, we introduced a portmapping abstraction layer, that creates a mechansim to help administer the view (filtering)of available ports given to the application, and the name of such ports. I hope we can consider the right platform neutral way to accomplish that. In javax.comm as it is now, the API has to know where to go and look to find ports. In 3.x I added the ability to specify where to look for standard ports as properties to make it more flexible, but for our thin client platform, which can represent a very dynamic buffet of ports splayed in the leaf nodes of a tree that isn't good enough. That complicates things for the users (having to specify and manage unique and long path names to ports which can come and go), so there is an option whereby the user can configure something like "com1" such that on a thin client it represents the first port of the first USB/serial dongle connected. Javax.comm knows how to find that in the context of the current thin client, but the administrator doesn't have to worry about it. How to architect the API flexibly enough to allow for this kind of thing needs to be considered. Paul > > Regards, > Joachim > > On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: > >> Hi Joachim, >> >> Thanks for the constructive critisism. :) >> >> Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >>> The static objects will work for Windows and Linux, however for OSX >>> they will create problems: >>> - ports can appear and disappear at any time with VCP drivers for USB >>> - the port names are not known until the usb-port is "plugged in" >> Ports can appear and disappear on *any* OS with USB support. Some >> Linux >> distributions even create and remove devicefiles on the fly. >> >> With the current API you fetch a list of all available ports and >> then you try >> to cast one. What happens if the port is no longer available at >> that time? >> What happens if a port vanishes during the data transfer? Of course >> you can >> catch exceptions but that makes the code quite messy. >> >> The idea was to get a PortStillAvailableListener interface. In that >> way the >> implementation is free to handle a cleanup or wait for return >> routine in a OO >> way. The I/O streams should just lock. >> >> The word static was not ment as persistent but as Java static >> available. >> Considder the following: >> >> java.lang.hw.HardwareConfiguration { >> public enum PortType { RS232, I2C, etc. }; >> >> /** Gets the currently available ports of type {@code PortType}. */ >> public static java.lang.hw.Port[] getPorts(PortType); >> } >> >> com.example.Driver implements PortUser, implements >> PortStillAvailableListener >> { >> public portNoLongerAvailable(PortEvent event) { >> // cleanup & dismiss. >> } >> } >> >> com.example.Application { >> public static void main(String[] args) { >> Driver someDriver = new Driver(); >> Port radomPort = HardwareConfiguration.getPorts( >> HardwareConfiguration.PortType.RS232)[1]; >> myDevice.addStillAvailableListener(someDriver); >> myDevice.connect(someDriver); >> } >> } >> >>> Please do not forget that tty ports can be opened by several >>> applications concurrently. All of those will "loose" the port if >>> anyone opens the corresponding cu port. >> Indeed we need a good overview of the differences between the various >> platforms. Should we create a document or a Wiki for this purpose? >> >> FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: >> http://www.openbsd.org/cgi-bin/man.cgi? >> query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD >> +Current&arch=i386&format=html >> >> Linux uses /var/lock: >> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES >> >> Is there absolutely no way to get a lock under Windows? >> >>> As this naming based >>> mechanism does not exist on Windows (maybe it does via an API) it >>> should probably be reflected in the API. In other words there are >>> "two levels of open": >>> >>> - Open for reading status lines (1) >>> - Open for reading/writing data (2) >>> >>> I am not sure if state (1) should also allow the modification of >>> certain status lines (ie to set a modem ready). >> I'm not sure I understand. Do you mean canonical and noncanonical >> mode? >> >> How far is Windows with the canonical mode. Is it comparable to POSIX? >> >>> I am also not sure if >>> the api should unify corresponding cu. and tty. ports into one single >>> port. >> I think the API should hide low-level details like devicefiles. >> >> >> Who is participating anyway? Is it just the four of us? >> >> Cheers, >> >> Pascal >> >> >>> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>>> For instance the current API is not very object oriented. >>>> It might be a good idea to have a static set of objects available >>>> representing >>>> every supported port available on the system in realtime. Each >>>> object should >>>> clearly know its own state and its capabilities. To get a port >>>> there could be >>>> a method like synchronized void connect(PortUser) where PortUser >>>> is a >>>> interface which handles the interaction with a input and a output >>>> stream and >>>> listers like PortStillAvailableListener, PortBufferListener and a >>>> DataAvailableListener. >>>> >>>> What is the collective feeling about that? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Wed Jul 19 16:32:37 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 16:32:37 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEA802.7060508@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <44BEB305.3030208@ergotech.com> For one, I'd object to the splitting of 232 and 485 and question why it's necessary. Often the only difference between 232 access and 485 access is whether there's a converter attached to the serial port. Put another way, while 485 is multidrop, I think that's an application level issue rather than a driver level issue. If the issue is electrical, I don't think that it's possible to reliably support receiver switching of a 2-wire 485 network within Java, the timing is just too tight, so your stuck with requiring a 485 converter that automatically switches (not an onerous burden for us) or some OS level intervention. Anyway, if we're going to start differentiating at the electrical level we still support some current loop systems (Siemens S5 PLC if you care). Jim Paul Klissner wrote: > Joachim Buechse wrote: >> Pascal, >> >> I think that the PortNoLongerAvailableListener creates more problems >> than it solves. >> >> I think that exceptions are much better suited for this case. There >> might be an additional method "Port.isOpen" or "Port.isAvailable" >> which interested applications may call at times best suited. >> >> Most implementations will only find out, that a port disappeared when >> trying to read or write. Anything else would require polling with a >> high frequency or kernel hooks that do not exist (in POSIX). Any kind >> of call back like portNoLongerAvailable() creates the risk of >> deadlocks and races which require an involved implementation as the >> library does not know what it is calling (ie a user might try to call >> close from the callback which can block a very long time). Callbacks >> introduce concurrency which unneccessarily increases the complexity. > > I think we should find out what are the minimum requirements > to get a JSR open, form an expert group, and get that group > discussing these things in the JSR. I'm not pushing for > Sun to sponsor it, as I think there is a community interest > already and that it deserves an independent life and > commitment. > > ACCESS EXCEPTIONS: > ----------------- > I agree, exceptions of this sort are the way to go. > Exceptions are already simpler than having to err > check at each function call, so a big improvement. > No need to architect a more trouble prone complexity > into the API. > > PROJECT SCOPE: > ------------- > > Also, we should think carefully about what the scope of > this project would be. Should it be javax."comm" which > handles both serial and parallel (is parallel going by the > wayside). Should it be split into two project: > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > > Should we differentiate between single-ended serial > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > quasi-multidrop and full multidrop busses such as > EIA422, EIA432 and EIA485? If we really were to > add I2C support to the API, we'd have to delve into > the semantics more, because there could be some > implicit decoding of the bus the API users would > want to see. > > At this point, I'm thinking they're all different, > and should be their own projects.. perhaps there > could be an umbrella layer that abstracted out > some of the generic issues like device ownership > and access, perhaps not. > > javax.eia232 > javax.eia485 or (javax.EIX4xx?) > javax.i2c, javax.spi (or javax.chipbus?) > > DRIVER PLUGINS: > -------------- > Taking javax.eia232 for example, I think we need an > architecture that allows for multiple plugins to > provide multiple simultaneous drivers/adapters to > allow for heterogeneous providers on a single system. > For example, not only can there be USB based serial > devices but networked serial devices, for example > accessing devices on thin clients. > > PORTMAPPING: > ----------- > For Sun's javax.comm 3.0, we introduced a portmapping > abstraction layer, that creates a mechansim to help > administer the view (filtering)of available ports given > to the application, and the name of such ports. I hope we > can consider the right platform neutral way to > accomplish that. > > In javax.comm as it is now, the API has to know > where to go and look to find ports. In 3.x I added > the ability to specify where to look for standard > ports as properties to make it more flexible, but > for our thin client platform, which can represent > a very dynamic buffet of ports splayed in the > leaf nodes of a tree that isn't good enough. > That complicates things for the users (having > to specify and manage unique and long path names > to ports which can come and go), so there is > an option whereby the user can configure > something like "com1" such that on a thin client > it represents the first port of the first USB/serial > dongle connected. Javax.comm knows how to find > that in the context of the current thin client, > but the administrator doesn't have to worry about it. > > How to architect the API flexibly enough to allow > for this kind of thing needs to be considered. > > Paul > > > >> Regards, >> Joachim >> >> On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: >> >>> Hi Joachim, >>> >>> Thanks for the constructive critisism. :) >>> >>> Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >>>> The static objects will work for Windows and Linux, however for OSX >>>> they will create problems: >>>> - ports can appear and disappear at any time with VCP drivers for USB >>>> - the port names are not known until the usb-port is "plugged in" >>> Ports can appear and disappear on *any* OS with USB support. Some >>> Linux >>> distributions even create and remove devicefiles on the fly. >>> >>> With the current API you fetch a list of all available ports and >>> then you try >>> to cast one. What happens if the port is no longer available at >>> that time? >>> What happens if a port vanishes during the data transfer? Of course >>> you can >>> catch exceptions but that makes the code quite messy. >>> >>> The idea was to get a PortStillAvailableListener interface. In that >>> way the >>> implementation is free to handle a cleanup or wait for return >>> routine in a OO >>> way. The I/O streams should just lock. >>> >>> The word static was not ment as persistent but as Java static >>> available. >>> Considder the following: >>> >>> java.lang.hw.HardwareConfiguration { >>> public enum PortType { RS232, I2C, etc. }; >>> >>> /** Gets the currently available ports of type {@code PortType}. */ >>> public static java.lang.hw.Port[] getPorts(PortType); >>> } >>> >>> com.example.Driver implements PortUser, implements >>> PortStillAvailableListener >>> { >>> public portNoLongerAvailable(PortEvent event) { >>> // cleanup & dismiss. >>> } >>> } >>> >>> com.example.Application { >>> public static void main(String[] args) { >>> Driver someDriver = new Driver(); >>> Port radomPort = HardwareConfiguration.getPorts( >>> HardwareConfiguration.PortType.RS232)[1]; >>> myDevice.addStillAvailableListener(someDriver); >>> myDevice.connect(someDriver); >>> } >>> } >>> >>>> Please do not forget that tty ports can be opened by several >>>> applications concurrently. All of those will "loose" the port if >>>> anyone opens the corresponding cu port. >>> Indeed we need a good overview of the differences between the various >>> platforms. Should we create a document or a Wiki for this purpose? >>> >>> FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: >>> http://www.openbsd.org/cgi-bin/man.cgi? >>> query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD >>> +Current&arch=i386&format=html >>> >>> Linux uses /var/lock: >>> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES >>> >>> Is there absolutely no way to get a lock under Windows? >>> >>>> As this naming based >>>> mechanism does not exist on Windows (maybe it does via an API) it >>>> should probably be reflected in the API. In other words there are >>>> "two levels of open": >>>> >>>> - Open for reading status lines (1) >>>> - Open for reading/writing data (2) >>>> >>>> I am not sure if state (1) should also allow the modification of >>>> certain status lines (ie to set a modem ready). >>> I'm not sure I understand. Do you mean canonical and noncanonical >>> mode? >>> >>> How far is Windows with the canonical mode. Is it comparable to POSIX? >>> >>>> I am also not sure if >>>> the api should unify corresponding cu. and tty. ports into one single >>>> port. >>> I think the API should hide low-level details like devicefiles. >>> >>> >>> Who is participating anyway? Is it just the four of us? >>> >>> Cheers, >>> >>> Pascal >>> >>> >>>> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>>>> For instance the current API is not very object oriented. >>>>> It might be a good idea to have a static set of objects available >>>>> representing >>>>> every supported port available on the system in realtime. Each >>>>> object should >>>>> clearly know its own state and its capabilities. To get a port >>>>> there could be >>>>> a method like synchronized void connect(PortUser) where PortUser >>>>> is a >>>>> interface which handles the interaction with a input and a output >>>>> stream and >>>>> listers like PortStillAvailableListener, PortBufferListener and a >>>>> DataAvailableListener. >>>>> >>>>> What is the collective feeling about that? >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Paul.Klissner at Sun.COM Wed Jul 19 17:31:36 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 16:31:36 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEB305.3030208@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> Message-ID: <44BEC0D8.4050806@sun.com> Jim Redman wrote: > For one, I'd object to the splitting of 232 and 485 and question why > it's necessary. Often the only difference between 232 access and 485 > access is whether there's a converter attached to the serial port. > > Put another way, while 485 is multidrop, I think that's an application > level issue rather than a driver level issue. > > If the issue is electrical, I don't think that it's possible to reliably > support receiver switching of a 2-wire 485 network within Java, the > timing is just too tight, so your stuck with requiring a 485 converter > that automatically switches (not an onerous burden for us) or some OS > level intervention. > > Anyway, if we're going to start differentiating at the electrical level > we still support some current loop systems (Siemens S5 PLC if you care). > > Jim To be honest, I've not done anything with 422, 423 or 485, so I have no objection to keeping them together if there isn't enough of a protocol distinction to make it worth seperating them out. I'd just like to find another suitable name than javax.comm, unless the JSR wants to start with javax.comm 4.0, since all the previous 'major revisions' are accounted for. javax.serialport? Paul > > Paul Klissner wrote: >> Joachim Buechse wrote: >>> Pascal, >>> >>> I think that the PortNoLongerAvailableListener creates more problems >>> than it solves. >>> >>> I think that exceptions are much better suited for this case. There >>> might be an additional method "Port.isOpen" or "Port.isAvailable" >>> which interested applications may call at times best suited. >>> >>> Most implementations will only find out, that a port disappeared when >>> trying to read or write. Anything else would require polling with a >>> high frequency or kernel hooks that do not exist (in POSIX). Any kind >>> of call back like portNoLongerAvailable() creates the risk of >>> deadlocks and races which require an involved implementation as the >>> library does not know what it is calling (ie a user might try to call >>> close from the callback which can block a very long time). Callbacks >>> introduce concurrency which unneccessarily increases the complexity. >> I think we should find out what are the minimum requirements >> to get a JSR open, form an expert group, and get that group >> discussing these things in the JSR. I'm not pushing for >> Sun to sponsor it, as I think there is a community interest >> already and that it deserves an independent life and >> commitment. >> >> ACCESS EXCEPTIONS: >> ----------------- >> I agree, exceptions of this sort are the way to go. >> Exceptions are already simpler than having to err >> check at each function call, so a big improvement. >> No need to architect a more trouble prone complexity >> into the API. >> >> PROJECT SCOPE: >> ------------- >> >> Also, we should think carefully about what the scope of >> this project would be. Should it be javax."comm" which >> handles both serial and parallel (is parallel going by the >> wayside). Should it be split into two project: >> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >> >> Should we differentiate between single-ended serial >> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >> quasi-multidrop and full multidrop busses such as >> EIA422, EIA432 and EIA485? If we really were to >> add I2C support to the API, we'd have to delve into >> the semantics more, because there could be some >> implicit decoding of the bus the API users would >> want to see. >> >> At this point, I'm thinking they're all different, >> and should be their own projects.. perhaps there >> could be an umbrella layer that abstracted out >> some of the generic issues like device ownership >> and access, perhaps not. >> >> javax.eia232 >> javax.eia485 or (javax.EIX4xx?) >> javax.i2c, javax.spi (or javax.chipbus?) >> >> DRIVER PLUGINS: >> -------------- >> Taking javax.eia232 for example, I think we need an >> architecture that allows for multiple plugins to >> provide multiple simultaneous drivers/adapters to >> allow for heterogeneous providers on a single system. >> For example, not only can there be USB based serial >> devices but networked serial devices, for example >> accessing devices on thin clients. >> >> PORTMAPPING: >> ----------- >> For Sun's javax.comm 3.0, we introduced a portmapping >> abstraction layer, that creates a mechansim to help >> administer the view (filtering)of available ports given >> to the application, and the name of such ports. I hope we >> can consider the right platform neutral way to >> accomplish that. >> >> In javax.comm as it is now, the API has to know >> where to go and look to find ports. In 3.x I added >> the ability to specify where to look for standard >> ports as properties to make it more flexible, but >> for our thin client platform, which can represent >> a very dynamic buffet of ports splayed in the >> leaf nodes of a tree that isn't good enough. >> That complicates things for the users (having >> to specify and manage unique and long path names >> to ports which can come and go), so there is >> an option whereby the user can configure >> something like "com1" such that on a thin client >> it represents the first port of the first USB/serial >> dongle connected. Javax.comm knows how to find >> that in the context of the current thin client, >> but the administrator doesn't have to worry about it. >> >> How to architect the API flexibly enough to allow >> for this kind of thing needs to be considered. >> >> Paul >> >> >> >>> Regards, >>> Joachim >>> >>> On 19.07.2006, at 14:11, Pascal S. de Kloe wrote: >>> >>>> Hi Joachim, >>>> >>>> Thanks for the constructive critisism. :) >>>> >>>> Op woensdag 19 juli 2006 09:17, schreef Joachim Buechse: >>>>> The static objects will work for Windows and Linux, however for OSX >>>>> they will create problems: >>>>> - ports can appear and disappear at any time with VCP drivers for USB >>>>> - the port names are not known until the usb-port is "plugged in" >>>> Ports can appear and disappear on *any* OS with USB support. Some >>>> Linux >>>> distributions even create and remove devicefiles on the fly. >>>> >>>> With the current API you fetch a list of all available ports and >>>> then you try >>>> to cast one. What happens if the port is no longer available at >>>> that time? >>>> What happens if a port vanishes during the data transfer? Of course >>>> you can >>>> catch exceptions but that makes the code quite messy. >>>> >>>> The idea was to get a PortStillAvailableListener interface. In that >>>> way the >>>> implementation is free to handle a cleanup or wait for return >>>> routine in a OO >>>> way. The I/O streams should just lock. >>>> >>>> The word static was not ment as persistent but as Java static >>>> available. >>>> Considder the following: >>>> >>>> java.lang.hw.HardwareConfiguration { >>>> public enum PortType { RS232, I2C, etc. }; >>>> >>>> /** Gets the currently available ports of type {@code PortType}. */ >>>> public static java.lang.hw.Port[] getPorts(PortType); >>>> } >>>> >>>> com.example.Driver implements PortUser, implements >>>> PortStillAvailableListener >>>> { >>>> public portNoLongerAvailable(PortEvent event) { >>>> // cleanup & dismiss. >>>> } >>>> } >>>> >>>> com.example.Application { >>>> public static void main(String[] args) { >>>> Driver someDriver = new Driver(); >>>> Port radomPort = HardwareConfiguration.getPorts( >>>> HardwareConfiguration.PortType.RS232)[1]; >>>> myDevice.addStillAvailableListener(someDriver); >>>> myDevice.connect(someDriver); >>>> } >>>> } >>>> >>>>> Please do not forget that tty ports can be opened by several >>>>> applications concurrently. All of those will "loose" the port if >>>>> anyone opens the corresponding cu port. >>>> Indeed we need a good overview of the differences between the various >>>> platforms. Should we create a document or a Wiki for this purpose? >>>> >>>> FreeBSD, NetBSD and OpenBSD have the UUCPLOCK facility: >>>> http://www.openbsd.org/cgi-bin/man.cgi? >>>> query=uu_lock&apropos=0&sektion=0&manpath=OpenBSD >>>> +Current&arch=i386&format=html >>>> >>>> Linux uses /var/lock: >>>> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES >>>> >>>> Is there absolutely no way to get a lock under Windows? >>>> >>>>> As this naming based >>>>> mechanism does not exist on Windows (maybe it does via an API) it >>>>> should probably be reflected in the API. In other words there are >>>>> "two levels of open": >>>>> >>>>> - Open for reading status lines (1) >>>>> - Open for reading/writing data (2) >>>>> >>>>> I am not sure if state (1) should also allow the modification of >>>>> certain status lines (ie to set a modem ready). >>>> I'm not sure I understand. Do you mean canonical and noncanonical >>>> mode? >>>> >>>> How far is Windows with the canonical mode. Is it comparable to POSIX? >>>> >>>>> I am also not sure if >>>>> the api should unify corresponding cu. and tty. ports into one single >>>>> port. >>>> I think the API should hide low-level details like devicefiles. >>>> >>>> >>>> Who is participating anyway? Is it just the four of us? >>>> >>>> Cheers, >>>> >>>> Pascal >>>> >>>> >>>>> On 19.07.2006, at 02:12, Pascal S. de Kloe wrote: >>>>>> For instance the current API is not very object oriented. >>>>>> It might be a good idea to have a static set of objects available >>>>>> representing >>>>>> every supported port available on the system in realtime. Each >>>>>> object should >>>>>> clearly know its own state and its capabilities. To get a port >>>>>> there could be >>>>>> a method like synchronized void connect(PortUser) where PortUser >>>>>> is a >>>>>> interface which handles the interaction with a input and a output >>>>>> stream and >>>>>> listers like PortStillAvailableListener, PortBufferListener and a >>>>>> DataAvailableListener. >>>>>> >>>>>> What is the collective feeling about that? >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From jredman at ergotech.com Wed Jul 19 18:03:40 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 18:03:40 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEC0D8.4050806@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> Message-ID: <44BEC85C.2030809@ergotech.com> Paul Klissner wrote: > I'd just like to find another suitable name than javax.comm, unless > the JSR wants to start with javax.comm 4.0, since all the previous > 'major revisions' are accounted for. javax.serialport? Which perhaps brings us back to what are we trying to fix and how badly. There are a number of 3rd party implementation of Java Comm, at least one from IBM - part of what was J9, now Websphere, or something (presumbly soon to get a name that has eclipse in it sometime soon). Esmertec has one, and there are few others rolling around. If RXTX is the only implementation of the JSR with no backward compatibility, we've just forked Java Serial support and we (for a least one) will be worse off. We won't be able to use the new support because of a lack of support on J2ME platforms that we have no control over and RXTX/current JavaComm will be in maintenance mode or unsupported on all other platforms. So, is there any chance of building a compatibility requirement into this. To pick are really bad example JDBC has support for a DataSource or a Driver. Could we have an ExcellentSerialPort with a fallback to a SerialPort on a class not found exception? Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From pascal at quies.net Wed Jul 19 18:22:45 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Thu, 20 Jul 2006 02:22:45 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEC85C.2030809@ergotech.com> References: <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> Message-ID: <200607200222.46023.pascal@quies.net> Op donderdag 20 juli 2006 02:03, schreef Jim Redman: > Which perhaps brings us back to what are we trying to fix and how badly. The initail problem was the license. :) RXTX is sitting in this gnu.comm namespace and is afraid to go to javax.comm. Getting a JSR would solve this problem. And while we're at it we might as well improve the situation with the various platforms. I made some sugestions that where denied as too complex. Cheers, Pascal From Paul.Klissner at Sun.COM Wed Jul 19 19:09:35 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 18:09:35 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607200222.46023.pascal@quies.net> References: <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <200607200222.46023.pascal@quies.net> Message-ID: <44BED7CF.5080405@sun.com> Pascal S. de Kloe wrote: > Op donderdag 20 juli 2006 02:03, schreef Jim Redman: >> Which perhaps brings us back to what are we trying to fix and how badly. > > The initail problem was the license. :) > > RXTX is sitting in this gnu.comm namespace and is afraid to go to javax.comm. > Getting a JSR would solve this problem. > > And while we're at it we might as well improve the situation with the various > platforms. I made some sugestions that where denied as too complex. "Denied" is a bit harsh :) I'll re-examine your e-mails to see if my preferences change. It's not like your proposition has been put up to a formal vote, just discussion. Paul From Paul.Klissner at Sun.COM Wed Jul 19 19:28:47 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 18:28:47 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEC85C.2030809@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> Message-ID: <44BEDC4F.9030403@sun.com> Jim Redman wrote: > Paul Klissner wrote: >> I'd just like to find another suitable name than javax.comm, unless >> the JSR wants to start with javax.comm 4.0, since all the previous >> 'major revisions' are accounted for. javax.serialport? > > Which perhaps brings us back to what are we trying to fix and how badly. The goals I'm most interested in at the moment are: 1. A pluggable platform portmapping scheme wherein each platform can determine which ports to present to the application, and preferably as some configurable logical name. For example on the Sun Ray thin client platform, if an application aquiring a view of serial ports available on the system, it will be informed of Sun Ray serial ports if the application is running in a session currently directed to that particular Sun Ray unit, even though the serial port's device node happens to be server-side deeply nested in a leaf node. If the application is not running on a Sun Ray the port doesn't show up. The Sun Ray plugin would make the decision about when and which ports to present to the application. 2. Pluggable driver-side interface where multiple platform-specific drivers can be utilized simultaneously to introduce more flexibility with the back end. > There are a number of 3rd party implementation of Java Comm, at least > one from IBM - part of what was J9, now Websphere, or something > (presumbly soon to get a name that has eclipse in it sometime soon). > Esmertec has one, and there are few others rolling around. I have not been advocating gutting the API, since much of it is perfectly adequate. I'm not totally opposed to making substantial changes or improvements depending on other people's needs. There's no reason previous versions of javax.comm need to suddenly disappear if products need legacy support. > > If RXTX is the only implementation of the JSR with no backward > compatibility, we've just forked Java Serial support and we (for a least > one) will be worse off. We won't be able to use the new support because > of a lack of support on J2ME platforms that we have no control over and > RXTX/current JavaComm will be in maintenance mode or unsupported on all > other platforms. There can't be *that* many platforms this is ported to. And it will be no javax.usb. Seems like most of the standard platforms will be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, JDBC... > > So, is there any chance of building a compatibility requirement into > this. To pick are really bad example JDBC has support for a DataSource > or a Driver. Could we have an ExcellentSerialPort with a fallback to a > SerialPort on a class not found exception? Maybe, or maybe we just let people know what we are doing and try to figure out how to get their applications ported. Might not be that difficult. From my standpoint anyway, earthshaking changes aren't really necessary. Others might disagree. Paul From rwelty at averillpark.net Wed Jul 19 19:35:54 2006 From: rwelty at averillpark.net (Richard P. Welty) Date: Wed, 19 Jul 2006 21:35:54 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter Message-ID: <44BEDDFA.7020108@averillpark.net> I'm returning to the use of rxtx after 2 years off doing things that don't need serial ports. I'm trying to get my laptop (fedora core 1) talking to a set of portable auto scales through a Keyspan USB adapter (in my past use of rxtx, I had actual serial ports, but those days are long gone.) I have the keyspan kernel module loaded, and lsusb shows the device as correctly identified. I'm missing the bit of magic needed to get rxtx to provide the port in response to CommPortIdentifier.getPortIdentifiers() thanks in advance for any help, richard From jredman at ergotech.com Wed Jul 19 19:43:25 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 19:43:25 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BED7CF.5080405@sun.com> References: <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <200607200222.46023.pascal@quies.net> <44BED7CF.5080405@sun.com> Message-ID: <44BEDFBD.4020404@ergotech.com> Paul Klissner wrote: > Pascal S. de Kloe wrote: >> Op donderdag 20 juli 2006 02:03, schreef Jim Redman: >>> Which perhaps brings us back to what are we trying to fix and how badly. >> The initail problem was the license. :) >> >> RXTX is sitting in this gnu.comm namespace and is afraid to go to javax.comm. >> Getting a JSR would solve this problem. >> >> And while we're at it we might as well improve the situation with the various >> platforms. I made some sugestions that where denied as too complex. > > "Denied" is a bit harsh :) I'll re-examine your e-mails > to see if my preferences change. It's not like your > proposition has been put up to a formal vote, just discussion. OK, I'll officially float backwards compatibility in the form of "It should be possible to use anything that comes out of the JSR in place of an existing java comm implementation". I wonder if "Denied" is too harsh for that one :) Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From ajmas at sympatico.ca Wed Jul 19 19:47:06 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Wed, 19 Jul 2006 21:47:06 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEDDFA.7020108@averillpark.net> References: <44BEDDFA.7020108@averillpark.net> Message-ID: <35101C10-59A5-4F02-AEEE-DB69112F8130@sympatico.ca> Do you see an associated device in /dev ? On 19-Jul-06, at 21:35 , Richard P. Welty wrote: > I'm returning to the use of rxtx after 2 years off doing > things that don't need serial ports. > > I'm trying to get my laptop (fedora core 1) talking to a > set of portable auto scales through a Keyspan USB adapter > (in my past use of rxtx, I had actual serial ports, but those > days are long gone.) I have the keyspan kernel module loaded, > and lsusb shows the device as correctly identified. I'm missing > the bit of magic needed to get rxtx to provide the port > in response to CommPortIdentifier.getPortIdentifiers() > > thanks in advance for any help, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Wed Jul 19 19:54:03 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 19:54:03 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEDC4F.9030403@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> Message-ID: <44BEE23B.30908@ergotech.com> Paul, For the record we're STILL supporting some PersonalJava platforms. We're _almost_ at the point where we can assume that the platforms will have a Collections framework, but routinely compile with a 1.1 check so that we don't make that assumption unnecessarily. Of 50+ non-graphical Factory Automation JavaBeans we have 2 that require Java2 (Reporting and JavaScripting), and we have people asking for a back-port. Embedded platforms don't change in a hurry. Unlike desktop platforms, embedded systems are expected to last 5-10+ years. There are factory automation vendors in the pharmaceutical industry who are buying systems on eBay because that's the FDA validate platform. It must be that make/model, spec'd sometime in the mid-90's. So... If you make an incompatible change TODAY figure we can start using that code _at the earliest_ somewhere around 2012 or the low teens. Are we _really_ the only people on the list supporting embedded/factory automation platforms? Jim Paul Klissner wrote: > Jim Redman wrote: >> Paul Klissner wrote: >>> I'd just like to find another suitable name than javax.comm, unless >>> the JSR wants to start with javax.comm 4.0, since all the previous >>> 'major revisions' are accounted for. javax.serialport? >> Which perhaps brings us back to what are we trying to fix and how badly. > The goals I'm most interested in at the moment are: > > 1. A pluggable platform portmapping scheme wherein each platform > can determine which ports to present to the application, and > preferably as some configurable logical name. > > For example on the Sun Ray thin client platform, if an application > aquiring a view of serial ports available on the system, it will > be informed of Sun Ray serial ports if the application is running > in a session currently directed to that particular Sun Ray unit, > even though the serial port's device node happens to be server-side > deeply nested in a leaf node. If the application is not running on > a Sun Ray the port doesn't show up. The Sun Ray plugin would make > the decision about when and which ports to present to the application. > > 2. Pluggable driver-side interface where multiple platform-specific > drivers can be utilized simultaneously to introduce more flexibility > with the back end. > >> There are a number of 3rd party implementation of Java Comm, at least >> one from IBM - part of what was J9, now Websphere, or something >> (presumbly soon to get a name that has eclipse in it sometime soon). >> Esmertec has one, and there are few others rolling around. > > I have not been advocating gutting the API, since much of it is > perfectly adequate. I'm not totally opposed to making substantial > changes or improvements depending on other people's needs. There's > no reason previous versions of javax.comm need to suddenly disappear > if products need legacy support. > > >> If RXTX is the only implementation of the JSR with no backward >> compatibility, we've just forked Java Serial support and we (for a least >> one) will be worse off. We won't be able to use the new support because >> of a lack of support on J2ME platforms that we have no control over and >> RXTX/current JavaComm will be in maintenance mode or unsupported on all >> other platforms. > > There can't be *that* many platforms this is ported to. And it will > be no javax.usb. Seems like most of the standard platforms will > be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, > JDBC... > >> So, is there any chance of building a compatibility requirement into >> this. To pick are really bad example JDBC has support for a DataSource >> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >> SerialPort on a class not found exception? > > Maybe, or maybe we just let people know what we are doing and > try to figure out how to get their applications ported. Might not > be that difficult. From my standpoint anyway, earthshaking > changes aren't really necessary. Others might disagree. > > Paul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tod at todbot.com Wed Jul 19 19:59:52 2006 From: tod at todbot.com (Tod E. Kurt) Date: Wed, 19 Jul 2006 18:59:52 -0700 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEDDFA.7020108@averillpark.net> References: <44BEDDFA.7020108@averillpark.net> Message-ID: Hi, "lsusb" doesn't show if you have the proper drivers loaded for the specific USB device, just that a USB device is plugged in. The text identifiers sent by the USB device aren't used by the OS except for things like lsusb. Look at the output of "dmesg" or /var/log/messages and see if you have a lines that looks like: keyspan 1-1:1.0: Keyspan 1 port adapter converter detected usb 1-1: Keyspan 1 port adapter converter now attached to ttyUSB0 If you do, then you've got a serial port at "/dev/ttyUSB0", and you can use minicom or whatever (even RXTX!) to play with it. If you get a message like: usb.c: USB device 4 (vend/prod 0x06cd/0x0121) is not claimed by any active driver. Then the USB driver can't find the 'keyspan' driver. If you're sure you have this driver, then hotplug isn't working for some reason. You could try running the command: % sudo modprobe keyspan And see if anything useful happens. You should see the 'keyspan' driver when you type "lsmod" to list the currently loaded kernel modules. -=tod On Jul 19, 2006, at 6:35 PM, Richard P. Welty wrote: > I'm returning to the use of rxtx after 2 years off doing > things that don't need serial ports. > > I'm trying to get my laptop (fedora core 1) talking to a > set of portable auto scales through a Keyspan USB adapter > (in my past use of rxtx, I had actual serial ports, but those > days are long gone.) I have the keyspan kernel module loaded, > and lsusb shows the device as correctly identified. I'm missing > the bit of magic needed to get rxtx to provide the port > in response to CommPortIdentifier.getPortIdentifiers() > > thanks in advance for any help, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From rwelty at suespammers.org Wed Jul 19 20:05:18 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Wed, 19 Jul 2006 22:05:18 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <35101C10-59A5-4F02-AEEE-DB69112F8130@sympatico.ca> References: <44BEDDFA.7020108@averillpark.net> <35101C10-59A5-4F02-AEEE-DB69112F8130@sympatico.ca> Message-ID: <44BEE4DE.9080707@suespammers.org> Andr?-John Mas wrote: > Do you see an associated device in /dev ? Well, there are lots of /dev/ttyUSB devices, there, but nothing jumps out as having been assigned to the keyspan. But then, I'm not that knowledgable about the USB mapping here; this is the first time I've tried to use one this way and I'm on the steep part of the learning curve. richard From rwelty at suespammers.org Wed Jul 19 20:08:20 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Wed, 19 Jul 2006 22:08:20 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: References: <44BEDDFA.7020108@averillpark.net> Message-ID: <44BEE594.50402@suespammers.org> Tod E. Kurt wrote: > Then the USB driver can't find the 'keyspan' driver. If you're sure > you have this driver, then hotplug isn't working for some reason. > You could try running the command: Ok, it looks like the keyspan driver may be the problem; it's having some sort of problem loading it. I'll have to look into this further tomorrow night. thanks, richard From pascal at quies.net Wed Jul 19 20:11:21 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Thu, 20 Jul 2006 04:11:21 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEDFBD.4020404@ergotech.com> References: <44BED7CF.5080405@sun.com> <44BEDFBD.4020404@ergotech.com> Message-ID: <200607200411.22012.pascal@quies.net> Op donderdag 20 juli 2006 03:43, schreef Jim Redman: > Paul Klissner wrote: > > Pascal S. de Kloe wrote: > >> Op donderdag 20 juli 2006 02:03, schreef Jim Redman: > >>> Which perhaps brings us back to what are we trying to fix and how > >>> badly. > >> > >> The initail problem was the license. :) > >> > >> RXTX is sitting in this gnu.comm namespace and is afraid to go to > >> javax.comm. Getting a JSR would solve this problem. > >> > >> And while we're at it we might as well improve the situation with the > >> various platforms. I made some sugestions that where denied as too > >> complex. > > > > "Denied" is a bit harsh :) I'll re-examine your e-mails > > to see if my preferences change. It's not like your > > proposition has been put up to a formal vote, just discussion. > > OK, I'll officially float backwards compatibility in the form of "It > should be possible to use anything that comes out of the JSR in place of > an existing java comm implementation". > > I wonder if "Denied" is too harsh for that one :) > > Jim Hehehe. I don't have any troubles with people voting against my ideas at all so don't worry Paul. :) However, it is exactly the compatibilty thing where Jim is talking about what makes me want to make a *huge* change if any. From jredman at ergotech.com Wed Jul 19 20:25:50 2006 From: jredman at ergotech.com (Jim Redman) Date: Wed, 19 Jul 2006 20:25:50 -0600 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEE594.50402@suespammers.org> References: <44BEDDFA.7020108@averillpark.net> <44BEE594.50402@suespammers.org> Message-ID: <44BEE9AE.3030200@ergotech.com> Some who remembers this better than me please help. You also need something like: -Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3 When you start the application. This can be put in a properties files (where?). Jim Richard P. Welty wrote: > Tod E. Kurt wrote: > >> Then the USB driver can't find the 'keyspan' driver. If you're sure >> you have this driver, then hotplug isn't working for some reason. >> You could try running the command: > > Ok, it looks like the keyspan driver may be the problem; it's having > some sort of problem loading it. I'll have to look into this further > tomorrow night. > > thanks, > richard > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From ajmas at sympatico.ca Wed Jul 19 20:32:52 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Wed, 19 Jul 2006 22:32:52 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEE9AE.3030200@ergotech.com> References: <44BEDDFA.7020108@averillpark.net> <44BEE594.50402@suespammers.org> <44BEE9AE.3030200@ergotech.com> Message-ID: Are you sure about this? I know on MacOS X no such configuration was needed. If this is indeed true, this is poor design, in this day and age of dynamic devices. On 19-Jul-06, at 22:25 , Jim Redman wrote: > Some who remembers this better than me please help. > > You also need something like: > > -Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyUSB0:/dev/ttyUSB1:/ > dev/ttyUSB2:/dev/ttyUSB3 > > When you start the application. This can be put in a properties files > (where?). > > Jim > > Richard P. Welty wrote: >> Tod E. Kurt wrote: >> >>> Then the USB driver can't find the 'keyspan' driver. If you're sure >>> you have this driver, then hotplug isn't working for some reason. >>> You could try running the command: >> >> Ok, it looks like the keyspan driver may be the problem; it's having >> some sort of problem loading it. I'll have to look into this further >> tomorrow night. >> >> thanks, >> richard >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From rwelty at suespammers.org Wed Jul 19 20:41:01 2006 From: rwelty at suespammers.org (Richard P. Welty) Date: Wed, 19 Jul 2006 22:41:01 -0400 Subject: [Rxtx] rxtx & Keyspan serial/usb adapter In-Reply-To: <44BEE9AE.3030200@ergotech.com> References: <44BEDDFA.7020108@averillpark.net> <44BEE594.50402@suespammers.org> <44BEE9AE.3030200@ergotech.com> Message-ID: <44BEED3D.5020304@suespammers.org> Jim Redman wrote: > Some who remembers this better than me please help. > > You also need something like: > > -Djavax.comm.rxtx.SerialPorts=/dev/ttyS0:/dev/ttyUSB0:/dev/ttyUSB1:/dev/ttyUSB2:/dev/ttyUSB3 > > When you start the application. This can be put in a properties files > (where?). Thanks for all the help, guys. Thinking back on how this laptop came to be in its current state, I'm of the opinion a format and complete rebuild with a newer version of Fedora is in order before I waste any more time in diagnosis. The problems I'm seeing clearly have nothing to do with RXTX and everything to do with how many upgrades have been chained together getting this laptop from whereever I started (RH 7.0 or 7.1) to FC1. It could probably be fixed in place, but I shudder to think about the amount of time needed to figure out the proper fix. But the software I'm putting together will need to run on Y2K/XP and Mac OS X, so I'll be following portability and installer discussions on this list rather intently (http://scale-app.sourceforge.net for anyone who cares.) richard From Paul.Klissner at Sun.COM Wed Jul 19 22:53:53 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 21:53:53 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEE23B.30908@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> Message-ID: <44BF0C61.4020900@sun.com> Jim Redman wrote: > Paul, > > For the record we're STILL supporting some PersonalJava platforms. > We're _almost_ at the point where we can assume that the platforms will > have a Collections framework, but routinely compile with a 1.1 check so > that we don't make that assumption unnecessarily. Of 50+ non-graphical > Factory Automation JavaBeans we have 2 that require Java2 (Reporting and > JavaScripting), and we have people asking for a back-port. > > Embedded platforms don't change in a hurry. Unlike desktop platforms, > embedded systems are expected to last 5-10+ years. > > There are factory automation vendors in the pharmaceutical industry who > are buying systems on eBay because that's the FDA validate platform. It > must be that make/model, spec'd sometime in the mid-90's. > > So... If you make an incompatible change TODAY figure we can start using > that code _at the earliest_ somewhere around 2012 or the low teens. > > Are we _really_ the only people on the list supporting embedded/factory > automation platforms? > > Jim Do you provide your own implementation classes? Why can't you just continue to use 2.1 for the embedded platform until 2012 if you're locked down? Are you worried bugs won't get fixed? Sun might consider open sourcing the 2.1 Java source. I can't promise that, but it's been discussed and hasn't met resistance, except from me, because I wasn't super impressed with the code. I can probably be persuaded to champion open sourcing that and going through the process/legal machinations within Sun if it frees us to pursue a JSR for a new generation of javax.comm where we can have a chunk of common code in Open Source and each platform is simply responsible for it's platform specific plugins. I don't have many opinions about this set in stone because there are a lot of technical and pragmatic considerations such as yours the community has that I am probably not aware of or sufficiently sensitive to yet. I don't feel I really have the bird's eye view of all of this yet. The other thing is, I can only offer 10% of my time right now, according to my management, which is why I'm not pushing to be the spec lead for the JSR, and want only to be a participant to represent Sun's interests on the E.G. There is nothing sacred about Sun employees in the JCP as far as a JSR initiated by another entity is concerned. I am not the person everything needs to be cleared through. Ideas I have will pass or fail based on their merit and the community perception just like anyone else's. Paul > > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul Klissner wrote: >>>> I'd just like to find another suitable name than javax.comm, unless >>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>> 'major revisions' are accounted for. javax.serialport? >>> Which perhaps brings us back to what are we trying to fix and how badly. >> The goals I'm most interested in at the moment are: >> >> 1. A pluggable platform portmapping scheme wherein each platform >> can determine which ports to present to the application, and >> preferably as some configurable logical name. >> >> For example on the Sun Ray thin client platform, if an application >> aquiring a view of serial ports available on the system, it will >> be informed of Sun Ray serial ports if the application is running >> in a session currently directed to that particular Sun Ray unit, >> even though the serial port's device node happens to be server-side >> deeply nested in a leaf node. If the application is not running on >> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >> the decision about when and which ports to present to the application. >> >> 2. Pluggable driver-side interface where multiple platform-specific >> drivers can be utilized simultaneously to introduce more flexibility >> with the back end. >> >>> There are a number of 3rd party implementation of Java Comm, at least >>> one from IBM - part of what was J9, now Websphere, or something >>> (presumbly soon to get a name that has eclipse in it sometime soon). >>> Esmertec has one, and there are few others rolling around. >> I have not been advocating gutting the API, since much of it is >> perfectly adequate. I'm not totally opposed to making substantial >> changes or improvements depending on other people's needs. There's >> no reason previous versions of javax.comm need to suddenly disappear >> if products need legacy support. >> >> >>> If RXTX is the only implementation of the JSR with no backward >>> compatibility, we've just forked Java Serial support and we (for a least >>> one) will be worse off. We won't be able to use the new support because >>> of a lack of support on J2ME platforms that we have no control over and >>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>> other platforms. >> There can't be *that* many platforms this is ported to. And it will >> be no javax.usb. Seems like most of the standard platforms will >> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >> JDBC... >> >>> So, is there any chance of building a compatibility requirement into >>> this. To pick are really bad example JDBC has support for a DataSource >>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>> SerialPort on a class not found exception? >> Maybe, or maybe we just let people know what we are doing and >> try to figure out how to get their applications ported. Might not >> be that difficult. From my standpoint anyway, earthshaking >> changes aren't really necessary. Others might disagree. >> >> Paul >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From Paul.Klissner at Sun.COM Thu Jul 20 00:27:41 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Wed, 19 Jul 2006 23:27:41 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BF0C61.4020900@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> Message-ID: <44BF225D.80104@sun.com> Paul Klissner wrote: > Jim Redman wrote: >> Paul, >> >> For the record we're STILL supporting some PersonalJava platforms. >> We're _almost_ at the point where we can assume that the platforms will >> have a Collections framework, but routinely compile with a 1.1 check so >> that we don't make that assumption unnecessarily. Of 50+ non-graphical >> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >> JavaScripting), and we have people asking for a back-port. >> >> Embedded platforms don't change in a hurry. Unlike desktop platforms, >> embedded systems are expected to last 5-10+ years. >> >> There are factory automation vendors in the pharmaceutical industry who >> are buying systems on eBay because that's the FDA validate platform. It >> must be that make/model, spec'd sometime in the mid-90's. >> >> So... If you make an incompatible change TODAY figure we can start using >> that code _at the earliest_ somewhere around 2012 or the low teens. >> >> Are we _really_ the only people on the list supporting embedded/factory >> automation platforms? >> >> Jim > > Do you provide your own implementation classes? > > Why can't you just continue to use 2.1 for the embedded platform until > 2012 if you're locked down? Are you worried bugs won't get fixed? > Sun might consider open sourcing the 2.1 Java source. Excuse me, I meant 2.0.3 > I can't promise > that, but it's been discussed and hasn't met resistance, except > from me, because I wasn't super impressed with the code. I can probably > be persuaded to champion open sourcing that and going through the > process/legal machinations within Sun if it frees us to pursue > a JSR for a new generation of javax.comm where we can have a chunk of > common code in Open Source and each platform is simply responsible > for it's platform specific plugins. > > I don't have many opinions about this set in stone because there > are a lot of technical and pragmatic considerations such as yours > the community has that I am probably not aware of or sufficiently > sensitive to yet. I don't feel I really have the bird's eye view > of all of this yet. > > The other thing is, I can only offer 10% of my time right now, > according to my management, which is why I'm not pushing to > be the spec lead for the JSR, and want only to be a participant > to represent Sun's interests on the E.G. There is nothing sacred > about Sun employees in the JCP as far as a JSR initiated by another > entity is concerned. I am not the person everything needs to be > cleared through. Ideas I have will pass or fail based on their > merit and the community perception just like anyone else's. > > Paul > >> Paul Klissner wrote: >>> Jim Redman wrote: >>>> Paul Klissner wrote: >>>>> I'd just like to find another suitable name than javax.comm, unless >>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>> 'major revisions' are accounted for. javax.serialport? >>>> Which perhaps brings us back to what are we trying to fix and how badly. >>> The goals I'm most interested in at the moment are: >>> >>> 1. A pluggable platform portmapping scheme wherein each platform >>> can determine which ports to present to the application, and >>> preferably as some configurable logical name. >>> >>> For example on the Sun Ray thin client platform, if an application >>> aquiring a view of serial ports available on the system, it will >>> be informed of Sun Ray serial ports if the application is running >>> in a session currently directed to that particular Sun Ray unit, >>> even though the serial port's device node happens to be server-side >>> deeply nested in a leaf node. If the application is not running on >>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>> the decision about when and which ports to present to the application. >>> >>> 2. Pluggable driver-side interface where multiple platform-specific >>> drivers can be utilized simultaneously to introduce more flexibility >>> with the back end. >>> >>>> There are a number of 3rd party implementation of Java Comm, at least >>>> one from IBM - part of what was J9, now Websphere, or something >>>> (presumbly soon to get a name that has eclipse in it sometime soon). >>>> Esmertec has one, and there are few others rolling around. >>> I have not been advocating gutting the API, since much of it is >>> perfectly adequate. I'm not totally opposed to making substantial >>> changes or improvements depending on other people's needs. There's >>> no reason previous versions of javax.comm need to suddenly disappear >>> if products need legacy support. >>> >>> >>>> If RXTX is the only implementation of the JSR with no backward >>>> compatibility, we've just forked Java Serial support and we (for a least >>>> one) will be worse off. We won't be able to use the new support because >>>> of a lack of support on J2ME platforms that we have no control over and >>>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>>> other platforms. >>> There can't be *that* many platforms this is ported to. And it will >>> be no javax.usb. Seems like most of the standard platforms will >>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>> JDBC... >>> >>>> So, is there any chance of building a compatibility requirement into >>>> this. To pick are really bad example JDBC has support for a DataSource >>>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>>> SerialPort on a class not found exception? >>> Maybe, or maybe we just let people know what we are doing and >>> try to figure out how to get their applications ported. Might not >>> be that difficult. From my standpoint anyway, earthshaking >>> changes aren't really necessary. Others might disagree. >>> >>> Paul >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Thu Jul 20 00:50:21 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 20 Jul 2006 08:50:21 +0200 Subject: [Rxtx] jcp and jsr Message-ID: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> Hi all, I work with SNIJDER Micro Systems. We're doing embedded Java and just heard about this discussion by way of Ted Kosan from the embedded Java community. We think Jim is right about the compatibility issues for embedded Java platforms. Our own embedded Java platform (see http://www.embedded-web.com ) uses a 3rd party implementation of javax.comm written by the JVM vendor. As Jim says, changes take much longer to propagate in the embedded space. If the 'new' javax.comm is not backwards compatible, embedded JVM vendors (esmertec, IBM, Tao Group, etc.) will probably evaluate whether it makes sense for them to support the new API. Some will eventually adopt it, but that will take time. Some will just stay with the current API, thus increasing the gap between embedded Java developers and desktop Java developers (different APIs to do the same thing) This is a very real problem in our opinion. Also taking into account that many desktop computers nowadays don't even have standard serial ports, I believe that the embedded Java community already gathers a significant share of the potential javax.comm users. I think backwards compatibility should be seriously considered. Best regards, Guillermo Jim Redman wrote: >Paul Klissner wrote: > > I'd just like to find another suitable name than javax.comm, unless > > the JSR wants to start with javax.comm 4.0, since all the previous > > 'major revisions' are accounted for. javax.serialport? > >Which perhaps brings us back to what are we trying to fix and how badly. > >There are a number of 3rd party implementation of Java Comm, at least >one from IBM - part of what was J9, now Websphere, or something >(presumbly soon to get a name that has eclipse in it sometime soon). >Esmertec has one, and there are few others rolling around. > >If RXTX is the only implementation of the JSR with no backward >compatibility, we've just forked Java Serial support and we (for a least >one) will be worse off. We won't be able to use the new support because >of a lack of support on J2ME platforms that we have no control over and >RXTX/current JavaComm will be in maintenance mode or unsupported on all >other platforms. > >So, is there any chance of building a compatibility requirement into >this. To pick are really bad example JDBC has support for a DataSource >or a Driver. Could we have an ExcellentSerialPort with a fallback to a >SerialPort on a class not found exception? > >Jim -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Thu Jul 20 00:57:04 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 20 Jul 2006 08:57:04 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> References: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> Message-ID: <7.0.1.0.0.20060720085221.036d88e8@sms.nl> Paul Klissner wrote: >Jim Redman wrote: > > Paul, > > > > For the record we're STILL supporting some PersonalJava platforms. > > We're _almost_ at the point where we can assume that the platforms will > > have a Collections framework, but routinely compile with a 1.1 check so > > that we don't make that assumption unnecessarily. Of 50+ non-graphical > > Factory Automation JavaBeans we have 2 that require Java2 (Reporting and > > JavaScripting), and we have people asking for a back-port. > > > > Embedded platforms don't change in a hurry. Unlike desktop platforms, > > embedded systems are expected to last 5-10+ years. > > > > There are factory automation vendors in the pharmaceutical industry who > > are buying systems on eBay because that's the FDA validate platform. It > > must be that make/model, spec'd sometime in the mid-90's. > > > > So... If you make an incompatible change TODAY figure we can start using > > that code _at the earliest_ somewhere around 2012 or the low teens. > > > > Are we _really_ the only people on the list supporting embedded/factory > > automation platforms? > > > > Jim > >Do you provide your own implementation classes? > >Why can't you just continue to use 2.1 for the embedded platform until >2012 if you're locked down? Are you worried bugs won't get fixed? If embedded platforms keep using the "old" (current) javax.comm API but the desktop Java world starts to use a new, backwards-incompatible API, then this will result in more trouble for embedded Java application developers as they will no longer be able to use the same API on desktop systems and embedded platforms. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Thu Jul 20 00:59:16 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Thu, 20 Jul 2006 08:59:16 +0200 Subject: [Rxtx] jcp and jsr Message-ID: <7.0.1.0.0.20060720085812.036d9c28@sms.nl> Pascal S. de Kloe wrote: >Who is participating anyway? Is it just the four of us? > >Cheers, > >Pascal We would be more than happy to participate if we can be of any help. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From Paul.Klissner at Sun.COM Thu Jul 20 02:23:42 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Thu, 20 Jul 2006 01:23:42 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <7.0.1.0.0.20060720085221.036d88e8@sms.nl> References: <7.0.1.0.0.20060720083646.036e0ed8@sms.nl> <7.0.1.0.0.20060720085221.036d88e8@sms.nl> Message-ID: <44BF3D8E.4030705@sun.com> Guillermo Rodriguez Garcia wrote: > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul, >>> >>> For the record we're STILL supporting some PersonalJava platforms. >>> We're _almost_ at the point where we can assume that the platforms will >>> have a Collections framework, but routinely compile with a 1.1 check so >>> that we don't make that assumption unnecessarily. Of 50+ non-graphical >>> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >>> JavaScripting), and we have people asking for a back-port. >>> >>> Embedded platforms don't change in a hurry. Unlike desktop platforms, >>> embedded systems are expected to last 5-10+ years. >>> >>> There are factory automation vendors in the pharmaceutical industry who >>> are buying systems on eBay because that's the FDA validate platform. It >>> must be that make/model, spec'd sometime in the mid-90's. >>> >>> So... If you make an incompatible change TODAY figure we can start using >>> that code _at the earliest_ somewhere around 2012 or the low teens. >>> >>> Are we _really_ the only people on the list supporting embedded/factory >>> automation platforms? >>> >>> Jim >> Do you provide your own implementation classes? >> >> Why can't you just continue to use 2.1 for the embedded platform until >> 2012 if you're locked down? Are you worried bugs won't get fixed? > > If embedded platforms keep using the "old" (current) javax.comm API but > the desktop Java world starts to use a new, backwards-incompatible API, > then this will result in more trouble for embedded Java application > developers as they will no longer be able to use the same API on desktop > systems and embedded platforms. OK, I understand the situation more clearly now. The kinds of changes I'm opting don't seem difficult to design in a backward compatible way. I haven't scrutinized the other requests on the list. I guess it will be interesting to hear what the proponents for other changes have to say. Paul > > Guillermo > > -- > Guillermo Rodriguez Garcia > > Snijder Micro Systems phone +31-493-351020 > G. Rodriguez Garcia fax +31-493-351530 > Visser 25 email guille at sms.nl > NL5751 BL Deurne > The Netherlands http://www.snijder.com > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Thu Jul 20 02:46:09 2006 From: joachim at buechse.de (Joachim Buechse) Date: Thu, 20 Jul 2006 10:46:09 +0200 Subject: [Rxtx] quo vadis API/namespace (Re: jcp and jsr) In-Reply-To: <44BEDC4F.9030403@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> Message-ID: Paul, for the first time in many months, I have the impression, that we have the same agenda;-) If the "driver-level"-api changes however "nobody" will be disappointed. However, regarding the user-level-api I disagree. As fundamental changes to the API have been suggested several times I must be ignoring something. I would be delighted to learn were the current API fails - i.e. what can not be done or is overly complex based on the current API. Of course it is better fun to start something from scratch, but unless there are really substantial gains from completely redesigning an API I don't see the point. The promise of Java is to write once (which I interpret as write against the same API for all platforms). Getting VM providers like esmertec to support a new/replacement API is not a simple task, it requires a business case which for the biggest part simply does not exist. If we keep the javax.comm namespace and keep the "user-level"-api a superset of the current PortIdentifier/Port-api, the same application can work against javax.comm 2.0/3.0/future.x. Of course a factory/wrapping approach can always unify different APIs but this adds more implementation/ testing complexity to every application. So in short: Unless we find a strong argument why javax.comm can't be used I prefer that we keep it. Unless we find a strong feature / use- case that can not be handled with (an extension of) the current CommPort/CommPortIndentifier I'd prefer to keep that as well. Regards, Joachim On 20.07.2006, at 03:28, Paul Klissner wrote: > The goals I'm most interested in at the moment are: > > 1. A pluggable platform portmapping scheme wherein each platform > can determine which ports to present to the application, and > preferably as some configurable logical name. > > For example on the Sun Ray thin client platform, if an application > aquiring a view of serial ports available on the system, it will > be informed of Sun Ray serial ports if the application is running > in a session currently directed to that particular Sun Ray unit, > even though the serial port's device node happens to be server-side > deeply nested in a leaf node. If the application is not running on > a Sun Ray the port doesn't show up. The Sun Ray plugin would make > the decision about when and which ports to present to the application. > > 2. Pluggable driver-side interface where multiple platform-specific > drivers can be utilized simultaneously to introduce more flexibility > with the back end. > >> There are a number of 3rd party implementation of Java Comm, at least >> one from IBM - part of what was J9, now Websphere, or something >> (presumbly soon to get a name that has eclipse in it sometime soon). >> Esmertec has one, and there are few others rolling around. > > I have not been advocating gutting the API, since much of it is > perfectly adequate. I'm not totally opposed to making substantial > changes or improvements depending on other people's needs. There's > no reason previous versions of javax.comm need to suddenly disappear > if products need legacy support. > > >> >> If RXTX is the only implementation of the JSR with no backward >> compatibility, we've just forked Java Serial support and we (for a >> least >> one) will be worse off. We won't be able to use the new support >> because >> of a lack of support on J2ME platforms that we have no control >> over and >> RXTX/current JavaComm will be in maintenance mode or unsupported >> on all >> other platforms. > > There can't be *that* many platforms this is ported to. And it will > be no javax.usb. Seems like most of the standard platforms will > be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, > JDBC... > >> >> So, is there any chance of building a compatibility requirement into >> this. To pick are really bad example JDBC has support for a >> DataSource >> or a Driver. Could we have an ExcellentSerialPort with a fallback >> to a >> SerialPort on a class not found exception? > > Maybe, or maybe we just let people know what we are doing and > try to figure out how to get their applications ported. Might not > be that difficult. From my standpoint anyway, earthshaking > changes aren't really necessary. Others might disagree. > > Paul > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Luis.Moreira at jet.uk Thu Jul 20 03:56:38 2006 From: Luis.Moreira at jet.uk (Luis Moreira) Date: Thu, 20 Jul 2006 10:56:38 +0100 Subject: [Rxtx] problems with setting up Rxtx Message-ID: Hi Guys, I have just joined the list and I am very new to JAVA. I am investigating serial communications and I just realised that the JAVAX.COMM package does not support windows anymore. I then looked at alternatives and the RXTX package came up. The problem I have at the moment is not using the classes but, rather how to install RXTX package so that I can use the classes, what do I need to install to support it and how if I write a program using it, do I make it portable. Best regards Luis From lyon at docjava.com Thu Jul 20 07:16:55 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 20 Jul 2006 09:16:55 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> Message-ID: Hi All, There has been some discussion about plugins for serial communications. As I see it, what Java really needs is a NativeLibraryManager. This is a rather much larger charge than "just" RXTX. The RXTX basic mode of operation is that we associate static blocks of code with a "System.load". Failure occurs when the class containing such a block of code is loaded AND the native library is not found. What are some of the options? 1. Do nothing, let the program fail with an exception. 2. try to catch an UnsatisfiedLinkError as a part of making the driver. 3. Search the java.library.path to see if the driver is present (i.e., guard the input). 4. Other?? In the case of either step 2 or 3, we need to fix the lack of a library. What are the options for fixing a library? 1. Do nothing, but give the user an interesting error with instructions on what to do. 2. Attempt to find the library on the file system (perhaps with user help). 3. Attempt to download the library and install it (perhaps with user permission). 4. Attempt to internalize the library as a UUEncoded serialized object and install it (better ask the user, again!). 5. Other?? My attempts at making RXTX more robust on install have led to mixed results. Altering the java.library.path has led to a bit of byte-code engineering (as this is loaded at JVM start time). Internalizing of libraries is attractive, until you realize how many libraries are involved. Dyanmically changing libraries during development is very attractive, for developers, who are changing libraries often. It is also very interesting for those who want to control the version of the libraries in the run-time. For example, something like the following will guard the input to the system load: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getInstance() { if (driver != null) return driver; if (!NativeLibDetect.isLibInPath("rxtxSerial")) fixDriver(); if (NativeLibDetect.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } At the other extreme, something like: try { System.load("rxtxSerial"); } catch (UnsatisfiedLinkError e) { System.out.println("could not load lib"); } Will at least attempt to handle the missing lib, in a simple way. Perhaps some error handling is better than none. To fix the driver, I can beam it down from a web page, using: private static void fixDriver() { File tmpDir = new File( SystemUtils.getTmpDir() + SystemUtils.getDirectorySeparator() + "native.jar"); try { UrlUtils.getUrl(getResourceUrl(), tmpDir); String nativeLib = getNativeLibName(); Unzipper uz = new Unzipper(tmpDir); uz.verify(); byte b[] = uz.getBlob(nativeLib); if (b == null) { System.out.println("could not get:" + nativeLib); return; } File f = getRxtxHome(); Futil.writeBytes(getRxtxLibFile(), b); SystemUtils.appendJavaLibraryPath(f); } catch (IOException e) { e.printStackTrace(); } } Where the libraries are stored in the hacky dispatch: private static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isMacOs()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); System.out.println("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } Appending to the library path is tricky, at run-time: public static void appendJavaLibraryPath(File p) { if (p.isFile()) System.out.println("warning: appendJavaLibraryPath:" + "only directories are findable:"+p); System.out.println("appending:"+p+" to java.library.path"); try { pathHack(); } catch (NoSuchFieldException e) { e.printStackTrace(); } catch (IllegalAccessException e) { e.printStackTrace(); } String javaLibraryPath = "java.library.path"; String newDirs = System.getProperty(javaLibraryPath) + File.pathSeparato rChar + p; System.setProperty(javaLibraryPath, newDirs); System.out.println("java.library.path:"+System.getProperty(javaLibraryPa th)); } The key is altering the core visibility of the sys_paths in the class loader: public static void pathHack() throws NoSuchFieldException, IllegalAccessExce ption { Class loaderClass = ClassLoader.class; Field userPaths = loaderClass.getDeclaredField("sys_paths"); userPaths.setAccessible(true); userPaths.set(null, null); userPaths.setAccessible(true); userPaths.set(null, null); } No, it isn't simple (nor even easy) but once the API is set we have a kind of NativeLibraryManager that helps us to make libraries, like RXTX more robust. As far as I know, there is nothing quite like it (unless you all know differently). Is there any interest in this? Forgive me if this is too far off the beaten path, but the inability to load a native library remains a source of fragility in the RXTX system, IMHO. Thanks for your thoughts! - Doug From jredman at ergotech.com Thu Jul 20 08:06:41 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 20 Jul 2006 08:06:41 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BF0C61.4020900@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> Message-ID: <44BF8DF1.4040101@ergotech.com> Paul, The issue with a new, incompatible implementation is, as you've identified below, is support for the old API. Open sourcing would be helpful, but then someone (us?) would have to maintain the source through changing versions of Window, and RXTX on Linux platforms. Or we'd have to have to versions of our codebase, which doesn't appeal too much. The maintenance issue is not impossible, but I think that in essence I'm agreeing with a comment you made earlier. IF a huge change is required, then lets get on with it. However, if the changes that are required are just extensions and enhancements, with some low-level re-engineering, then can we keep a compatible high-level API so that people needing the new features can use an extended API and those who need cross-platform compatibility can continue to use the existing features. Jim Paul Klissner wrote: > Jim Redman wrote: >> Paul, >> >> For the record we're STILL supporting some PersonalJava platforms. >> We're _almost_ at the point where we can assume that the platforms will >> have a Collections framework, but routinely compile with a 1.1 check so >> that we don't make that assumption unnecessarily. Of 50+ non-graphical >> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >> JavaScripting), and we have people asking for a back-port. >> >> Embedded platforms don't change in a hurry. Unlike desktop platforms, >> embedded systems are expected to last 5-10+ years. >> >> There are factory automation vendors in the pharmaceutical industry who >> are buying systems on eBay because that's the FDA validate platform. It >> must be that make/model, spec'd sometime in the mid-90's. >> >> So... If you make an incompatible change TODAY figure we can start using >> that code _at the earliest_ somewhere around 2012 or the low teens. >> >> Are we _really_ the only people on the list supporting embedded/factory >> automation platforms? >> >> Jim > > Do you provide your own implementation classes? > > Why can't you just continue to use 2.1 for the embedded platform until > 2012 if you're locked down? Are you worried bugs won't get fixed? > Sun might consider open sourcing the 2.1 Java source. I can't promise > that, but it's been discussed and hasn't met resistance, except > from me, because I wasn't super impressed with the code. I can probably > be persuaded to champion open sourcing that and going through the > process/legal machinations within Sun if it frees us to pursue > a JSR for a new generation of javax.comm where we can have a chunk of > common code in Open Source and each platform is simply responsible > for it's platform specific plugins. > > I don't have many opinions about this set in stone because there > are a lot of technical and pragmatic considerations such as yours > the community has that I am probably not aware of or sufficiently > sensitive to yet. I don't feel I really have the bird's eye view > of all of this yet. > > The other thing is, I can only offer 10% of my time right now, > according to my management, which is why I'm not pushing to > be the spec lead for the JSR, and want only to be a participant > to represent Sun's interests on the E.G. There is nothing sacred > about Sun employees in the JCP as far as a JSR initiated by another > entity is concerned. I am not the person everything needs to be > cleared through. Ideas I have will pass or fail based on their > merit and the community perception just like anyone else's. > > Paul > >> Paul Klissner wrote: >>> Jim Redman wrote: >>>> Paul Klissner wrote: >>>>> I'd just like to find another suitable name than javax.comm, unless >>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>> 'major revisions' are accounted for. javax.serialport? >>>> Which perhaps brings us back to what are we trying to fix and how badly. >>> The goals I'm most interested in at the moment are: >>> >>> 1. A pluggable platform portmapping scheme wherein each platform >>> can determine which ports to present to the application, and >>> preferably as some configurable logical name. >>> >>> For example on the Sun Ray thin client platform, if an application >>> aquiring a view of serial ports available on the system, it will >>> be informed of Sun Ray serial ports if the application is running >>> in a session currently directed to that particular Sun Ray unit, >>> even though the serial port's device node happens to be server-side >>> deeply nested in a leaf node. If the application is not running on >>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>> the decision about when and which ports to present to the application. >>> >>> 2. Pluggable driver-side interface where multiple platform-specific >>> drivers can be utilized simultaneously to introduce more flexibility >>> with the back end. >>> >>>> There are a number of 3rd party implementation of Java Comm, at least >>>> one from IBM - part of what was J9, now Websphere, or something >>>> (presumbly soon to get a name that has eclipse in it sometime soon). >>>> Esmertec has one, and there are few others rolling around. >>> I have not been advocating gutting the API, since much of it is >>> perfectly adequate. I'm not totally opposed to making substantial >>> changes or improvements depending on other people's needs. There's >>> no reason previous versions of javax.comm need to suddenly disappear >>> if products need legacy support. >>> >>> >>>> If RXTX is the only implementation of the JSR with no backward >>>> compatibility, we've just forked Java Serial support and we (for a least >>>> one) will be worse off. We won't be able to use the new support because >>>> of a lack of support on J2ME platforms that we have no control over and >>>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>>> other platforms. >>> There can't be *that* many platforms this is ported to. And it will >>> be no javax.usb. Seems like most of the standard platforms will >>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>> JDBC... >>> >>>> So, is there any chance of building a compatibility requirement into >>>> this. To pick are really bad example JDBC has support for a DataSource >>>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>>> SerialPort on a class not found exception? >>> Maybe, or maybe we just let people know what we are doing and >>> try to figure out how to get their applications ported. Might not >>> be that difficult. From my standpoint anyway, earthshaking >>> changes aren't really necessary. Others might disagree. >>> >>> Paul >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From Paul.Klissner at Sun.COM Thu Jul 20 09:31:38 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Thu, 20 Jul 2006 08:31:38 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BF8DF1.4040101@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> <44BF8DF1.4040101@ergotech.com> Message-ID: <44BFA1DA.10301@sun.com> Jim Redman wrote: > Paul, > > The issue with a new, incompatible implementation is, as you've > identified below, is support for the old API. Open sourcing would be > helpful, but then someone (us?) would have to maintain the source > through changing versions of Window, and RXTX on Linux platforms. Or > we'd have to have to versions of our codebase, which doesn't appeal too > much. > > The maintenance issue is not impossible, but I think that in essence I'm > agreeing with a comment you made earlier. > > IF a huge change is required, then lets get on with it. However, if the > changes that are required are just extensions and enhancements, with > some low-level re-engineering, then can we keep a compatible high-level > API so that people needing the new features can use an extended API and > those who need cross-platform compatibility can continue to use the > existing features. > > Jim Guillermo made a crystal clear case and I understand the problem that that will be caused by forking the API in any sense of the word. I only want to uphold Sun's interests and resolve the problems we ran into with the RXTX community when Sun added portmapping to 3.0, which was not easily undone and was implemented as kind of a hack because it wasn't directly supported by the javax.comm architection. As I mentioned previously the changes I want to make have primarily to do with adding platform-specific portmapping via plugins, and supporting multiple javax.comm backend drivers on the same host (some ports would use one driver, others ports might use another). Also I'd like to address some bugfixes that were done in Sun's version 3.0 (including better error reporting, and more robust code for locating configuration files). Besides that, I'm not aware of any deficiences, but I've glanced other e-mails where people have suggested some. It would be good to get a summary of everyone's wishes. I've stated mine. I given much thought to what it would take to properly address EIA-422, EIA-423 and EIA-485 (if any); but those would probably be extensions. Sounds like the differences might be transparent to the API. I'll look into that more. Paul > > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul, >>> >>> For the record we're STILL supporting some PersonalJava platforms. >>> We're _almost_ at the point where we can assume that the platforms will >>> have a Collections framework, but routinely compile with a 1.1 check so >>> that we don't make that assumption unnecessarily. Of 50+ non-graphical >>> Factory Automation JavaBeans we have 2 that require Java2 (Reporting and >>> JavaScripting), and we have people asking for a back-port. >>> >>> Embedded platforms don't change in a hurry. Unlike desktop platforms, >>> embedded systems are expected to last 5-10+ years. >>> >>> There are factory automation vendors in the pharmaceutical industry who >>> are buying systems on eBay because that's the FDA validate platform. It >>> must be that make/model, spec'd sometime in the mid-90's. >>> >>> So... If you make an incompatible change TODAY figure we can start using >>> that code _at the earliest_ somewhere around 2012 or the low teens. >>> >>> Are we _really_ the only people on the list supporting embedded/factory >>> automation platforms? >>> >>> Jim >> Do you provide your own implementation classes? >> >> Why can't you just continue to use 2.1 for the embedded platform until >> 2012 if you're locked down? Are you worried bugs won't get fixed? >> Sun might consider open sourcing the 2.1 Java source. I can't promise >> that, but it's been discussed and hasn't met resistance, except >> from me, because I wasn't super impressed with the code. I can probably >> be persuaded to champion open sourcing that and going through the >> process/legal machinations within Sun if it frees us to pursue >> a JSR for a new generation of javax.comm where we can have a chunk of >> common code in Open Source and each platform is simply responsible >> for it's platform specific plugins. >> >> I don't have many opinions about this set in stone because there >> are a lot of technical and pragmatic considerations such as yours >> the community has that I am probably not aware of or sufficiently >> sensitive to yet. I don't feel I really have the bird's eye view >> of all of this yet. >> >> The other thing is, I can only offer 10% of my time right now, >> according to my management, which is why I'm not pushing to >> be the spec lead for the JSR, and want only to be a participant >> to represent Sun's interests on the E.G. There is nothing sacred >> about Sun employees in the JCP as far as a JSR initiated by another >> entity is concerned. I am not the person everything needs to be >> cleared through. Ideas I have will pass or fail based on their >> merit and the community perception just like anyone else's. >> >> Paul >> >>> Paul Klissner wrote: >>>> Jim Redman wrote: >>>>> Paul Klissner wrote: >>>>>> I'd just like to find another suitable name than javax.comm, unless >>>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>>> 'major revisions' are accounted for. javax.serialport? >>>>> Which perhaps brings us back to what are we trying to fix and how badly. >>>> The goals I'm most interested in at the moment are: >>>> >>>> 1. A pluggable platform portmapping scheme wherein each platform >>>> can determine which ports to present to the application, and >>>> preferably as some configurable logical name. >>>> >>>> For example on the Sun Ray thin client platform, if an application >>>> aquiring a view of serial ports available on the system, it will >>>> be informed of Sun Ray serial ports if the application is running >>>> in a session currently directed to that particular Sun Ray unit, >>>> even though the serial port's device node happens to be server-side >>>> deeply nested in a leaf node. If the application is not running on >>>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>>> the decision about when and which ports to present to the application. >>>> >>>> 2. Pluggable driver-side interface where multiple platform-specific >>>> drivers can be utilized simultaneously to introduce more flexibility >>>> with the back end. >>>> >>>>> There are a number of 3rd party implementation of Java Comm, at least >>>>> one from IBM - part of what was J9, now Websphere, or something >>>>> (presumbly soon to get a name that has eclipse in it sometime soon). >>>>> Esmertec has one, and there are few others rolling around. >>>> I have not been advocating gutting the API, since much of it is >>>> perfectly adequate. I'm not totally opposed to making substantial >>>> changes or improvements depending on other people's needs. There's >>>> no reason previous versions of javax.comm need to suddenly disappear >>>> if products need legacy support. >>>> >>>> >>>>> If RXTX is the only implementation of the JSR with no backward >>>>> compatibility, we've just forked Java Serial support and we (for a least >>>>> one) will be worse off. We won't be able to use the new support because >>>>> of a lack of support on J2ME platforms that we have no control over and >>>>> RXTX/current JavaComm will be in maintenance mode or unsupported on all >>>>> other platforms. >>>> There can't be *that* many platforms this is ported to. And it will >>>> be no javax.usb. Seems like most of the standard platforms will >>>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>>> JDBC... >>>> >>>>> So, is there any chance of building a compatibility requirement into >>>>> this. To pick are really bad example JDBC has support for a DataSource >>>>> or a Driver. Could we have an ExcellentSerialPort with a fallback to a >>>>> SerialPort on a class not found exception? >>>> Maybe, or maybe we just let people know what we are doing and >>>> try to figure out how to get their applications ported. Might not >>>> be that difficult. From my standpoint anyway, earthshaking >>>> changes aren't really necessary. Others might disagree. >>>> >>>> Paul >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > From Paul.Klissner at Sun.COM Thu Jul 20 09:45:11 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Thu, 20 Jul 2006 08:45:11 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BFA1DA.10301@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> <44BF8DF1.4040101@ergotech.com> <44BFA1DA.10301@sun.com> Message-ID: <44BFA507.3020001@sun.com> Paul Klissner wrote: > Jim Redman wrote: >> Paul, >> >> The issue with a new, incompatible implementation is, as you've >> identified below, is support for the old API. Open sourcing would be >> helpful, but then someone (us?) would have to maintain the source >> through changing versions of Window, and RXTX on Linux platforms. Or >> we'd have to have to versions of our codebase, which doesn't appeal >> too much. >> >> The maintenance issue is not impossible, but I think that in essence >> I'm agreeing with a comment you made earlier. >> >> IF a huge change is required, then lets get on with it. However, if >> the changes that are required are just extensions and enhancements, >> with some low-level re-engineering, then can we keep a compatible >> high-level API so that people needing the new features can use an >> extended API and those who need cross-platform compatibility can >> continue to use the existing features. >> >> Jim > > Guillermo made a crystal clear case and I understand the problem > that that will be caused by forking the API in any sense of the > word. I only want to uphold Sun's interests and resolve the problems > we ran into with the RXTX community when Sun added portmapping > to 3.0, which was not easily undone and was implemented as kind > of a hack because it wasn't directly supported by the javax.comm > architection. ^^^"architecture" > > As I mentioned previously the changes I want to make have primarily > to do with adding platform-specific portmapping via plugins, > and supporting multiple javax.comm backend drivers on the same > host (some ports would use one driver, others ports might use another). > > Also I'd like to address some bugfixes that were done in Sun's > version 3.0 (including better error reporting, and more robust > code for locating configuration files). Besides that, I'm not > aware of any deficiences, but I've glanced other e-mails where > people have suggested some. It would be good to get a summary > of everyone's wishes. I've stated mine. > > I given much thought to what it would take to properly address ^^^haven't > EIA-422, EIA-423 and EIA-485 (if any); but those would > probably be extensions. Sounds like the differences might > be transparent to the API. I'll look into that more. > > Paul > > >> >> Paul Klissner wrote: >>> Jim Redman wrote: >>>> Paul, >>>> >>>> For the record we're STILL supporting some PersonalJava platforms. >>>> We're _almost_ at the point where we can assume that the platforms >>>> will have a Collections framework, but routinely compile with a 1.1 >>>> check so that we don't make that assumption unnecessarily. Of 50+ >>>> non-graphical Factory Automation JavaBeans we have 2 that require >>>> Java2 (Reporting and JavaScripting), and we have people asking for a >>>> back-port. >>>> >>>> Embedded platforms don't change in a hurry. Unlike desktop >>>> platforms, embedded systems are expected to last 5-10+ years. >>>> >>>> There are factory automation vendors in the pharmaceutical industry >>>> who are buying systems on eBay because that's the FDA validate >>>> platform. It must be that make/model, spec'd sometime in the mid-90's. >>>> >>>> So... If you make an incompatible change TODAY figure we can start >>>> using that code _at the earliest_ somewhere around 2012 or the low >>>> teens. >>>> >>>> Are we _really_ the only people on the list supporting >>>> embedded/factory automation platforms? >>>> >>>> Jim >>> Do you provide your own implementation classes? >>> >>> Why can't you just continue to use 2.1 for the embedded platform until >>> 2012 if you're locked down? Are you worried bugs won't get fixed? >>> Sun might consider open sourcing the 2.1 Java source. I can't promise >>> that, but it's been discussed and hasn't met resistance, except >>> from me, because I wasn't super impressed with the code. I can probably >>> be persuaded to champion open sourcing that and going through the >>> process/legal machinations within Sun if it frees us to pursue >>> a JSR for a new generation of javax.comm where we can have a chunk of >>> common code in Open Source and each platform is simply responsible >>> for it's platform specific plugins. >>> >>> I don't have many opinions about this set in stone because there >>> are a lot of technical and pragmatic considerations such as yours >>> the community has that I am probably not aware of or sufficiently >>> sensitive to yet. I don't feel I really have the bird's eye view >>> of all of this yet. >>> >>> The other thing is, I can only offer 10% of my time right now, >>> according to my management, which is why I'm not pushing to >>> be the spec lead for the JSR, and want only to be a participant >>> to represent Sun's interests on the E.G. There is nothing sacred >>> about Sun employees in the JCP as far as a JSR initiated by another >>> entity is concerned. I am not the person everything needs to be >>> cleared through. Ideas I have will pass or fail based on their >>> merit and the community perception just like anyone else's. >>> >>> Paul >>> >>>> Paul Klissner wrote: >>>>> Jim Redman wrote: >>>>>> Paul Klissner wrote: >>>>>>> I'd just like to find another suitable name than javax.comm, unless >>>>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>>>> 'major revisions' are accounted for. javax.serialport? >>>>>> Which perhaps brings us back to what are we trying to fix and how >>>>>> badly. >>>>> The goals I'm most interested in at the moment are: >>>>> >>>>> 1. A pluggable platform portmapping scheme wherein each platform >>>>> can determine which ports to present to the application, and >>>>> preferably as some configurable logical name. >>>>> >>>>> For example on the Sun Ray thin client platform, if an application >>>>> aquiring a view of serial ports available on the system, it will >>>>> be informed of Sun Ray serial ports if the application is running >>>>> in a session currently directed to that particular Sun Ray unit, >>>>> even though the serial port's device node happens to be server-side >>>>> deeply nested in a leaf node. If the application is not running on >>>>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>>>> the decision about when and which ports to present to the application. >>>>> >>>>> 2. Pluggable driver-side interface where multiple platform-specific >>>>> drivers can be utilized simultaneously to introduce more flexibility >>>>> with the back end. >>>>> >>>>>> There are a number of 3rd party implementation of Java Comm, at >>>>>> least one from IBM - part of what was J9, now Websphere, or >>>>>> something (presumbly soon to get a name that has eclipse in it >>>>>> sometime soon). Esmertec has one, and there are few others rolling >>>>>> around. >>>>> I have not been advocating gutting the API, since much of it is >>>>> perfectly adequate. I'm not totally opposed to making substantial >>>>> changes or improvements depending on other people's needs. There's >>>>> no reason previous versions of javax.comm need to suddenly disappear >>>>> if products need legacy support. >>>>> >>>>> >>>>>> If RXTX is the only implementation of the JSR with no backward >>>>>> compatibility, we've just forked Java Serial support and we (for a >>>>>> least one) will be worse off. We won't be able to use the new >>>>>> support because of a lack of support on J2ME platforms that we >>>>>> have no control over and RXTX/current JavaComm will be in >>>>>> maintenance mode or unsupported on all other platforms. >>>>> There can't be *that* many platforms this is ported to. And it will >>>>> be no javax.usb. Seems like most of the standard platforms will >>>>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>>>> JDBC... >>>>> >>>>>> So, is there any chance of building a compatibility requirement >>>>>> into this. To pick are really bad example JDBC has support for a >>>>>> DataSource or a Driver. Could we have an ExcellentSerialPort with >>>>>> a fallback to a SerialPort on a class not found exception? >>>>> Maybe, or maybe we just let people know what we are doing and >>>>> try to figure out how to get their applications ported. Might not >>>>> be that difficult. From my standpoint anyway, earthshaking >>>>> changes aren't really necessary. Others might disagree. >>>>> >>>>> Paul >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> > From jredman at ergotech.com Thu Jul 20 10:30:01 2006 From: jredman at ergotech.com (Jim Redman) Date: Thu, 20 Jul 2006 10:30:01 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44BFA507.3020001@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <44BEB305.3030208@ergotech.com> <44BEC0D8.4050806@sun.com> <44BEC85C.2030809@ergotech.com> <44BEDC4F.9030403@sun.com> <44BEE23B.30908@ergotech.com> <44BF0C61.4020900@sun.com> <44BF8DF1.4040101@ergotech.com> <44BFA1DA.10301@sun.com> <44BFA507.3020001@sun.com> Message-ID: <44BFAF89.5010003@ergotech.com> Thast what hapens if you post late at nihgt nad erly in the moning as wel. :) Paul Klissner wrote: > Paul Klissner wrote: >> Jim Redman wrote: >>> Paul, >>> >>> The issue with a new, incompatible implementation is, as you've >>> identified below, is support for the old API. Open sourcing would be >>> helpful, but then someone (us?) would have to maintain the source >>> through changing versions of Window, and RXTX on Linux platforms. Or >>> we'd have to have to versions of our codebase, which doesn't appeal >>> too much. >>> >>> The maintenance issue is not impossible, but I think that in essence >>> I'm agreeing with a comment you made earlier. >>> >>> IF a huge change is required, then lets get on with it. However, if >>> the changes that are required are just extensions and enhancements, >>> with some low-level re-engineering, then can we keep a compatible >>> high-level API so that people needing the new features can use an >>> extended API and those who need cross-platform compatibility can >>> continue to use the existing features. >>> >>> Jim >> Guillermo made a crystal clear case and I understand the problem >> that that will be caused by forking the API in any sense of the >> word. I only want to uphold Sun's interests and resolve the problems >> we ran into with the RXTX community when Sun added portmapping >> to 3.0, which was not easily undone and was implemented as kind >> of a hack because it wasn't directly supported by the javax.comm >> architection. > ^^^"architecture" >> As I mentioned previously the changes I want to make have primarily >> to do with adding platform-specific portmapping via plugins, >> and supporting multiple javax.comm backend drivers on the same >> host (some ports would use one driver, others ports might use another). >> >> Also I'd like to address some bugfixes that were done in Sun's >> version 3.0 (including better error reporting, and more robust >> code for locating configuration files). Besides that, I'm not >> aware of any deficiences, but I've glanced other e-mails where >> people have suggested some. It would be good to get a summary >> of everyone's wishes. I've stated mine. >> >> I given much thought to what it would take to properly address > ^^^haven't >> EIA-422, EIA-423 and EIA-485 (if any); but those would >> probably be extensions. Sounds like the differences might >> be transparent to the API. I'll look into that more. >> >> Paul >> >> >>> Paul Klissner wrote: >>>> Jim Redman wrote: >>>>> Paul, >>>>> >>>>> For the record we're STILL supporting some PersonalJava platforms. >>>>> We're _almost_ at the point where we can assume that the platforms >>>>> will have a Collections framework, but routinely compile with a 1.1 >>>>> check so that we don't make that assumption unnecessarily. Of 50+ >>>>> non-graphical Factory Automation JavaBeans we have 2 that require >>>>> Java2 (Reporting and JavaScripting), and we have people asking for a >>>>> back-port. >>>>> >>>>> Embedded platforms don't change in a hurry. Unlike desktop >>>>> platforms, embedded systems are expected to last 5-10+ years. >>>>> >>>>> There are factory automation vendors in the pharmaceutical industry >>>>> who are buying systems on eBay because that's the FDA validate >>>>> platform. It must be that make/model, spec'd sometime in the mid-90's. >>>>> >>>>> So... If you make an incompatible change TODAY figure we can start >>>>> using that code _at the earliest_ somewhere around 2012 or the low >>>>> teens. >>>>> >>>>> Are we _really_ the only people on the list supporting >>>>> embedded/factory automation platforms? >>>>> >>>>> Jim >>>> Do you provide your own implementation classes? >>>> >>>> Why can't you just continue to use 2.1 for the embedded platform until >>>> 2012 if you're locked down? Are you worried bugs won't get fixed? >>>> Sun might consider open sourcing the 2.1 Java source. I can't promise >>>> that, but it's been discussed and hasn't met resistance, except >>>> from me, because I wasn't super impressed with the code. I can probably >>>> be persuaded to champion open sourcing that and going through the >>>> process/legal machinations within Sun if it frees us to pursue >>>> a JSR for a new generation of javax.comm where we can have a chunk of >>>> common code in Open Source and each platform is simply responsible >>>> for it's platform specific plugins. >>>> >>>> I don't have many opinions about this set in stone because there >>>> are a lot of technical and pragmatic considerations such as yours >>>> the community has that I am probably not aware of or sufficiently >>>> sensitive to yet. I don't feel I really have the bird's eye view >>>> of all of this yet. >>>> >>>> The other thing is, I can only offer 10% of my time right now, >>>> according to my management, which is why I'm not pushing to >>>> be the spec lead for the JSR, and want only to be a participant >>>> to represent Sun's interests on the E.G. There is nothing sacred >>>> about Sun employees in the JCP as far as a JSR initiated by another >>>> entity is concerned. I am not the person everything needs to be >>>> cleared through. Ideas I have will pass or fail based on their >>>> merit and the community perception just like anyone else's. >>>> >>>> Paul >>>> >>>>> Paul Klissner wrote: >>>>>> Jim Redman wrote: >>>>>>> Paul Klissner wrote: >>>>>>>> I'd just like to find another suitable name than javax.comm, unless >>>>>>>> the JSR wants to start with javax.comm 4.0, since all the previous >>>>>>>> 'major revisions' are accounted for. javax.serialport? >>>>>>> Which perhaps brings us back to what are we trying to fix and how >>>>>>> badly. >>>>>> The goals I'm most interested in at the moment are: >>>>>> >>>>>> 1. A pluggable platform portmapping scheme wherein each platform >>>>>> can determine which ports to present to the application, and >>>>>> preferably as some configurable logical name. >>>>>> >>>>>> For example on the Sun Ray thin client platform, if an application >>>>>> aquiring a view of serial ports available on the system, it will >>>>>> be informed of Sun Ray serial ports if the application is running >>>>>> in a session currently directed to that particular Sun Ray unit, >>>>>> even though the serial port's device node happens to be server-side >>>>>> deeply nested in a leaf node. If the application is not running on >>>>>> a Sun Ray the port doesn't show up. The Sun Ray plugin would make >>>>>> the decision about when and which ports to present to the application. >>>>>> >>>>>> 2. Pluggable driver-side interface where multiple platform-specific >>>>>> drivers can be utilized simultaneously to introduce more flexibility >>>>>> with the back end. >>>>>> >>>>>>> There are a number of 3rd party implementation of Java Comm, at >>>>>>> least one from IBM - part of what was J9, now Websphere, or >>>>>>> something (presumbly soon to get a name that has eclipse in it >>>>>>> sometime soon). Esmertec has one, and there are few others rolling >>>>>>> around. >>>>>> I have not been advocating gutting the API, since much of it is >>>>>> perfectly adequate. I'm not totally opposed to making substantial >>>>>> changes or improvements depending on other people's needs. There's >>>>>> no reason previous versions of javax.comm need to suddenly disappear >>>>>> if products need legacy support. >>>>>> >>>>>> >>>>>>> If RXTX is the only implementation of the JSR with no backward >>>>>>> compatibility, we've just forked Java Serial support and we (for a >>>>>>> least one) will be worse off. We won't be able to use the new >>>>>>> support because of a lack of support on J2ME platforms that we >>>>>>> have no control over and RXTX/current JavaComm will be in >>>>>>> maintenance mode or unsupported on all other platforms. >>>>>> There can't be *that* many platforms this is ported to. And it will >>>>>> be no javax.usb. Seems like most of the standard platforms will >>>>>> be ported pretty quickly... Linux, Solaris, Windows... why not J2ME, >>>>>> JDBC... >>>>>> >>>>>>> So, is there any chance of building a compatibility requirement >>>>>>> into this. To pick are really bad example JDBC has support for a >>>>>>> DataSource or a Driver. Could we have an ExcellentSerialPort with >>>>>>> a fallback to a SerialPort on a class not found exception? >>>>>> Maybe, or maybe we just let people know what we are doing and >>>>>> try to figure out how to get their applications ported. Might not >>>>>> be that difficult. From my standpoint anyway, earthshaking >>>>>> changes aren't really necessary. Others might disagree. >>>>>> >>>>>> Paul >>>>>> _______________________________________________ >>>>>> Rxtx mailing list >>>>>> Rxtx at qbang.org >>>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From tjarvi at qbang.org Thu Jul 20 10:31:57 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 20 Jul 2006 10:31:57 -0600 (MDT) Subject: [Rxtx] jcp and jsr In-Reply-To: <44BEA802.7060508@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: > PROJECT SCOPE: > ------------- > > Also, we should think carefully about what the scope of > this project would be. Should it be javax."comm" which > handles both serial and parallel (is parallel going by the > wayside). Should it be split into two project: > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > > Should we differentiate between single-ended serial > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > quasi-multidrop and full multidrop busses such as > EIA422, EIA432 and EIA485? If we really were to > add I2C support to the API, we'd have to delve into > the semantics more, because there could be some > implicit decoding of the bus the API users would > want to see. > Hi Paul The way RXTX works, which is a fair representation of the people using the API, is complete support for RIA232, minimal support for IEEE1284. From what I understand, Sun was going along the same lines. If we combined both projects, we would have half a parallel port implementation. I see maybe 4 requests for features not in the parallel support a year. The other protocols should not be limited by a JSR which is going to be focused upon serial port interests. The IEA485 hacks in RXTX along with I2C and Raw should _not_ be considered a strong basis for extending the API to cover these protocols. If people want to do real implementations, they should not face a 'standard' which wasnt really focused upon their interests. I think we understand the parallel port issues fairly well but have not implemented many features and I don't know if we would. So a versatile API is favorable but I do not think we have the proper community to represent much more than Serial. We could provide a framework or maybe just a model for further work with other standards. -- Trent Jarvi tjarvi at qbang.org From naranjo.manuel at gmail.com Thu Jul 20 10:49:33 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Thu, 20 Jul 2006 13:49:33 -0300 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <44BFB41D.4010604@gmail.com> Trent Jarvi wrote: >> PROJECT SCOPE: >> ------------- >> >> Also, we should think carefully about what the scope of >> this project would be. Should it be javax."comm" which >> handles both serial and parallel (is parallel going by the >> wayside). Should it be split into two project: >> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >> >> Should we differentiate between single-ended serial >> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >> quasi-multidrop and full multidrop busses such as >> EIA422, EIA432 and EIA485? If we really were to >> add I2C support to the API, we'd have to delve into >> the semantics more, because there could be some >> implicit decoding of the bus the API users would >> want to see. >> > > Hi Paul > > The way RXTX works, which is a fair representation of the people using the > API, is complete support for RIA232, minimal support for IEEE1284. From > what I understand, Sun was going along the same lines. If we combined > both projects, we would have half a parallel port implementation. I see > maybe 4 requests for features not in the parallel support a year. > > The other protocols should not be limited by a JSR which is going to be > focused upon serial port interests. The IEA485 hacks in RXTX along with > I2C and Raw should _not_ be considered a strong basis for extending the > API to cover these protocols. If people want to do real implementations, > they should not face a 'standard' which wasnt really focused upon their > interests. I think we understand the parallel port issues fairly well but > have not implemented many features and I don't know if we would. > > So a versatile API is favorable but I do not think we have the proper > community to represent much more than Serial. We could provide a > framework or maybe just a model for further work with other standards. > > -- > Trent Jarvi > tjarvi at qbang.org > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > Hi, I agree with Trent, as far as I have seen most projects that were using RXTX and Java Comm where designed to work only with Serial Ports. What is fact is that a Parallel port can not be modeled at all like a Serial Port, except that they both expose and Input Stream and an Output Stream. As I have read there is a huge market of embedded applications using port accessing. We could take two different aproaches with the JSR, one could be define a way to access every kind of port independent of the implementation of the port himself. We could access Serial, Parallel, I2C, USB, etc. But we will have huge problems with it, because we will have to face a lot of low level programming which of course will be platform dependent, and that is were the write one use everywhere of Java could dye. The other approach is to define an Api that only supports Serial Ports, compatible with the one that is defined in javax.comm 2.0, and make some classes that extend that packages, maybe even in another package, like AWT and JSWING do. We then could eventually extend to other kinds of ports but that will require a lot of work more. I'm not a person specialized on Informatical Engineering, so I do not think I can give a hand on Low Level programming, I do can help with the Java part, debugging and testing. Regards, Manuel From brian at mbari.org Thu Jul 20 11:19:33 2006 From: brian at mbari.org (Brian Schlining) Date: Thu, 20 Jul 2006 10:19:33 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <8BFCAB48-6302-44CD-ABF0-560BC04AD26E@mbari.org> > The way RXTX works, which is a fair representation of the people > using the > API, is complete support for RIA232, minimal support for IEEE1284. > From > what I understand, Sun was going along the same lines. If we combined > both projects, we would have half a parallel port implementation. > I see > maybe 4 requests for features not in the parallel support a year. > > The other protocols should not be limited by a JSR which is going > to be > focused upon serial port interests. The IEA485 hacks in RXTX along > with > I2C and Raw should _not_ be considered a strong basis for extending > the > API to cover these protocols. If people want to do real > implementations, > they should not face a 'standard' which wasnt really focused upon > their > interests. I think we understand the parallel port issues fairly > well but > have not implemented many features and I don't know if we would. > > So a versatile API is favorable but I do not think we have the proper > community to represent much more than Serial. We could provide a > framework or maybe just a model for further work with other standards. I agree completely. Folks use RXTX for serial ports. In my field (Oceanography), we uses RS232 to talk to nearly all our instruments. So we really need a great implementation of serial port communications in Java that runs on a variety of architectures. I'd prefer if the JSR focused on that. >> I given much thought to what it would take to properly address >> > ^^^haven't > >> EIA-422, EIA-423 and EIA-485 (if any); but those would >> probably be extensions. Sounds like the differences might >> be transparent to the API. I'll look into that more. I've had good luck using the current implementation of RXTX with RS422, although you'll need to use a pin converter. my 2 cents. Brian Schlining Software Engineer http://www.mbari.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060720/fb956c68/attachment-0346.html From pascal at quies.net Fri Jul 21 15:43:40 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Fri, 21 Jul 2006 23:43:40 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: Message-ID: <200607212343.40882.pascal@quies.net> Op donderdag 20 juli 2006 15:16, schreef Dr. Douglas Lyon: > Hi All, > There has been some discussion about plugins for serial communications. > > As I see it, what Java really needs is a NativeLibraryManager. This is > a rather much larger charge than "just" RXTX. > > The RXTX basic mode of operation is that we associate static > blocks of code with a "System.load". > > Failure occurs when the class containing such a block of code is > loaded AND the native library is not found. > > What are some of the options? > > 1. Do nothing, let the program fail with an exception. > 2. try to catch an UnsatisfiedLinkError as a part of making > the driver. > 3. Search the java.library.path to see if the driver is present > (i.e., guard the input). > 4. Other?? > > In the case of either step 2 or 3, we need to fix the lack of a library. > > What are the options for fixing a library? > 1. Do nothing, but give the user an interesting error with instructions on > what to do. > 2. Attempt to find the library on the file system (perhaps with user help). > 3. Attempt to download the library and install it (perhaps with user > permission). > 4. Attempt to internalize the library as a UUEncoded serialized object and > install it (better ask the user, again!). > 5. Other?? 5. Put the binaries together with the attached classes in a jar. Joachim told me that and it works! I forgot to publish the results. :$ ---- begin example import org.rxtx.CommunicationAPI; ... CommunicationAPI commExtension = new CommunicationAPI(); try { commExtenios.loadNativeLibraries(); } catch (Exception e) { // We *need* javax.comm } // Now we have the extension available. ... ---- end example Do you like it? Commens anyone? The path to the libraries is in the form of /native/rxtx/-/{libserial,libparallel} so /native/rxtx/windows-i386/libserial would do. I asked for binaries but only Joachim offered me help with OS X on the next release. Does anyone have javax.comm warper classes? -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 6781 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060721/b39a5592/CommunicationAPI-0345.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: PlatformNotSupportedException.java Type: text/x-java Size: 1621 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060721/b39a5592/PlatformNotSupportedException-0345.bin From pascal at quies.net Fri Jul 21 15:45:30 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Fri, 21 Jul 2006 23:45:30 +0200 Subject: [Rxtx] quo vadis API/namespace (Re: jcp and jsr) In-Reply-To: References: <44BEDC4F.9030403@sun.com> Message-ID: <200607212345.30495.pascal@quies.net> Op donderdag 20 juli 2006 10:46, schreef Joachim Buechse: > So in short: Unless we find a strong argument why javax.comm can't be > used I prefer that we keep it. Unless we find a strong feature / use- > case that can not be handled with (an extension of) the current > CommPort/CommPortIndentifier I'd prefer to keep that as well. I seem to be the only one who sees failures in the API so lets keep it that way. Now how do we get a JSR/lisence if we don't want any changes? :P From lyon at docjava.com Sat Jul 22 06:07:03 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 22 Jul 2006 08:07:03 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607212343.40882.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> Message-ID: Hi All, I like the idea of the native lib in a jar with other classes. An alternative I did not know would work. Now, if you place the rxtx classes and native library in the same jar, do they both have to be in any specific place in order to be found? In my approach, you can locate the native library at run-time, and you need not alter any environmental variables nor mangle the JDK home. Thus, each user can have a different native library, one for development and one for release, for example. Regards, - Doug >Op donderdag 20 juli 2006 15:16, schreef Dr. Douglas Lyon: >> Hi All, >> There has been some discussion about plugins for serial communications. >> >> As I see it, what Java really needs is a NativeLibraryManager. This is >> a rather much larger charge than "just" RXTX. >> >> The RXTX basic mode of operation is that we associate static >> blocks of code with a "System.load". >> >> Failure occurs when the class containing such a block of code is >> loaded AND the native library is not found. >> >> What are some of the options? >> >> 1. Do nothing, let the program fail with an exception. >> 2. try to catch an UnsatisfiedLinkError as a part of making >> the driver. >> 3. Search the java.library.path to see if the driver is present >> (i.e., guard the input). >> 4. Other?? >> >> In the case of either step 2 or 3, we need to fix the lack of a library. >> >> What are the options for fixing a library? >> 1. Do nothing, but give the user an interesting error with instructions on >> what to do. >> 2. Attempt to find the library on the file system (perhaps with user help). >> 3. Attempt to download the library and install it (perhaps with user >> permission). >> 4. Attempt to internalize the library as a UUEncoded serialized object and >> install it (better ask the user, again!). >> 5. Other?? > >5. Put the binaries together with the attached classes in a jar. > >Joachim told me that and it works! I forgot to publish the results. :$ > > >---- begin example >import org.rxtx.CommunicationAPI; > >... >CommunicationAPI commExtension = new CommunicationAPI(); >try { > commExtenios.loadNativeLibraries(); >} catch (Exception e) { > // We *need* javax.comm >} > >// Now we have the extension available. >... >---- end example > > >Do you like it? Commens anyone? > > >The path to the libraries is in the form >of /native/rxtx/-/{libserial,libparallel} >so /native/rxtx/windows-i386/libserial would do. > >I asked for binaries but only Joachim offered me help with OS X on the next >release. > >Does anyone have javax.comm warper classes? > >Attachment converted: PowerBookHd:CommunicationAPI.java (TEXT/ttxt) (001C1686) >Attachment converted: PowerBookHd:PlatformNotSupporte#1C1687.java >(TEXT/ttxt) (001C1687) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 22 07:06:06 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 15:06:06 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607212343.40882.pascal@quies.net> Message-ID: <200607221506.07140.pascal@quies.net> > Now, if you place the rxtx classes and native library in the same > jar, do they both have to be in any specific place in order to be found? Answer: > >The path to the libraries is in the form > >of /native/rxtx/-/{libserial,libparallel} > >so /native/rxtx/windows-i386/libserial would do. I'me looking for the various os.name and os.arch values right now. From lyon at docjava.com Sat Jul 22 08:06:26 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sat, 22 Jul 2006 10:06:26 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607221506.07140.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> <200607221506.07140.pascal@quies.net> Message-ID: Hi All, Here is how I have arranged my signed versions of the native binaries: http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/windows/native.jar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/native.jar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/linux/native.jar Then I do: public static URL getResourceUrl() throws MalformedURLException { String rxtxUrl = "http://show.docjava.com:8086/" + "book/cgij/code/jnlp/libs/rxtx/"; if (OsUtils.isLinux()) return new URL(rxtxUrl + "linux/native.jar"); if (OsUtils.isMacOs()) return new URL(rxtxUrl + "mac/native.jar"); if (OsUtils.isWindows()) return new URL(rxtxUrl + "windows/native.jar"); System.out.println("no automatic install supported for this platform. " + "Please e-mail lyon at docjava.com with a bug report"); return null; } My new-age NativeLibraryManger concept-thang allows you to write stuff like: /** * This method fixes the driver by beaming over * to the tmp directory a native.jar file. * The native.jar file is signed and its * native libs are beamed over to the user home directory * ~/.rxtx/
* Finally, the java.library.path is altered to include
* ~/.rxtx/ */ private static void fixDriver() { try { NativeLibraryManager.fixDriver(getResourceUrl(), NativeLibraryManager.mapLibraryName("rxtxSerial")); } catch (IOException e) { e.printStackTrace(); } } I do a lazy singleton design pattern: public final class SafeCommDriver { private static RXTXCommDriver driver = null; private SafeCommDriver() { } public synchronized static RXTXCommDriver getInstance() { if (driver != null) return driver; if (!NativeLibraryManager.isLibInPath("rxtxSerial")) fixDriver(); if (NativeLibraryManager.isLibInPath("rxtxSerial")) { driver = new RXTXCommDriver(); driver.initialize(); } return driver; } I am at a cross-roads here, since a file-based distro might be preferable to a URL based distro. To make this really general, and to "remember" where the last version of a native library came from, I serialize a bean into user preferences The user can then store native libraries anywhere, remembering the location in the preferences. What is the general feeling about this? Thanks! - Doug > > Now, if you place the rxtx classes and native library in the same >> jar, do they both have to be in any specific place in order to be found? > >Answer: > >> >The path to the libraries is in the form >> >of /native/rxtx/-/{libserial,libparallel} >> >so /native/rxtx/windows-i386/libserial would do. > >I'me looking for the various os.name and os.arch values right now. >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Sat Jul 22 10:30:55 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 22 Jul 2006 11:30:55 -0500 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607212343.40882.pascal@quies.net> Message-ID: <44C252BF.6040404@cox.net> Dr. Douglas Lyon wrote: > Hi All, > I like the idea of the native lib in a jar with other classes. > An alternative I did not know would work. I have several applications that run with a security policy. In these applications, native library loading will require an appropriate FilePermission that should be known about ahead of time. The current native library implementation will require the native library to be extracted from the jar and written to disk, requiring a FilePermission("...","write") for that file, and then will also require read access to load the library. I personally don't want to give write access to a JVM for a shared library which can provide a point of abuse by errant code. Gregg Wonderly From gergg at cox.net Sat Jul 22 10:33:52 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sat, 22 Jul 2006 11:33:52 -0500 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607212343.40882.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> Message-ID: <44C25370.9070506@cox.net> >Pascal S. de Kloe wrote: >>> I am also not sure if >>> the api should unify corresponding cu. and tty. ports into one single >>> port. >> >> I think the API should hide low-level details like devicefiles. > >Not all ports have device files. It's long been my goal to add support >for virtual serial ports, that is, serial ports on Ethernet terminal >servers, for example integrating RFC2217. This means that the port name >is some combination of an IP address and TCP port number. Nothing in /dev. What I think would make the most sense is a simple "device" enumeration Server Provider Interface that would bring port objects into the JVM based on the platform JVM providers knowledge of how to enumerate those ports. Application writers would provide a plugin using the SPI that would codify those devices into named entities that they are interested in. public interface HardwarePort { public String getName(); public String getHardwareID(); public String getManufacturer(); public List getCapabilities(); public Object getImplementation(); } public interface PortCapability { public String getDescription(); public CapabilityId getIdentifier(); } public enum CapabilityId { INPUT, // Can receive input OUTPUT, // Can send output ASYNCHRONOUS, // Can send and receive at the same time SYNCHRONOUS, // No synchronous I/O ADDRESSABLE // Port has an address associated } Then, you might imagine that the enumerated capabilities had a standardized/specified interface that you'd find implemented on ports that had such capabilities. The getImplementation() method would return the implementation class provided by the JVM provider that had all of the interfaces tied to it. These are just some quick thoughts, pick away at them. I am very interested in getting a new comm api in place which can provide the ability for all USB connected devices to have drivers provided as 100% java for all non-timing critical types of device interfaces. The JVM provider should have an SPI to write to which will enable them to abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into something that we can talk 100% java to. That's my big desire. Starting with something simple which gives a good start in that direction would be great! Gregg Wonderly From pascal at quies.net Sat Jul 22 10:43:27 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 18:43:27 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <44C252BF.6040404@cox.net> References: <44C252BF.6040404@cox.net> Message-ID: <200607221843.27765.pascal@quies.net> Op zaterdag 22 juli 2006 18:30, schreef Gregg Wonderly: > Dr. Douglas Lyon wrote: > > Hi All, > > I like the idea of the native lib in a jar with other classes. > > An alternative I did not know would work. > > I have several applications that run with a security policy. In these > applications, native library loading will require an appropriate > FilePermission that should be known about ahead of time. The current > native library implementation will require the native library to be > extracted from the jar and written to disk, requiring a > FilePermission("...","write") for that file, and then will also require > read access to load the library. I personally don't want to give write > access to a JVM for a shared library which can provide a point of abuse by > errant code. > > Gregg Wonderly That's indeed a pitty limitation. It creates a lot of possible exceptions too. On the other hand, any native lib passes the securiy model. Applications who can access hardware ports can be expected to create files, right? From pascal at quies.net Sat Jul 22 10:54:13 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 18:54:13 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607221506.07140.pascal@quies.net> Message-ID: <200607221854.13467.pascal@quies.net> Hi Dr., We're both trying to do the same thing. The CommunicationAPI does not only look at the OS but it also indexes the available hardware architectures and does not need OsUtils. Any Java 2 runtime will do. The plan was to make a single JAR with the binaries for all supported platforms, the RXTX gnu.io package and the javax.comm wrapers. A signed version would be nice. A few questions remain tough. Does anybody know how Sun uses the SunOS and Solaris identifiers for the Java property os.name? Op zaterdag 22 juli 2006 16:06, schreef Dr. Douglas Lyon: > Hi All, > Here is how I have arranged my signed versions of the native > binaries: > http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/windows/native.j >ar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/native.jar > http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/linux/native.jar > > Then I do: > public static URL getResourceUrl() throws MalformedURLException { > String rxtxUrl = "http://show.docjava.com:8086/" + > "book/cgij/code/jnlp/libs/rxtx/"; > if (OsUtils.isLinux()) > return new URL(rxtxUrl + "linux/native.jar"); > if (OsUtils.isMacOs()) > return new URL(rxtxUrl + "mac/native.jar"); > if (OsUtils.isWindows()) > return new URL(rxtxUrl + "windows/native.jar"); > System.out.println("no automatic install supported for this > platform. " + > "Please e-mail lyon at docjava.com with a bug report"); > return null; > } > > My new-age NativeLibraryManger concept-thang allows you to > write stuff like: > > /** > * This method fixes the driver by beaming over > * to the tmp directory a native.jar file. > * The native.jar file is signed and its > * native libs are beamed over to the user home directory > * ~/.rxtx/
> * Finally, the java.library.path is altered to include
> * ~/.rxtx/ > */ > private static void fixDriver() { > > try { > NativeLibraryManager.fixDriver(getResourceUrl(), > NativeLibraryManager.mapLibraryName("rxtxSerial")); > } catch (IOException e) { > e.printStackTrace(); > } > } > > I do a lazy singleton design pattern: > > public final class SafeCommDriver { > private static RXTXCommDriver driver = null; > > private SafeCommDriver() { > } > > public synchronized static RXTXCommDriver getInstance() { > if (driver != null) return driver; > if (!NativeLibraryManager.isLibInPath("rxtxSerial")) > fixDriver(); > if (NativeLibraryManager.isLibInPath("rxtxSerial")) { > driver = new RXTXCommDriver(); > driver.initialize(); > } > return driver; > } > > I am at a cross-roads here, since a file-based distro might be preferable > to a URL based distro. To make this really general, and to "remember" where > the last version of a native library came from, I serialize a bean into > user preferences > The user can then store native libraries anywhere, remembering the location > in the preferences. > > What is the general feeling about this? > > Thanks! > - Doug > > > > Now, if you place the rxtx classes and native library in the same > >> > >> jar, do they both have to be in any specific place in order to be > >> found? > > > >Answer: > >> >The path to the libraries is in the form > >> >of /native/rxtx/-/{libserial,libparallel} > >> >so /native/rxtx/windows-i386/libserial would do. > > > >I'me looking for the various os.name and os.arch values right now. > >_______________________________________________ > >Rxtx mailing list > >Rxtx at qbang.org > >http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Sat Jul 22 11:17:51 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 22 Jul 2006 19:17:51 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <44C252BF.6040404@cox.net> References: <200607212343.40882.pascal@quies.net> <44C252BF.6040404@cox.net> Message-ID: <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> We could easily have a stub method / flag that allows you to explicitly load the native library (via System.loadLibrary ie from the java.library.path). In this case the "auto-extraction" would not take place. On 22.07.2006, at 18:30, Gregg Wonderly wrote: > Dr. Douglas Lyon wrote: >> Hi All, >> I like the idea of the native lib in a jar with other classes. >> An alternative I did not know would work. > > I have several applications that run with a security policy. In these > applications, native library loading will require an appropriate > FilePermission > that should be known about ahead of time. The current native library > implementation will require the native library to be extracted from > the jar and > written to disk, requiring a FilePermission("...","write") for that > file, and > then will also require read access to load the library. I > personally don't want > to give write access to a JVM for a shared library which can > provide a point of > abuse by errant code. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 22 11:20:19 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 19:20:19 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607221506.07140.pascal@quies.net> Message-ID: <200607221920.20096.pascal@quies.net> The attachment setup.zip contains a very small update of CommunicationAPI and a good start with the various platforms. All we need to do is fill those directories with binaries. Various binaries are missing the pararlel library. Why is that? -------------- next part -------------- A non-text attachment was scrubbed... Name: setup.zip Type: application/x-zip Size: 8459 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060722/12770623/setup-0344.bin From gregg at cytetech.com Thu Jul 20 21:32:55 2006 From: gregg at cytetech.com (Gregg Wonderly) Date: Thu, 20 Jul 2006 22:32:55 -0500 Subject: [Rxtx] jcp and jsr Message-ID: <44C04AE7.9050800@cytetech.com> >Pascal S. de Kloe wrote: >>> I am also not sure if >>> the api should unify corresponding cu. and tty. ports into one single >>> port. >> >> I think the API should hide low-level details like devicefiles. > >Not all ports have device files. It's long been my goal to add support >for virtual serial ports, that is, serial ports on Ethernet terminal >servers, for example integrating RFC2217. This means that the port name >is some combination of an IP address and TCP port number. Nothing in /dev. What I think would make the most sense is a simple "device" enumeration Server Provider Interface that would bring port objects into the JVM based on the platform JVM providers knowledge of how to enumerate those ports. Application writers would provide a plugin using the SPI that would codify those devices into named entities that they are interested in. public interface HardwarePort { public String getName(); public String getHardwareID(); public String getManufacturer(); public List getCapabilities(); public Object getImplementation(); } public interface PortCapability { public String getDescription(); public CapabilityId getIdentifier(); } public enum CapabilityId { INPUT, // Can receive input OUTPUT, // Can send output ASYNCHRONOUS, // Can send and receive at the same time SYNCHRONOUS, // No synchronous I/O ADDRESSABLE // Port has an address associated } Then, you might imagine that the enumerated capabilities had a standardized/specified interface that you'd find implemented on ports that had such capabilities. The getImplementation() method would return the implementation class provided by the JVM provider that had all of the interfaces tied to it. These are just some quick thoughts, pick away at them. I am very interested in getting a new comm api in place which can provide the ability for all USB connected devices to have drivers provided as 100% java for all non-timing critical types of device interfaces. The JVM provider should have an SPI to write to which will enable them to abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into something that we can talk 100% java to. That's my big desire. Starting with something simple which gives a good start in that direction would be great! Gregg Wonderly From pascal at quies.net Sat Jul 22 11:32:03 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 19:32:03 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <44C25370.9070506@cox.net> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> Message-ID: <200607221932.04194.pascal@quies.net> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: > >Pascal S. de Kloe wrote: > >>> I am also not sure if > >>> the api should unify corresponding cu. and tty. ports into one single > >>> port. > >> > >> I think the API should hide low-level details like devicefiles. > > > >Not all ports have device files. It's long been my goal to add support > >for virtual serial ports, that is, serial ports on Ethernet terminal > >servers, for example integrating RFC2217. This means that the port name > >is some combination of an IP address and TCP port number. Nothing in > > /dev. > > What I think would make the most sense is a simple "device" enumeration > Server Provider Interface that would bring port objects into the JVM based > on the platform JVM providers knowledge of how to enumerate those ports. > Application writers would provide a plugin using the SPI that would codify > those devices into named entities that they are interested in. > > public interface HardwarePort { > public String getName(); > public String getHardwareID(); > public String getManufacturer(); > public List getCapabilities(); > public Object getImplementation(); > } > > public interface PortCapability { > public String getDescription(); > public CapabilityId getIdentifier(); > } > > public enum CapabilityId { > INPUT, // Can receive input > OUTPUT, // Can send output > ASYNCHRONOUS, // Can send and receive at the same time > SYNCHRONOUS, // No synchronous I/O > ADDRESSABLE // Port has an address associated > } > > Then, you might imagine that the enumerated capabilities had a > standardized/specified interface that you'd find implemented on ports that > had such capabilities. > > The getImplementation() method would return the implementation class > provided by the JVM provider that had all of the interfaces tied to it. > > These are just some quick thoughts, pick away at them. > > I am very interested in getting a new comm api in place which can provide > the ability for all USB connected devices to have drivers provided as 100% > java for all non-timing critical types of device interfaces. > > The JVM provider should have an SPI to write to which will enable them to > abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into something > that we can talk 100% java to. > > That's my big desire. Starting with something simple which gives a good > start in that direction would be great! That was exactly my wish too. The point people brought up was: 1) It's too complex. 2) What does it solve? In both facts they are right. It'll take a *long* time to plan such a thing right but if it works you have a product. Anyway, I'd like to join. ;) From joachim at buechse.de Sat Jul 22 11:37:11 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 22 Jul 2006 19:37:11 +0200 Subject: [Rxtx] Strange error (show stopper) Message-ID: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> I just discovered a strange error in RXTX on OSX. SerialDemo.java manages to corrupt the event_info_structure by a simple OpenPort,ClosePort - this could be in relation to the deadlock problem that was reported recently. Could anyone try to reproduce this on Solaris or some other system which is neither WIN32 nor Linux (ie which uses a drain thread). In SerialImp.c : RXTXPort(interruptEventLoop) Apparently the event_info_structure gets corrupted shortly after pthread_kill(index->drain_tid, SIGABRT); In particular, the index->closing flag gets overwritten by a pointer value. **** Adding the following debugging code: pthread_kill(index->drain_tid, SIGABRT); sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i \n", index->fd, index, index->closing ); report( message ); /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ usleep(50 * 1000); sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i \n", index->fd, index, index->closing ); report( message ); **** gives me: 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 drain_loop: received EINTR------------------ drain_loop exiting --------------------- entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 eventLoop: got interrupt 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 **** Modifying SerialImp.h : event_info_struct by moving the prev*, next* pointers jmethodID checkMonitorThread; struct event_info_struct *dummy, *dummy2; fd_set rfds; struct timeval tv_sleep; int closing; struct event_info_struct *next, *prev; *** (ie replacing their original position with dummys and moving them *** behind the closing flag) results in this: 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 drain_loop: received EINTR------------------ drain_loop exiting --------------------- entering check_tiocmget_changes leaving check_tiocmget_changes port_has_changed_fionread: change is 0 eventLoop: got interrupt 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 *** I was not able to track down the problem. If anyone could check wether this happens on other platforms as well, we may get closer to a fix. Regards, Joachim --- Joachim B?chse Softwarel?sungen und Beratung Hadlaubsteig 2 CH-8006 Z?rich From joachim at buechse.de Sat Jul 22 11:46:35 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sat, 22 Jul 2006 19:46:35 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <200607221932.04194.pascal@quies.net> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> Message-ID: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> It seems that Gregg's suggestion could be implemented without changing the existing "user-level" API of javax.comm. Most of the information suggested for HardwarePort is not accessible from within the POSSIX-API but this is a different story. It is clear that javax.comm can never provide a way to talk to all USB devices, simply because some USB devices have several endpoints. But it could provide a means of talking to devices that function as a bidirectional-pipe (ie any USB to serial bridge). Regards, Joachim On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>> Pascal S. de Kloe wrote: >>>>> I am also not sure if >>>>> the api should unify corresponding cu. and tty. ports into one >>>>> single >>>>> port. >>>> >>>> I think the API should hide low-level details like devicefiles. >>> >>> Not all ports have device files. It's long been my goal to add >>> support >>> for virtual serial ports, that is, serial ports on Ethernet terminal >>> servers, for example integrating RFC2217. This means that the >>> port name >>> is some combination of an IP address and TCP port number. >>> Nothing in >>> /dev. >> >> What I think would make the most sense is a simple "device" >> enumeration >> Server Provider Interface that would bring port objects into the >> JVM based >> on the platform JVM providers knowledge of how to enumerate those >> ports. >> Application writers would provide a plugin using the SPI that >> would codify >> those devices into named entities that they are interested in. >> >> public interface HardwarePort { >> public String getName(); >> public String getHardwareID(); >> public String getManufacturer(); >> public List getCapabilities(); >> public Object getImplementation(); >> } >> >> public interface PortCapability { >> public String getDescription(); >> public CapabilityId getIdentifier(); >> } >> >> public enum CapabilityId { >> INPUT, // Can receive input >> OUTPUT, // Can send output >> ASYNCHRONOUS, // Can send and receive at the same time >> SYNCHRONOUS, // No synchronous I/O >> ADDRESSABLE // Port has an address associated >> } >> >> Then, you might imagine that the enumerated capabilities had a >> standardized/specified interface that you'd find implemented on >> ports that >> had such capabilities. >> >> The getImplementation() method would return the implementation class >> provided by the JVM provider that had all of the interfaces tied >> to it. >> >> These are just some quick thoughts, pick away at them. >> >> I am very interested in getting a new comm api in place which can >> provide >> the ability for all USB connected devices to have drivers provided >> as 100% >> java for all non-timing critical types of device interfaces. >> >> The JVM provider should have an SPI to write to which will enable >> them to >> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >> something >> that we can talk 100% java to. >> >> That's my big desire. Starting with something simple which gives >> a good >> start in that direction would be great! > > That was exactly my wish too. > > The point people brought up was: > 1) It's too complex. > 2) What does it solve? > > In both facts they are right. It'll take a *long* time to plan such > a thing > right but if it works you have a product. Anyway, I'd like to join. ;) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Sat Jul 22 11:55:23 2006 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Sat, 22 Jul 2006 14:55:23 -0300 Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: <44C2668B.5080703@gmail.com> Joachim Buechse escribi?: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. > > It is clear that javax.comm can never provide a way to talk to all > USB devices, simply because some USB devices have several endpoints. > But it could provide a means of talking to devices that function as a > bidirectional-pipe (ie any USB to serial bridge). > > Regards, > Joachim Hi, About USB, why do not we contact the guys that make a library to support USB under Java from Linux? I think there is all ready an JSR for USB access, what we could do to this JSR is help to implement Usb access from other OSes. Regards, Manuel > > On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > >> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>> Pascal S. de Kloe wrote: >>>>>> I am also not sure if >>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>> single >>>>>> port. >>>>> I think the API should hide low-level details like devicefiles. >>>> Not all ports have device files. It's long been my goal to add >>>> support >>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>> servers, for example integrating RFC2217. This means that the >>>> port name >>>> is some combination of an IP address and TCP port number. >>>> Nothing in >>>> /dev. >>> What I think would make the most sense is a simple "device" >>> enumeration >>> Server Provider Interface that would bring port objects into the >>> JVM based >>> on the platform JVM providers knowledge of how to enumerate those >>> ports. >>> Application writers would provide a plugin using the SPI that >>> would codify >>> those devices into named entities that they are interested in. >>> >>> public interface HardwarePort { >>> public String getName(); >>> public String getHardwareID(); >>> public String getManufacturer(); >>> public List getCapabilities(); >>> public Object getImplementation(); >>> } >>> >>> public interface PortCapability { >>> public String getDescription(); >>> public CapabilityId getIdentifier(); >>> } >>> >>> public enum CapabilityId { >>> INPUT, // Can receive input >>> OUTPUT, // Can send output >>> ASYNCHRONOUS, // Can send and receive at the same time >>> SYNCHRONOUS, // No synchronous I/O >>> ADDRESSABLE // Port has an address associated >>> } >>> >>> Then, you might imagine that the enumerated capabilities had a >>> standardized/specified interface that you'd find implemented on >>> ports that >>> had such capabilities. >>> >>> The getImplementation() method would return the implementation class >>> provided by the JVM provider that had all of the interfaces tied >>> to it. >>> >>> These are just some quick thoughts, pick away at them. >>> >>> I am very interested in getting a new comm api in place which can >>> provide >>> the ability for all USB connected devices to have drivers provided >>> as 100% >>> java for all non-timing critical types of device interfaces. >>> >>> The JVM provider should have an SPI to write to which will enable >>> them to >>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>> something >>> that we can talk 100% java to. >>> >>> That's my big desire. Starting with something simple which gives >>> a good >>> start in that direction would be great! >> That was exactly my wish too. >> >> The point people brought up was: >> 1) It's too complex. >> 2) What does it solve? >> >> In both facts they are right. It'll take a *long* time to plan such >> a thing >> right but if it works you have a product. Anyway, I'd like to join. ;) >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From ajmas at sympatico.ca Sat Jul 22 11:58:00 2006 From: ajmas at sympatico.ca (=?ISO-8859-1?Q?Andr=E9-John_Mas?=) Date: Sat, 22 Jul 2006 13:58:00 -0400 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> Message-ID: <41E45C85-4A22-4C5B-915F-62ED36BACCF2@sympatico.ca> A couple of questions: - what version are you using? - does this happen with the version in cvs? Andre On 22-Jul-06, at 13:37 , Joachim Buechse wrote: > I just discovered a strange error in RXTX on OSX. SerialDemo.java > manages to corrupt the event_info_structure by a simple > OpenPort,ClosePort - this could be in relation to the deadlock > problem that was reported recently. > > Could anyone try to reproduce this on Solaris or some other system > which is neither WIN32 nor Linux (ie which uses a drain thread). > > In SerialImp.c : RXTXPort(interruptEventLoop) > > Apparently the event_info_structure gets corrupted shortly after > > pthread_kill(index->drain_tid, SIGABRT); > > In particular, the index->closing flag gets overwritten by a pointer > value. > > > **** Adding the following debugging code: > > pthread_kill(index->drain_tid, SIGABRT); > sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ > usleep(50 * 1000); > sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > > **** gives me: > > 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 > > **** Modifying SerialImp.h : event_info_struct by moving the > prev*, next* pointers > > jmethodID checkMonitorThread; > struct event_info_struct *dummy, *dummy2; > fd_set rfds; > struct timeval tv_sleep; > int closing; > struct event_info_struct *next, *prev; > > *** (ie replacing their original position with dummys and moving them > *** behind the closing flag) results in this: > > 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 > > > *** I was not able to track down the problem. If anyone could check > wether this happens on other platforms as well, we may get closer to > a fix. > > Regards, > Joachim > > --- > Joachim B?chse > Softwarel?sungen und Beratung > Hadlaubsteig 2 > CH-8006 Z?rich > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Paul.Klissner at Sun.COM Sat Jul 22 12:19:41 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Sat, 22 Jul 2006 11:19:41 -0700 Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: <44C26C3D.8020501@sun.com> Joachim Buechse wrote: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. > > It is clear that javax.comm can never provide a way to talk to all > USB devices, simply because some USB devices have several endpoints. > But it could provide a means of talking to devices that function as a > bidirectional-pipe (ie any USB to serial bridge). If the 'back end' driver could be java as well an .so then driver's could be written using javax.usb, which is available currently for Linux. Paul > > Regards, > Joachim > > On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > >> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>> Pascal S. de Kloe wrote: >>>>>> I am also not sure if >>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>> single >>>>>> port. >>>>> I think the API should hide low-level details like devicefiles. >>>> Not all ports have device files. It's long been my goal to add >>>> support >>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>> servers, for example integrating RFC2217. This means that the >>>> port name >>>> is some combination of an IP address and TCP port number. >>>> Nothing in >>>> /dev. >>> What I think would make the most sense is a simple "device" >>> enumeration >>> Server Provider Interface that would bring port objects into the >>> JVM based >>> on the platform JVM providers knowledge of how to enumerate those >>> ports. >>> Application writers would provide a plugin using the SPI that >>> would codify >>> those devices into named entities that they are interested in. >>> >>> public interface HardwarePort { >>> public String getName(); >>> public String getHardwareID(); >>> public String getManufacturer(); >>> public List getCapabilities(); >>> public Object getImplementation(); >>> } >>> >>> public interface PortCapability { >>> public String getDescription(); >>> public CapabilityId getIdentifier(); >>> } >>> >>> public enum CapabilityId { >>> INPUT, // Can receive input >>> OUTPUT, // Can send output >>> ASYNCHRONOUS, // Can send and receive at the same time >>> SYNCHRONOUS, // No synchronous I/O >>> ADDRESSABLE // Port has an address associated >>> } >>> >>> Then, you might imagine that the enumerated capabilities had a >>> standardized/specified interface that you'd find implemented on >>> ports that >>> had such capabilities. >>> >>> The getImplementation() method would return the implementation class >>> provided by the JVM provider that had all of the interfaces tied >>> to it. >>> >>> These are just some quick thoughts, pick away at them. >>> >>> I am very interested in getting a new comm api in place which can >>> provide >>> the ability for all USB connected devices to have drivers provided >>> as 100% >>> java for all non-timing critical types of device interfaces. >>> >>> The JVM provider should have an SPI to write to which will enable >>> them to >>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>> something >>> that we can talk 100% java to. >>> >>> That's my big desire. Starting with something simple which gives >>> a good >>> start in that direction would be great! >> That was exactly my wish too. >> >> The point people brought up was: >> 1) It's too complex. >> 2) What does it solve? >> >> In both facts they are right. It'll take a *long* time to plan such >> a thing >> right but if it works you have a product. Anyway, I'd like to join. ;) >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sat Jul 22 12:48:15 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sat, 22 Jul 2006 20:48:15 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607221920.20096.pascal@quies.net> References: <200607221920.20096.pascal@quies.net> Message-ID: <200607222048.16215.pascal@quies.net> http://quies.net/communicationapi.jar Fixed a few typo's and it works on Linux i386. It should also work on Windows i386. The rest is missing libParallel or more... -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 6664 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060722/5fd7c1ce/CommunicationAPI-0344.bin From Paul.Klissner at Sun.COM Sat Jul 22 12:53:12 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Sat, 22 Jul 2006 11:53:12 -0700 Subject: [Rxtx] jcp and jsr (libusb, javax.usb) In-Reply-To: <44C2668B.5080703@gmail.com> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> <44C2668B.5080703@gmail.com> Message-ID: <44C27418.1090309@sun.com> Manuel Naranjo wrote: > Joachim Buechse escribi?: >> It seems that Gregg's suggestion could be implemented without >> changing the existing "user-level" API of javax.comm. Most of the >> information suggested for HardwarePort is not accessible from within >> the POSSIX-API but this is a different story. >> >> It is clear that javax.comm can never provide a way to talk to all >> USB devices, simply because some USB devices have several endpoints. >> But it could provide a means of talking to devices that function as a >> bidirectional-pipe (ie any USB to serial bridge). >> >> Regards, >> Joachim > > Hi, > About USB, why do not we contact the guys that make a library to support > USB under Java from Linux? > I think there is all ready an JSR for USB access, what we could do to this > JSR is help to implement Usb access from other OSes. JAVAX.USB --------- javax.usb already a SourceForge project. I was Sun's rep on the expert group for JSR-80, javax.usb. I lived and breathed it for a 1.5 yrs working with spec lead from IBM on it. It's for real and the linux implementation works (not sure about the Win32 port on sourceforge). IBM even created a porting layer to simplify porting it to other platforms by implementing in Java all of the numerous 'clerical' functions of the API in Java so that the porting layer is absolutely minimal. The hardest part is managing the hotpluggable device tree topology as objects, and depending on one's platform or coding skills probably wouldn't take more than a week or two to get right. LIBUSB 1.0 (*NOT* libusb 0.1.8) ---------- There is also the native C library libusb. libusb 0.1.8 is weak, but libusb 1.0 under development holds the promise of being an extrordinarily robust C API to access USB devices through, and could definitely use some help getting people to port it to other platforms. I've attached the proposed libusb 1.0 API header which Sun worked with Johannes on for months before he went off into oblivion. The API has stalled and a fire might need to be lit under Johannes or it might need to be forked to get it moving again, but the spec for 1.0 is awesome, and this puppy is ready to turn into something sweet with some fresh blood on it. And it is a really good technology to become aquainted with... hint hint. Both of those APIs are really excellent and hold great promise for the community and use of USB technology in general. One of my goals, now which competes for my time with other higher priority projects was to layer an implementation of javax.usb over libusb 1.0, so that javax.usb would follow libusb to any platform and only one port would be required. But since libusb 1.0 is moving slowly, largely because the current sourceforge gatekeeper for the project, Johannes Erdfelt's lack of energy and sparse communication, it might be faster to simply port javax.usb to Mac OS, Win, Solaris and BSD if some people could get behind those, unless someone want's to get behind making libusb happen. >>>> >>>> public enum CapabilityId { >>>> INPUT, // Can receive input >>>> OUTPUT, // Can send output >>>> ASYNCHRONOUS, // Can send and receive at the same time >>>> SYNCHRONOUS, // No synchronous I/O >>>> ADDRESSABLE // Port has an address associated >>>> } My understanding is that synchronous/asynchronous refers to the way the data is clocked. I think FULLDUPLEX/HALFDUPLEX is what the author meant, or needs to be added. Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: libusb.h Type: text/x-sun-h-file Size: 26696 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060722/4a43e034/libusb-0344.bin From pascal at quies.net Sat Jul 22 17:53:31 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 01:53:31 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> References: <44C252BF.6040404@cox.net> <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> Message-ID: <200607230153.32328.pascal@quies.net> Hi Joachim, I'm not getting it. How do you easily get a "stub method / flag"? Op zaterdag 22 juli 2006 19:17, schreef Joachim Buechse: > We could easily have a stub method / flag that allows you to > explicitly load the native library (via System.loadLibrary ie from > the java.library.path). In this case the "auto-extraction" would not > take place. > > On 22.07.2006, at 18:30, Gregg Wonderly wrote: > > Dr. Douglas Lyon wrote: > >> Hi All, > >> I like the idea of the native lib in a jar with other classes. > >> An alternative I did not know would work. > > > > I have several applications that run with a security policy. In these > > applications, native library loading will require an appropriate > > FilePermission > > that should be known about ahead of time. The current native library > > implementation will require the native library to be extracted from > > the jar and > > written to disk, requiring a FilePermission("...","write") for that > > file, and > > then will also require read access to load the library. I > > personally don't want > > to give write access to a JVM for a shared library which can > > provide a point of > > abuse by errant code. > > > > Gregg Wonderly > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Sat Jul 22 18:46:33 2006 From: jredman at ergotech.com (Jim Redman) Date: Sat, 22 Jul 2006 18:46:33 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <44C26C3D.8020501@sun.com> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> <44C26C3D.8020501@sun.com> Message-ID: <44C2C6E9.8020408@ergotech.com> Paul, I think that you've already proposed a "pluggable" underlying architecture and I think that this might be better implemented there. If you need some more examples, I'd like to have a Bluetooth interface (with dynamic discovery). Jim Paul Klissner wrote: > Joachim Buechse wrote: >> It seems that Gregg's suggestion could be implemented without >> changing the existing "user-level" API of javax.comm. Most of the >> information suggested for HardwarePort is not accessible from within >> the POSSIX-API but this is a different story. >> >> It is clear that javax.comm can never provide a way to talk to all >> USB devices, simply because some USB devices have several endpoints. >> But it could provide a means of talking to devices that function as a >> bidirectional-pipe (ie any USB to serial bridge). > > If the 'back end' driver could be java as well an .so > then driver's could be written using javax.usb, which > is available currently for Linux. > > Paul > > > >> Regards, >> Joachim >> >> On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: >> >>> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>>> Pascal S. de Kloe wrote: >>>>>>> I am also not sure if >>>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>>> single >>>>>>> port. >>>>>> I think the API should hide low-level details like devicefiles. >>>>> Not all ports have device files. It's long been my goal to add >>>>> support >>>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>>> servers, for example integrating RFC2217. This means that the >>>>> port name >>>>> is some combination of an IP address and TCP port number. >>>>> Nothing in >>>>> /dev. >>>> What I think would make the most sense is a simple "device" >>>> enumeration >>>> Server Provider Interface that would bring port objects into the >>>> JVM based >>>> on the platform JVM providers knowledge of how to enumerate those >>>> ports. >>>> Application writers would provide a plugin using the SPI that >>>> would codify >>>> those devices into named entities that they are interested in. >>>> >>>> public interface HardwarePort { >>>> public String getName(); >>>> public String getHardwareID(); >>>> public String getManufacturer(); >>>> public List getCapabilities(); >>>> public Object getImplementation(); >>>> } >>>> >>>> public interface PortCapability { >>>> public String getDescription(); >>>> public CapabilityId getIdentifier(); >>>> } >>>> >>>> public enum CapabilityId { >>>> INPUT, // Can receive input >>>> OUTPUT, // Can send output >>>> ASYNCHRONOUS, // Can send and receive at the same time >>>> SYNCHRONOUS, // No synchronous I/O >>>> ADDRESSABLE // Port has an address associated >>>> } >>>> >>>> Then, you might imagine that the enumerated capabilities had a >>>> standardized/specified interface that you'd find implemented on >>>> ports that >>>> had such capabilities. >>>> >>>> The getImplementation() method would return the implementation class >>>> provided by the JVM provider that had all of the interfaces tied >>>> to it. >>>> >>>> These are just some quick thoughts, pick away at them. >>>> >>>> I am very interested in getting a new comm api in place which can >>>> provide >>>> the ability for all USB connected devices to have drivers provided >>>> as 100% >>>> java for all non-timing critical types of device interfaces. >>>> >>>> The JVM provider should have an SPI to write to which will enable >>>> them to >>>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>>> something >>>> that we can talk 100% java to. >>>> >>>> That's my big desire. Starting with something simple which gives >>>> a good >>>> start in that direction would be great! >>> That was exactly my wish too. >>> >>> The point people brought up was: >>> 1) It's too complex. >>> 2) What does it solve? >>> >>> In both facts they are right. It'll take a *long* time to plan such >>> a thing >>> right but if it works you have a product. Anyway, I'd like to join. ;) >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From lyon at docjava.com Sun Jul 23 04:27:22 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 06:27:22 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607222048.16215.pascal@quies.net> References: <200607221920.20096.pascal@quies.net> <200607222048.16215.pascal@quies.net> Message-ID: The Class.forName is a static method. Therefore myClass.forName Should be Class.forName and myClass becomes an unused parameter. - DL >http://quies.net/communicationapi.jar > >Fixed a few typo's and it works on Linux i386. It should also work on Windows >i386. The rest is missing libParallel or more... > > >Attachment converted: PowerBookHd:CommunicationAPI 1.java >(TEXT/ttxt) (001C1A15) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Jul 23 04:32:45 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 06:32:45 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607222048.16215.pascal@quies.net> References: <200607221920.20096.pascal@quies.net> <200607222048.16215.pascal@quies.net> Message-ID: Also, the is Java2 check does not check if you are running under jdk1.5 - DL >http://quies.net/communicationapi.jar > >Fixed a few typo's and it works on Linux i386. It should also work on Windows >i386. The rest is missing libParallel or more... > > >Attachment converted: PowerBookHd:CommunicationAPI 1.java >(TEXT/ttxt) (001C1A15) >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Jul 23 04:54:12 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 06:54:12 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607221843.27765.pascal@quies.net> References: <44C252BF.6040404@cox.net> <200607221843.27765.pascal@quies.net> Message-ID: Hi All, Perhaps Java web start can address Gregg's concerns. The native libs are placed into a signed jar for distribution. As to the assertion that serial-port based programs need file io abilities, that seems true, to me. Particularly for /dev/ttyN type native libs or libs that use lock files. The question of how to obtain a signed application that is given file-io authority may be settled by using a signing technology. Even applets can be signed, to enable improved access to the file system. What else can we try? Any ideas? Thanks! - Doug >Op zaterdag 22 juli 2006 18:30, schreef Gregg Wonderly: >> Dr. Douglas Lyon wrote: >> > Hi All, >> > I like the idea of the native lib in a jar with other classes. >> > An alternative I did not know would work. >> >> I have several applications that run with a security policy. In these >> applications, native library loading will require an appropriate >> FilePermission that should be known about ahead of time. The current >> native library implementation will require the native library to be >> extracted from the jar and written to disk, requiring a >> FilePermission("...","write") for that file, and then will also require >> read access to load the library. I personally don't want to give write >> access to a JVM for a shared library which can provide a point of abuse by >> errant code. >> >> Gregg Wonderly > >That's indeed a pitty limitation. It creates a lot of possible exceptions too. > >On the other hand, any native lib passes the securiy model. Applications who >can access hardware ports can be expected to create files, right? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 04:57:33 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 12:57:33 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607222048.16215.pascal@quies.net> Message-ID: <200607231257.34284.pascal@quies.net> Op zondag 23 juli 2006 12:27, schreef Dr. Douglas Lyon: > The Class.forName is a static method. Therefore > myClass.forName Should be Class.forName and > myClass becomes an unused parameter. > - DL Thank you. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 6625 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060723/00f3b627/CommunicationAPI-0344.bin From pascal at quies.net Sun Jul 23 05:02:59 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 13:02:59 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607222048.16215.pascal@quies.net> Message-ID: <200607231302.59252.pascal@quies.net> Op zondag 23 juli 2006 12:32, schreef Dr. Douglas Lyon: > Also, the is Java2 check does not check if you are running under > jdk1.5 > - DL Could you please explain? The JDK 1.5 will pass the check just fine. From lyon at docjava.com Sun Jul 23 05:34:10 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 07:34:10 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607221854.13467.pascal@quies.net> References: <200607221506.07140.pascal@quies.net> <200607221854.13467.pascal@quies.net> Message-ID: Hi All, Please call me Doug (the Dr. is for the classroom). Thanks! - Doug >Hi Dr., > >We're both trying to do the same thing. > >The CommunicationAPI does not only look at the OS but it also indexes the >available hardware architectures and does not need OsUtils. Any Java 2 >runtime will do. > >The plan was to make a single JAR with the binaries for all supported >platforms, the RXTX gnu.io package and the javax.comm wrapers. > >A signed version would be nice. > >A few questions remain tough. Does anybody know how Sun uses the SunOS and >Solaris identifiers for the Java property os.name? > > > >Op zaterdag 22 juli 2006 16:06, schreef Dr. Douglas Lyon: >> Hi All, >> Here is how I have arranged my signed versions of the native >> binaries: >> http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/windows/native.j >>ar http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/mac/native.jar >> http://show.docjava.com:8086/book/cgij/code/jnlp/libs/rxtx/linux/native.jar >> >> Then I do: >> public static URL getResourceUrl() throws MalformedURLException { >> String rxtxUrl = "http://show.docjava.com:8086/" + >> "book/cgij/code/jnlp/libs/rxtx/"; >> if (OsUtils.isLinux()) >> return new URL(rxtxUrl + "linux/native.jar"); >> if (OsUtils.isMacOs()) >> return new URL(rxtxUrl + "mac/native.jar"); >> if (OsUtils.isWindows()) >> return new URL(rxtxUrl + "windows/native.jar"); >> System.out.println("no automatic install supported for this >> platform. " + >> "Please e-mail lyon at docjava.com with a bug report"); >> return null; >> } >> >> My new-age NativeLibraryManger concept-thang allows you to >> write stuff like: >> >> /** >> * This method fixes the driver by beaming over >> * to the tmp directory a native.jar file. >> * The native.jar file is signed and its >> * native libs are beamed over to the user home directory >> * ~/.rxtx/
>> * Finally, the java.library.path is altered to include
>> * ~/.rxtx/ >> */ >> private static void fixDriver() { >> >> try { >> NativeLibraryManager.fixDriver(getResourceUrl(), >> NativeLibraryManager.mapLibraryName("rxtxSerial")); >> } catch (IOException e) { >> e.printStackTrace(); >> } >> } >> >> I do a lazy singleton design pattern: >> >> public final class SafeCommDriver { >> private static RXTXCommDriver driver = null; >> >> private SafeCommDriver() { >> } >> >> public synchronized static RXTXCommDriver getInstance() { >> if (driver != null) return driver; >> if (!NativeLibraryManager.isLibInPath("rxtxSerial")) >> fixDriver(); >> if (NativeLibraryManager.isLibInPath("rxtxSerial")) { >> driver = new RXTXCommDriver(); >> driver.initialize(); >> } >> return driver; >> } >> >> I am at a cross-roads here, since a file-based distro might be preferable >> to a URL based distro. To make this really general, and to "remember" where >> the last version of a native library came from, I serialize a bean into >> user preferences >> The user can then store native libraries anywhere, remembering the location >> in the preferences. >> >> What is the general feeling about this? >> >> Thanks! >> - Doug >> >> > > Now, if you place the rxtx classes and native library in the same >> >> >> >> jar, do they both have to be in any specific place in order to be >> >> found? >> > >> >Answer: >> >> >The path to the libraries is in the form >> >> >of /native/rxtx/-/{libserial,libparallel} >> >> >so /native/rxtx/windows-i386/libserial would do. >> > >> >I'me looking for the various os.name and os.arch values right now. >> >_______________________________________________ >> >Rxtx mailing list >> >Rxtx at qbang.org >> >http://mailman.qbang.org/mailman/listinfo/rxtx > > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 06:12:33 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 14:12:33 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607221843.27765.pascal@quies.net> Message-ID: <200607231412.34078.pascal@quies.net> Op zondag 23 juli 2006 12:54, schreef Dr. Douglas Lyon: > Hi All, > Perhaps Java web start can address Gregg's concerns. > The native libs are placed into a signed jar for distribution. > As to the assertion that serial-port based programs need file io > abilities, that seems true, to me. Particularly for /dev/ttyN type > native libs or libs that use lock files. > The question of how to obtain a signed application that is given > file-io authority may be settled by using a signing technology. > > Even applets can be signed, to enable improved access to the file > system. > > What else can we try? Any ideas? It might be a good idea to use a more optimized version for youre networked applications. These native libraries are huge for some reason. Can you build a "downloader"? From lyon at docjava.com Sun Jul 23 06:46:43 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 08:46:43 -0400 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: <200607231302.59252.pascal@quies.net> References: <200607222048.16215.pascal@quies.net> <200607231302.59252.pascal@quies.net> Message-ID: public static void main(String[] args) { System.out.println("isJava2="+System.getProperty("java.version")); } Prints out 1.5_06 on my system, but you seem to need the "1.2" to be present on the system...right? RXTX does work under 1.5, at least on my system. - DL >Op zondag 23 juli 2006 12:32, schreef Dr. Douglas Lyon: >> Also, the is Java2 check does not check if you are running under >> jdk1.5 >> - DL > >Could you please explain? >The JDK 1.5 will pass the check just fine. >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Sun Jul 23 06:58:02 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 08:58:02 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607231412.34078.pascal@quies.net> References: <200607221843.27765.pascal@quies.net> <200607231412.34078.pascal@quies.net> Message-ID: Hi All, Yes, I do have a download, as to the question of "huge": ls -al native.jar -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar 28kbytes is not really huge, right? In fact, if you uncompress the jar, you get: -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so Which is almost 80kbytes, so the jar is 40% of the native libs size, and it is signed. At least on the Linux version, it is smaller. I did not check the other versions. And with java web start, the JNLP only downloads the native jar if it is new or changed. And it only downloads the native jar used for the target platform. Here is how the jnlp looks, FYI... addbk.JAddressBook.Main DocJava, Inc. I have been playing around with "eager" and "lazy" directives, but I can't really tell the difference. Cheers! - Doug >Op zondag 23 juli 2006 12:54, schreef Dr. Douglas Lyon: >> Hi All, >> Perhaps Java web start can address Gregg's concerns. >> The native libs are placed into a signed jar for distribution. >> As to the assertion that serial-port based programs need file io >> abilities, that seems true, to me. Particularly for /dev/ttyN type >> native libs or libs that use lock files. >> The question of how to obtain a signed application that is given >> file-io authority may be settled by using a signing technology. >> >> Even applets can be signed, to enable improved access to the file >> system. >> >> What else can we try? Any ideas? > >It might be a good idea to use a more optimized version for youre networked >applications. These native libraries are huge for some reason. >Can you build a "downloader"? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 07:53:54 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 15:53:54 +0200 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607231302.59252.pascal@quies.net> Message-ID: <200607231553.55088.pascal@quies.net> Op zondag 23 juli 2006 14:46, schreef Dr. Douglas Lyon: > public static void main(String[] args) { > System.out.println("isJava2="+System.getProperty("java.version")); > > } > Prints out 1.5_06 on my system, but you seem to need the "1.2" to be > present on the system...right? if (System.getProperty("java.version").compareTo("1.2") < 0) throw new Error("RXTX requires a Java 2 platform."); The line requires a version string of "1.2" or higher. Sun decided to name all versions since 1.2 as Java 2. (That is why there is this 2 in J2SE.) The error should never happen anyway if you compile the code with the -target 1.2 flag. From pascal at quies.net Sun Jul 23 07:55:52 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 15:55:52 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607231412.34078.pascal@quies.net> Message-ID: <200607231555.52419.pascal@quies.net> Op zondag 23 juli 2006 14:58, schreef Dr. Douglas Lyon: > Hi All, > Yes, I do have a download, as to the question of "huge": > ls -al native.jar > -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar > 28kbytes is not really huge, right? > In fact, if you uncompress the jar, you get: > -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so > -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so > Which is almost 80kbytes, so the jar is 40% of the native libs size, and > it is signed. > At least on the Linux version, it is smaller. I did not check the > other versions. > > And with java web start, the JNLP only downloads the native jar if it is > new or changed. > And it only downloads the native jar used for the target platform. > > Here is how the jnlp looks, FYI... > codebase="http://show.docjava.com:8086/book/cgij/code/jnlp/"> > > addbk.JAddressBook.Main > DocJava, Inc. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have been playing around with "eager" and "lazy" directives, > but I can't really tell the difference. > > Cheers! > - Doug That is a nice sollution. Is there a tag for the architecture too becouse now you assume i386 and that is of course not necesairy true. From joachim at buechse.de Sun Jul 23 11:17:29 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 23 Jul 2006 19:17:29 +0200 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <41E45C85-4A22-4C5B-915F-62ED36BACCF2@sympatico.ca> References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> <41E45C85-4A22-4C5B-915F-62ED36BACCF2@sympatico.ca> Message-ID: <0B7FC525-4C71-49E8-B652-CCF6C67B4A58@buechse.de> This happens with the versions in CVS (2.07+ and 2.17+). On 22.07.2006, at 19:58, Andr?-John Mas wrote: > A couple of questions: > - what version are you using? > - does this happen with the version in cvs? > > Andre > > On 22-Jul-06, at 13:37 , Joachim Buechse wrote: > >> I just discovered a strange error in RXTX on OSX. SerialDemo.java >> manages to corrupt the event_info_structure by a simple >> OpenPort,ClosePort - this could be in relation to the deadlock >> problem that was reported recently. >> >> Could anyone try to reproduce this on Solaris or some other system >> which is neither WIN32 nor Linux (ie which uses a drain thread). >> >> In SerialImp.c : RXTXPort(interruptEventLoop) >> >> Apparently the event_info_structure gets corrupted shortly after >> >> pthread_kill(index->drain_tid, SIGABRT); >> >> In particular, the index->closing flag gets overwritten by a pointer >> value. >> >> >> **** Adding the following debugging code: >> >> pthread_kill(index->drain_tid, SIGABRT); >> sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i >> \n", index->fd, index, index->closing ); >> report( message ); >> /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ >> usleep(50 * 1000); >> sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i >> \n", index->fd, index, index->closing ); >> report( message ); >> >> **** gives me: >> >> 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 >> drain_loop: received EINTR------------------ drain_loop exiting >> --------------------- >> entering check_tiocmget_changes >> leaving check_tiocmget_changes >> port_has_changed_fionread: change is 0 >> eventLoop: got interrupt >> 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 >> >> **** Modifying SerialImp.h : event_info_struct by moving the >> prev*, next* pointers >> >> jmethodID checkMonitorThread; >> struct event_info_struct *dummy, *dummy2; >> fd_set rfds; >> struct timeval tv_sleep; >> int closing; >> struct event_info_struct *next, *prev; >> >> *** (ie replacing their original position with dummys and moving them >> *** behind the closing flag) results in this: >> >> 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 >> drain_loop: received EINTR------------------ drain_loop exiting >> --------------------- >> entering check_tiocmget_changes >> leaving check_tiocmget_changes >> port_has_changed_fionread: change is 0 >> eventLoop: got interrupt >> 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 >> >> >> *** I was not able to track down the problem. If anyone could check >> wether this happens on other platforms as well, we may get closer to >> a fix. >> >> Regards, >> Joachim >> >> --- >> Joachim B?chse >> Softwarel?sungen und Beratung >> Hadlaubsteig 2 >> CH-8006 Z?rich >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Sun Jul 23 11:44:48 2006 From: joachim at buechse.de (Joachim Buechse) Date: Sun, 23 Jul 2006 19:44:48 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607230153.32328.pascal@quies.net> References: <44C252BF.6040404@cox.net> <4D668C6F-FB5E-4602-ACF8-F39E5A329E7E@buechse.de> <200607230153.32328.pascal@quies.net> Message-ID: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> Gregg's concern was, that extracting the library from the jar and loading it via System.load needs file access privileges. To solve this concern, all that's required is a static method/flag that triggers loading via System.loadLibrary instead (of course, then he needs to make sure, that the library is on the java.library.path). This could also be handled via a system property of course. Regards, Joachim On 23.07.2006, at 01:53, Pascal S. de Kloe wrote: > Hi Joachim, > > I'm not getting it. > How do you easily get a "stub method / flag"? > > > Op zaterdag 22 juli 2006 19:17, schreef Joachim Buechse: >> We could easily have a stub method / flag that allows you to >> explicitly load the native library (via System.loadLibrary ie from >> the java.library.path). In this case the "auto-extraction" would not >> take place. >> >> On 22.07.2006, at 18:30, Gregg Wonderly wrote: >>> Dr. Douglas Lyon wrote: >>>> Hi All, >>>> I like the idea of the native lib in a jar with other classes. >>>> An alternative I did not know would work. >>> >>> I have several applications that run with a security policy. In >>> these >>> applications, native library loading will require an appropriate >>> FilePermission >>> that should be known about ahead of time. The current native >>> library >>> implementation will require the native library to be extracted from >>> the jar and >>> written to disk, requiring a FilePermission("...","write") for that >>> file, and >>> then will also require read access to load the library. I >>> personally don't want >>> to give write access to a JVM for a shared library which can >>> provide a point of >>> abuse by errant code. >>> >>> Gregg Wonderly >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 13:34:17 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Sun, 23 Jul 2006 21:34:17 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> References: <200607230153.32328.pascal@quies.net> <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> Message-ID: <200607232134.17451.pascal@quies.net> Aaah, the penny drops. I was reading it as the stub method _root_ flag like using the root of a jar as a context for java.library.path. Thanks for explaining. :) I'll build it right away. Op zondag 23 juli 2006 19:44, schreef Joachim Buechse: > Gregg's concern was, that extracting the library from the jar and > loading it via System.load needs file access privileges. To solve > this concern, all that's required is a static method/flag that > triggers loading via System.loadLibrary instead (of course, then he > needs to make sure, that the library is on the java.library.path). > This could also be handled via a system property of course. > > Regards, > Joachim > > On 23.07.2006, at 01:53, Pascal S. de Kloe wrote: > > Hi Joachim, > > > > I'm not getting it. > > How do you easily get a "stub method / flag"? > > > > Op zaterdag 22 juli 2006 19:17, schreef Joachim Buechse: > >> We could easily have a stub method / flag that allows you to > >> explicitly load the native library (via System.loadLibrary ie from > >> the java.library.path). In this case the "auto-extraction" would not > >> take place. > >> > >> On 22.07.2006, at 18:30, Gregg Wonderly wrote: > >>> Dr. Douglas Lyon wrote: > >>>> Hi All, > >>>> I like the idea of the native lib in a jar with other classes. > >>>> An alternative I did not know would work. > >>> > >>> I have several applications that run with a security policy. In > >>> these > >>> applications, native library loading will require an appropriate > >>> FilePermission > >>> that should be known about ahead of time. The current native > >>> library > >>> implementation will require the native library to be extracted from > >>> the jar and > >>> written to disk, requiring a FilePermission("...","write") for that > >>> file, and > >>> then will also require read access to load the library. I > >>> personally don't want > >>> to give write access to a JVM for a shared library which can > >>> provide a point of > >>> abuse by errant code. > >>> > >>> Gregg Wonderly > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Sun Jul 23 18:10:45 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 02:10:45 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607232134.17451.pascal@quies.net> References: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> <200607232134.17451.pascal@quies.net> Message-ID: <200607240210.45992.pascal@quies.net> Hello gentleman, The CommunicationAPI class / utility is almost ready. Could you please have a final look and give your opinion? Does anybody know how the SunOS and the Solaris os.name is used? Sun uses just sparc as the description for os.arch. Is it safe to use the 32-bit binaries? @Gregg You can extract the necessary libraries during the installation with the extractNativeLibraries method to the application directory so they get loaded automatically. Is that good enough? @Trent Would you include this class afther any possible comments in the distribution? -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 10884 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060723/d2e99122/CommunicationAPI-0343.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: PlatformNotSupportedException.java Type: text/x-java Size: 1621 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060723/d2e99122/PlatformNotSupportedException-0343.bin From lyon at docjava.com Sun Jul 23 18:14:08 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 23 Jul 2006 20:14:08 -0400 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607231555.52419.pascal@quies.net> References: <200607231412.34078.pascal@quies.net> <200607231555.52419.pascal@quies.net> Message-ID: Hi All, The present JNLP distro that I use: > > >> >> > Works for Macs using G3 and G4's. I have not tested this with an i386 mac, as I do not have one. And it only works with i386 based linux... As far as architecture goes: Allows for a chip arch, and this might address your question. The real bottleneck is that you need one of everything to test a deployment, or you have to know a bunch of people (like on this list!) to do a proper test. Cheers! - Doug >Op zondag 23 juli 2006 14:58, schreef Dr. Douglas Lyon: >> Hi All, >> Yes, I do have a download, as to the question of "huge": >> ls -al native.jar >> -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar >> 28kbytes is not really huge, right? >> In fact, if you uncompress the jar, you get: >> -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so >> -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so >> Which is almost 80kbytes, so the jar is 40% of the native libs size, and >> it is signed. >> At least on the Linux version, it is smaller. I did not check the >> other versions. >> >> And with java web start, the JNLP only downloads the native jar if it is >> new or changed. >> And it only downloads the native jar used for the target platform. >> >> Here is how the jnlp looks, FYI... >> > codebase="http://show.docjava.com:8086/book/cgij/code/jnlp/"> >> >> addbk.JAddressBook.Main >> DocJava, Inc. >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > >> >> > > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> I have been playing around with "eager" and "lazy" directives, >> but I can't really tell the difference. >> >> Cheers! >> - Doug > >That is a nice sollution. > >Is there a tag for the architecture too becouse now you assume i386 and that >is of course not necesairy true. >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Sun Jul 23 10:38:50 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 23 Jul 2006 11:38:50 -0500 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607221843.27765.pascal@quies.net> References: <44C252BF.6040404@cox.net> <200607221843.27765.pascal@quies.net> Message-ID: <44C3A61A.3060706@cox.net> Pascal S. de Kloe wrote: > Op zaterdag 22 juli 2006 18:30, schreef Gregg Wonderly: >>I have several applications that run with a security policy. In these >>applications, native library loading will require an appropriate >>FilePermission that should be known about ahead of time. The current >>native library implementation will require the native library to be >>extracted from the jar and written to disk, requiring a >>FilePermission("...","write") for that file, and then will also require >>read access to load the library. I personally don't want to give write >>access to a JVM for a shared library which can provide a point of abuse by >>errant code. > That's indeed a pitty limitation. It creates a lot of possible exceptions too. > > On the other hand, any native lib passes the securiy model. Applications who > can access hardware ports can be expected to create files, right? The use of an appropriate security policy is a deployment time configuration. There needs to be appropriate limits that confine the software to its intended tasks. Gregg Wonderly From gergg at cox.net Sun Jul 23 10:56:39 2006 From: gergg at cox.net (Gregg Wonderly) Date: Sun, 23 Jul 2006 11:56:39 -0500 Subject: [Rxtx] NativeLibraryManager - A general solution an to old problem. In-Reply-To: References: <200607221920.20096.pascal@quies.net> <200607222048.16215.pascal@quies.net> Message-ID: <44C3AA47.4060003@cox.net> Dr. Douglas Lyon wrote: > The Class.forName is a static method. Therefore > myClass.forName Should be Class.forName and > myClass becomes an unused parameter. Or better yet, make that parameter a context classloader and call Class.forName( classname, classloader); so that the location of the codebase for loading classes can be separate from the applications classpath. Gregg Wonderly From tjarvi at qbang.org Sun Jul 23 20:26:04 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 20:26:04 -0600 (MDT) Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: I do not see a point of having CommAPI do much more than basic termios interfaces and possibly parallel ports. The kernels can deliver that interface just fine for USB and other types. One problem with the current implementation for USB and IrDA is hotplug. There is a HAL daemon that can send connect and disconnect events which should probably be added to a new API. Sun is also working on a HAL port for Solaris. It is hackish but I saw at the Linux symposium that it will be getting attention and improving. The point being that these events could be included not that HAL is the end of all problems. It would appear to me that anything further in USB space should be done with the/a USB API to avoid duplication of efforts. USB is only one of many low level options for termios interfaces. On Sat, 22 Jul 2006, Joachim Buechse wrote: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. > > It is clear that javax.comm can never provide a way to talk to all > USB devices, simply because some USB devices have several endpoints. > But it could provide a means of talking to devices that function as a > bidirectional-pipe (ie any USB to serial bridge). > > Regards, > Joachim > > On 22.07.2006, at 19:32, Pascal S. de Kloe wrote: > >> Op zaterdag 22 juli 2006 18:33, schreef Gregg Wonderly: >>>> Pascal S. de Kloe wrote: >>>>>> I am also not sure if >>>>>> the api should unify corresponding cu. and tty. ports into one >>>>>> single >>>>>> port. >>>>> >>>>> I think the API should hide low-level details like devicefiles. >>>> >>>> Not all ports have device files. It's long been my goal to add >>>> support >>>> for virtual serial ports, that is, serial ports on Ethernet terminal >>>> servers, for example integrating RFC2217. This means that the >>>> port name >>>> is some combination of an IP address and TCP port number. >>>> Nothing in >>>> /dev. >>> >>> What I think would make the most sense is a simple "device" >>> enumeration >>> Server Provider Interface that would bring port objects into the >>> JVM based >>> on the platform JVM providers knowledge of how to enumerate those >>> ports. >>> Application writers would provide a plugin using the SPI that >>> would codify >>> those devices into named entities that they are interested in. >>> >>> public interface HardwarePort { >>> public String getName(); >>> public String getHardwareID(); >>> public String getManufacturer(); >>> public List getCapabilities(); >>> public Object getImplementation(); >>> } >>> >>> public interface PortCapability { >>> public String getDescription(); >>> public CapabilityId getIdentifier(); >>> } >>> >>> public enum CapabilityId { >>> INPUT, // Can receive input >>> OUTPUT, // Can send output >>> ASYNCHRONOUS, // Can send and receive at the same time >>> SYNCHRONOUS, // No synchronous I/O >>> ADDRESSABLE // Port has an address associated >>> } >>> >>> Then, you might imagine that the enumerated capabilities had a >>> standardized/specified interface that you'd find implemented on >>> ports that >>> had such capabilities. >>> >>> The getImplementation() method would return the implementation class >>> provided by the JVM provider that had all of the interfaces tied >>> to it. >>> >>> These are just some quick thoughts, pick away at them. >>> >>> I am very interested in getting a new comm api in place which can >>> provide >>> the ability for all USB connected devices to have drivers provided >>> as 100% >>> java for all non-timing critical types of device interfaces. >>> >>> The JVM provider should have an SPI to write to which will enable >>> them to >>> abstract each Serial/Parallel/PS-2/USB/1394/SATA/media port into >>> something >>> that we can talk 100% java to. >>> >>> That's my big desire. Starting with something simple which gives >>> a good >>> start in that direction would be great! >> >> That was exactly my wish too. >> >> The point people brought up was: >> 1) It's too complex. >> 2) What does it solve? >> >> In both facts they are right. It'll take a *long* time to plan such >> a thing >> right but if it works you have a product. Anyway, I'd like to join. ;) >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Sun Jul 23 20:31:45 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 20:31:45 -0600 (MDT) Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607231412.34078.pascal@quies.net> References: <200607221843.27765.pascal@quies.net> <200607231412.34078.pascal@quies.net> Message-ID: On Sun, 23 Jul 2006, Pascal S. de Kloe wrote: > Op zondag 23 juli 2006 12:54, schreef Dr. Douglas Lyon: >> Hi All, >> Perhaps Java web start can address Gregg's concerns. >> The native libs are placed into a signed jar for distribution. >> As to the assertion that serial-port based programs need file io >> abilities, that seems true, to me. Particularly for /dev/ttyN type >> native libs or libs that use lock files. >> The question of how to obtain a signed application that is given >> file-io authority may be settled by using a signing technology. >> >> Even applets can be signed, to enable improved access to the file >> system. >> >> What else can we try? Any ideas? > > It might be a good idea to use a more optimized version for youre networked > applications. These native libraries are huge for some reason. > Can you build a "downloader"? It may be that the binaries are not stripped. "strip librtxserial.so" for instance. That will remove the symbols which are not usually needed in production. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jul 23 20:49:16 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 20:49:16 -0600 (MDT) Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607240210.45992.pascal@quies.net> References: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> <200607232134.17451.pascal@quies.net> <200607240210.45992.pascal@quies.net> Message-ID: On Mon, 24 Jul 2006, Pascal S. de Kloe wrote: > Hello gentleman, > > The CommunicationAPI class / utility is almost ready. > Could you please have a final look and give your opinion? > > > Does anybody know how the SunOS and the Solaris os.name is used? > > Sun uses just sparc as the description for os.arch. Is it safe to use the > 32-bit binaries? > > > > @Gregg > You can extract the necessary libraries during the installation with the > extractNativeLibraries method to the application directory so they get loaded > automatically. Is that good enough? > > @Trent > Would you include this class afther any possible comments in the distribution? > Hi Pascal, It would appear to me that this is a tool for using the API, not an API. So perhaps the classname is not the best choice. The class also has a main which would not make a great deal of sense to include in the library to me. It would make a nice example for the contrib directory or a new utility directory though. Documentation of its availability in the main document could make it stand out from the other contrib files. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jul 23 21:27:48 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 21:27:48 -0600 (MDT) Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> Message-ID: On Sat, 22 Jul 2006, Joachim Buechse wrote: > I just discovered a strange error in RXTX on OSX. SerialDemo.java > manages to corrupt the event_info_structure by a simple > OpenPort,ClosePort - this could be in relation to the deadlock > problem that was reported recently. > > Could anyone try to reproduce this on Solaris or some other system > which is neither WIN32 nor Linux (ie which uses a drain thread). > > In SerialImp.c : RXTXPort(interruptEventLoop) > > Apparently the event_info_structure gets corrupted shortly after > > pthread_kill(index->drain_tid, SIGABRT); > > In particular, the index->closing flag gets overwritten by a pointer > value. > > > **** Adding the following debugging code: > > pthread_kill(index->drain_tid, SIGABRT); > sprintf( message, "2 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > /* TODO use wait/join/SIGCHLD/?? instead of sleep? */ > usleep(50 * 1000); > sprintf( message, "3 interrupted thread for FD %i PTR %i CLOSING %i > \n", index->fd, index, index->closing ); > report( message ); > > **** gives me: > > 2 interrupted thread for FD 18 PTR -253176128 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 18 PTR -253176128 CLOSING -253175712 > > **** Modifying SerialImp.h : event_info_struct by moving the > prev*, next* pointers > > jmethodID checkMonitorThread; > struct event_info_struct *dummy, *dummy2; > fd_set rfds; > struct timeval tv_sleep; > int closing; > struct event_info_struct *next, *prev; > > *** (ie replacing their original position with dummys and moving them > *** behind the closing flag) results in this: > > 2 interrupted thread for FD 18 PTR -253176144 CLOSING 0 > drain_loop: received EINTR------------------ drain_loop exiting > --------------------- > entering check_tiocmget_changes > leaving check_tiocmget_changes > port_has_changed_fionread: change is 0 > eventLoop: got interrupt > 3 interrupted thread for FD 5320640 PTR -253176144 CLOSING -253175712 > > > *** I was not able to track down the problem. If anyone could check > wether this happens on other platforms as well, we may get closer to > a fix. > Hi Joachim Interesting. I did run many tests with that code on may OSs. To be fair, the tests are just starting to get into good shape again. I'm still tagging releases with a bit of feel and not enough process. I'll look at this some more tomorrow night. The SIGABRT was added recently as part of the close speedups. Thats from memory. I can provide the exact patch that introduced that tomorrow. -- Trent Jarvi tjarvi at qbang.org From tjarvi at qbang.org Sun Jul 23 22:22:26 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 23 Jul 2006 22:22:26 -0600 (MDT) Subject: [Rxtx] clarification Message-ID: It should be clear that doug is the maintainer of rxtx.org now. I'll be running around very fast trying to make that easier for him but if you want something in rxtx, it is doug that does that. There are some things doug isnt very good at. He needs some help there. If he asks others for their opinion, thats his call. If he asks others for help, thats his call. This was setup to help the community. I hope everyone makes good use of it as they are now. I'm very happy with what I see but I want to make it clear that nobody should be asking me to be in rxtx. I have interests but they may not always be yours. -- Trent Jarvi tjarvi at qbang.org From guille at sms.nl Mon Jul 24 00:32:26 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Mon, 24 Jul 2006 08:32:26 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> Message-ID: <7.0.1.0.0.20060724082455.038aa518@sms.nl> At 18:31 20/07/2006, Trent Jarvi wrote: > > PROJECT SCOPE: > > ------------- > > > > Also, we should think carefully about what the scope of > > this project would be. Should it be javax."comm" which > > handles both serial and parallel (is parallel going by the > > wayside). Should it be split into two project: > > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > > > > Should we differentiate between single-ended serial > > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > > quasi-multidrop and full multidrop busses such as > > EIA422, EIA432 and EIA485? If we really were to > > add I2C support to the API, we'd have to delve into > > the semantics more, because there could be some > > implicit decoding of the bus the API users would > > want to see. > > > >Hi Paul > >The way RXTX works, which is a fair representation of the people using the >API, is complete support for RIA232, minimal support for IEEE1284. From >what I understand, Sun was going along the same lines. If we combined >both projects, we would have half a parallel port implementation. I see >maybe 4 requests for features not in the parallel support a year. > >The other protocols should not be limited by a JSR which is going to be >focused upon serial port interests. The IEA485 hacks in RXTX along with >I2C and Raw should _not_ be considered a strong basis for extending the >API to cover these protocols. If people want to do real implementations, >they should not face a 'standard' which wasnt really focused upon their >interests. I think we understand the parallel port issues fairly well but >have not implemented many features and I don't know if we would. I agree with all of this. API requirements for I2C, SPI, etc. are very different from those for RS232/485/422. Our embedded Java platform has APIs for all of these and more and they don't share a lot apart from the fact that they all use Input/OutputStreams (and in the case of SPI you still need to cater with the fact that every time you want to read you must also write to the device.) If I was to design javax.comm from scratch, I think I would focus on serial ports exclusively (== whatever the underlying OS represents as serial ports). Even parallel is a bit out of place IMHO, although I understand it needs to stay for backwards compatibility. >So a versatile API is favorable but I do not think we have the proper >community to represent much more than Serial. Yes, I think the same. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From joachim at buechse.de Mon Jul 24 01:33:14 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 24 Jul 2006 09:33:14 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607231412.34078.pascal@quies.net> <200607231555.52419.pascal@quies.net> Message-ID: <106C7BEC-EC26-4A05-8E94-61E2C9F2A54E@buechse.de> Or you put your project on Sourceforge and use this: http://sourceforge.net/docs/compile_farm#hosts On 24.07.2006, at 02:14, Dr. Douglas Lyon wrote: > Hi All, > The present JNLP distro that I use: >>> >>> >> download="eager" /> >>> >> > > Works for Macs using G3 and G4's. I have not tested > this with an i386 mac, as I do not have one. And it only works > with i386 based linux... > > As far as architecture goes: > > > > Allows for a chip arch, and this might address your question. > > The real bottleneck is that you need one of everything to test a > deployment, > or you have to know a bunch of people (like on this list!) to do a > proper test. > > Cheers! > - Doug > > >> Op zondag 23 juli 2006 14:58, schreef Dr. Douglas Lyon: >>> Hi All, >>> Yes, I do have a download, as to the question of "huge": >>> ls -al native.jar >>> -rw-rw-r-- 1 lyon lyon 28795 Aug 12 2005 native.jar >>> 28kbytes is not really huge, right? >>> In fact, if you uncompress the jar, you get: >>> -rw-rw-r-- 1 lyon lyon 15487 Jul 23 08:46 librxtxParallel.so >>> -rw-rw-r-- 1 lyon lyon 55564 Jul 23 08:46 librxtxSerial.so >>> Which is almost 80kbytes, so the jar is 40% of the native libs >>> size, and >>> it is signed. >>> At least on the Linux version, it is smaller. I did not check the >>> other versions. >>> >>> And with java web start, the JNLP only downloads the native jar >>> if it is >>> new or changed. >>> And it only downloads the native jar used for the target platform. >>> >>> Here is how the jnlp looks, FYI... >>> >> codebase="http://show.docjava.com:8086/book/cgij/code/ >>> jnlp/"> >>> >>> addbk.JAddressBook.Main >>> DocJava, Inc. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> download="eager" /> >>> >>> >>> >>> >>> >> download="lazy" /> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I have been playing around with "eager" and "lazy" directives, >>> but I can't really tell the difference. >>> >>> Cheers! >>> - Doug >> >> That is a nice sollution. >> >> Is there a tag for the architecture too becouse now you assume >> i386 and that >> is of course not necesairy true. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From joachim at buechse.de Mon Jul 24 02:13:15 2006 From: joachim at buechse.de (Joachim Buechse) Date: Mon, 24 Jul 2006 10:13:15 +0200 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: References: <8BCF406B-5A6E-4588-AF94-935A0D238E99@buechse.de> Message-ID: <939306BB-2AEE-4D20-906E-9A9B40C76125@buechse.de> The pthread_kill is followed by a sleep. When the sleep returns the structure is damaged. I did not find the source that overwrites the closing field - it is correctly set by the exiting drain thread. But something overwrites it afterwards. I currently believe that this existed for some time but was never seen because the previous versions did not rely on the structure to be in good shape when tearing down connections. However I may be completely wrong and it is an OSX problem. To help me find the source, it would be nice to get some indications what the 2 debug lines I suggested return on other platforms. Joachim On 24.07.2006, at 05:27, Trent Jarvi wrote: > On Sat, 22 Jul 2006, Joachim Buechse wrote: > >> I just discovered a strange error in RXTX on OSX. SerialDemo.java >> manages to corrupt the event_info_structure by a simple >> OpenPort,ClosePort - this could be in relation to the deadlock >> problem that was reported recently. >> >> Could anyone try to reproduce this on Solaris or some other system >> which is neither WIN32 nor Linux (ie which uses a drain thread). >> >> In SerialImp.c : RXTXPort(interruptEventLoop) >> >> Apparently the event_info_structure gets corrupted shortly after >> >> pthread_kill(index->drain_tid, SIGABRT); >> >> In particular, the index->closing flag gets overwritten by a pointer >> value. > > Hi Joachim > > Interesting. I did run many tests with that code on may OSs. To > be fair, > the tests are just starting to get into good shape again. I'm still > tagging releases with a bit of feel and not enough process. I'll > look at > this some more tomorrow night. > > The SIGABRT was added recently as part of the close speedups. > Thats from > memory. I can provide the exact patch that introduced that tomorrow. > > -- > Trent Jarvi > tjarvi at qbang.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From pascal at quies.net Mon Jul 24 05:58:21 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 13:58:21 +0200 Subject: [Rxtx] =?iso-8859-1?q?NativeLibraryManager_-_A_general_solution_a?= =?iso-8859-1?q?n_to_old=09problem=2E?= In-Reply-To: <44C3AA47.4060003@cox.net> References: <44C3AA47.4060003@cox.net> Message-ID: <200607241358.21366.pascal@quies.net> Op zondag 23 juli 2006 18:56, schreef Gregg Wonderly: > Dr. Douglas Lyon wrote: > > The Class.forName is a static method. Therefore > > myClass.forName Should be Class.forName and > > myClass becomes an unused parameter. > > Or better yet, make that parameter a context classloader and call > > Class.forName( classname, classloader); > > so that the location of the codebase for loading classes can be separate > from the applications classpath. I agree. -------------- next part -------------- A non-text attachment was scrubbed... Name: CommunicationAPI.java Type: text/x-java Size: 10719 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20060724/693f269d/CommunicationAPI-0343.bin From pascal at quies.net Mon Jul 24 06:05:53 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 14:05:53 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: References: <200607240210.45992.pascal@quies.net> Message-ID: <200607241405.53456.pascal@quies.net> Op maandag 24 juli 2006 04:49, schreef Trent Jarvi: > > @Trent > > Would you include this class afther any possible comments in the > > distribution? > > Hi Pascal, > > It would appear to me that this is a tool for using the API, not an API. > So perhaps the classname is not the best choice. > > The class also has a main which would not make a great deal of sense to > include in the library to me. It would make a nice example for the > contrib directory or a new utility directory though. Documentation of its > availability in the main document could make it stand out from the other > contrib files. The name-change and the removal of main() would ofcourse be no problem. You really don't want to distribute binaries, huh? How can the developers of RXTX know whether it works on a machine they don't have? Anyway, I don't see anotherway to get a version of the extension "that just works" than to build my own distribution. :@ I also can't believe that nobody on this list has binaries for official supported platforms like Windows IA64 and Windows x86_64 unless the build fails on these platforms (which would be nice to know). http://java.sun.com/j2se/1.4.2/system-configurations.html http://java.sun.com/j2se/1.5.0/system-configurations.html From pascal at quies.net Mon Jul 24 06:08:45 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 14:08:45 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <106C7BEC-EC26-4A05-8E94-61E2C9F2A54E@buechse.de> References: <106C7BEC-EC26-4A05-8E94-61E2C9F2A54E@buechse.de> Message-ID: <200607241408.45956.pascal@quies.net> Op maandag 24 juli 2006 09:33, schreef Joachim Buechse: > Or you put your project on Sourceforge and use this: > > http://sourceforge.net/docs/compile_farm#hosts That's nice. :) I'll host a distribution on Sourceforge real soon. HP also has a such a facility for PA-RISC and IA64 architectures at http://www.testdrive.hp.com/ The other day I was thinking about building a big bittorrent with Qemu images for developers. The number of platforms seems impressive: http://qemu.org/status.html With each image compressed with bzip2 a clean installation of OpenBSD and FreeBSD and a Debian Woody + gmake + gcc for each Qemu platform will take about 1.5GB. From lyon at docjava.com Mon Jul 24 07:07:02 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 24 Jul 2006 09:07:02 -0400 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060724082455.038aa518@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: Hi All, There has been a lot of discussion regarding RS485. Let me see if I can summarize this, please correct me if I am wrong; I am deliberately ignoring connector and electrical issues, focusing, instead, on protocol and software issues. Also, I have never used RS485, and I don't know much about it. 1. Serial ports that claim RS232 are typically used in the data link layer of the OSI model of networking. Basically, this means that they work with a point-to-point protocol and are meant to connect two devices. 2. Within the RS232 standard there are framing bits (start and stop bits) and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. Thats' it. 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) you do it in software, not in the RS232 standard. 4. RS485 is different from RS232 in that it is in the Network Layer of the OSI model of networking. 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in a factory). RS-485 is similar to RS-422, but RS-422 allows just one driver with multiple receivers whereas RS-485 supports multiple drivers and receivers. 6. RS-485 is a serial bus with multiple nodes and thus must handle network link layer protocols. By using high-impedance receivers, you can have as many as 256 nodes. 7. The RS-485 can be implemented with RXTX in the core and a layer of software on top to handle media access control (MAC sublayer). There are also hardware converters. http://www.rs485.com/pconverters.html for example. However, some of these require software control. There is some support in the form of the Rs485.java class, in RXTX. 8. The RS-485 specification will add to the size of the JSR 9. Javax.comm specification, version 2.0 (the Real OLD version) says: This version of the Java communications API contains support for RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not mentioned. 10. DO people want to add RS485 to a new JSR? Would it make sense for the RS-485 people to speak up now? Please let me know if you think my summary is wrong. Thanks! - Doug >At 18:31 20/07/2006, Trent Jarvi wrote: >> > PROJECT SCOPE: >> > ------------- >> > >> > Also, we should think carefully about what the scope of >> > this project would be. Should it be javax."comm" which >> > handles both serial and parallel (is parallel going by the >> > wayside). Should it be split into two project: >> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >> > >> > Should we differentiate between single-ended serial >> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >> > quasi-multidrop and full multidrop busses such as >> > EIA422, EIA432 and EIA485? If we really were to >> > add I2C support to the API, we'd have to delve into >> > the semantics more, because there could be some >> > implicit decoding of the bus the API users would >> > want to see. >> > >> >>Hi Paul >> >>The way RXTX works, which is a fair representation of the people using the >>API, is complete support for RIA232, minimal support for IEEE1284. From >>what I understand, Sun was going along the same lines. If we combined >>both projects, we would have half a parallel port implementation. I see >>maybe 4 requests for features not in the parallel support a year. >> >>The other protocols should not be limited by a JSR which is going to be >>focused upon serial port interests. The IEA485 hacks in RXTX along with >>I2C and Raw should _not_ be considered a strong basis for extending the >>API to cover these protocols. If people want to do real implementations, >>they should not face a 'standard' which wasnt really focused upon their >>interests. I think we understand the parallel port issues fairly well but >>have not implemented many features and I don't know if we would. > >I agree with all of this. API requirements for I2C, SPI, etc. are very >different from those for RS232/485/422. Our embedded Java platform has >APIs for all of these and more and they don't share a lot apart from the >fact that they all use Input/OutputStreams (and in the case of SPI you >still need to cater with the fact that every time you want to read you >must also write to the device.) > >If I was to design javax.comm from scratch, I think I would focus on >serial ports exclusively (== whatever the underlying OS represents as >serial ports). Even parallel is a bit out of place IMHO, although I >understand it needs to stay for backwards compatibility. > > >>So a versatile API is favorable but I do not think we have the proper >>community to represent much more than Serial. > >Yes, I think the same. > >Guillermo >-- >Guillermo Rodriguez Garcia > >Snijder Micro Systems phone +31-493-351020 >G. Rodriguez Garcia fax +31-493-351530 >Visser 25 email guille at sms.nl >NL5751 BL Deurne >The Netherlands http://www.snijder.com > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From naranjo.manuel at gmail.com Mon Jul 24 07:46:55 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Mon, 24 Jul 2006 10:46:55 -0300 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: <44C4CF4F.1080706@gmail.com> Doug: I do not think that RS485 is a must by now. I do think we must make a JSR to standarize a bit Serial Ports accessing. Maybe we can make a JSR just for serial ports, and then start trying with other kind of ports and make others JSR. Or try to expand our first JSR, but I trully do not know if that can be made. About other ports besides RS485, the others I2C, SPI, etc, run at a very low level, maybe too close to the processor for Java. I do not know if Java is fast enough to access this ports, even more as this ports depends directly from the architecture, the write once run every way of Java is somekind useless at this level, so I do not think this is suitable for us. Regards, Manuel > Hi All, > There has been a lot of discussion regarding RS485. > > Let me see if I can summarize this, please correct me if I am wrong; > I am deliberately ignoring connector and electrical issues, focusing, > instead, on protocol and software issues. Also, I have never used > RS485, and I don't know much about it. > > 1. Serial ports that claim RS232 are typically used in > the data link layer of the OSI model of networking. Basically, this means > that they work with a point-to-point protocol and are meant to connect two > devices. > > 2. Within the RS232 standard there are framing bits (start and stop bits) > and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. > Thats' it. > > 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) > you do it in software, not in the RS232 standard. > > 4. RS485 is different from RS232 in that it is in the Network Layer of > the OSI model of networking. > > 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > a factory). > RS-485 is similar to RS-422, but RS-422 allows just one driver with > multiple receivers whereas RS-485 supports multiple drivers and > receivers. > > 6. RS-485 is a serial bus with multiple nodes and thus must handle network > link layer protocols. By using high-impedance receivers, you can have > as many as 256 nodes. > > 7. The RS-485 can be implemented with RXTX in the core and a layer of software > on top to handle media access control (MAC sublayer). There are also > hardware converters. > http://www.rs485.com/pconverters.html for example. However, some of > these require software control. There is some support in the form of > the Rs485.java class, > in RXTX. > > 8. The RS-485 specification will add to the size of the JSR > > 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > This version of the Java communications API contains support for > RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > mentioned. > > 10. DO people want to add RS485 to a new JSR? > > Would it make sense for the RS-485 people to speak up now? > Please let me know if you think my summary is wrong. > > Thanks! > - Doug > > > > > > >> At 18:31 20/07/2006, Trent Jarvi wrote: >> >>> > PROJECT SCOPE: >>> > ------------- >>> > >>> > Also, we should think carefully about what the scope of >>> > this project would be. Should it be javax."comm" which >>> > handles both serial and parallel (is parallel going by the >>> > wayside). Should it be split into two project: >>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>> > >>> > Should we differentiate between single-ended serial >>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>> > quasi-multidrop and full multidrop busses such as >>> > EIA422, EIA432 and EIA485? If we really were to >>> > add I2C support to the API, we'd have to delve into >>> > the semantics more, because there could be some >>> > implicit decoding of the bus the API users would >>> > want to see. >>> > >>> >>> Hi Paul >>> >>> The way RXTX works, which is a fair representation of the people using the >>> API, is complete support for RIA232, minimal support for IEEE1284. From >>> what I understand, Sun was going along the same lines. If we combined >>> both projects, we would have half a parallel port implementation. I see >>> maybe 4 requests for features not in the parallel support a year. >>> >>> The other protocols should not be limited by a JSR which is going to be >>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>> I2C and Raw should _not_ be considered a strong basis for extending the >>> API to cover these protocols. If people want to do real implementations, >>> they should not face a 'standard' which wasnt really focused upon their >>> interests. I think we understand the parallel port issues fairly well but >>> have not implemented many features and I don't know if we would. >>> >> I agree with all of this. API requirements for I2C, SPI, etc. are very >> different from those for RS232/485/422. Our embedded Java platform has >> APIs for all of these and more and they don't share a lot apart from the >> fact that they all use Input/OutputStreams (and in the case of SPI you >> still need to cater with the fact that every time you want to read you >> must also write to the device.) >> >> If I was to design javax.comm from scratch, I think I would focus on >> serial ports exclusively (== whatever the underlying OS represents as >> serial ports). Even parallel is a bit out of place IMHO, although I >> understand it needs to stay for backwards compatibility. >> >> >> >>> So a versatile API is favorable but I do not think we have the proper >>> community to represent much more than Serial. >>> >> Yes, I think the same. >> >> Guillermo >> -- >> Guillermo Rodriguez Garcia >> >> Snijder Micro Systems phone +31-493-351020 >> G. Rodriguez Garcia fax +31-493-351530 >> Visser 25 email guille at sms.nl >> NL5751 BL Deurne >> The Netherlands http://www.snijder.com >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From gergg at cox.net Mon Jul 24 07:51:53 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 08:51:53 -0500 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <200607240210.45992.pascal@quies.net> References: <8C36C125-6081-41FE-A4E5-08AFB3DA7132@buechse.de> <200607232134.17451.pascal@quies.net> <200607240210.45992.pascal@quies.net> Message-ID: <44C4D079.80609@cox.net> Pascal S. de Kloe wrote: > @Gregg > You can extract the necessary libraries during the installation with the > extractNativeLibraries method to the application directory so they get loaded > automatically. Is that good enough? If you start the JVM with -Djava.security.manager what permissions are required? Can you send me a policy that is applicable so that I can review what permissions are being required? Gregg Wonderly From gergg at cox.net Mon Jul 24 07:54:22 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 08:54:22 -0500 Subject: [Rxtx] jcp and jsr In-Reply-To: <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> References: <200607212343.40882.pascal@quies.net> <44C25370.9070506@cox.net> <200607221932.04194.pascal@quies.net> <2B7CC0BE-919A-4A63-985A-1E44085F1FF5@buechse.de> Message-ID: <44C4D10E.50604@cox.net> Joachim Buechse wrote: > It seems that Gregg's suggestion could be implemented without > changing the existing "user-level" API of javax.comm. Most of the > information suggested for HardwarePort is not accessible from within > the POSSIX-API but this is a different story. Sorry for the late reply here. My intent was this. That there could be a low level port/device SPI that could be put in place once, and then overtime we could layer other APIs, including an updated javax.comm which would make use of this SPI. Gregg Wonderly From cmalan at lhar.co.za Mon Jul 24 08:04:01 2006 From: cmalan at lhar.co.za (Christo Malan) Date: Mon, 24 Jul 2006 16:04:01 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: <44C4D351.603@lhar.co.za> Hi I don't think RS-485 belong in rxtx, the scope of the spec is not wide enough as it only specify the electrical layer. Their is no data protocol recommended or defined. This mean that we have no idea when to sample for a bit, how long is a bit and how many bits before we can say new data is available. Christo Dr. Douglas Lyon wrote: > Hi All, > There has been a lot of discussion regarding RS485. > > Let me see if I can summarize this, please correct me if I am wrong; > I am deliberately ignoring connector and electrical issues, focusing, > instead, on protocol and software issues. Also, I have never used > RS485, and I don't know much about it. > > 1. Serial ports that claim RS232 are typically used in > the data link layer of the OSI model of networking. Basically, this means > that they work with a point-to-point protocol and are meant to connect two > devices. > > 2. Within the RS232 standard there are framing bits (start and stop bits) > and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. > Thats' it. > > 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) > you do it in software, not in the RS232 standard. > > 4. RS485 is different from RS232 in that it is in the Network Layer of > the OSI model of networking. > > 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > a factory). > RS-485 is similar to RS-422, but RS-422 allows just one driver with > multiple receivers whereas RS-485 supports multiple drivers and > receivers. > > 6. RS-485 is a serial bus with multiple nodes and thus must handle network > link layer protocols. By using high-impedance receivers, you can have > as many as 256 nodes. > > 7. The RS-485 can be implemented with RXTX in the core and a layer of software > on top to handle media access control (MAC sublayer). There are also > hardware converters. > http://www.rs485.com/pconverters.html for example. However, some of > these require software control. There is some support in the form of > the Rs485.java class, > in RXTX. > > 8. The RS-485 specification will add to the size of the JSR > > 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > This version of the Java communications API contains support for > RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > mentioned. > > 10. DO people want to add RS485 to a new JSR? > > Would it make sense for the RS-485 people to speak up now? > Please let me know if you think my summary is wrong. > > Thanks! > - Doug > > > > > > >> At 18:31 20/07/2006, Trent Jarvi wrote: >> >>> > PROJECT SCOPE: >>> > ------------- >>> > >>> > Also, we should think carefully about what the scope of >>> > this project would be. Should it be javax."comm" which >>> > handles both serial and parallel (is parallel going by the >>> > wayside). Should it be split into two project: >>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>> > >>> > Should we differentiate between single-ended serial >>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>> > quasi-multidrop and full multidrop busses such as >>> > EIA422, EIA432 and EIA485? If we really were to >>> > add I2C support to the API, we'd have to delve into >>> > the semantics more, because there could be some >>> > implicit decoding of the bus the API users would >>> > want to see. >>> > >>> >>> Hi Paul >>> >>> The way RXTX works, which is a fair representation of the people using the >>> API, is complete support for RIA232, minimal support for IEEE1284. From >>> what I understand, Sun was going along the same lines. If we combined >>> both projects, we would have half a parallel port implementation. I see >>> maybe 4 requests for features not in the parallel support a year. >>> >>> The other protocols should not be limited by a JSR which is going to be >>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>> I2C and Raw should _not_ be considered a strong basis for extending the >>> API to cover these protocols. If people want to do real implementations, >>> they should not face a 'standard' which wasnt really focused upon their >>> interests. I think we understand the parallel port issues fairly well but >>> have not implemented many features and I don't know if we would. >>> >> I agree with all of this. API requirements for I2C, SPI, etc. are very >> different from those for RS232/485/422. Our embedded Java platform has >> APIs for all of these and more and they don't share a lot apart from the >> fact that they all use Input/OutputStreams (and in the case of SPI you >> still need to cater with the fact that every time you want to read you >> must also write to the device.) >> >> If I was to design javax.comm from scratch, I think I would focus on >> serial ports exclusively (== whatever the underlying OS represents as >> serial ports). Even parallel is a bit out of place IMHO, although I >> understand it needs to stay for backwards compatibility. >> >> >> >>> So a versatile API is favorable but I do not think we have the proper >>> community to represent much more than Serial. >>> >> Yes, I think the same. >> >> Guillermo >> -- >> Guillermo Rodriguez Garcia >> >> Snijder Micro Systems phone +31-493-351020 >> G. Rodriguez Garcia fax +31-493-351530 >> Visser 25 email guille at sms.nl >> NL5751 BL Deurne >> The Netherlands http://www.snijder.com >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > From pascal at quies.net Mon Jul 24 08:19:03 2006 From: pascal at quies.net (Pascal S. de Kloe) Date: Mon, 24 Jul 2006 16:19:03 +0200 Subject: [Rxtx] NativeLibraryManager In-Reply-To: <44C4D079.80609@cox.net> References: <200607240210.45992.pascal@quies.net> <44C4D079.80609@cox.net> Message-ID: <200607241619.04053.pascal@quies.net> Op maandag 24 juli 2006 15:51, schreef Gregg Wonderly: > Pascal S. de Kloe wrote: > > @Gregg > > You can extract the necessary libraries during the installation with the > > extractNativeLibraries method to the application directory so they get > > loaded automatically. Is that good enough? > > If you start the JVM with -Djava.security.manager what permissions are > required? Can you send me a policy that is applicable so that I can review > what permissions are being required? Just look at the javadoc in CommunicationAPI.java for SecurityExceptions. ;) From gergg at cox.net Mon Jul 24 08:21:49 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 09:21:49 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4CF4F.1080706@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> Message-ID: <44C4D77D.5080200@cox.net> Manuel Francisco Naranjo wrote: > Doug: > I do not think that RS485 is a must by now. I do think we must make a > JSR to standarize a bit Serial Ports accessing. Maybe we can make a JSR > just for serial ports, and then start trying with other kind of ports > and make others JSR. Or try to expand our first JSR, but I trully do > not know if that can be made. I think that anyone aimed at the javax.comm space should be interested in creating a hardware access SPI first. This is the predominate stumbling block for java having access to various hardware devices. The more we can promote as a standard, the more we can expect consistency and availability! > About other ports besides RS485, the others I2C, SPI, etc, run at a very > low level, maybe too close to the processor for Java. SPI (not service provider interface) is a great protocol for disparet systems because the clocking is synchronous based on the fastest speed available at each end. This means that you can do SPI, today, in java by connecting serial port signal lines, or parallel port data lines to an SPI device, and bit banging the protocol. It won't be lightening fast, but it will be very much functional. What would make the most since is the ability for applications to designate various signalling line sources such as serial signaling lines and parallel port data lines as SPI data, slave select and clock signals, and plug those into an existing API. public class SPISlaveSelectLine { public SPISlaveSelectLine( int slave, SignalPort sp ) { ... } } public class SPIClockLine { public SPIClockLine( SignalPort sp ) { ... } } public class SPIDataLine { public SPIDataLine( SignalPort sp ) { ... } } I'd really like to see the embedded systems community take up this task and push these kinds of things forward. Having standard APIs would make it possible to run your software on aJile's AJ processors, the Muvium PIC environment, javacard, J2ME, etc. Imagine being able to plug a cellphone into the wall, attach a cable which has signalling lines and presto a remote terminal for monitoring and control. Data collection is a very needed capability as the next wave of technology evolution. The Java platform is not enabled with APIs to do this trivially yet. So, it doesn't look viable to many... Gregg Wonderly From guille at sms.nl Mon Jul 24 08:37:21 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 16:37:21 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> Message-ID: <1153751841.44c4db21de4bb@webmail.eatserver.nl> Hi Doug, Some comments below. Quoting "Dr. Douglas Lyon" : > Hi All, > There has been a lot of discussion regarding RS485. > > Let me see if I can summarize this, please correct me if I am wrong; > I am deliberately ignoring connector and electrical issues, focusing, > instead, on protocol and software issues. Also, I have never used > RS485, and I don't know much about it. > > 1. Serial ports that claim RS232 are typically used in > the data link layer of the OSI model of networking. Basically, this means > that they work with a point-to-point protocol and are meant to connect two > devices. It is actually physical + link (layers 1 and 2 of the OSI model), but yes, this is essentially right. > > 2. Within the RS232 standard there are framing bits (start and stop bits) > and error control bits (parity). The flow control is xon-xoff or DTR, CTS, > RTS. Thats' it. I'm not even sure that the RS232 standard talks about xon-xoff and such, I think it does not do much more than defining the electrical signals. Also note that RS232 was originally defined for the DTE-DCE interface (e.g. a device such as a modem connected to a computer). The current use of RS232 as a "general purpose" point to point link is a generalization of the RS232 standard. > > 3. If you want more than that from RS232 (forward error correction, ARQ, > etc.) > you do it in software, not in the RS232 standard. > > 4. RS485 is different from RS232 in that it is in the Network Layer of > the OSI model of networking. I would not put it that way. RS485 is very similar to RS232 with three main differences: - Only tx/rx, no extra signals such as DTR, RTS, CTS, etc (but then many "RS232" serial ports don't have them either) - Different electrical specs (which do not concern us here) - Multidrop and only one node talks at a given time (half duplex) But it does not define addresses (many RS485-based protocol use addresses for the nodes but that's not part of the RS485 standard), routing, etc. For software developers it still looks like a serial port (which it is!) except for the half-duplex part. More on this below. So RS485 is still about layers 1 and 2, same as RS232. I think all of this could be easier if we talk about UARTs instead of "RS232/RS485/RS422". All of these three are typically UARTs with some sort of buffer to get the electrical levels right: RS232 interface == UART + RS232 buffer/transceiver RS485 interface == UART + RS485 buffer/transceiver RS422 interface == UART + RS422 buffer/transceiver > > 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > a factory). > RS-485 is similar to RS-422, but RS-422 allows just one driver with > multiple receivers whereas RS-485 supports multiple drivers and > receivers. RS422 is exactly the same as RS485 except that it uses 4 wires instead of 2 wires so it can be full duplex again (but again this depends on the protocol you layer on top) > > 6. RS-485 is a serial bus with multiple nodes and thus must handle network > link layer protocols. By using high-impedance receivers, you can have > as many as 256 nodes. > > 7. The RS-485 can be implemented with RXTX in the core and a layer of > software > on top to handle media access control (MAC sublayer). There are also > hardware converters. > http://www.rs485.com/pconverters.html for example. However, some of > these require software control. There is some support in the form of > the Rs485.java class, > in RXTX. > > 8. The RS-485 specification will add to the size of the JSR > > 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > This version of the Java communications API contains support for > RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > mentioned. > > 10. DO people want to add RS485 to a new JSR? > > Would it make sense for the RS-485 people to speak up now? > Please let me know if you think my summary is wrong. Basically, for a software developer the only difference between RS485 and RS232 is the half-duplex nature of RS485, which means that you cannot receive and send at the same time. This has some implications depending on how RS485 is implemented in hardware, and on the (application) protocol defined on top of RS485. As I said, a RS485 interface is normally implemented using a standard UART plus a RS485 buffer/transceiver. RS485 buffers/transceivers can be in transmit mode or in receive mode. In a given RS485 bus, only one node should be in transmit mode at any given time, with the rest of the nodes 'listening' until it is their turn to transmit (and it is the application level protocol the one defines who should transmit next.) The RS485 chips used as buffers/transceivers normally have a control pin that is used to switch them into transmit or receive mode. There are typically three ways to handle this: 1. One of the control signals from the UART, such as RTS, DTR, etc. is connected to this control pin. The software must explicitly toggle this signal in order to switch the RS485 buffer/transceiver into transmit or receive mode. This puts a lot of burden on the software side and is sometimes unreliable because of complex timing issues as well as issues with buffering at the device driver level, but it is still a popular solution. 2. The UART itself knows about RS485 and can be configured to control the RS485 buffer/transceiver automatically, without any sort of software intervention. This is a very good solution since it is transparent to the software. However most UARTs don't know about RS485. 3. Standard UART + some custom hardware to control the direction pin. This is also transparent to the software. RS232/RS485 converters are an example of this approach. Implications for the software: For 3/ the software does not need to do anything special. For 2/ all you need is some sort of mechanism to tell the UART to enter RS485-mode (typically a ioctlex). For 1/ there is no simple solution. The timing issues make it difficult to implement this sort of mechanism in user space so it is often done at the device driver level. If this is the case, then all one needs is a mechanism to tell the driver to enter RS485-mode (again, a ioctlex). If this is NOT the case, then the application will need to take care. To do this more or less reliably, you would probably need a couple of things: - Some way to disable software buffering (and FIFOs if possible) - Some way to poll the UART's serial transmit register so that you can determine exactly when all data has been sent (many UARTs don't even support this) and switch to receive mode. - High resolution timers. - Real-time capabilities. Pretty strict requirements as you can see, which is why this approach never works very well except for very specific applications. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From naranjo.manuel at gmail.com Mon Jul 24 08:39:15 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Mon, 24 Jul 2006 11:39:15 -0300 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D77D.5080200@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> Message-ID: <44C4DB93.8080008@gmail.com> Gregg: Thanks for taking me out of the dark ;). Trully I did not know that SPI was an underlaying level of Serial ports, and Parallel ports. I give back what I said. I also would like to see my cell phone plug to every were, and be able to program it with java, is just that I do not know if we are going to get ourselves in a very almost unfinishable task. Regards, Manuel > Manuel Francisco Naranjo wrote: > >> Doug: >> I do not think that RS485 is a must by now. I do think we must make a >> JSR to standarize a bit Serial Ports accessing. Maybe we can make a JSR >> > > just for serial ports, and then start trying with other kind of ports > > and make others JSR. Or try to expand our first JSR, but I trully do > > not know if that can be made. > > I think that anyone aimed at the javax.comm space should be interested in > creating a hardware access SPI first. This is the predominate stumbling > block for java having access to various hardware devices. The more we can > promote as a standard, the more we can expect consistency and availability! > > >> About other ports besides RS485, the others I2C, SPI, etc, run at a very >> low level, maybe too close to the processor for Java. >> > > SPI (not service provider interface) is a great protocol for disparet systems > because the clocking is synchronous based on the fastest speed available at each > end. This means that you can do SPI, today, in java by connecting serial port > signal lines, or parallel port data lines to an SPI device, and bit banging the > protocol. It won't be lightening fast, but it will be very much functional. > What would make the most since is the ability for applications to designate > various signalling line sources such as serial signaling lines and parallel port > data lines as SPI data, slave select and clock signals, and plug those into an > existing API. > > public class SPISlaveSelectLine { > public SPISlaveSelectLine( int slave, SignalPort sp ) { > ... > } > } > > public class SPIClockLine { > public SPIClockLine( SignalPort sp ) { > ... > } > } > > public class SPIDataLine { > public SPIDataLine( SignalPort sp ) { > ... > } > } > > I'd really like to see the embedded systems community take up this task and push > these kinds of things forward. Having standard APIs would make it possible to > run your software on aJile's AJ processors, the Muvium PIC environment, > javacard, J2ME, etc. Imagine being able to plug a cellphone into the wall, > attach a cable which has signalling lines and presto a remote terminal for > monitoring and control. > > Data collection is a very needed capability as the next wave of technology > evolution. The Java platform is not enabled with APIs to do this trivially yet. > So, it doesn't look viable to many... > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From guille at sms.nl Mon Jul 24 08:41:21 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 16:41:21 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D351.603@lhar.co.za> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: <1153752081.44c4dc11eedf3@webmail.eatserver.nl> Quoting Christo Malan : > Hi > > I don't think RS-485 belong in rxtx, the scope of the spec is not wide > enough as it only specify the electrical layer. Their is no data > protocol recommended or defined. RS485 is exactly at the same level as RS232, no more and no less. > This mean that we have no idea when to > sample for a bit, how long is a bit and how many bits before we can say > new data is available. A "RS485 serial port" is just a UART whose output complies with the RS485 electrical spec, just as a "RS232 serial port" is just a UART whose output complies with the RS232 electrical spec. Bit times, sampling intervals, character structure etc. are the same for both protocols... Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From tjarvi at qbang.org Mon Jul 24 08:44:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 24 Jul 2006 08:44:53 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D351.603@lhar.co.za> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: A JSR/JCP would not just involve RXTX. In fact it would be very nice to have others with expertise in various areas like I2C, IrDA, RS485, RS422, ... involved. Within the RXTX community, I do not think we have enough depth to tackle RS485 alone. I'm aware of some of the low level issues but to be honest, I've never actually used it. The RS485 classes in RXTX are more like notes to myself about the issues involved without hardware solutions. In operating systems like Linux, this may be much less of an issue in the future. Linux is putting realtime patches now in the kernels which could make RS485 over EIA232 possible. This is probably the last chance RS485 has to get into a published spec for a long time though. Right now, I do not think its reasonable to include it in the process. Others could make that less of a problem. On Mon, 24 Jul 2006, Christo Malan wrote: > Hi > > I don't think RS-485 belong in rxtx, the scope of the spec is not wide > enough as it only specify the electrical layer. Their is no data > protocol recommended or defined. This mean that we have no idea when to > sample for a bit, how long is a bit and how many bits before we can say > new data is available. > > Christo > > Dr. Douglas Lyon wrote: >> Hi All, >> There has been a lot of discussion regarding RS485. >> >> Let me see if I can summarize this, please correct me if I am wrong; >> I am deliberately ignoring connector and electrical issues, focusing, >> instead, on protocol and software issues. Also, I have never used >> RS485, and I don't know much about it. >> >> 1. Serial ports that claim RS232 are typically used in >> the data link layer of the OSI model of networking. Basically, this means >> that they work with a point-to-point protocol and are meant to connect two >> devices. >> >> 2. Within the RS232 standard there are framing bits (start and stop bits) >> and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. >> Thats' it. >> >> 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) >> you do it in software, not in the RS232 standard. >> >> 4. RS485 is different from RS232 in that it is in the Network Layer of >> the OSI model of networking. >> >> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in >> a factory). >> RS-485 is similar to RS-422, but RS-422 allows just one driver with >> multiple receivers whereas RS-485 supports multiple drivers and >> receivers. >> >> 6. RS-485 is a serial bus with multiple nodes and thus must handle network >> link layer protocols. By using high-impedance receivers, you can have >> as many as 256 nodes. >> >> 7. The RS-485 can be implemented with RXTX in the core and a layer of software >> on top to handle media access control (MAC sublayer). There are also >> hardware converters. >> http://www.rs485.com/pconverters.html for example. However, some of >> these require software control. There is some support in the form of >> the Rs485.java class, >> in RXTX. >> >> 8. The RS-485 specification will add to the size of the JSR >> >> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: >> This version of the Java communications API contains support for >> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not >> mentioned. >> >> 10. DO people want to add RS485 to a new JSR? >> >> Would it make sense for the RS-485 people to speak up now? >> Please let me know if you think my summary is wrong. >> >> Thanks! >> - Doug >> >> >> >> >> >> >>> At 18:31 20/07/2006, Trent Jarvi wrote: >>> >>>> > PROJECT SCOPE: >>>> > ------------- >>>> > >>>> > Also, we should think carefully about what the scope of >>>> > this project would be. Should it be javax."comm" which >>>> > handles both serial and parallel (is parallel going by the >>>> > wayside). Should it be split into two project: >>>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>>> > >>>> > Should we differentiate between single-ended serial >>>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>>> > quasi-multidrop and full multidrop busses such as >>>> > EIA422, EIA432 and EIA485? If we really were to >>>> > add I2C support to the API, we'd have to delve into >>>> > the semantics more, because there could be some >>>> > implicit decoding of the bus the API users would >>>> > want to see. >>>> > >>>> >>>> Hi Paul >>>> >>>> The way RXTX works, which is a fair representation of the people using the >>>> API, is complete support for RIA232, minimal support for IEEE1284. From >>>> what I understand, Sun was going along the same lines. If we combined >>>> both projects, we would have half a parallel port implementation. I see >>>> maybe 4 requests for features not in the parallel support a year. >>>> >>>> The other protocols should not be limited by a JSR which is going to be >>>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>>> I2C and Raw should _not_ be considered a strong basis for extending the >>>> API to cover these protocols. If people want to do real implementations, >>>> they should not face a 'standard' which wasnt really focused upon their >>>> interests. I think we understand the parallel port issues fairly well but >>>> have not implemented many features and I don't know if we would. >>>> >>> I agree with all of this. API requirements for I2C, SPI, etc. are very >>> different from those for RS232/485/422. Our embedded Java platform has >>> APIs for all of these and more and they don't share a lot apart from the >>> fact that they all use Input/OutputStreams (and in the case of SPI you >>> still need to cater with the fact that every time you want to read you >>> must also write to the device.) >>> >>> If I was to design javax.comm from scratch, I think I would focus on >>> serial ports exclusively (== whatever the underlying OS represents as >>> serial ports). Even parallel is a bit out of place IMHO, although I >>> understand it needs to stay for backwards compatibility. >>> >>> >>> >>>> So a versatile API is favorable but I do not think we have the proper >>>> community to represent much more than Serial. >>>> >>> Yes, I think the same. >>> >>> Guillermo >>> -- >>> Guillermo Rodriguez Garcia >>> >>> Snijder Micro Systems phone +31-493-351020 >>> G. Rodriguez Garcia fax +31-493-351530 >>> Visser 25 email guille at sms.nl >>> NL5751 BL Deurne >>> The Netherlands http://www.snijder.com >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From guille at sms.nl Mon Jul 24 08:47:47 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 16:47:47 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D77D.5080200@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> Message-ID: <1153752467.44c4dd93c08f7@webmail.eatserver.nl> Hi Gregg, Quoting Gregg Wonderly : > SPI (not service provider interface) is a great protocol for disparet systems > > because the clocking is synchronous based on the fastest speed available at > each > end. This means that you can do SPI, today, in java by connecting serial > port > signal lines, or parallel port data lines to an SPI device, and bit banging > the > protocol. It won't be lightening fast, but it will be very much functional. [...] > I'd really like to see the embedded systems community take up this task and > push > these kinds of things forward. Having standard APIs would make it possible > to > run your software on aJile's AJ processors, the Muvium PIC environment, > javacard, J2ME, etc. Imagine being able to plug a cellphone into the wall, > attach a cable which has signalling lines and presto a remote terminal for > monitoring and control. As an embedded Java vendor, SNIJDER Micro Systems certainly sees the value of standardized APIs to talk to different types of communication buses including SPI, I2C, 1-Wire, etc., for embedded applications. However we think this has nothing to do with javax.comm. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From guille at sms.nl Mon Jul 24 09:05:22 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 17:05:22 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4DB93.8080008@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <44C4DB93.8080008@gmail.com> Message-ID: <1153753522.44c4e1b24f2e1@webmail.eatserver.nl> Quoting Manuel Francisco Naranjo : > Gregg: > Thanks for taking me out of the dark ;). Trully I did not know that SPI > was an underlaying level of Serial ports, and Parallel ports. In fact it isn't; it is just another serial protocol, just like I2C. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From jredman at ergotech.com Mon Jul 24 09:29:10 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 09:29:10 -0600 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: <44C4E746.8070808@ergotech.com> Folks, The RS232/485/422/etc. etc. is a complete red herring (http://en.wikipedia.org/wiki/Red_herring in case you don't know the expression). The differences between the two are at the electrical level, not at the RXTX level. I'll provide a concrete example and see if we can get away from this issue. There's an industrial serial communications standard - Modbus. Modbus capable devices are very common and can be purchased, generally, with an RS232 or a 485 or a 422 - you decide when you buy it. Some actually provide both 232 and 485 on the same connector. Now, within our environment you configure a Modbus JavaBean. One of the parameters is the "Station Number". The station number is required for both RS232 and RS485 devices - the protocol doesn't change based on the electrical requirements of the device. Now I can configure an application talking to, say, station 2 and station 7. I can add an RS485 converter to the computer serial port and put two physical devices there, configured as station 2 and station 7 and everything works fine. HOWEVER, over RS232 some devices will respond to both station 2 and station 7. So THE SAME APPLICATION will work with both 232 and 485. The only changes are hardware related. This same behavior is true of a number of 485 "networks" and many industrial devices that have 485 interfaces have 232 as an option using the same protocol. Jim Trent Jarvi wrote: > A JSR/JCP would not just involve RXTX. In fact it would be very nice to > have others with expertise in various areas like I2C, IrDA, RS485, RS422, > ... involved. > > Within the RXTX community, I do not think we have enough depth to tackle > RS485 alone. I'm aware of some of the low level issues but to be honest, > I've never actually used it. The RS485 classes in RXTX are more like > notes to myself about the issues involved without hardware solutions. In > operating systems like Linux, this may be much less of an issue in the > future. Linux is putting realtime patches now in the kernels which could > make RS485 over EIA232 possible. > > This is probably the last chance RS485 has to get into a published spec > for a long time though. Right now, I do not think its reasonable to > include it in the process. Others could make that less of a problem. > > On Mon, 24 Jul 2006, Christo Malan wrote: > >> Hi >> >> I don't think RS-485 belong in rxtx, the scope of the spec is not wide >> enough as it only specify the electrical layer. Their is no data >> protocol recommended or defined. This mean that we have no idea when to >> sample for a bit, how long is a bit and how many bits before we can say >> new data is available. >> >> Christo >> >> Dr. Douglas Lyon wrote: >>> Hi All, >>> There has been a lot of discussion regarding RS485. >>> >>> Let me see if I can summarize this, please correct me if I am wrong; >>> I am deliberately ignoring connector and electrical issues, focusing, >>> instead, on protocol and software issues. Also, I have never used >>> RS485, and I don't know much about it. >>> >>> 1. Serial ports that claim RS232 are typically used in >>> the data link layer of the OSI model of networking. Basically, this means >>> that they work with a point-to-point protocol and are meant to connect two >>> devices. >>> >>> 2. Within the RS232 standard there are framing bits (start and stop bits) >>> and error control bits (parity). The flow control is xon-xoff or DTR, CTS, RTS. >>> Thats' it. >>> >>> 3. If you want more than that from RS232 (forward error correction, ARQ, etc.) >>> you do it in software, not in the RS232 standard. >>> >>> 4. RS485 is different from RS232 in that it is in the Network Layer of >>> the OSI model of networking. >>> >>> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in >>> a factory). >>> RS-485 is similar to RS-422, but RS-422 allows just one driver with >>> multiple receivers whereas RS-485 supports multiple drivers and >>> receivers. >>> >>> 6. RS-485 is a serial bus with multiple nodes and thus must handle network >>> link layer protocols. By using high-impedance receivers, you can have >>> as many as 256 nodes. >>> >>> 7. The RS-485 can be implemented with RXTX in the core and a layer of software >>> on top to handle media access control (MAC sublayer). There are also >>> hardware converters. >>> http://www.rs485.com/pconverters.html for example. However, some of >>> these require software control. There is some support in the form of >>> the Rs485.java class, >>> in RXTX. >>> >>> 8. The RS-485 specification will add to the size of the JSR >>> >>> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: >>> This version of the Java communications API contains support for >>> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not >>> mentioned. >>> >>> 10. DO people want to add RS485 to a new JSR? >>> >>> Would it make sense for the RS-485 people to speak up now? >>> Please let me know if you think my summary is wrong. >>> >>> Thanks! >>> - Doug >>> >>> >>> >>> >>> >>> >>>> At 18:31 20/07/2006, Trent Jarvi wrote: >>>> >>>>>> PROJECT SCOPE: >>>>>> ------------- >>>>>> >>>>>> Also, we should think carefully about what the scope of >>>>>> this project would be. Should it be javax."comm" which >>>>>> handles both serial and parallel (is parallel going by the >>>>>> wayside). Should it be split into two project: >>>>>> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>>>>> >>>>>> Should we differentiate between single-ended serial >>>>>> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>>>>> quasi-multidrop and full multidrop busses such as >>>>>> EIA422, EIA432 and EIA485? If we really were to >>>>>> add I2C support to the API, we'd have to delve into >>>>>> the semantics more, because there could be some >>>>>> implicit decoding of the bus the API users would >>>>>> want to see. >>>>>> >>>>> Hi Paul >>>>> >>>>> The way RXTX works, which is a fair representation of the people using the >>>>> API, is complete support for RIA232, minimal support for IEEE1284. From >>>>> what I understand, Sun was going along the same lines. If we combined >>>>> both projects, we would have half a parallel port implementation. I see >>>>> maybe 4 requests for features not in the parallel support a year. >>>>> >>>>> The other protocols should not be limited by a JSR which is going to be >>>>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>>>> I2C and Raw should _not_ be considered a strong basis for extending the >>>>> API to cover these protocols. If people want to do real implementations, >>>>> they should not face a 'standard' which wasnt really focused upon their >>>>> interests. I think we understand the parallel port issues fairly well but >>>>> have not implemented many features and I don't know if we would. >>>>> >>>> I agree with all of this. API requirements for I2C, SPI, etc. are very >>>> different from those for RS232/485/422. Our embedded Java platform has >>>> APIs for all of these and more and they don't share a lot apart from the >>>> fact that they all use Input/OutputStreams (and in the case of SPI you >>>> still need to cater with the fact that every time you want to read you >>>> must also write to the device.) >>>> >>>> If I was to design javax.comm from scratch, I think I would focus on >>>> serial ports exclusively (== whatever the underlying OS represents as >>>> serial ports). Even parallel is a bit out of place IMHO, although I >>>> understand it needs to stay for backwards compatibility. >>>> >>>> >>>> >>>>> So a versatile API is favorable but I do not think we have the proper >>>>> community to represent much more than Serial. >>>>> >>>> Yes, I think the same. >>>> >>>> Guillermo >>>> -- >>>> Guillermo Rodriguez Garcia >>>> >>>> Snijder Micro Systems phone +31-493-351020 >>>> G. Rodriguez Garcia fax +31-493-351530 >>>> Visser 25 email guille at sms.nl >>>> NL5751 BL Deurne >>>> The Netherlands http://www.snijder.com >>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >>> >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From jredman at ergotech.com Mon Jul 24 09:50:21 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 09:50:21 -0600 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4D77D.5080200@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> Message-ID: <44C4EC3D.6010204@ergotech.com> Jim, How about we go back to basics and define a serial port. Under Java, I can open /dev/ttyS0, COM1:, etc and read/write a serial port. So what does RXTX bring to the table? If we can define what we need from the product at a high level (functional spec.) then we can look at what's wrong underneath (design requirements). I can do this fairly easily. Functionally, I want support for SerialPort - a superset of that would be fine. SerialPort provides an abstraction that provides everything I need for accessing serial devices. At the design level, I'd like a "pluggable" architecture. That is, I'd like to able to accommodate anything that it makes sense to implement in terms of the SerialPort interface. An obvious plugin is one that supports the current RXTX serial port access - through device files. But _I'd_ like a plugin for serial ports over Ethernet, serial ports over BlueTooth (including discovery), etc. I'm sure others could think of modules they'd like i2c, SPI, etc. etc. I'm not sure that ANY of these should be part of the spec. although perhaps the device file based version could be part of a reference implementation. I don't know that this is really much different from the existing architecture. I doubt that much code could be shared between, for example, a BlueTooth serial port and a /dev/ttyS0 serial port, but perhaps those more familiar with the code could comment. I suspect some cleanup of registration, etc. would be needed to formalize plugins, but I doubt it's too great. Some time ago I learnt the definition of a "Goal". It should be concrete, winnable and build unity. So, I have laid out a concrete goal, build to a superset of the SerialPort interface, it's winnable because it's not a complete rewrite of RXTX and it builds unity because anyone's pet electrical specification can be added. A simplistic view, tell me where I went wrong. Jim -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From lyon at docjava.com Mon Jul 24 10:06:40 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Mon, 24 Jul 2006 12:06:40 -0400 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4E746.8070808@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> Message-ID: >Hi All, Wow, what an informed and interesting debate from my most innocent and well-intentioned of e-mails. I must say that I am learning a great deal from this list! When I speak about RS232 I wanted to focus on the protocol, not the connector shape or pin-out or electrical issues. Issues like that are addressed by the rs232c standard. The RS232 is a really loaded term! The C revision of the standard was issued in 1969 in part to accommodate electrical characteristics. Revision D was issued in 1986. The current revision is TIA-232-F Interface Between Data Terminal Equipment and Data Circuit-Terminating Equipment Employing Serial Binary Data Interchange, issued in 1997. None of this is of any particular relevance to the basic underlying question: Should the next JSR attempt to address the multi-drop abilities of RS-485? Thanks! - Doug >Folks, > >The RS232/485/422/etc. etc. is a complete red herring >(http://en.wikipedia.org/wiki/Red_herring in case you don't know the >expression). The differences between the two are at the electrical >level, not at the RXTX level. I'll provide a concrete example and see >if we can get away from this issue. > >There's an industrial serial communications standard - Modbus. Modbus >capable devices are very common and can be purchased, generally, with an >RS232 or a 485 or a 422 - you decide when you buy it. Some actually >provide both 232 and 485 on the same connector. Now, within our >environment you configure a Modbus JavaBean. One of the parameters is >the "Station Number". The station number is required for both RS232 and >RS485 devices - the protocol doesn't change based on the electrical >requirements of the device. Now I can configure an application talking >to, say, station 2 and station 7. I can add an RS485 converter to the >computer serial port and put two physical devices there, configured as >station 2 and station 7 and everything works fine. HOWEVER, over RS232 >some devices will respond to both station 2 and station 7. So THE SAME >APPLICATION will work with both 232 and 485. The only changes are >hardware related. This same behavior is true of a number of 485 >"networks" and many industrial devices that have 485 interfaces have 232 >as an option using the same protocol. > >Jim > > >Trent Jarvi wrote: >> A JSR/JCP would not just involve RXTX. In fact it would be very nice to >> have others with expertise in various areas like I2C, IrDA, RS485, RS422, >> ... involved. >> >> Within the RXTX community, I do not think we have enough depth to tackle >> RS485 alone. I'm aware of some of the low level issues but to be honest, >> I've never actually used it. The RS485 classes in RXTX are more like >> notes to myself about the issues involved without hardware solutions. In >> operating systems like Linux, this may be much less of an issue in the >> future. Linux is putting realtime patches now in the kernels which could >> make RS485 over EIA232 possible. >> >> This is probably the last chance RS485 has to get into a published spec >> for a long time though. Right now, I do not think its reasonable to >> include it in the process. Others could make that less of a problem. >> >> On Mon, 24 Jul 2006, Christo Malan wrote: >> >>> Hi >>> >>> I don't think RS-485 belong in rxtx, the scope of the spec is not wide >>> enough as it only specify the electrical layer. Their is no data >>> protocol recommended or defined. This mean that we have no idea when to >>> sample for a bit, how long is a bit and how many bits before we can say >>> new data is available. >>> >>> Christo >>> >>> Dr. Douglas Lyon wrote: >>>> Hi All, >>>> There has been a lot of discussion regarding RS485. >>>> >>>> Let me see if I can summarize this, please correct me if I am wrong; >>>> I am deliberately ignoring connector and electrical issues, focusing, >>>> instead, on protocol and software issues. Also, I have never used >>>> RS485, and I don't know much about it. > >>> >>>> 1. Serial ports that claim RS232 are typically used in >>>> the data link layer of the OSI model of networking. Basically, this means >>>> that they work with a point-to-point protocol and are meant to connect two > >>> devices. >>>> >>>> 2. Within the RS232 standard there are framing bits (start and stop bits) >>>> and error control bits (parity). The flow control is xon-xoff or >>>>DTR, CTS, RTS. >>>> Thats' it. >>>> >>>> 3. If you want more than that from RS232 (forward error >>>>correction, ARQ, etc.) >>>> you do it in software, not in the RS232 standard. >>>> >>>> 4. RS485 is different from RS232 in that it is in the Network Layer of >>>> the OSI model of networking. >>>> >>>> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in >>>> a factory). >>>> RS-485 is similar to RS-422, but RS-422 allows just one driver with >>>> multiple receivers whereas RS-485 supports multiple drivers and >>>> receivers. >>>> >>>> 6. RS-485 is a serial bus with multiple nodes and thus must handle network >>>> link layer protocols. By using high-impedance receivers, you can have >>>> as many as 256 nodes. >>>> >>>> 7. The RS-485 can be implemented with RXTX in the core and a >>>>layer of software >>>> on top to handle media access control (MAC sublayer). There are also >>>> hardware converters. >>>> http://www.rs485.com/pconverters.html for example. However, some of >>>> these require software control. There is some support in the form of >>>> the Rs485.java class, >>>> in RXTX. >>>> >>>> 8. The RS-485 specification will add to the size of the JSR >>>> >>>> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: >>>> This version of the Java communications API contains support for >>>> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not >>>> mentioned. >>>> >>>> 10. DO people want to add RS485 to a new JSR? >>>> >>>> Would it make sense for the RS-485 people to speak up now? >>>> Please let me know if you think my summary is wrong. >>>> >>>> Thanks! >>>> - Doug >>>> >>>> >>>> >>>> >>>> >>>> >>>>> At 18:31 20/07/2006, Trent Jarvi wrote: >>>>> >>>>>>> PROJECT SCOPE: >>>>>>> ------------- >>>>>>> >>>>>>> Also, we should think carefully about what the scope of >>>>>>> this project would be. Should it be javax."comm" which >>>>>>> handles both serial and parallel (is parallel going by the >>>>>>> wayside). Should it be split into two project: >>>>>>> javax.EIA232 (or javax.RS232), and javax.IEEE1284? >>>>>>> >>>>>>> Should we differentiate between single-ended serial >>>>>>> protocols, like EIA232, I2C, 2-WIRE, SPI, vs. >>>>>>> quasi-multidrop and full multidrop busses such as >>>>>>> EIA422, EIA432 and EIA485? If we really were to >>>>>>> add I2C support to the API, we'd have to delve into >>>>>>> the semantics more, because there could be some >>>>>>> implicit decoding of the bus the API users would >>>>>>> want to see. >>>>>>> >>>>>> Hi Paul >>>>>> >>>>>> The way RXTX works, which is a fair representation of the >>>>>>people using the >>>>>> API, is complete support for RIA232, minimal support for IEEE1284. From >>>>>> what I understand, Sun was going along the same lines. If we combined >>>>>> both projects, we would have half a parallel port implementation. I see >>>>>> maybe 4 requests for features not in the parallel support a year. >>>>>> >>>>>> The other protocols should not be limited by a JSR which is going to be >>>>>> focused upon serial port interests. The IEA485 hacks in RXTX along with >>>>>> I2C and Raw should _not_ be considered a strong basis for extending the >>>>>> API to cover these protocols. If people want to do real >>>>>>implementations, >>>>>> they should not face a 'standard' which wasnt really focused upon their >>>>>> interests. I think we understand the parallel port issues >>>>>>fairly well but >>>>>> have not implemented many features and I don't know if we would. >>>>>> >>>>> I agree with all of this. API requirements for I2C, SPI, etc. are very >>>>> different from those for RS232/485/422. Our embedded Java platform has >>>>> APIs for all of these and more and they don't share a lot apart from the >>>>> fact that they all use Input/OutputStreams (and in the case of SPI you > >>>> still need to cater with the fact that every time you want to read you >>>>> must also write to the device.) >>>>> >>>>> If I was to design javax.comm from scratch, I think I would focus on >>>>> serial ports exclusively (== whatever the underlying OS represents as > >>>> serial ports). Even parallel is a bit out of place IMHO, although I >>>>> understand it needs to stay for backwards compatibility. >>>>> >>>>> >>>>> >>>>>> So a versatile API is favorable but I do not think we have the proper >>>>>> community to represent much more than Serial. >>>>>> >>>>> Yes, I think the same. >>>>> >>>>> Guillermo >>>>> -- >>>>> Guillermo Rodriguez Garcia >>>>> >>>>> Snijder Micro Systems phone +31-493-351020 >>>>> G. Rodriguez Garcia fax +31-493-351530 >>>>> Visser 25 email guille at sms.nl >>>>> NL5751 BL Deurne >>>>> The Netherlands http://www.snijder.com >>>>> >>>>> _______________________________________________ >>>>> Rxtx mailing list >>>>> Rxtx at qbang.org >>>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>>> >>>> _______________________________________________ >>>> Rxtx mailing list >>>> Rxtx at qbang.org >>>> http://mailman.qbang.org/mailman/listinfo/rxtx >>>> >>>> >>>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > >-- >Jim Redman >(505) 662 5156 x85 >http://www.ergotech.com >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Mon Jul 24 10:16:44 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 18:16:44 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> Message-ID: <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> Hi Doug, Quoting "Dr. Douglas Lyon" : > >Hi All, > > > Wow, what an informed and interesting debate from my most > innocent and well-intentioned of e-mails. > > I must say that I am learning a great deal from this list! > > When I speak about > RS232 I wanted to focus on the protocol, not the connector shape or > pin-out or electrical issues. Issues like that are addressed by the > rs232c standard. > The RS232 is a really loaded term! Right. Maybe we should be talking about "serial ports" instead. At the functional level it does not make any difference whether it is RS232, RS485, or RS422... except maybe for the direction control in the case of RS485 ports. [...] > > None of this is of any particular relevance to the basic underlying > question: > > Should the next JSR attempt to address the multi-drop abilities of RS-485? What I would suggest is to just add a new 'ioctlex'-like method to the SerialPort API: A method that you'd use to pass platform- or implementation-specific info to the underlying driver or OS to do things such as "enabling RS485 mode" or "disable FIFOs" or "poll the TSR register". No need to define any function codes. This is for stuff that is platform- or implementation-specific and as such cannot be easily abstracted anyway. The goal is to accomodate hat those systems that have serial ports with special, non-standard capabilities without forcing developers to leave javax.comm. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From Paul.Klissner at Sun.COM Mon Jul 24 10:45:33 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Mon, 24 Jul 2006 09:45:33 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> Message-ID: <44C4F92D.6090807@sun.com> >> None of this is of any particular relevance to the basic underlying >> question: >> >> Should the next JSR attempt to address the multi-drop abilities of RS-485? > > What I would suggest is to just add a new 'ioctlex'-like method > to the SerialPort API: A method that you'd use to pass platform- > or implementation-specific info to the underlying driver or OS > to do things such as "enabling RS485 mode" or "disable FIFOs" or > "poll the TSR register". > > No need to define any function codes. This is for stuff that is > platform- or implementation-specific and as such cannot be easily > abstracted anyway. Detrimental to platform independence. Paul From berkland at spamcop.net Mon Jul 24 11:07:58 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 24 Jul 2006 13:07:58 -0400 Subject: [Rxtx] jcp and jsr In-Reply-To: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> Message-ID: <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> Gregg Wonderly wrote: > That there could be a low level port/device SPI > that could be put in place once, and then overtime > we could layer other APIs, including an updated > javax.comm which would make use of this SPI. I think there is great merit in this suggestion. I would like to see the ability to register a new "port" along with a custom handler in the Java client code before attempting to access the port. e.g . CommManager.getInstance().registerPortImpl("USB1:", new HidPortAdapter(/*vendorId=*/ "1234", /*deviceId=*/ "4321"); CommManager.getInstance().registerPortImpl("Ether1:", new InetPortAdapter(/*ipAndPort=*/ "192.168.1.101:8088"); It would allow other protocols that this group doesn't have depth in to be developed by someone who does on an "as needed" basis. Additionally, the value of this would be with some devices that implement basically the same protocol that was initially used over RS232 for a USB (via an HID) or Ethernet interface. There are a number of these in POS hardware. The existing JavaPOS driver written against JavaCOMM 2.0 could be reused by plugging in an HID or IP adapter before attempting to access the device. It might also be valuable to use something like an extended version of the portmapping file found in JavaCOMM 3.0. A configuration file could allow this definition to take place outside of any Java client code. Such a mapping file wouldn't even need to be part of the JSR API or reference implementation. It could be handled in a specific implementation. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060724/7f51342e/attachment-0342.html From guille at sms.nl Mon Jul 24 11:14:54 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Mon, 24 Jul 2006 19:14:54 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C4F92D.6090807@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> Message-ID: <1153761294.44c5000ec1360@webmail.eatserver.nl> Quoting Paul Klissner : > >> None of this is of any particular relevance to the basic underlying > >> question: > >> > >> Should the next JSR attempt to address the multi-drop abilities of > RS-485? > > > > What I would suggest is to just add a new 'ioctlex'-like method > > to the SerialPort API: A method that you'd use to pass platform- > > or implementation-specific info to the underlying driver or OS > > to do things such as "enabling RS485 mode" or "disable FIFOs" or > > "poll the TSR register". > > > > No need to define any function codes. This is for stuff that is > > platform- or implementation-specific and as such cannot be easily > > abstracted anyway. > > Detrimental to platform independence. Yes, it is. But as you go closer and closer to the hardware level some things are by nature platform-dependent, and sometimes just cannot be solved in a platform-independent way. In these cases, is it better to have no solution at all than having one that is less than perfect? Put it another way, would you prefer having people say "I just cannot do this in Java; I'll go somewhere else" rather than "I can do this in Java -- only not in a platform-independent way" ? Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From gergg at cox.net Mon Jul 24 11:34:00 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 12:34:00 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153752467.44c4dd93c08f7@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> Message-ID: <44C50488.1040508@cox.net> Guillermo Rodriguez wrote: > As an embedded Java vendor, SNIJDER Micro Systems certainly sees the > value of standardized APIs to talk to different types of communication > buses including SPI, I2C, 1-Wire, etc., for embedded applications. > However we think this has nothing to do with javax.comm. I don't think this is only about javax.comm. Certainly that's important. I'm just wading into this conversation mainstream and trying to say: If you are going to do anything about "fixing" javax.comm to work on all platforms, please, please, please start with a hardware port SPI definition that lets you get to serial ports, and then provide the existing javax.com API and whatever new API you think is necessary (I don't have any really issues with the existing API directly). Then, there will be a place for others interesting in SPI, i2C, USB and other things to get started with providing access to devices that are also interesting in Java applications, and directly, in embedded Java applications. Gregg Wonderly From Paul.Klissner at Sun.COM Mon Jul 24 11:41:51 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Mon, 24 Jul 2006 10:41:51 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153761294.44c5000ec1360@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> Message-ID: <44C5065F.3060802@sun.com> Guillermo Rodriguez wrote: > Quoting Paul Klissner : > >>>> None of this is of any particular relevance to the basic underlying >>>> question: >>>> >>>> Should the next JSR attempt to address the multi-drop abilities of >> RS-485? >>> What I would suggest is to just add a new 'ioctlex'-like method >>> to the SerialPort API: A method that you'd use to pass platform- >>> or implementation-specific info to the underlying driver or OS >>> to do things such as "enabling RS485 mode" or "disable FIFOs" or >>> "poll the TSR register". >>> >>> No need to define any function codes. This is for stuff that is >>> platform- or implementation-specific and as such cannot be easily >>> abstracted anyway. >> Detrimental to platform independence. > > Yes, it is. But as you go closer and closer to the hardware level some > things are by nature platform-dependent, and sometimes just cannot be > solved in a platform-independent way. In these cases, is it better to > have no solution at all than having one that is less than perfect? > > Put it another way, would you prefer having people say "I just cannot > do this in Java; I'll go somewhere else" rather than "I can do this > in Java -- only not in a platform-independent way" ? If there isn't a reasonable way to abstract it out, then why use Java? The whole idea is platform neutrality, otherwise, what is the huge advantage of adopting a standardized Java API? I think it is wrong to subvert the API. I think we have to arrive at some sort of consensus about the scope of the API and do our best to engineer a robust API in terms of that scope using abstraction. There may be outliers, but the outliers probably aren't portable, and probably would do just as well to not use java for that particular application. If this was a JSR, if we found some compelling problem that kept cropping up the API could be reved so as not to just orphan cases with legitimate requests. If someone really needs to do funky things with the hardware, why wouldn't that be put in the native back end? Couldn't some of this be addressed by the multiple SPI layer that I recommended as one of the two changes I'd like to see made to javax.comm (the other being a port mapping plugin layer)? Paul From jredman at ergotech.com Mon Jul 24 11:49:46 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 11:49:46 -0600 Subject: [Rxtx] jcp and jsr In-Reply-To: <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> Message-ID: <44C5083A.6090902@ergotech.com> A thought for later since we haven't really reached this level of detail, but since this type of approach seems likely... If a configuration file is mandatory, can we specify what the file is called and what the format of the options are (mandatory?, and optional) without limiting extensions. This just adds consistency across platforms/implementations. Jim Doug Berkland wrote: > Gregg Wonderly wrote: > > That there could be a low level port/device SPI > > that could be put in place once, and then overtime > > we could layer other APIs, including an updated > > javax.comm which would make use of this SPI. > > I think there is great merit in this suggestion. I would like to see > the ability to register a new "port" along with a custom handler in the > Java client code before attempting to access the port. > e.g . > CommManager.getInstance().registerPortImpl("USB1:", new > HidPortAdapter(/*vendorId=*/ "1234", /*deviceId=*/ "4321"); > CommManager.getInstance().registerPortImpl("Ether1:", new > InetPortAdapter(/*ipAndPort=*/ " 192.168.1.101:8088 > "); > > It would allow other protocols that this group doesn't have depth in to > be developed by someone who does on an "as needed" basis. > > Additionally, the value of this would be with some devices that > implement basically the same protocol that was initially used over RS232 > for a USB (via an HID) or Ethernet interface. There are a number of > these in POS hardware. The existing JavaPOS driver written against > JavaCOMM 2.0 could be reused by plugging in an HID or IP adapter before > attempting to access the device. > > It might also be valuable to use something like an extended version of > the portmapping file found in JavaCOMM 3.0. A configuration file could > allow this definition to take place outside of any Java client code. > Such a mapping file wouldn't even need to be part of the JSR API or > reference implementation. It could be handled in a specific > implementation. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From mtnvega at yahoo.com.br Mon Jul 24 11:51:40 2006 From: mtnvega at yahoo.com.br (mtnvega) Date: Mon, 24 Jul 2006 14:51:40 -0300 Subject: [Rxtx] Serial Read/Write Details Message-ID: <44C508AC.7060103@yahoo.com.br> Hello, I'm have being flirting with RXTX for a while since I'm working on a college project where I will need to communicate with a microcontroller using USART. Now is the time to start using it! But I have some doubts and I hope you can help-me. I will need to both send and receive data from the serial port. First I will need to send some command bytes then wait for some data that will be returned from the microcontroller. And I would like to know which is the best way to do that. I'm mean, of course send and receive data is the purpose of the serial port and RXTX but I'm looking for some details since there will be no package control but just a fixed command format and confirmation messages from the microcontroller side. I would like to know if I should open and close the port or if I can just open it once. I read that upon writing to output the input buffer are filled with the same data, is it right? If yes, isn't it a problem since I'm waiting for data back in a very small time? Thank you, Luiz _______________________________________________________ Voc? quer respostas para suas perguntas? Ou voc? sabe muito e quer compartilhar seu conhecimento? Experimente o Yahoo! Respostas ! http://br.answers.yahoo.com/ From jredman at ergotech.com Mon Jul 24 12:45:50 2006 From: jredman at ergotech.com (Jim Redman) Date: Mon, 24 Jul 2006 12:45:50 -0600 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C50488.1040508@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> Message-ID: <44C5155E.7080105@ergotech.com> Gregg, Is SPI applicable to a SerialPort interface over Ethernet (or Bluetooth)? I've assumed that it's specific to directly-connected-UART-based serial ports - something similar to I2C. I'm starting to think that I'm opposed to having hardware definitions (transport layer?) in the JavaComm spec., but then what's left? Jim Gregg Wonderly wrote: > Guillermo Rodriguez wrote: >> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the >> value of standardized APIs to talk to different types of communication >> buses including SPI, I2C, 1-Wire, etc., for embedded applications. >> However we think this has nothing to do with javax.comm. > > I don't think this is only about javax.comm. Certainly that's important. I'm > just wading into this conversation mainstream and trying to say: > > If you are going to do anything about "fixing" javax.comm to work on all > platforms, please, please, please start with a hardware port SPI definition that > lets you get to serial ports, and then provide the existing javax.com API and > whatever new API you think is necessary (I don't have any really issues with the > existing API directly). > > Then, there will be a place for others interesting in SPI, i2C, USB and other > things to get started with providing access to devices that are also interesting > in Java applications, and directly, in embedded Java applications. > > Gregg Wonderly > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Mon Jul 24 13:15:19 2006 From: gergg at cox.net (Gregg Wonderly) Date: Mon, 24 Jul 2006 14:15:19 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C5155E.7080105@ergotech.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <44C5155E.7080105@ergotech.com> Message-ID: <44C51C47.90409@cox.net> Jim Redman wrote: > Is SPI applicable to a SerialPort interface over Ethernet (or > Bluetooth)? I've assumed that it's specific to > directly-connected-UART-based serial ports - something similar to I2C. SPI is a simple 2 line (clock and data) plus slave select bi-directional, full duplex data transfer mechanism. It has nothing to do, directly with serial ports, but could be implemented using serial port signalling lines. > I'm starting to think that I'm opposed to having hardware definitions > (transport layer?) in the JavaComm spec., but then what's left? Jim, there are multiple conversations going on, on the list. There is a group of people that just want a standard serial port mechanism in Java, apparently NOW! They are going back and forth about that. There is another conversation about doing a JSR to make the serial port interfaces a standard, since Sun's original implementation was never a Java standard. There is a small group saying if you're going to do a JSR for serial ports, why not provide a nice foundation for serial ports which might also support other kinds of "ports" and associated protocols. And there are a couple of other conversations about Pascal's stuff. It's this last group that I am the most interested in. I think that it is possible to create a simple Service Provider Interface for 'hardware interfacing' that covers serial ports and also includes expandability to cover other types of hardware. We want to find the level of abstraction that the most number of OSes provide in their user level APIs, and create a matching SPI at that level which will allow a JVM vendor to provide access to the types of hardware that is common on their OSes/hardware. Then, third parties might add some value by providing some good abstrations for particular types of protocols or particular vendors' hardware (ports which can be switched between RS232 and RS485 for example). Finally, we can create an implementation of the javax.comm API which uses this SPI to provide exactly the same API as today, but with an approved foundation for hardware access from java using 100% java code. Gregg Wonderly From mark at mdsh.com Mon Jul 24 16:03:38 2006 From: mark at mdsh.com (Mark Himsley) Date: Mon, 24 Jul 2006 23:03:38 +0100 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> Message-ID: I don't see how any Java app is going to know the difference between an RS232, RS422, or RS485 port. I regularly use RXTX controlling RS422 devices (controlling VTRs) and I can use an RS232 port with bodged wiring (for short distances) or RS232 port with a media converted - either of which may be built into the PC or may be a USB device - or an RS422 USB device. They are just 'serial port' devices. Please don't get hung up on higher layer stuff - that's for application developers to add on top of a rock-solid multi platform 'serial port' driver implementations. On 24 July 2006 08:44 -0600 Trent Jarvi wrote: > > A JSR/JCP would not just involve RXTX. In fact it would be very nice to > have others with expertise in various areas like I2C, IrDA, RS485, RS422, > ... involved. > > Within the RXTX community, I do not think we have enough depth to tackle > RS485 alone. I'm aware of some of the low level issues but to be honest, > I've never actually used it. The RS485 classes in RXTX are more like > notes to myself about the issues involved without hardware solutions. In > operating systems like Linux, this may be much less of an issue in the > future. Linux is putting realtime patches now in the kernels which could > make RS485 over EIA232 possible. > > This is probably the last chance RS485 has to get into a published spec > for a long time though. Right now, I do not think its reasonable to > include it in the process. Others could make that less of a problem. > > On Mon, 24 Jul 2006, Christo Malan wrote: > > > Hi > > > > I don't think RS-485 belong in rxtx, the scope of the spec is not wide > > enough as it only specify the electrical layer. Their is no data > > protocol recommended or defined. This mean that we have no idea when to > > sample for a bit, how long is a bit and how many bits before we can say > > new data is available. > > > > Christo > > > > Dr. Douglas Lyon wrote: > >> Hi All, > >> There has been a lot of discussion regarding RS485. > >> > >> Let me see if I can summarize this, please correct me if I am wrong; > >> I am deliberately ignoring connector and electrical issues, focusing, > >> instead, on protocol and software issues. Also, I have never used > >> RS485, and I don't know much about it. > >> > >> 1. Serial ports that claim RS232 are typically used in > >> the data link layer of the OSI model of networking. Basically, this > >> means that they work with a point-to-point protocol and are meant to > >> connect two devices. > >> > >> 2. Within the RS232 standard there are framing bits (start and stop > >> bits) and error control bits (parity). The flow control is xon-xoff or > >> DTR, CTS, RTS. Thats' it. > >> > >> 3. If you want more than that from RS232 (forward error correction, > >> ARQ, etc.) you do it in software, not in the RS232 standard. > >> > >> 4. RS485 is different from RS232 in that it is in the Network Layer of > >> the OSI model of networking. > >> > >> 5. Serial devices under RS-485 mode, are linked in a LAN (perhaps in > >> a factory). > >> RS-485 is similar to RS-422, but RS-422 allows just one driver with > >> multiple receivers whereas RS-485 supports multiple drivers and > >> receivers. > >> > >> 6. RS-485 is a serial bus with multiple nodes and thus must handle > >> network link layer protocols. By using high-impedance receivers, you > >> can have as many as 256 nodes. > >> > >> 7. The RS-485 can be implemented with RXTX in the core and a layer of > >> software on top to handle media access control (MAC sublayer). There > >> are also hardware converters. > >> http://www.rs485.com/pconverters.html for example. However, some of > >> these require software control. There is some support in the form of > >> the Rs485.java class, > >> in RXTX. > >> > >> 8. The RS-485 specification will add to the size of the JSR > >> > >> 9. Javax.comm specification, version 2.0 (the Real OLD version) says: > >> This version of the Java communications API contains support for > >> RS232 serial ports and IEEE 1284 parallel ports. RS485/RS422 was not > >> mentioned. > >> > >> 10. DO people want to add RS485 to a new JSR? > >> > >> Would it make sense for the RS-485 people to speak up now? > >> Please let me know if you think my summary is wrong. > >> > >> Thanks! > >> - Doug > >> > >> > >> > >> > >> > >> > >>> At 18:31 20/07/2006, Trent Jarvi wrote: > >>> > >>>> > PROJECT SCOPE: > >>>> > ------------- > >>>> > > >>>> > Also, we should think carefully about what the scope of > >>>> > this project would be. Should it be javax."comm" which > >>>> > handles both serial and parallel (is parallel going by the > >>>> > wayside). Should it be split into two project: > >>>> > javax.EIA232 (or javax.RS232), and javax.IEEE1284? > >>>> > > >>>> > Should we differentiate between single-ended serial > >>>> > protocols, like EIA232, I2C, 2-WIRE, SPI, vs. > >>>> > quasi-multidrop and full multidrop busses such as > >>>> > EIA422, EIA432 and EIA485? If we really were to > >>>> > add I2C support to the API, we'd have to delve into > >>>> > the semantics more, because there could be some > >>>> > implicit decoding of the bus the API users would > >>>> > want to see. > >>>> > > >>>> > >>>> Hi Paul > >>>> > >>>> The way RXTX works, which is a fair representation of the people > >>>> using the API, is complete support for RIA232, minimal support for > >>>> IEEE1284. From what I understand, Sun was going along the same > >>>> lines. If we combined both projects, we would have half a parallel > >>>> port implementation. I see maybe 4 requests for features not in the > >>>> parallel support a year. > >>>> > >>>> The other protocols should not be limited by a JSR which is going to > >>>> be focused upon serial port interests. The IEA485 hacks in RXTX > >>>> along with I2C and Raw should _not_ be considered a strong basis for > >>>> extending the API to cover these protocols. If people want to do > >>>> real implementations, they should not face a 'standard' which wasnt > >>>> really focused upon their interests. I think we understand the > >>>> parallel port issues fairly well but have not implemented many > >>>> features and I don't know if we would. > >>>> > >>> I agree with all of this. API requirements for I2C, SPI, etc. are very > >>> different from those for RS232/485/422. Our embedded Java platform has > >>> APIs for all of these and more and they don't share a lot apart from > >>> the fact that they all use Input/OutputStreams (and in the case of > >>> SPI you still need to cater with the fact that every time you want to > >>> read you must also write to the device.) > >>> > >>> If I was to design javax.comm from scratch, I think I would focus on > >>> serial ports exclusively (== whatever the underlying OS represents as > >>> serial ports). Even parallel is a bit out of place IMHO, although I > >>> understand it needs to stay for backwards compatibility. > >>> > >>> > >>> > >>>> So a versatile API is favorable but I do not think we have the proper > >>>> community to represent much more than Serial. > >>>> > >>> Yes, I think the same. > >>> > >>> Guillermo > >>> -- > >>> Guillermo Rodriguez Garcia > >>> > >>> Snijder Micro Systems phone +31-493-351020 > >>> G. Rodriguez Garcia fax +31-493-351530 > >>> Visser 25 email guille at sms.nl > >>> NL5751 BL Deurne > >>> The Netherlands http://www.snijder.com > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx at qbang.org > >>> http://mailman.qbang.org/mailman/listinfo/rxtx > >>> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> > >> > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Mark Himsley From berkland at spamcop.net Mon Jul 24 16:55:18 2006 From: berkland at spamcop.net (Doug Berkland) Date: Mon, 24 Jul 2006 18:55:18 -0400 Subject: [Rxtx] jcp and jsr In-Reply-To: <44C5083A.6090902@ergotech.com> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> <44C5083A.6090902@ergotech.com> Message-ID: <269e40090607241555g281c7f24s5577b86e35d27eab@mail.gmail.com> I'm sorry, I keep reading SPI as "Service Provider Interface" instead of "Serial Peripheral Interface". (See http://en.wikipedia.org/wiki/Serial_Peripheral_Interface.) What I thought was being suggested was a pluggable implementation like that found in javax.security. (The SPI there actually stands for "Security Provider Interface" not "Service Provider Interface" like I had thought.) I guess that might be a CPI (Comm Provider Interface) or PPI (Port Provider Interface.) At any rate what I would like to see is a JSR with (in order of priority) - compatible API for code written against current javax.comm 2.0 classes - ability to register or "force" a port by providing a name and implementation (not have to rely completely on the "auto-discovery") - nothing precluding the use of a portmapping in a given implementation - ability to register port implementations On 7/24/06, Jim Redman wrote: > > A thought for later since we haven't really reached this level of > detail, but since this type of approach seems likely... > > If a configuration file is mandatory, can we specify what the file is > called and what the format of the options are (mandatory?, and optional) > without limiting extensions. > > This just adds consistency across platforms/implementations. > > Jim > > Doug Berkland wrote: > > Gregg Wonderly wrote: > > > That there could be a low level port/device SPI > > > that could be put in place once, and then overtime > > > we could layer other APIs, including an updated > > > javax.comm which would make use of this SPI. > > > > I think there is great merit in this suggestion. I would like to see > > the ability to register a new "port" along with a custom handler in the > > Java client code before attempting to access the port. > > e.g . > > CommManager.getInstance().registerPortImpl("USB1:", new > > HidPortAdapter(/*vendorId=*/ "1234", /*deviceId=*/ "4321"); > > CommManager.getInstance().registerPortImpl("Ether1:", new > > InetPortAdapter(/*ipAndPort=*/ " 192.168.1.101:8088 > > "); > > > > It would allow other protocols that this group doesn't have depth in to > > be developed by someone who does on an "as needed" basis. > > > > Additionally, the value of this would be with some devices that > > implement basically the same protocol that was initially used over RS232 > > for a USB (via an HID) or Ethernet interface. There are a number of > > these in POS hardware. The existing JavaPOS driver written against > > JavaCOMM 2.0 could be reused by plugging in an HID or IP adapter before > > attempting to access the device. > > > > It might also be valuable to use something like an extended version of > > the portmapping file found in JavaCOMM 3.0. A configuration file could > > allow this definition to take place outside of any Java client code. > > Such a mapping file wouldn't even need to be part of the JSR API or > > reference implementation. It could be handled in a specific > > implementation. > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- > Jim Redman > (505) 662 5156 x85 > http://www.ergotech.com > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20060724/02c50e6a/attachment-0342.html From tjarvi at qbang.org Mon Jul 24 18:44:54 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 24 Jul 2006 18:44:54 -0600 (MDT) Subject: [Rxtx] Serial Read/Write Details In-Reply-To: <44C508AC.7060103@yahoo.com.br> References: <44C508AC.7060103@yahoo.com.br> Message-ID: On Mon, 24 Jul 2006, mtnvega wrote: > Hello, > > I'm have being flirting with RXTX for a while since I'm working on a > college project where I will > need to communicate with a microcontroller using USART. > > Now is the time to start using it! But I have some doubts and I hope you > can help-me. > > I will need to both send and receive data from the serial port. First I > will need to send some command > bytes then wait for some data that will be returned from the > microcontroller. And I would like > to know which is the best way to do that. I'm mean, of course send and > receive data is the purpose > of the serial port and RXTX but I'm looking for some details since there > will be no package control > but just a fixed command format and confirmation messages from the > microcontroller side. > > I would like to know if I should open and close the port or if I can > just open it once. > I read that upon writing to output the input buffer are filled with the > same data, is it right? > If yes, isn't it a problem since I'm waiting for data back in a very > small time? > Hi Luiz Unless you want to use the port with a second application, just open the port once and close it when you exit the application. The input will not be filled with the data you write. The API has events to let you know when data is available and when your data has gone out the port. You can look in the contrib directory that comes with the source for crude examples of event notification. I think there is an example on the wiki too. I don't think you will have any problems. -- Trent Jarvi tjarvi at qbang.org From guille at sms.nl Tue Jul 25 00:26:12 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 08:26:12 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C50488.1040508@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> Message-ID: <7.0.1.0.0.20060725082124.036309e0@sms.nl> At 19:34 24/07/2006, Gregg Wonderly wrote: >Guillermo Rodriguez wrote: > > As an embedded Java vendor, SNIJDER Micro Systems certainly sees the > > value of standardized APIs to talk to different types of communication > > buses including SPI, I2C, 1-Wire, etc., for embedded applications. > > However we think this has nothing to do with javax.comm. > >I don't think this is only about javax.comm. Certainly that's >important. I'm >just wading into this conversation mainstream and trying to say: > >If you are going to do anything about "fixing" javax.comm to work on all >platforms, please, please, please start with a hardware port SPI >definition that >lets you get to serial ports, and then provide the existing javax.com API and >whatever new API you think is necessary (I don't have any really >issues with the >existing API directly). > >Then, there will be a place for others interesting in SPI, i2C, USB and other >things to get started with providing access to devices that are also >interesting >in Java applications, and directly, in embedded Java applications. I do agree that the best a hardware port SPI definition (where SPI = Service Provider Interface, not the SPI protocol) is a good thing to have to support serial ports layered over other transports. However these are still serial ports at the end. I still don't think the javax.comm API is well suited to "any" serial bus such as I2C, SPI, etc. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 00:41:46 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 08:41:46 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C5065F.3060802@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> Message-ID: <7.0.1.0.0.20060725082630.036d2d10@sms.nl> At 19:41 24/07/2006, Paul Klissner wrote: >Guillermo Rodriguez wrote: >>Quoting Paul Klissner : >> >>>>>None of this is of any particular relevance to the basic underlying >>>>>question: >>>>> >>>>>Should the next JSR attempt to address the multi-drop abilities of >>>RS-485? >>>>What I would suggest is to just add a new 'ioctlex'-like method >>>>to the SerialPort API: A method that you'd use to pass platform- >>>>or implementation-specific info to the underlying driver or OS >>>>to do things such as "enabling RS485 mode" or "disable FIFOs" or >>>>"poll the TSR register". >>>> >>>>No need to define any function codes. This is for stuff that is >>>>platform- or implementation-specific and as such cannot be easily >>>>abstracted anyway. >>>Detrimental to platform independence. >>Yes, it is. But as you go closer and closer to the hardware level some >>things are by nature platform-dependent, and sometimes just cannot be >>solved in a platform-independent way. In these cases, is it better to >>have no solution at all than having one that is less than perfect? >>Put it another way, would you prefer having people say "I just cannot >>do this in Java; I'll go somewhere else" rather than "I can do this >>in Java -- only not in a platform-independent way" ? > >If there isn't a reasonable way to abstract it out, then >why use Java? If an application can be 99% platform independent with small bits being not portable, why *not* use Java? I'd prefer to see people using Java to write non-portable applications than having them use C instead. I believe that Java should promote platform neutrality, but that does not necessarily mean precluding the use of anything that is NOT platform independent. And let's face it, if you are using javax.comm to talk to some serial device directly, then chances are you are already tied to some specific hardware anyway. Also, some people (myself included) think that Java can also be used as a systems programming language, not only for applications. For many embedded platforms this is certainly the case. In our platform we even write device drivers directly in Java. I would imagine the Sun SPOT team (www.sunspotworld.com) supports a similar view. If people needs to do non-portable stuff and wants to do it in Java I'd rather have them do it in Java than tell them to do it in C instead. >The whole idea is platform neutrality, otherwise, what is the >huge advantage of adopting a standardized Java API? I think >it is wrong to subvert the API. I think we have to arrive at >some sort of consensus about the scope of the API and do our >best to engineer a robust API in terms of that scope using >abstraction. > >There may be outliers, but the outliers probably aren't portable, >and probably would do just as well to not use java for that >particular application. The cases I have in mind is more like portable applications with very small bits of non portable code. I can imagine lots of portable applications that need access to RS485, specially in the industrial process control and factory automation fields. As I said in an earlier mail RS485 is half- duplex, but there is standard way to do RS485 direction control from software. Does it mean that the whole application should not be written in Java, only because some small bits of code related to RS485 direction control are not completely portable? > If this was a JSR, if we found some >compelling problem that kept cropping up the API could be >reved so as not to just orphan cases with legitimate requests. > >If someone really needs to do funky things with the hardware, >why wouldn't that be put in the native back end? But nobody said the functionality can't be implemented in the native back end. However you still need an application level API to enable/disable it. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 00:44:43 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 08:44:43 +0200 Subject: [Rxtx] jcp and jsr In-Reply-To: <269e40090607241555g281c7f24s5577b86e35d27eab@mail.gmail.co m> References: <269e40090607240958i53124a1didcc7c3318e3e74f4@mail.gmail.com> <269e40090607241007h3fadc850r3136dcab8ea464d4@mail.gmail.com> <44C5083A.6090902@ergotech.com> <269e40090607241555g281c7f24s5577b86e35d27eab@mail.gmail.com> Message-ID: <7.0.1.0.0.20060725084431.036d0700@sms.nl> At 00:55 25/07/2006, Doug Berkland wrote: >I'm sorry, I keep reading SPI as "Service Provider Interface" >instead of "Serial Peripheral Interface". (See >http://en.wikipedia.org/wiki/Serial_Peripheral_Interface. >) > >What I thought was being suggested was a pluggable implementation >like that found in javax.security. (The SPI there actually stands >for "Security Provider Interface" not "Service Provider Interface" >like I had thought.) I guess that might be a CPI (Comm Provider >Interface) or PPI (Port Provider Interface.) > >At any rate what I would like to see is a JSR with (in order of priority) >- compatible API for code written against current javax.comm 2.0 classes >- ability to register or "force" a port by providing a name and >implementation (not have to rely completely on the "auto-discovery") >- nothing precluding the use of a portmapping in a given implementation >- ability to register port implementations That sounds very good to me. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From tjarvi at qbang.org Tue Jul 25 01:21:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 01:21:53 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725082124.036309e0@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> Message-ID: On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: > At 19:34 24/07/2006, Gregg Wonderly wrote: >> Guillermo Rodriguez wrote: >>> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the >>> value of standardized APIs to talk to different types of communication >>> buses including SPI, I2C, 1-Wire, etc., for embedded applications. >>> However we think this has nothing to do with javax.comm. >> >> I don't think this is only about javax.comm. Certainly that's >> important. I'm >> just wading into this conversation mainstream and trying to say: >> >> If you are going to do anything about "fixing" javax.comm to work on all >> platforms, please, please, please start with a hardware port SPI >> definition that >> lets you get to serial ports, and then provide the existing javax.com API and >> whatever new API you think is necessary (I don't have any really >> issues with the >> existing API directly). >> >> Then, there will be a place for others interesting in SPI, i2C, USB and other >> things to get started with providing access to devices that are also >> interesting >> in Java applications, and directly, in embedded Java applications. > > I do agree that the best a hardware port SPI definition (where SPI = Service > Provider Interface, not the SPI protocol) is a good thing to have to support > serial ports layered over other transports. However these are still serial > ports at the end. I still don't think the javax.comm API is well suited to > "any" serial bus such as I2C, SPI, etc. > Perhaps the javax.com namespace is just wrong. I think thats a larger issue we are not well prepared to answer. We do have a larger group participating so there is interest beyond our current solution. My concern is getting into blue sky efforts that never materialize. We have a very concrete solution that just needs a few modifications to make current java users happy. This solution is more or less supporting POSIX termios on all platforms including windows. This solution does not ask deep questions like is it USB or RS485 or IrDA. Smart kernel people worry about that. Thats what works. When the fun goes away and I'm fixing spam on slow mail-lists, thats what will continue to work. Thats what will be tested on hundreds of machines every six months. I don't want to remind people of JSR80 windows support but you should keep that in mind while getting too far from the crusty roman roads. I'd love to move off to the side in the namespace and leave javax.com for a great effort unifying the time space continuum to be announced at a later date. Beyond that, we would need serious commitment from people in the community to get more working. Both rxtx.org and Sun are about maxed out right now. -- Trent Jarvi tjarvi at qbang.org From martin at jopdesign.com Tue Jul 25 01:32:22 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 09:32:22 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> Message-ID: <005b01c6afbc$794fc060$0202a8c0@luna> >>> None of this is of any particular relevance to the basic underlying >>> question: >>> >>> Should the next JSR attempt to address the multi-drop abilities of RS-485? I would vote for a strong yes. >> >> What I would suggest is to just add a new 'ioctlex'-like method >> to the SerialPort API: A method that you'd use to pass platform- >> or implementation-specific info to the underlying driver or OS >> to do things such as "enabling RS485 mode" or "disable FIFOs" or >> "poll the TSR register". >> >> No need to define any function codes. This is for stuff that is >> platform- or implementation-specific and as such cannot be easily >> abstracted anyway. > > Detrimental to platform independence. We can model it platform independent with two methods: enterTransmit() and extiTransmit() to do whatever is necessary on the underlying platform to switch to RS485 transmit mode and back. Martin From guille at sms.nl Tue Jul 25 01:45:53 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 09:45:53 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <005b01c6afbc$794fc060$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> Message-ID: <7.0.1.0.0.20060725094317.0363b390@sms.nl> Hi Martin, At 09:32 25/07/2006, Martin Schoeberl wrote: > >>> None of this is of any particular relevance to the basic underlying > >>> question: > >>> > >>> Should the next JSR attempt to address the multi-drop abilities > of RS-485? > >I would vote for a strong yes. > > >> > >> What I would suggest is to just add a new 'ioctlex'-like method > >> to the SerialPort API: A method that you'd use to pass platform- > >> or implementation-specific info to the underlying driver or OS > >> to do things such as "enabling RS485 mode" or "disable FIFOs" or > >> "poll the TSR register". > >> > >> No need to define any function codes. This is for stuff that is > >> platform- or implementation-specific and as such cannot be easily > >> abstracted anyway. > > > > Detrimental to platform independence. > >We can model it platform independent with two methods: > >enterTransmit() and extiTransmit() to do whatever is necessary >on the underlying platform to switch to RS485 transmit mode and >back. Tempting as it is, I don't think this covers all cases. For example, in those cases where RS485 direction control must be done 100% in software, the software needs to have a way to flush (sync) software buffers, poll the hardware FIFOs and TSR (not THR), etc. Or, for example, for those UARTs that do automatic RS485 direction control with a configurable turnaround delay, how would you configure this turnaround delay from the application? Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 01:48:10 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 09:48:10 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> Message-ID: <7.0.1.0.0.20060725094602.036cec00@sms.nl> Hi Trent, At 09:21 25/07/2006, Trent Jarvi wrote: >On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: > > > At 19:34 24/07/2006, Gregg Wonderly wrote: > >> Guillermo Rodriguez wrote: > >>> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the > >>> value of standardized APIs to talk to different types of communication > >>> buses including SPI, I2C, 1-Wire, etc., for embedded applications. > >>> However we think this has nothing to do with javax.comm. > >> > >> I don't think this is only about javax.comm. Certainly that's > >> important. I'm > >> just wading into this conversation mainstream and trying to say: > >> > >> If you are going to do anything about "fixing" javax.comm to work on all > >> platforms, please, please, please start with a hardware port SPI > >> definition that > >> lets you get to serial ports, and then provide the existing > javax.com API and > >> whatever new API you think is necessary (I don't have any really > >> issues with the > >> existing API directly). > >> > >> Then, there will be a place for others interesting in SPI, i2C, > USB and other > >> things to get started with providing access to devices that are also > >> interesting > >> in Java applications, and directly, in embedded Java applications. > > > > I do agree that the best a hardware port SPI definition (where > SPI = Service > > Provider Interface, not the SPI protocol) is a good thing to have > to support > > serial ports layered over other transports. However these are still serial > > ports at the end. I still don't think the javax.comm API is well suited to > > "any" serial bus such as I2C, SPI, etc. > > > >Perhaps the javax.com namespace is just wrong. I think thats a larger >issue we are not well prepared to answer. We do have a larger group >participating so there is interest beyond our current solution. My concern was not about the name specifically, but about the idea that a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, IrDA, etc. Looking from a distance all of these may look similar but the fact is, they have little to do with each other (apart from being 'communication protocols' or 'buses') Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From Paul.Klissner at Sun.COM Tue Jul 25 01:51:26 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Tue, 25 Jul 2006 00:51:26 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725082630.036d2d10@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> Message-ID: <44C5CD7E.9030903@sun.com> Guillermo Rodriguez Garcia wrote: > At 19:41 24/07/2006, Paul Klissner wrote: >> Guillermo Rodriguez wrote: >>> Quoting Paul Klissner : >>> >>>>>> None of this is of any particular relevance to the basic underlying >>>>>> question: >>>>>> >>>>>> Should the next JSR attempt to address the multi-drop abilities of >>>> RS-485? >>>>> What I would suggest is to just add a new 'ioctlex'-like method >>>>> to the SerialPort API: A method that you'd use to pass platform- >>>>> or implementation-specific info to the underlying driver or OS >>>>> to do things such as "enabling RS485 mode" or "disable FIFOs" or >>>>> "poll the TSR register". >>>>> >>>>> No need to define any function codes. This is for stuff that is >>>>> platform- or implementation-specific and as such cannot be easily >>>>> abstracted anyway. >>>> Detrimental to platform independence. >>> Yes, it is. But as you go closer and closer to the hardware level some >>> things are by nature platform-dependent, and sometimes just cannot be >>> solved in a platform-independent way. In these cases, is it better to >>> have no solution at all than having one that is less than perfect? >>> Put it another way, would you prefer having people say "I just cannot >>> do this in Java; I'll go somewhere else" rather than "I can do this >>> in Java -- only not in a platform-independent way" ? >> If there isn't a reasonable way to abstract it out, then >> why use Java? > > If an application can be 99% platform independent with small bits > being not portable, why *not* use Java? I'd prefer to see people > using Java to write non-portable applications than having them > use C instead. > > I believe that Java should promote platform neutrality, but that > does not necessarily mean precluding the use of anything that is > NOT platform independent. And let's face it, if you are using > javax.comm to talk to some serial device directly, then chances > are you are already tied to some specific hardware anyway. > > Also, some people (myself included) think that Java can also be > used as a systems programming language, not only for applications. > For many embedded platforms this is certainly the case. In our > platform we even write device drivers directly in Java. I would > imagine the Sun SPOT team (www.sunspotworld.com) supports a > similar view. > > If people needs to do non-portable stuff and wants to do it in > Java I'd rather have them do it in Java than tell them to do it > in C instead. That sounds a bit evangelizing. I think C is perfectly viable for some jobs, and might even be preferable in some cases, for example in some cases where performance or space is a factor. I feel it isn't right to corrupt an API with hacks for the goal of enticing users to Java, even for all the 'right' reasons. >> If someone really needs to do funky things with the hardware, >> why wouldn't that be put in the native back end? > > But nobody said the functionality can't be implemented in the > native back end. However you still need an application level API > to enable/disable it. Sure, but the functions, if really along the lines of the defined standard, can be abstracted, rather than cheat with a general purpose hack-all ioctl-like interface that just begs to be abused, lending itself to a litany of non-portable applications. I maintain we should scope the project appropriately, then take our best shot at a reasonably complete set of abstract functions, and improve it if necessary over time (alpha and beta, release candidates? And then update the API in a backward-compatible way based on feedback after FCS if necessary), rather than add an everything-but-the-kitchen-sink escape clause method. A determined programmer facing a corner case can figure out a way to accomplish the goal in most cases. Even if the API doesn't provide an ioctl call, it is possible to create implementation classes that mak methods visible outsidethe scope of the API-defined methods. For example, if I am implementing class Foo in FooImpl.java, And Foo.java defines interface methods a(), b() and c(), FooImpl.java can also have public methods d(), e() and f(), which can be accessed from the application by casting a Foo object into a FooImpl object. This is one way to provide a back door without compromising the core API itself to do it. This puts the responsibility of breaking platform independence on the developers and not on the designers. Paul From tjarvi at qbang.org Tue Jul 25 02:57:28 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 02:57:28 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725094602.036cec00@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> Message-ID: On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: > Hi Trent, > > At 09:21 25/07/2006, Trent Jarvi wrote: >> On Tue, 25 Jul 2006, Guillermo Rodriguez Garcia wrote: >> >>> At 19:34 24/07/2006, Gregg Wonderly wrote: >>>> Guillermo Rodriguez wrote: >>>>> As an embedded Java vendor, SNIJDER Micro Systems certainly sees the >>>>> value of standardized APIs to talk to different types of communication >>>>> buses including SPI, I2C, 1-Wire, etc., for embedded applications. >>>>> However we think this has nothing to do with javax.comm. >>>> >>>> I don't think this is only about javax.comm. Certainly that's >>>> important. I'm >>>> just wading into this conversation mainstream and trying to say: >>>> >>>> If you are going to do anything about "fixing" javax.comm to work on all >>>> platforms, please, please, please start with a hardware port SPI >>>> definition that >>>> lets you get to serial ports, and then provide the existing >> javax.com API and >>>> whatever new API you think is necessary (I don't have any really >>>> issues with the >>>> existing API directly). >>>> >>>> Then, there will be a place for others interesting in SPI, i2C, >> USB and other >>>> things to get started with providing access to devices that are also >>>> interesting >>>> in Java applications, and directly, in embedded Java applications. >>> >>> I do agree that the best a hardware port SPI definition (where >> SPI = Service >>> Provider Interface, not the SPI protocol) is a good thing to have >> to support >>> serial ports layered over other transports. However these are still serial >>> ports at the end. I still don't think the javax.comm API is well suited to >>> "any" serial bus such as I2C, SPI, etc. >>> >> >> Perhaps the javax.com namespace is just wrong. I think thats a larger >> issue we are not well prepared to answer. We do have a larger group >> participating so there is interest beyond our current solution. > > My concern was not about the name specifically, but about the idea that > a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, > IrDA, etc. Looking from a distance all of these may look similar but > the fact is, they have little to do with each other (apart from being > 'communication protocols' or 'buses') > Hi Guillermo Interesting name. Fair enough. My thoughts are that if it can't be unified in the kernel we are out of our skulls trying to do it in user space. Hacks trying to do such will sure to be in open solaris or linux symposiums about why user space sucks. But there is a minimal bit that overlapps that is what most users want. If we limit the scope, it isnt that hard of a problem. By limiting the scope we also limit our deliverables. If you have an interest in a specific area it will probably not be enough. -- Trent Jarvi tjarvi at qbang.org From martin at jopdesign.com Tue Jul 25 03:25:38 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 11:25:38 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> Message-ID: <001901c6afcc$4bcf64f0$0c28a8c0@luna> >> >> >> >> What I would suggest is to just add a new 'ioctlex'-like method >> >> to the SerialPort API: A method that you'd use to pass platform- >> >> or implementation-specific info to the underlying driver or OS >> >> to do things such as "enabling RS485 mode" or "disable FIFOs" or >> >> "poll the TSR register". >> >> >> >> No need to define any function codes. This is for stuff that is >> >> platform- or implementation-specific and as such cannot be easily >> >> abstracted anyway. >> > >> > Detrimental to platform independence. >> >>We can model it platform independent with two methods: >> >>enterTransmit() and extiTransmit() to do whatever is necessary >>on the underlying platform to switch to RS485 transmit mode and >>back. > > Tempting as it is, I don't think this covers all cases. For example, > in those cases where RS485 direction control must be done 100% in > software, the software needs to have a way to flush (sync) software > buffers, poll the hardware FIFOs and TSR (not THR), etc. I just meant to hide those low-level issues you mention in the enter/exitTransmit modes. > > Or, for example, for those UARTs that do automatic RS485 direction > control with a configurable turnaround delay, how would you configure > this turnaround delay from the application? Mmh, perhaps in a similar way as you configure timeouts? Isn't this 'just' a timeout value? Martin From guille at sms.nl Tue Jul 25 04:05:29 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 12:05:29 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <001901c6afcc$4bcf64f0$0c28a8c0@luna> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> Message-ID: <7.0.1.0.0.20060725115736.03706a38@sms.nl> At 11:25 25/07/2006, Martin Schoeberl wrote: > >> >> > >> >> What I would suggest is to just add a new 'ioctlex'-like method > >> >> to the SerialPort API: A method that you'd use to pass platform- > >> >> or implementation-specific info to the underlying driver or OS > >> >> to do things such as "enabling RS485 mode" or "disable FIFOs" or > >> >> "poll the TSR register". > >> >> > >> >> No need to define any function codes. This is for stuff that is > >> >> platform- or implementation-specific and as such cannot be easily > >> >> abstracted anyway. > >> > > >> > Detrimental to platform independence. > >> > >>We can model it platform independent with two methods: > >> > >>enterTransmit() and extiTransmit() to do whatever is necessary > >>on the underlying platform to switch to RS485 transmit mode and > >>back. > > > > Tempting as it is, I don't think this covers all cases. For example, > > in those cases where RS485 direction control must be done 100% in > > software, the software needs to have a way to flush (sync) software > > buffers, poll the hardware FIFOs and TSR (not THR), etc. > >I just meant to hide those low-level issues you mention in the >enter/exitTransmit modes. If the system has dedicated RS485 hardware then the underlying kernel or device driver may know about it and all of the hassle can be conveniently encapsulated in some enter/exitTransmit methods -- but in this case you can also skip these and just have the driver enable transmit mode as long as it has data to transmit, and stay in receive mode otherwise. If the system has a UART that can be configured as RS232 or RS485 then you may need to tell the kernel or device driver to enter RS485 mode explicitly. Your approach may work there as well. If the system does not have dedicated RS485 hardware and you are using an external RS232-RS485 protocol converter (a very common case) then the driver and kernel probably don't know about that and you have to take care at the application level (javax.comm doesn't even need to know this converter exists), and in order to that you may need to do different things depending on the specific converter you're using. > > > > Or, for example, for those UARTs that do automatic RS485 direction > > control with a configurable turnaround delay, how would you configure > > this turnaround delay from the application? > >Mmh, perhaps in a similar way as you configure timeouts? >Isn't this 'just' a timeout value? Yes, but this is just a specific parameter that you can configure in a specific type of UART (an EXAR UART). Other UARTs might be different. The point I'm trying to make is that there are just too many parameters to have an API for each specific case. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 04:12:31 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 12:12:31 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C5CD7E.9030903@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> <44C5CD7E.9030903@sun.com> Message-ID: <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> At 09:51 25/07/2006, Paul Klissner wrote: >Guillermo Rodriguez Garcia wrote: > > At 19:41 24/07/2006, Paul Klissner wrote: > >> Guillermo Rodriguez wrote: > >>> Quoting Paul Klissner : > >>> > >>>>>> None of this is of any particular relevance to the basic underlying > >>>>>> question: > >>>>>> > >>>>>> Should the next JSR attempt to address the multi-drop abilities of > >>>> RS-485? > >>>>> What I would suggest is to just add a new 'ioctlex'-like method > >>>>> to the SerialPort API: A method that you'd use to pass platform- > >>>>> or implementation-specific info to the underlying driver or OS > >>>>> to do things such as "enabling RS485 mode" or "disable FIFOs" or > >>>>> "poll the TSR register". > >>>>> > >>>>> No need to define any function codes. This is for stuff that is > >>>>> platform- or implementation-specific and as such cannot be easily > >>>>> abstracted anyway. > >>>> Detrimental to platform independence. > >>> Yes, it is. But as you go closer and closer to the hardware level some > >>> things are by nature platform-dependent, and sometimes just cannot be > >>> solved in a platform-independent way. In these cases, is it better to > >>> have no solution at all than having one that is less than perfect? > >>> Put it another way, would you prefer having people say "I just cannot > >>> do this in Java; I'll go somewhere else" rather than "I can do this > >>> in Java -- only not in a platform-independent way" ? > >> If there isn't a reasonable way to abstract it out, then > >> why use Java? > > > > If an application can be 99% platform independent with small bits > > being not portable, why *not* use Java? I'd prefer to see people > > using Java to write non-portable applications than having them > > use C instead. > > > > I believe that Java should promote platform neutrality, but that > > does not necessarily mean precluding the use of anything that is > > NOT platform independent. And let's face it, if you are using > > javax.comm to talk to some serial device directly, then chances > > are you are already tied to some specific hardware anyway. > > > > Also, some people (myself included) think that Java can also be > > used as a systems programming language, not only for applications. > > For many embedded platforms this is certainly the case. In our > > platform we even write device drivers directly in Java. I would > > imagine the Sun SPOT team (www.sunspotworld.com) supports a > > similar view. > > > > If people needs to do non-portable stuff and wants to do it in > > Java I'd rather have them do it in Java than tell them to do it > > in C instead. > >That sounds a bit evangelizing. Could be, but then what's wrong with that? As I said there is people that thinks that Java can be perfectly adequate for system level programming -- especially for embedded platforms. I guess the whole issue is whether it is better to have no solution at all for a specific problem than a solution that is not perfect (in this context a "perfect" solution is one that is portable and platform-independent). I think a solution that is not perfect is better than no solution. If I understand correctly you say that you prefer to have no Java solution (and have people use C) rather than one that is not portable. >I think C is perfectly viable >for some jobs, and might even be preferable in some cases, for example >in some cases where performance or space is a factor. I feel it isn't >right to corrupt an API with hacks for the goal of enticing users >to Java, even for all the 'right' reasons. > > >> If someone really needs to do funky things with the hardware, > >> why wouldn't that be put in the native back end? > > > > But nobody said the functionality can't be implemented in the > > native back end. However you still need an application level API > > to enable/disable it. > >Sure, but the functions, if really along the lines of the defined >standard, can be abstracted, rather than cheat with a general >purpose hack-all ioctl-like interface that just begs to be abused, >lending itself to a litany of non-portable applications. Well, I didn't specifically say there's no way to abstract these functions. I only said that it is not easy, and that I don't know of any reasonable way to do it. But if others can find a way, that is fine of course. >I maintain we should scope the project appropriately, then take >our best shot at a reasonably complete set of abstract functions, >and improve it if necessary over time (alpha and beta, release >candidates? And then update the API in a backward-compatible way >based on feedback after FCS if necessary), rather than add an >everything-but-the-kitchen-sink escape clause method. > >A determined programmer facing a corner case can figure out a way >to accomplish the goal in most cases. Even if the API doesn't provide >an ioctl call, it is possible to create implementation classes that >mak methods visible outsidethe scope of the API-defined methods. > >For example, if I am implementing class Foo in FooImpl.java, >And Foo.java defines interface methods a(), b() and c(), >FooImpl.java can also have public methods d(), e() and f(), which can >be accessed from the application by casting a Foo object into >a FooImpl object. This is one way to provide a back door without >compromising the core API itself to do it. This puts the >responsibility of breaking platform independence on the developers >and not on the designers. Yes, that may be a good way to do it. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 04:21:31 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 12:21:31 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> Message-ID: <7.0.1.0.0.20060725121958.03714668@sms.nl> Hi Trent, At 10:57 25/07/2006, Trent Jarvi wrote: > >> Perhaps the javax.com namespace is just wrong. I think thats a larger > >> issue we are not well prepared to answer. We do have a larger group > >> participating so there is interest beyond our current solution. > > > > My concern was not about the name specifically, but about the idea that > > a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, > > IrDA, etc. Looking from a distance all of these may look similar but > > the fact is, they have little to do with each other (apart from being > > 'communication protocols' or 'buses') > > > >Hi Guillermo > >Interesting name. > >Fair enough. My thoughts are that if it can't be unified in the kernel we >are out of our skulls trying to do it in user space. Hacks trying to do >such will sure to be in open solaris or linux symposiums about why user >space sucks. > >But there is a minimal bit that overlapps that is what most users want. >If we limit the scope, it isnt that hard of a problem. By limiting the >scope we also limit our deliverables. If you have an interest in a >specific area it will probably not be enough. Yes, you are right. But isn't this 'minimal bit that overlaps' what we have already? (basically support for UART-based serial ports plus minimal support for parallel ports) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From lyon at docjava.com Tue Jul 25 05:44:43 2006 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 25 Jul 2006 07:44:43 -0400 Subject: [Rxtx] 7 RS485 questions... In-Reply-To: <7.0.1.0.0.20060725115736.03706a38@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: Hi All, 1. Does anyone have a sense for how much larger the JSR would be if it embraced a multi-drop protocol, like RS485? 2. Do we address collision detection and addressing in RS485? 3. How would collision detection and addressing impact the size of the specification? 4. Would JSR80 (and, perhaps a RS485-USB converter) be the more appropriate place for RS485 support? 5. Is RS485 Transmission controlled by RTS, and the TxD line? 6. How tight is the windows timing on control of the RTS line? 7. Does an RTS controlled RS485 converter work well at high baud rates under windows? Thanks! - Doug From naranjo.manuel at gmail.com Tue Jul 25 06:29:45 2006 From: naranjo.manuel at gmail.com (Manuel Francisco Naranjo) Date: Tue, 25 Jul 2006 09:29:45 -0300 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725094602.036cec00@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> Message-ID: <44C60EB9.5000803@gmail.com> Guillermo Rodriguez Garcia escribi?: > My concern was not about the name specifically, but about the idea that > a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, > IrDA, etc. Looking from a distance all of these may look similar but > the fact is, they have little to do with each other (apart from being > 'communication protocols' or 'buses') > I think Guillermo is right, all ports has in common that they are buses. A stupid idea but why don't declarate the package javax.bus and make javax.comm a dedicated namespace to rs232 and parallell to mantain backward compatibility, obviously the classes at javax.comm should extend classes from javax.bus. Regards, Manuel From j.a.horsmeier at wanadoo.nl Tue Jul 25 07:00:17 2006 From: j.a.horsmeier at wanadoo.nl (Jos A. Horsmeier) Date: Tue, 25 Jul 2006 15:00:17 +0200 Subject: [Rxtx] 7 RS485 questions... In-Reply-To: Message-ID: <05a701c6afea$47002e00$0a01a8c0@CALVIN> Douglas Lyon wrote: > 1. Does anyone have a sense for how much larger the JSR would > be if it embraced a multi-drop protocol, like RS485? The RS485 multidrop capability all resides on top of the communication layer, i.e. all transmitters but one are disabled (all devices are just listening). When the message has been sent at most one device answers (see 2) > 2. Do we address collision detection and addressing in RS485? Addressing a device is also implemented on top of the communication layer. If/when two devices happen to have the same address it would be disastrous. An address is defined by the protocol, e.g. modbus allows for 250 or so different addresses but another protocol might allow for 2^32 different devices hooked up on one two wire cable. > 3. How would collision detection and addressing impact the size of > the specification? IMHO it's none of rxtx's business, it's a configuration error on the devices if that happens. > 4. Would JSR80 (and, perhaps a RS485-USB converter) be the > more appropriate place for RS485 support? Don't know. > 5. Is RS485 Transmission controlled by RTS, and the TxD line? Two wire RS485 doesn't have a RTS line. It's all in the timing. The half duplex protocol is extremely simple: one master sends, all devices listen, after that at most one device enables its transmitter and sends something back. > 6. How tight is the windows timing on control of the RTS line? Before a device enables its transmitter it should wait a bit because of cable lengths and the other device that must *disable* its transmitter. It's all up to the devices and rxtx can do nothing about it. > 7. Does an RTS controlled RS485 converter work well at high baud > rates under windows? Baud rates aren't the problem; cable lengths are the problem, sensitivity for distortion are the problem. The wait time between en/disabling transmitters can be configured in the devices and can be software controlled on the pc. kind regards, Jos From tjarvi at qbang.org Tue Jul 25 07:08:53 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 07:08:53 -0600 (MDT) Subject: [Rxtx] 7 RS485 questions... In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: > 5. Is RS485 Transmission controlled by RTS, and the TxD line? This is done when using EIA232 to drive RS485 with no adaptor. This is the RS485 hack that is in RXTX 2.1 that never went anyplace. I discovered no typical kernel will openly support this line of thought. It is not maintainable. There are hardware solutions. Off the top of my head it required < 10 ms responses and typical kernels + java do 10 ms responses. Realtime kernels or special kernel drivers are required. It is possible but not supportable. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Tue Jul 25 07:46:52 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 08:46:52 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <005b01c6afbc$794fc060$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> Message-ID: <44C620CC.6090901@cox.net> Martin Schoeberl wrote: > We can model it platform independent with two methods: > > enterTransmit() and extiTransmit() to do whatever is necessary > on the underlying platform to switch to RS485 transmit mode and > back. Or, do what is typically done, and use a single write operation as the indication of a 'packet' that will let the underlying RS-485/422 driver assert the appropriate signalling. Gregg Wonderly From guille at sms.nl Tue Jul 25 07:48:04 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Tue, 25 Jul 2006 15:48:04 +0200 Subject: [Rxtx] 7 RS485 questions... In-Reply-To: References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: <7.0.1.0.0.20060725154329.036deb18@sms.nl> Hi Doug, Some answers below. At 13:44 25/07/2006, Dr. Douglas Lyon wrote: >Hi All, > >1. Does anyone have a sense for how much larger the JSR would be >if it embraced a multi-drop protocol, like RS485? As I've said in other mails RS485 is in essence just a UART-based serial port interface just like RS232. The only functional difference is that it is multi-drop and half-duplex so there must be a way for nodes to switch between transmit and receive modes but then the RS485 standard does not tell you when or how you should do that -- this depends on the upper layer protocols (for example Modbus) >2. Do we address collision detection and addressing in RS485? Collision detection and addressing are not defined by the RS485 standard. Upper layer protocols such as Modbus take care of that. >3. How would collision detection and addressing impact the size of >the specification? See above. >4. Would JSR80 (and, perhaps a RS485-USB converter) be the more appropriate >place for RS485 support? I don't think so. As I said RS485 is just a serial port like RS232 is. >5. Is RS485 Transmission controlled by RTS, and the TxD line? Some RS232-RS485 protocol converters use the RTS line as a control signal to switch between transmit and receive modes. Others use DTR. Others do not use any of them. >6. How tight is the windows timing on control of the RTS line? Depends on the upper layer protocols, e.g. Modbus. Not defined by RS485. >7. Does an RTS controlled RS485 converter work well at high baud >rates under windows? Depends on how tight the timing is. For some applications it may work well but for many probably won't. Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Tue Jul 25 09:22:09 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Tue, 25 Jul 2006 17:22:09 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C620CC.6090901@cox.net> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> Message-ID: <1153840929.44c6372186f67@webmail.eatserver.nl> Hi Gregg, Quoting Gregg Wonderly : > Martin Schoeberl wrote: > > We can model it platform independent with two methods: > > > > enterTransmit() and extiTransmit() to do whatever is necessary > > on the underlying platform to switch to RS485 transmit mode and > > back. > > Or, do what is typically done, and use a single write operation as the > indication of a 'packet' that will let the underlying RS-485/422 driver > assert > the appropriate signalling. The problem with this is that there is no guarantee that a single call to the write method of the OutputStream associated with a javax.comm SerialPort will translate to a single write to the underlying device driver -- this depends on the javax.comm implementation. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From Paul.Klissner at Sun.COM Tue Jul 25 09:35:19 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Tue, 25 Jul 2006 08:35:19 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C60EB9.5000803@gmail.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> <44C60EB9.5000803@gmail.com> Message-ID: <44C63A37.8080406@sun.com> Manuel Francisco Naranjo wrote: > Guillermo Rodriguez Garcia escribi?: >> My concern was not about the name specifically, but about the idea that >> a single API should cover, at the same time, RSxxx, SPI, I2C, 1-Wire, >> IrDA, etc. Looking from a distance all of these may look similar but >> the fact is, they have little to do with each other (apart from being >> 'communication protocols' or 'buses') >> > I think Guillermo is right, all ports has in common that they are buses. > A stupid idea but why don't declarate the package javax.bus and make > javax.comm a dedicated namespace to rs232 and parallell to mantain > backward compatibility, obviously the classes at javax.comm should > extend classes from javax.bus. I like the initial sound of that idea too and was starting to think along those lines myself. But what would be the points of commonality to extend? Device mapping, ownership? Read, write, type, status? Too late for javax.usb (JSR80) very complex Bus and for the most part cast in stone. And 'bus' has such a wide scope. Also that would imply two downloads to install any given bus support, which might not be the end of the world. And maybe two JSRs? Paul From martin at jopdesign.com Tue Jul 25 09:37:12 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 17:37:12 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> Message-ID: <00c801c6b000$33a68f00$0c28a8c0@luna> >> Martin Schoeberl wrote: >> > We can model it platform independent with two methods: >> > >> > enterTransmit() and extiTransmit() to do whatever is necessary >> > on the underlying platform to switch to RS485 transmit mode and >> > back. >> >> Or, do what is typically done, and use a single write operation as the >> indication of a 'packet' that will let the underlying RS-485/422 driver >> assert >> the appropriate signalling. > > The problem with this is that there is no guarantee that a single call > to the write method of the OutputStream associated with a javax.comm > SerialPort will translate to a single write to the underlying device > driver -- this depends on the javax.comm implementation. > I completely agree - it's still a stream and not a packet. This is similar to a single write to a TCP/IP socket. There is no guarantee that you get this data as a single packet/single read on the other side. However, I've seen a lot of programs assuming that this happens ;-) Martin From gergg at cox.net Tue Jul 25 10:15:41 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 11:15:41 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725082124.036309e0@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> Message-ID: <44C643AD.6020604@cox.net> Guillermo Rodriguez Garcia wrote: > At 19:34 24/07/2006, Gregg Wonderly wrote: >>Then, there will be a place for others interesting in SPI, i2C, USB and other >>things to get started with providing access to devices that are also >>interesting >>in Java applications, and directly, in embedded Java applications. > > I do agree that the best a hardware port SPI definition (where SPI = Service > Provider Interface, not the SPI protocol) is a good thing to have to support > serial ports layered over other transports. However these are still serial > ports at the end. I still don't think the javax.comm API is well suited to > "any" serial bus such as I2C, SPI, etc. Yes, absolutely these other wire protocols are different. As I tried to say before, I think that the javax.comm API works fine for my needs. I think that we need to keep it around, no matter what else happens. So, for me, there are a few choices. 1. Create a new JSR to formalize the existing API and include some hardwired JNI code to provide port enumeration and access. 2. Create a new JSR to create a port abstraction SPI to allow JVM providers to enumerate all kinds of port/circuit based hardware to the JVM. Create an implementation of the existing javax.comm API that uses this SPI. 3. Just implement some JNI and Java libraries post them on sourceforge/java.net and let people have at them. For 1 and 2, you'll have to get the JCP to approve that the JSR is worth making a standard. Option 3 doesn't really solve a problem as much as it creates a new way to deal with an existing problem. I think 2 is the most desireable way to go. It really will open the door for more access to hardware from Java! Gregg Wonderly From joachim at buechse.de Tue Jul 25 10:17:07 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 25 Jul 2006 18:17:07 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <00c801c6b000$33a68f00$0c28a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: Just trigger writing on flush(). It is perfectly legal for an Outputstream implementation to do do nothing until flush is called and the documentation of OutputStream.flush reads: "Flushes this output stream and forces any buffered output bytes to be written out. The general contract of flush is that calling it is an indication that, if any bytes previously written have been buffered by the implementation of the output stream, such bytes should immediately be written to their intended destination." As RS485 is a "dont speak up unless requested" protocol, a mandatory flush after write seems like the way to go to me No client can prevent another client from writing, so there is no point in keeping the output-drivers enabled after all data currently buffered has been written. So flush() should trigger "enterTransmit, writePacket[s], exitTransmit". If the service provider (ie concrete implementation of the flush method) decides that the write is inapropriate at the moment (ie because of a higher level arbitration protocol that might be implemented by the service provider) it will simply block the flush or throw an IOException (preferably after some sort of timeout). Regards, Joachim PS: It is great to see all the motivation that is brought forward on this list regarding the future. It would be great if only 10% of that motivation could be transformed into a cleanup and extension of the existing code. The current code access model seems rather inappropriate for the prototyping of the ideas beeing presented. Trent can we get a "contributions" branch with "free" access. On 25.07.2006, at 17:37, Martin Schoeberl wrote: >>> Martin Schoeberl wrote: >>>> We can model it platform independent with two methods: >>>> >>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>> on the underlying platform to switch to RS485 transmit mode and >>>> back. >>> >>> Or, do what is typically done, and use a single write operation >>> as the >>> indication of a 'packet' that will let the underlying RS-485/422 >>> driver >>> assert >>> the appropriate signalling. >> >> The problem with this is that there is no guarantee that a single >> call >> to the write method of the OutputStream associated with a javax.comm >> SerialPort will translate to a single write to the underlying device >> driver -- this depends on the javax.comm implementation. >> > I completely agree - it's still a stream and not a packet. > > This is similar to a single write to a TCP/IP socket. There > is no guarantee that you get this data as a single packet/single > read on the other side. However, I've seen a lot of programs > assuming that this happens ;-) > > Martin > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From guille at sms.nl Tue Jul 25 10:34:59 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Tue, 25 Jul 2006 18:34:59 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <1153845299.44c64833920bd@webmail.eatserver.nl> Hi Joachim, That is a very nice approach which I think would work well as far as the underlying device driver knows about RS485. However it still does not solve the problem with external protocol converters where the device driver only knows about regular UARTs and RTS or DTR must be used to toggle direction of the converter. Guillermo Quoting Joachim Buechse : > Just trigger writing on flush(). It is perfectly legal for an > Outputstream implementation to do do nothing until flush is called > and the documentation of OutputStream.flush reads: > > "Flushes this output stream and forces any buffered output bytes to > be written out. The general contract of flush is that calling it is > an indication that, if any bytes previously written have been > buffered by the implementation of the output stream, such bytes > should immediately be written to their intended destination." > > As RS485 is a "dont speak up unless requested" protocol, a mandatory > flush after write seems like the way to go to me > > No client can prevent another client from writing, so there is no > point in keeping the output-drivers enabled after all data currently > buffered has been written. So flush() should trigger "enterTransmit, > writePacket[s], exitTransmit". If the service provider (ie concrete > implementation of the flush method) decides that the write is > inapropriate at the moment (ie because of a higher level arbitration > protocol that might be implemented by the service provider) it will > simply block the flush or throw an IOException (preferably after some > sort of timeout). > > Regards, > Joachim > > PS: It is great to see all the motivation that is brought forward on > this list regarding the future. It would be great if only 10% of that > motivation could be transformed into a cleanup and extension of the > existing code. The current code access model seems rather > inappropriate for the prototyping of the ideas beeing presented. > Trent can we get a "contributions" branch with "free" access. > > > On 25.07.2006, at 17:37, Martin Schoeberl wrote: > > >>> Martin Schoeberl wrote: > >>>> We can model it platform independent with two methods: > >>>> > >>>> enterTransmit() and extiTransmit() to do whatever is necessary > >>>> on the underlying platform to switch to RS485 transmit mode and > >>>> back. > >>> > >>> Or, do what is typically done, and use a single write operation > >>> as the > >>> indication of a 'packet' that will let the underlying RS-485/422 > >>> driver > >>> assert > >>> the appropriate signalling. > >> > >> The problem with this is that there is no guarantee that a single > >> call > >> to the write method of the OutputStream associated with a javax.comm > >> SerialPort will translate to a single write to the underlying device > >> driver -- this depends on the javax.comm implementation. > >> > > I completely agree - it's still a stream and not a packet. > > > > This is similar to a single write to a TCP/IP socket. There > > is no guarantee that you get this data as a single packet/single > > read on the other side. However, I've seen a lot of programs > > assuming that this happens ;-) > > > > Martin > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- http://www.snijder.com/ SNIJDER Micro Systems From guille at sms.nl Tue Jul 25 10:44:56 2006 From: guille at sms.nl (Guillermo Rodriguez) Date: Tue, 25 Jul 2006 18:44:56 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C643AD.6020604@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <44C643AD.6020604@cox.net> Message-ID: <1153845896.44c64a8890968@webmail.eatserver.nl> Hi Gregg, Quoting Gregg Wonderly : > Guillermo Rodriguez Garcia wrote: > > At 19:34 24/07/2006, Gregg Wonderly wrote: > >>Then, there will be a place for others interesting in SPI, i2C, USB and > other > >>things to get started with providing access to devices that are also > >>interesting > >>in Java applications, and directly, in embedded Java applications. > > > > I do agree that the best a hardware port SPI definition (where SPI = > Service > > Provider Interface, not the SPI protocol) is a good thing to have to > support > > serial ports layered over other transports. However these are still serial > > ports at the end. I still don't think the javax.comm API is well suited to > > "any" serial bus such as I2C, SPI, etc. > > Yes, absolutely these other wire protocols are different. As I tried to say > > before, I think that the javax.comm API works fine for my needs. I think > that > we need to keep it around, no matter what else happens. So, for me, there > are a > few choices. > > 1. Create a new JSR to formalize the existing API and include some hardwired > JNI > code to provide port enumeration and access. > > 2. Create a new JSR to create a port abstraction SPI to allow JVM providers > to > enumerate all kinds of port/circuit based hardware to the JVM. Create an > implementation of the existing javax.comm API that uses this SPI. As an embedded Java vendor we work very close to the hardware level and have to deal daily with dozens of different types of ports and communication buses and protocols. Based on our experience I think that a SPI for "all kinds of port/circuit based hardware" is just too generic and not really practical. I think having a Service Provider Interface within javax.comm so that custom serial port implementations can be plugged in is a very good idea. However I don't think it is convenient to have it as a separate JSR and then with such a broad scope. Guillermo -- http://www.snijder.com/ SNIJDER Micro Systems From joachim at buechse.de Tue Jul 25 10:56:12 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 25 Jul 2006 18:56:12 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <1153845299.44c64833920bd@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> <1153845299.44c64833920bd@webmail.eatserver.nl> Message-ID: In this case you need to configure your port with a different device driver. You may optionally take an existing port, wrap it up in a "wrapping device driver" implemented in Java and add it to the list of ports as a new port... In any case the core application should not care. On 25.07.2006, at 18:34, Guillermo Rodriguez wrote: > Hi Joachim, > > That is a very nice approach which I think would work well as far > as the underlying device driver knows about RS485. > > However it still does not solve the problem with external protocol > converters where the device driver only knows about regular UARTs > and RTS or DTR must be used to toggle direction of the converter. > > Guillermo > > Quoting Joachim Buechse : > >> Just trigger writing on flush(). It is perfectly legal for an >> Outputstream implementation to do do nothing until flush is called >> and the documentation of OutputStream.flush reads: >> >> "Flushes this output stream and forces any buffered output bytes to >> be written out. The general contract of flush is that calling it is >> an indication that, if any bytes previously written have been >> buffered by the implementation of the output stream, such bytes >> should immediately be written to their intended destination." >> >> As RS485 is a "dont speak up unless requested" protocol, a mandatory >> flush after write seems like the way to go to me >> >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). >> >> Regards, >> Joachim >> >> PS: It is great to see all the motivation that is brought forward on >> this list regarding the future. It would be great if only 10% of that >> motivation could be transformed into a cleanup and extension of the >> existing code. The current code access model seems rather >> inappropriate for the prototyping of the ideas beeing presented. >> Trent can we get a "contributions" branch with "free" access. >> >> >> On 25.07.2006, at 17:37, Martin Schoeberl wrote: >> >>>>> Martin Schoeberl wrote: >>>>>> We can model it platform independent with two methods: >>>>>> >>>>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>>>> on the underlying platform to switch to RS485 transmit mode and >>>>>> back. >>>>> >>>>> Or, do what is typically done, and use a single write operation >>>>> as the >>>>> indication of a 'packet' that will let the underlying RS-485/422 >>>>> driver >>>>> assert >>>>> the appropriate signalling. >>>> >>>> The problem with this is that there is no guarantee that a single >>>> call >>>> to the write method of the OutputStream associated with a >>>> javax.comm >>>> SerialPort will translate to a single write to the underlying >>>> device >>>> driver -- this depends on the javax.comm implementation. >>>> >>> I completely agree - it's still a stream and not a packet. >>> >>> This is similar to a single write to a TCP/IP socket. There >>> is no guarantee that you get this data as a single packet/single >>> read on the other side. However, I've seen a lot of programs >>> assuming that this happens ;-) >>> >>> Martin >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > > -- > http://www.snijder.com/ > SNIJDER Micro Systems > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From martin at jopdesign.com Tue Jul 25 11:13:10 2006 From: martin at jopdesign.com (Martin Schoeberl) Date: Tue, 25 Jul 2006 19:13:10 +0200 Subject: [Rxtx] JSR Direction; packetizing writes References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com><005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net><1153840929.44c6372186f67@webmail.eatserver.nl><00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <000f01c6b00d$9bcc51c0$0202a8c0@luna> > No client can prevent another client from writing, so there is no > point in keeping the output-drivers enabled after all data currently > buffered has been written. So flush() should trigger "enterTransmit, > writePacket[s], exitTransmit". If the service provider (ie concrete > implementation of the flush method) decides that the write is > inapropriate at the moment (ie because of a higher level arbitration > protocol that might be implemented by the service provider) it will > simply block the flush or throw an IOException (preferably after some > sort of timeout). Not only flush() would mean enterTransmit(). With your idea each write should enable the driver, but only flush() can disable the driver after the last byte is written. RS485 is a beast. E.g. some driver chips need a few us (100us for a Maxim 1480B!) from output enable till output low/high. On a different application we had to wait a little bit before disabling the output driver to have a clear '1' on the bus as it took too long for the termination resistors to force the bus to 1. I can imagine that this is not really funny with general RS232/RS485 converters. Martin From joachim at buechse.de Tue Jul 25 11:42:18 2006 From: joachim at buechse.de (Joachim Buechse) Date: Tue, 25 Jul 2006 19:42:18 +0200 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <000f01c6b00d$9bcc51c0$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com><005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net><1153840929.44c6372186f67@webmail.eatserver.nl><00c801c6b000$33a68f00$0c28a8c0@luna> <000f01c6b00d$9bcc51c0$0202a8c0@luna> Message-ID: Simple answer: NO. You can not control the timing of the Java VM (especially not on ME) and hence you do not want to enable the outputs before you have all data collected. The timings you mention are all in the implementation space of the device driver. The core application should not care, neither should the javax.comm api in my opinion. Should I happen to be the pour soul that tries to implement an RS485 device driver reference implementation I will try to remember your email and add appropriate properties. Regards, Joachim On 25.07.2006, at 19:13, Martin Schoeberl wrote: >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). > > Not only flush() would mean enterTransmit(). With your idea each > write should enable the driver, but only flush() can disable > the driver after the last byte is written. > > RS485 is a beast. E.g. some driver chips need a few us (100us > for a Maxim 1480B!) from output enable till output low/high. > > On a different application we had to wait a little bit before > disabling the output driver to have a clear '1' on the bus as it took > too long for the termination resistors to force the bus to 1. > > I can imagine that this is not really funny with general > RS232/RS485 converters. > > Martin > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jredman at ergotech.com Tue Jul 25 12:50:20 2006 From: jredman at ergotech.com (Jim Redman) Date: Tue, 25 Jul 2006 12:50:20 -0600 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <44C667EC.2070602@ergotech.com> The horror! This would be terribly inefficient. Especially in serial protocols you need to start getting bits on the wire as soon as possible. It could also have some timeout implications. Jim Joachim Buechse wrote: > Just trigger writing on flush(). It is perfectly legal for an > Outputstream implementation to do do nothing until flush is called > and the documentation of OutputStream.flush reads: > > "Flushes this output stream and forces any buffered output bytes to > be written out. The general contract of flush is that calling it is > an indication that, if any bytes previously written have been > buffered by the implementation of the output stream, such bytes > should immediately be written to their intended destination." > > As RS485 is a "dont speak up unless requested" protocol, a mandatory > flush after write seems like the way to go to me > > No client can prevent another client from writing, so there is no > point in keeping the output-drivers enabled after all data currently > buffered has been written. So flush() should trigger "enterTransmit, > writePacket[s], exitTransmit". If the service provider (ie concrete > implementation of the flush method) decides that the write is > inapropriate at the moment (ie because of a higher level arbitration > protocol that might be implemented by the service provider) it will > simply block the flush or throw an IOException (preferably after some > sort of timeout). > > Regards, > Joachim > > PS: It is great to see all the motivation that is brought forward on > this list regarding the future. It would be great if only 10% of that > motivation could be transformed into a cleanup and extension of the > existing code. The current code access model seems rather > inappropriate for the prototyping of the ideas beeing presented. > Trent can we get a "contributions" branch with "free" access. > > > On 25.07.2006, at 17:37, Martin Schoeberl wrote: > >>>> Martin Schoeberl wrote: >>>>> We can model it platform independent with two methods: >>>>> >>>>> enterTransmit() and extiTransmit() to do whatever is necessary >>>>> on the underlying platform to switch to RS485 transmit mode and >>>>> back. >>>> Or, do what is typically done, and use a single write operation >>>> as the >>>> indication of a 'packet' that will let the underlying RS-485/422 >>>> driver >>>> assert >>>> the appropriate signalling. >>> The problem with this is that there is no guarantee that a single >>> call >>> to the write method of the OutputStream associated with a javax.comm >>> SerialPort will translate to a single write to the underlying device >>> driver -- this depends on the javax.comm implementation. >>> >> I completely agree - it's still a stream and not a packet. >> >> This is similar to a single write to a TCP/IP socket. There >> is no guarantee that you get this data as a single packet/single >> read on the other side. However, I've seen a lot of programs >> assuming that this happens ;-) >> >> Martin >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From jredman at ergotech.com Tue Jul 25 12:53:02 2006 From: jredman at ergotech.com (Jim Redman) Date: Tue, 25 Jul 2006 12:53:02 -0600 Subject: [Rxtx] JSR Direction; packetizing writes In-Reply-To: <000f01c6b00d$9bcc51c0$0202a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com><005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net><1153840929.44c6372186f67@webmail.eatserver.nl><00c801c6b000$33a68f00$0c28a8c0@luna> <000f01c6b00d$9bcc51c0$0202a8c0@luna> Message-ID: <44C6688E.8040202@ergotech.com> Since we now seem to have entered a discussion of how to switch receive/transmit on 485 lines, I can tell you from experience that you cannot reliably do this from Java. Java just is not fast enough. I spend some time trying to get this to work with RXTX and it would work _most_ of the time, but you need to be able to guarantee ms level response which you can't do in any system that doesn't have real-time capabilities. Jim Martin Schoeberl wrote: >> No client can prevent another client from writing, so there is no >> point in keeping the output-drivers enabled after all data currently >> buffered has been written. So flush() should trigger "enterTransmit, >> writePacket[s], exitTransmit". If the service provider (ie concrete >> implementation of the flush method) decides that the write is >> inapropriate at the moment (ie because of a higher level arbitration >> protocol that might be implemented by the service provider) it will >> simply block the flush or throw an IOException (preferably after some >> sort of timeout). > > Not only flush() would mean enterTransmit(). With your idea each > write should enable the driver, but only flush() can disable > the driver after the last byte is written. > > RS485 is a beast. E.g. some driver chips need a few us (100us > for a Maxim 1480B!) from output enable till output low/high. > > On a different application we had to wait a little bit before > disabling the output driver to have a clear '1' on the bus as it took > too long for the termination resistors to force the bus to 1. > > I can imagine that this is not really funny with general > RS232/RS485 converters. > > Martin > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Jim Redman (505) 662 5156 x85 http://www.ergotech.com From gergg at cox.net Tue Jul 25 13:37:14 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 14:37:14 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725115736.03706a38@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> Message-ID: <44C672EA.1080604@cox.net> Guillermo Rodriguez Garcia wrote: > At 11:25 25/07/2006, Martin Schoeberl wrote: >>Mmh, perhaps in a similar way as you configure timeouts? >>Isn't this 'just' a timeout value? > > Yes, but this is just a specific parameter that you can configure in a > specific type of UART (an EXAR UART). Other UARTs might be different. The > point I'm trying to make is that there are just too many parameters to > have an API for each specific case. In my earlier example/proposal, I included the ability for attributes of a port to be expressed as a collection of enumeration values for standard things. That would be fine for simple things like Input, Output, Sync, Async etc. When there are specific attributes of specific hardware, the vendor is going to have to provide a way to configure those attributes. One of the primary mechanisms in Java to do this is the JavaBean pattern that can be manifested in a Map type object when an API needs to preexist. So, we can provide an mechanism for propagating random attributes using a Map argument to a method such as public void setConfig( Map params ) throws IOException; public Map getConfig() throws IOException; Then, there is a conduit in and out of the driver that the user can use without needing more standards/spec'd code/API. This isn't much different than an ioctl(2) like mechanism, but it feels more Java like. A URL like mechanism, such as that which JDBC drivers use, could also be attractive. I've also wanted to replace java.net with the J2ME connection based mechanism as well. We might consider looking at the J2ME connector architecture to see if there is any gain in using some of that experience. Gregg Wonderly From gergg at cox.net Tue Jul 25 13:38:42 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 14:38:42 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> <44C5CD7E.9030903@sun.com> <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> Message-ID: <44C67342.9020402@cox.net> Guillermo Rodriguez Garcia wrote: > At 09:51 25/07/2006, Paul Klissner wrote: >>For example, if I am implementing class Foo in FooImpl.java, >>And Foo.java defines interface methods a(), b() and c(), >>FooImpl.java can also have public methods d(), e() and f(), which can >>be accessed from the application by casting a Foo object into >>a FooImpl object. This is one way to provide a back door without >>compromising the core API itself to do it. This puts the >>responsibility of breaking platform independence on the developers >>and not on the designers. > > Yes, that may be a good way to do it. The J2ME connector architecture is an example of a place where this is done. Gregg Wonderly From Paul.Klissner at Sun.COM Tue Jul 25 14:02:40 2006 From: Paul.Klissner at Sun.COM (Paul Klissner) Date: Tue, 25 Jul 2006 13:02:40 -0700 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C67342.9020402@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <1153761294.44c5000ec1360@webmail.eatserver.nl> <44C5065F.3060802@sun.com> <7.0.1.0.0.20060725082630.036d2d10@sms.nl> <44C5CD7E.9030903@sun.com> <7.0.1.0.0.20060725120533.0362d8c8@sms.nl> <44C67342.9020402@cox.net> Message-ID: <44C678E0.90209@sun.com> Gregg Wonderly wrote: > Guillermo Rodriguez Garcia wrote: >> At 09:51 25/07/2006, Paul Klissner wrote: >>> For example, if I am implementing class Foo in FooImpl.java, >>> And Foo.java defines interface methods a(), b() and c(), >>> FooImpl.java can also have public methods d(), e() and f(), which can >>> be accessed from the application by casting a Foo object into >>> a FooImpl object. This is one way to provide a back door without >>> compromising the core API itself to do it. This puts the >>> responsibility of breaking platform independence on the developers >>> and not on the designers. >> Yes, that may be a good way to do it. > > The J2ME connector architecture is an example of a place where this is done. It's how I debugged my javax.usb implementations. Paul From Pawan.Kharbanda at dot.state.co.us Tue Jul 25 14:02:53 2006 From: Pawan.Kharbanda at dot.state.co.us (Kharbanda, Pawan) Date: Tue, 25 Jul 2006 14:02:53 -0600 Subject: [Rxtx] Strange error (show stopper) Message-ID: <939A619A756047469C41EE9BA51890FB0429DFA4@hqexchange3.dot.state.co.us> Joachim, I believe it's the same problem that I reported earlier (Thread deadlocks/Locked Ports), I am not a C person so don't know exactly whatz going in the native code but was able to find a workaround for right now by synchronizing the "interruptEventLoop" and "eventLoop" methods in the RXTXPort class. It helped but is not the right solution, I still find the deadlocks but not as often as I used too. A fix for this will be highly appreciated. I have some Test Classes that I have posted earlier to simulate the problem. ~pk -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Joachim Buechse Sent: Monday, July 24, 2006 2:13 AM To: RXTX Developers and Users Subject: Re: [Rxtx] Strange error (show stopper) The pthread_kill is followed by a sleep. When the sleep returns the structure is damaged. I did not find the source that overwrites the closing field - it is correctly set by the exiting drain thread. But something overwrites it afterwards. I currently believe that this existed for some time but was never seen because the previous versions did not rely on the structure to be in good shape when tearing down connections. However I may be completely wrong and it is an OSX problem. To help me find the source, it would be nice to get some indications what the 2 debug lines I suggested return on other platforms. Joachim On 24.07.2006, at 05:27, Trent Jarvi wrote: > On Sat, 22 Jul 2006, Joachim Buechse wrote: > >> I just discovered a strange error in RXTX on OSX. SerialDemo.java >> manages to corrupt the event_info_structure by a simple >> OpenPort,ClosePort - this could be in relation to the deadlock >> problem that was reported recently. >> >> Could anyone try to reproduce this on Solaris or some other system >> which is neither WIN32 nor Linux (ie which uses a drain thread). >> >> In SerialImp.c : RXTXPort(interruptEventLoop) >> >> Apparently the event_info_structure gets corrupted shortly after >> >> pthread_kill(index->drain_tid, SIGABRT); >> >> In particular, the index->closing flag gets overwritten by a pointer >> value. > > Hi Joachim > > Interesting. I did run many tests with that code on may OSs. To be > fair, the tests are just starting to get into good shape again. I'm > still tagging releases with a bit of feel and not enough process. > I'll look at this some more tomorrow night. > > The SIGABRT was added recently as part of the close speedups. > Thats from > memory. I can provide the exact patch that introduced that tomorrow. > > -- > Trent Jarvi > tjarvi at qbang.org > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From gergg at cox.net Tue Jul 25 17:42:23 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 18:42:23 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <1153840929.44c6372186f67@webmail.eatserver.nl> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> Message-ID: <44C6AC5F.3060107@cox.net> Guillermo Rodriguez wrote: > The problem with this is that there is no guarantee that a single call > to the write method of the OutputStream associated with a javax.comm > SerialPort will translate to a single write to the underlying device > driver -- this depends on the javax.comm implementation. More specifically, it depends on a software layer that would targeted specifically at solving this problem for RS-485 and other transports which have blocking or packetizing issues. There are many. In amatuer radio, we have TNCs (radio modems) which will block things using newline separators in some modes, and 0xc0 in others. Gregg Wonderly From gergg at cox.net Tue Jul 25 17:46:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 18:46:11 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C63A37.8080406@sun.com> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> <44C60EB9.5000803@gmail.com> <44C63A37.8080406@sun.com> Message-ID: <44C6AD43.1090302@cox.net> Paul Klissner wrote: > Also that would imply two downloads to install any given > bus support, which might not be the end of the world. > And maybe two JSRs? Why are we hovering around this "downloads" issue? If we create a JSR that covers everything needed for javax.comm compatibility, does that still imply that it would be an unincluded, optional part of the JVM? If that is still something that people will tolerate, I'm a little lost for words. Still today, I can use the old javax.comm support. If we're just going to recreate the same concerns, issues and limitations, then what's the point? Gregg Wonderly From gergg at cox.net Tue Jul 25 17:48:42 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 18:48:42 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <00c801c6b000$33a68f00$0c28a8c0@luna> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com><7.0.1.0.0.20060724082455.038aa518@sms.nl><44C4D351.603@lhar.co.za><44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl><44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna><44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <00c801c6b000$33a68f00$0c28a8c0@luna> Message-ID: <44C6ADDA.5040208@cox.net> Martin Schoeberl wrote: > I completely agree - it's still a stream and not a packet. > > This is similar to a single write to a TCP/IP socket. There > is no guarantee that you get this data as a single packet/single > read on the other side. However, I've seen a lot of programs > assuming that this happens ;-) For nearly forever, serialport drivers have operated in the mode that they send either everything up to the divider char, or a single char. This was specifically done for protocols such as modbus which have 1 1/2 bit time delays indicating end of packet. This kind of thing is something that needs to be maintained for serial protocols to work. A user has to have a way to send a single "packet" of data and make sure that it flows out of the uart uninterrupted. Gregg Wonderly From gergg at cox.net Tue Jul 25 18:03:11 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 19:03:11 -0500 Subject: [Rxtx] Strange error (show stopper) In-Reply-To: <939A619A756047469C41EE9BA51890FB0429DFA4@hqexchange3.dot.state.co.us> References: <939A619A756047469C41EE9BA51890FB0429DFA4@hqexchange3.dot.state.co.us> Message-ID: <44C6B13F.1000306@cox.net> Kharbanda, Pawan wrote: > Joachim, > I believe it's the same problem that I reported earlier (Thread > deadlocks/Locked Ports), I am not a C person so don't know exactly whatz > going in the native code but was able to find a workaround for right now > by synchronizing the "interruptEventLoop" and "eventLoop" methods in the > RXTXPort class. It helped but is not the right solution, I still find > the deadlocks but not as often as I used too. > > A fix for this will be highly appreciated. I have some Test Classes that > I have posted earlier to simulate the problem. You can send SIGQUIT (signal #3) to unix JVMs to get a stacktrace of where all the threads are at and who owns what locks. Also, on windows, you can run the JVM in a DOS window and use CTRL-BREAK to get the stack trace. This won't go beyond the native level, but it might expose what you need to know. Gregg Wonderly From tjarvi at qbang.org Tue Jul 25 22:21:22 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 22:21:22 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6AC5F.3060107@cox.net> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: On Tue, 25 Jul 2006, Gregg Wonderly wrote: > Guillermo Rodriguez wrote: >> The problem with this is that there is no guarantee that a single call >> to the write method of the OutputStream associated with a javax.comm >> SerialPort will translate to a single write to the underlying device >> driver -- this depends on the javax.comm implementation. > > More specifically, it depends on a software layer that would targeted > specifically at solving this problem for RS-485 and other transports which have > blocking or packetizing issues. There are many. In amatuer radio, we have TNCs > (radio modems) which will block things using newline separators in some modes, > and 0xc0 in others. > I had looked into RS-485 some. It is daunting without proper hardware. One option is to do a native local tcpip/udp server to remove most of the the 'java issues.' Realtime patches comming down the pipe make it tempting to jump into the tarpit of failures. Beyond that, we should be very explicit about what type of RS-485 hardware we do support and it should not involve things that we have to control DTR/RTS in almost realtime (<20 ms). There are going to be people wanting < $5/EURO winmodem type solutions that will be nothing but problems. Thats doable by hacking kernel drivers but it will never get into mainstream kernels. I do not think thats reasonable from java and is even questionable in typical C. It will work fine until you start oracle... It would be nice to get RS-485 support in. Things like controlling low cost devices in houses, ... But cutting out the hardware isn't a viable solution in java. -- Trent Jarvi tjarvi From tjarvi at qbang.org Tue Jul 25 22:40:36 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 22:40:36 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6AD43.1090302@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4CF4F.1080706@gmail.com> <44C4D77D.5080200@cox.net> <1153752467.44c4dd93c08f7@webmail.eatserver.nl> <44C50488.1040508@cox.net> <7.0.1.0.0.20060725082124.036309e0@sms.nl> <7.0.1.0.0.20060725094602.036cec00@sms.nl> <44C60EB9.5000803@gmail.com> <44C63A37.8080406@sun.com> <44C6AD43.1090302@cox.net> Message-ID: On Tue, 25 Jul 2006, Gregg Wonderly wrote: > Paul Klissner wrote: >> Also that would imply two downloads to install any given >> bus support, which might not be the end of the world. >> And maybe two JSRs? > > Why are we hovering around this "downloads" issue? If we create a JSR that > covers everything needed for javax.comm compatibility, does that still imply > that it would be an unincluded, optional part of the JVM? If that is still > something that people will tolerate, I'm a little lost for words. Still today, > I can use the old javax.comm support. If we're just going to recreate the same > concerns, issues and limitations, then what's the point? > I don't have a problem with Sun shipping rxtx or whatever it becomes. They may have some legacy issues :) Just poking fun. The current state does not work for java users. Not having w32 support means about 80+% of the users do not have support. The rxtx w32 support is heavily influenced by cygwin so it wont change license out of respect for that project. If you really hate life and the LGPL, you can do a w32 port and the rest will just fall into place while you chase windows bugs for 5 years. Anything that dances around w32 support is just an academic waste of time. -- Trent Jarvi tjarvi at qbang.org From gergg at cox.net Tue Jul 25 22:41:21 2006 From: gergg at cox.net (Gregg Wonderly) Date: Tue, 25 Jul 2006 23:41:21 -0500 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> Message-ID: <44C6F271.2020604@cox.net> Trent Jarvi wrote: > I had looked into RS-485 some. It is daunting without proper hardware. > One option is to do a native local tcpip/udp server to remove most of the > the 'java issues.' Realtime patches comming down the pipe make it tempting > to jump into the tarpit of failures. Trent, there is not a way for a non-realtime OS to drive 485 hardware without the hardware taking care of the timing issues. But, a non-realtime OS can support software APIs which let the developer express in an API the types of things that a piece of hardware is capable of. Then we can have an API, and the hardware people and the OS people will provide the solutions where possible. > It would be nice to get RS-485 support in. Things like controlling > low cost devices in houses, ... But cutting out the hardware isn't a > viable solution in java. The 485 hardware devices will have to have non-realtime requirements associated with the controlling mechanisms. There are some of those. I'm mostly interested in having a 485 API for realtime java and/or the aJile and other uC environments which can provide realtime environments. Gregg Wonderly From tjarvi at qbang.org Tue Jul 25 22:54:44 2006 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 25 Jul 2006 22:54:44 -0600 (MDT) Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6F271.2020604@cox.net> References: <200607190212.27131.pascal@quies.net><23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de><200607191411.27566.pascal@quies.net><375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de><44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com><1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <44C620CC.6090901@cox.net> <1153840929.44c6372186f67@webmail.eatserver.nl> <44C6AC5F.3060107@cox.net> <44C6F271.2020604@cox.net> Message-ID: On Tue, 25 Jul 2006, Gregg Wonderly wrote: > Trent Jarvi wrote: >> I had looked into RS-485 some. It is daunting without proper hardware. >> One option is to do a native local tcpip/udp server to remove most of the >> the 'java issues.' Realtime patches comming down the pipe make it tempting >> to jump into the tarpit of failures. > > Trent, there is not a way for a non-realtime OS to drive 485 hardware without > the hardware taking care of the timing issues. But, a non-realtime OS can > support software APIs which let the developer express in an API the types of > things that a piece of hardware is capable of. Then we can have an API, and the > hardware people and the OS people will provide the solutions where possible. > >> It would be nice to get RS-485 support in. Things like controlling >> low cost devices in houses, ... But cutting out the hardware isn't a >> viable solution in java. > > The 485 hardware devices will have to have non-realtime requirements associated > with the controlling mechanisms. There are some of those. I'm mostly > interested in having a 485 API for realtime java and/or the aJile and other uC > environments which can provide realtime environments. > Hi Gregg I do not disagree with you but I have a problem with this (realtime java and/or the aJile and other Uc environements) being something I may be hearing bugs about 5 years from now. Is this really something that should be in the API or is it something that would make a nice niche market for support and services? Do the two really go together? If you like that market and I think there is a niche market there, great. This is a good area for SPI type interfaces where you could support it but it was not provided by default. -- Trent Jarvi tjarvi at qbang.org From guille at sms.nl Wed Jul 26 00:39:47 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 08:39:47 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C672EA.1080604@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0.0.20060724082455.038aa518@sms.nl> <44C4D351.603@lhar.co.za> <44C4E746.8070808@ergotech.com> <1153757804.44c4f26c2e9dc@webmail.eatserver.nl> <44C4F92D.6090807@sun.com> <005b01c6afbc$794fc060$0202a8c0@luna> <7.0.1.0.0.20060725094317.0363b390@sms.nl> <001901c6afcc$4bcf64f0$0c28a8c0@luna> <7.0.1.0.0.20060725115736.03706a38@sms.nl> <44C672EA.1080604@cox.net> Message-ID: <7.0.1.0.0.20060726083751.03633188@sms.nl> At 21:37 25/07/2006, Gregg Wonderly wrote: >Guillermo Rodriguez Garcia wrote: > > At 11:25 25/07/2006, Martin Schoeberl wrote: > >>Mmh, perhaps in a similar way as you configure timeouts? > >>Isn't this 'just' a timeout value? > > > > Yes, but this is just a specific parameter that you can configure in a > > specific type of UART (an EXAR UART). Other UARTs might be different. The > > point I'm trying to make is that there are just too many parameters to > > have an API for each specific case. > >In my earlier example/proposal, I included the ability for >attributes of a port >to be expressed as a collection of enumeration values for standard >things. That >would be fine for simple things like Input, Output, Sync, Async >etc. When there >are specific attributes of specific hardware, the vendor is going to have to >provide a way to configure those attributes. One of the primary >mechanisms in >Java to do this is the JavaBean pattern that can be manifested in a Map type >object when an API needs to preexist. So, we can provide an mechanism for >propagating random attributes using a Map argument to a method such as > >public void setConfig( Map params ) throws IOException; >public Map getConfig() throws IOException; > >Then, there is a conduit in and out of the driver that the user can >use without >needing more standards/spec'd code/API. > >This isn't much different than an ioctl(2) like mechanism, This is exactly what I was thinking while reading your mail :) >but it feels more Java like. It would do the job as well and I would be happy with that. However Paul's proposal where implementation classes extend the core API as necessary might be more elegant (for the same reason that it is more elegant than ioctl) Guillermo -- Guillermo Rodriguez Garcia Snijder Micro Systems phone +31-493-351020 G. Rodriguez Garcia fax +31-493-351530 Visser 25 email guille at sms.nl NL5751 BL Deurne The Netherlands http://www.snijder.com From guille at sms.nl Wed Jul 26 00:41:40 2006 From: guille at sms.nl (Guillermo Rodriguez Garcia) Date: Wed, 26 Jul 2006 08:41:40 +0200 Subject: [Rxtx] JSR Direction; Network or Data Link Layer spec? In-Reply-To: <44C6AC5F.3060107@cox.net> References: <200607190212.27131.pascal@quies.net> <23B58821-4D89-43DF-A52F-D80E6A984DA0@buechse.de> <200607191411.27566.pascal@quies.net> <375D5D58-0F96-4DA2-B168-1A4AC37200F8@buechse.de> <44BEA802.7060508@sun.com> <7.0.1.0