From Kustaa.Nyholm at planmeca.com Tue Mar 1 00:54:17 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 09:54:17 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> Message-ID: Adrian, had a look at your code/rewrite and it looks rather clean/nice. I was looking at the code to gain insight (not related to the rewrite) into what is involved in serial port programming in Windows. Or rather, to refresh my memory and see how others have done, because I've been there done that. So my questions are just to satisfy my curiosity, not to criticize or suggest improvements. 1) It looks like a new thread (EventMonitor) is created for each Serial port, is that correct? Many people seem to try to avoid using many threads in this sort of situation, and like to use something like unix select(). I personally find using threads more natural and better impedance match to the problem being solved here. I guess 'many people' above refers to those implementing thousands of connections and who cannot live with the overhead and limited number of threads available. 2) The EventMonitor basically polls for events at 50 msec interval? 3) There is a comment in the source code near the sleep(50) : // Sufficient up to 19200 baud I'm sure you thought about this carefully, so again not criticizing, but seeking to understand how or why, because at 50 msec would seem to limit through in some cases. Like if you send one byte and need to wait for one to return, then this limits speed to 200 chars/sec? 4) I've done something similar to a few years back from Java using JNI to access Win32 API serial port, and I seem to recall that I had threading issues ie when I submitted a read (ReadFile) and there was no data coming in, the thread would not only block but also consume a lot of CPU cycles ie it was not sleeping properly inside the ReadFile call when the serial port blocked. Im a bit fuzzy about the details after five years, so my question is have you checked if there an issue here? 5) AFAIK the select() on Windows does not work serial ports but there is some other mechanism (events?) to implement the same functionality, did you consider that? Probably, so you decided against it, why? br Kusti From adrian.crum at sandglass-software.com Tue Mar 1 04:13:34 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:13:34 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: References: Message-ID: <4D6CD4DE.7040501@sandglass-software.com> The javax.comm API specification requires one event monitor thread per port. I don't like the idea of having a thread per port either, but one of the rewrite's design goals is strict conformance to the specification. The 50 mS polling interval is just a placeholder. The final design of that is yet to be decided. In Windows, you have two choices for I/O: overlapped and non-overlapped. In overlapped I/O a thread is blocked, waiting for something to happen. In non-overlapped I/O a thread does not block. I chose non-overlapped I/O to avoid thread blocking at the OS level - instead, the thread blocking is kept in Java. -Adrian On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > Adrian, > > had a look at your code/rewrite and it looks rather clean/nice. > > I was looking at the code to gain insight (not related to the > rewrite) into what is involved in serial port programming > in Windows. Or rather, to refresh my memory and see how others have > done, because I've been there done that. > > So my questions are just to satisfy my curiosity, not to criticize > or suggest improvements. > > 1) It looks like a new thread (EventMonitor) is created for > each Serial port, is that correct? > > Many people seem to try to avoid using many threads in this sort > of situation, and like to use something like unix select(). > I personally find using threads more natural and better impedance > match to the problem being solved here. I guess 'many people' above > > refers to those implementing thousands of connections and > who cannot live with the overhead and limited number of threads > available. > > 2) The EventMonitor basically polls for events at 50 msec interval? > > 3) There is a comment in the source code near the sleep(50) : > > // Sufficient up to 19200 baud > > > I'm sure you thought about this carefully, so again not > criticizing, but seeking to understand how or why, because > at 50 msec would seem to limit through in some cases. Like > if you send one byte and need to wait for one to return, > then this limits speed to 200 chars/sec? > > 4) I've done something similar to a few years back from > Java using JNI to access Win32 API serial port, and > I seem to recall that I had threading issues ie when > I submitted a read (ReadFile) and there was no data coming > in, the thread would not only block but also consume a > lot of CPU cycles ie it was not sleeping properly inside > the ReadFile call when the serial port blocked. > > Im a bit fuzzy about the details after five years, so my question is > have you checked if there an issue here? > > > 5) AFAIK the select() on Windows does not work serial ports > but there is some other mechanism (events?) to implement the > same functionality, did you consider that? Probably, so you > decided against it, why? > > > br Kusti > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Tue Mar 1 04:25:23 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:25:23 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C2E90.9010601@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > My question would be: Why would you do that? The rewrite does > most of the work for you - all you have to do is implement > two C++ virtual classes and two C++ functions. You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? I just took a short look, maybe it could be discussed further, but I don't think I like it much. BTW, the main interface defined there is called gnu.io.Dispatcher? I thought the package names should be used in a way to avoid clashes, e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name space authority :)). > In Windows that took me a few hours. where is the implementation? I found commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp with things like const bool SerialPortImpl::isDataAvailable() const { // Needs implementation return true; } and timeouts.ReadIntervalTimeout = MAXDWORD;* timeouts.ReadTotalTimeoutMultiplier = 0; timeouts.ReadTotalTimeoutConstant = 0; timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 0; if (!SetCommTimeouts(hComm, &timeouts)) throw IOException(); which seems to be oversimplified or some prototype only? I think (and I wrote about this already in the past years) that correct timeout handling is one of the challenges, so I think this should be prototyped first - for each system flavor - before cementation of the (JNI-) interfaces. Personally, I would vote to form it in a way allowing to be implemented on embedded devices, for example. Another big challenge is to prove a rewrite fully working (and probably compatible to the old implementation) on "all" the supported OSes. Not a big problem for linux and windows, just use some thousand lines test code, test drivers and serial loopbacks etc, but for the exotic platforms, probably a high number of, this probably won't be too easy... (there are more challenges, such as being comfortable and threadsafe [are read and write permitted at the same time?], detailed and helpful exceptions on user API level [not necessarily on JNI/JNA layer], how to have a configurable threadsafe logging/tracing [maybe also from native code to assist porting / testing on exotic OSes, such as OSes where the developers have no direct access too, which can be quite hard to usually leads to good log messages], just to name a few.). So even it might seem easy for one platform and I agree with Micheal that > > * yay! let's start a rewrite is unlikely to succeede soon... However, when considering this, before IMHO a powerful Java API has to be defined, because according to my experiences for implementing non-trivial protocols InputStream/OutputStream might not be comfortable/powerfull enough (eventually I consider both wrong) and have some InputStream derivation available as wrapper (so applications can use InputStream and whatever high-level-API they want). The JNI interface shall make such a powerful implementation possible, thus the interface of it is driving the JNI interface design and thus I think it had to be done first. All this surely requires much work: agreements on the APIs, safeness for the users, design, documentation, all the implementations and the testing. As long as such bug amount of work cannot be spent, for example if some employee would get half a year time paid for it or so :-), probably it is unlikely to progress on this. Otherwise, I'm afraid, patches, improvements, new design ideas and even rewrites wouldn't become complete and thus won't form a new rxtx version (3.0); thus either collect dust in some forgotten CVS branch or could generate a split... > I can't imagine other ports taking > much longer than that - especially since POSIX-based code can > be shared between ports. Things are more complex than they seem to be... I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select on serial ports isn't supported; maybe it is non-trivial to "map" (like mapping select() to WaitForMultipleObjects() which might have different semantics etc.) or maybe some different approach has to be used. A system may have POSIX like termios interfaces but not support timeouts or have any other interoperability bug... You never run out of things that can go wrong. And if something can go wrong, it will... :-) Or, as Michael wrote: > > I seriously don't believe anyone will come up with anything better anytime soon. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue Mar 1 04:39:37 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:39:37 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com><13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED6B@COSNPREXC3.usr.ingenico.loc> > 3. Write all of the native (or non-native) code to implement > the native interface. > > Is that correct? If yes, how is that easier than the simple > implementation the current rewrite design uses? To have it complete, reliable, traceable, maintainable and well tested, it is much more work, I'm afraid. A prototype can be done within a few days (maybe on one day), but getting it right (including a passed review) IMHO is a completely different story. In the end you may end up with an average of ten lines per day, when assuming four major native packs (common, win, mac, termios/select) with let's say just 5000 lines each (with logging messages and detailed exceptions this is not much) we would have to estimate a total effort of nine man-years (20000/10/220)... oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 04:40:18 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:40:18 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6CDB22.9070401@sandglass-software.com> Every journey begins with a single step. -Adrian On 3/1/2011 3:25 AM, Steffen DETTMER wrote: > * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> My question would be: Why would you do that? The rewrite does >> most of the work for you - all you have to do is implement >> two C++ virtual classes and two C++ functions. > You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? > I just took a short look, maybe it could be discussed further, > but I don't think I like it much. > BTW, the main interface defined there is called gnu.io.Dispatcher? > I thought the package names should be used in a way to avoid clashes, > e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name > space authority :)). > >> In Windows that took me a few hours. > where is the implementation? > I found > commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp > with things like > > const bool SerialPortImpl::isDataAvailable() const > { > // Needs implementation > return true; > } > > and > > timeouts.ReadIntervalTimeout = MAXDWORD;* > timeouts.ReadTotalTimeoutMultiplier = 0; > timeouts.ReadTotalTimeoutConstant = 0; > timeouts.WriteTotalTimeoutMultiplier = 0; > timeouts.WriteTotalTimeoutConstant = 0; > if (!SetCommTimeouts(hComm,&timeouts)) > throw IOException(); > > which seems to be oversimplified or some prototype only? > > I think (and I wrote about this already in the past years) that correct > timeout handling is one of the challenges, so I think this should be > prototyped first - for each system flavor - before cementation of the > (JNI-) interfaces. Personally, I would vote to form it in a way allowing > to be implemented on embedded devices, for example. > > Another big challenge is to prove a rewrite fully working (and probably > compatible to the old implementation) on "all" the supported OSes. Not a > big problem for linux and windows, just use some thousand lines test > code, test drivers and serial loopbacks etc, but for the exotic > platforms, probably a high number of, this probably won't be too easy... > (there are more challenges, such as being comfortable and threadsafe > [are read and write permitted at the same time?], detailed and helpful > exceptions on user API level [not necessarily on JNI/JNA layer], how to > have a configurable threadsafe logging/tracing [maybe also from native > code to assist porting / testing on exotic OSes, such as OSes where the > developers have no direct access too, which can be quite hard to usually > leads to good log messages], just to name a few.). > > So even it might seem easy for one platform and I agree with Micheal > that > >>> * yay! let's start a rewrite > is unlikely to succeede soon... > > However, when considering this, before IMHO a powerful Java API has to > be defined, because according to my experiences for implementing > non-trivial protocols InputStream/OutputStream might not be > comfortable/powerfull enough (eventually I consider both wrong) and have > some InputStream derivation available as wrapper (so applications can > use InputStream and whatever high-level-API they want). > The JNI interface shall make such a powerful implementation possible, > thus the interface of it is driving the JNI interface design and thus I > think it had to be done first. > > All this surely requires much work: agreements on the APIs, safeness for > the users, design, documentation, all the implementations and the > testing. As long as such bug amount of work cannot be spent, for example > if some employee would get half a year time paid for it or so :-), > probably it is unlikely to progress on this. > > Otherwise, I'm afraid, patches, improvements, new design ideas and even > rewrites wouldn't become complete and thus won't form a new rxtx version > (3.0); thus either collect dust in some forgotten CVS branch or could > generate a split... > >> I can't imagine other ports taking >> much longer than that - especially since POSIX-based code can >> be shared between ports. > Things are more complex than they seem to be... > > I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select > on serial ports isn't supported; maybe it is non-trivial to "map" (like > mapping select() to WaitForMultipleObjects() which might have different > semantics etc.) or maybe some different approach has to be used. A > system may have POSIX like termios interfaces but not support timeouts > or have any other interoperability bug... > You never run out of things that can go wrong. And if something can go > wrong, it will... :-) > > Or, as Michael wrote: > >>> I seriously don't believe anyone will come up with anything better > anytime soon. > > oki, > > Steffen > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Kustaa.Nyholm at planmeca.com Tue Mar 1 04:57:02 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 13:57:02 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: On 3/1/11 13:13, "Adrian Crum" wrote: >The javax.comm API specification requires one event monitor thread per >port. I don't like the idea of having a thread per port either, but one >of the rewrite's design goals is strict conformance to the specification. Ah, had not spotted that requirement. > >The 50 mS polling interval is just a placeholder. The final design of >that is yet to be decided. > >In Windows, you have two choices for I/O: overlapped and non-overlapped. >In overlapped I/O a thread is blocked, waiting for something to happen. >In non-overlapped I/O a thread does not block. I chose non-overlapped >I/O to avoid thread blocking at the OS level - instead, the thread >blocking is kept in Java. > >-Adrian thanks for the explanation. br Kusti From iqzw2r602 at sneakemail.com Tue Mar 1 05:08:17 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:08:17 +1100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <32684-1298981297-704398@sneakemail.com> This reminds me of a nasty problem I had with overlapped I/O on windows with jpathwatch. You can't start an I/O request in one thread and then do the check if that request completed in another thread. Very strange things happen when you attempt that; made me change the design of the Windows implementation quite drastically (one thread on a command queue that executes requests from other threads instead of letting them wildly call into GetOverlappedResult()). Out of curiosity: Did you come across that too? Or are all requests handled in the same thread they're issued? Cheers, Uwe On Tue, Mar 1, 2011 at 10:13 PM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > The javax.comm API specification requires one event monitor thread per > port. I don't like the idea of having a thread per port either, but one of > the rewrite's design goals is strict conformance to the specification. > > The 50 mS polling interval is just a placeholder. The final design of that > is yet to be decided. > > In Windows, you have two choices for I/O: overlapped and non-overlapped. In > overlapped I/O a thread is blocked, waiting for something to happen. In > non-overlapped I/O a thread does not block. I chose non-overlapped I/O to > avoid thread blocking at the OS level - instead, the thread blocking is kept > in Java. > > -Adrian > > > On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > >> Adrian, >> >> had a look at your code/rewrite and it looks rather clean/nice. >> >> I was looking at the code to gain insight (not related to the >> rewrite) into what is involved in serial port programming >> in Windows. Or rather, to refresh my memory and see how others have >> done, because I've been there done that. >> >> So my questions are just to satisfy my curiosity, not to criticize >> or suggest improvements. >> >> 1) It looks like a new thread (EventMonitor) is created for >> each Serial port, is that correct? >> >> Many people seem to try to avoid using many threads in this sort >> of situation, and like to use something like unix select(). >> I personally find using threads more natural and better impedance >> match to the problem being solved here. I guess 'many people' above >> >> refers to those implementing thousands of connections and >> who cannot live with the overhead and limited number of threads >> available. >> >> 2) The EventMonitor basically polls for events at 50 msec interval? >> >> 3) There is a comment in the source code near the sleep(50) : >> >> // Sufficient up to 19200 baud >> >> >> I'm sure you thought about this carefully, so again not >> criticizing, but seeking to understand how or why, because >> at 50 msec would seem to limit through in some cases. Like >> if you send one byte and need to wait for one to return, >> then this limits speed to 200 chars/sec? >> >> 4) I've done something similar to a few years back from >> Java using JNI to access Win32 API serial port, and >> I seem to recall that I had threading issues ie when >> I submitted a read (ReadFile) and there was no data coming >> in, the thread would not only block but also consume a >> lot of CPU cycles ie it was not sleeping properly inside >> the ReadFile call when the serial port blocked. >> >> Im a bit fuzzy about the details after five years, so my question is >> have you checked if there an issue here? >> >> >> 5) AFAIK the select() on Windows does not work serial ports >> but there is some other mechanism (events?) to implement the >> same functionality, did you consider that? Probably, so you >> decided against it, why? >> >> >> br Kusti >> >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 05:37:07 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:37:07 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <1142-1298983027-957144@sneakemail.com> On Tue, Mar 1, 2011 at 1:32 PM, Adrian Crum wrote: > Just to make sure I'm understanding you correctly, anyone porting RxTx to > a new platform would have to do the following: > > 1. Write their own Java implementation of an abstract Dispatcher class. > yep. I'd probably put all my calls to native OS wrappers in there two, looks the most straight-forward to me. > 2. Write a native (JNI or JNA) interface for the abstract class > implementation. > yes. For POSIX you'd probably only write one piece of code that provides implementations for open(), close(), and friends. You can compile that on all posix platforms (yeah, the devil is in the detail, but it's very little code, still). So this does open() (when using ***, but you can also use +++) // Unix.java class Unix{ public static native int open(String filename, int flags, int mode); .... } // Unix.cpp JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) { const char* pathname = env->GetStringUTFChars(jpathname, 0); if(pathname == 0) return -1; // java throws an out of memory error in this case int result = open(pathname, flags, mode); Unix_cacheErrno(); // handle interference between JVM and errno; env->ReleaseStringUTFChars(jpathname, pathname); return result; } .... 3. Write all of the native (or non-native) code to implement the native > interface. > Not sure what you mean by that. I've done the OS wrappers in step 2. step 1. implements that Dispatcher. What else do I need? > Is that correct? If yes, how is that easier than the simple implementation > the current rewrite design uses? > Yes, except for 3 (see above). How it is easier: I can debug the Java code directly. I can step from the read() call of an input stream directly into the guts of the RXTX implementation on my platform and see e.g. why it's hanging, because I see all the way up the call stack right where it calls Unix.read(). You can't easily do that with a fat native library, especially if you have no second set of devtools installed (the ones for native development). And I bet anyone knowing both languages can write it faster in Java, with less bugs. > On a side note: there is no requirement to write native code using C++. If > C++ is a real obstacle to adoption, then regular C could be used instead. In > that case, there would be a Dispatcher.c file that contains function > protoypes that need to be implemented. Dispatcher.c would still maintain the > same role as Dispatcher.cpp - which is to shield native code developers from > the details of JNI. Just build out the missing functions using C data types > and you're ready to go. > As I said, whatever works for you. Java works for me better than C++ in this case... Cheers, Uwe -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Mar 1 08:26:41 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 16:26:41 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> > The javax.comm API specification requires one event monitor > thread per port. Where does it require this? Do you mean "All the events received by this listener are generated by one dedicated thread that belongs to the SerialPort object. "? I think this is an implementation detail, isn't it? At least it is mentioned after "The current implementation only allows one listener per SerialPort". A bit bad that javadoc does not distinguish between API spec and implementation documentation. Also I don't think that TooManyListenersException MUST be thrown (I think it CAN be thrown). > I don't like the idea of having a thread per > port either, but one of the rewrite's design goals is strict > conformance to the specification. (but not necessarily on JNI layer) > The 50 mS polling interval is just a placeholder. The final > design of that is yet to be decided. I though no polling would be wanted; what could be the placeholder stand for? Do you mean a different interval duration or do you mean something completely different? > In Windows, you have two choices for I/O: overlapped and > non-overlapped. > In overlapped I/O a thread is blocked, waiting for something > to happen. > In non-overlapped I/O a thread does not block. I chose > non-overlapped I/O to avoid thread blocking at the OS level - > instead, the thread blocking is kept in Java. Isn't "overlapped" (asynchronous) I/O meaning that you invoke some ReadFile(..., &overlapped, ...) INSTEAD of performing a synchronous (blocking) function call blocking the thread? As far as I see, W32_Support.cpp uses CreateFile without FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O operations are serialized, even if the calls to the read and write functions specify an OVERLAPPED structure." [1] and "A synchronous handle behaves such that I/O function calls using that handle are blocked until they complete" [2] Given that CCOMTIMEOUTS get: "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the bytes that have already been received, even if no bytes have been received." [3] It looks likes this implementation relies on polling, which probably would waste much computing power. What did I miss? oki, Steffen [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro nous_and_asynchronous_i_o_handles [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 09:23:47 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:23:47 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6D1D93.6090306@sandglass-software.com> Unfortunately, the javax.comm API specification includes a lot of implementation details. That is one of the weaknesses of the specification in my opinion. The bottom line is, anyone wanting to use RxTx as a javax.comm implementation is going to expect it to do the things the specification says it does. -Adrian On 3/1/2011 7:26 AM, Steffen DETTMER wrote: >> The javax.comm API specification requires one event monitor >> thread per port. > Where does it require this? > > Do you mean "All the events received by this listener are generated > by one dedicated thread that belongs to the SerialPort object. "? > > I think this is an implementation detail, isn't it? At least it is > mentioned after "The current implementation only allows one listener per > SerialPort". A bit bad that javadoc does not distinguish between API > spec and implementation documentation. Also I don't think that > TooManyListenersException MUST be thrown (I think it CAN be thrown). > >> I don't like the idea of having a thread per >> port either, but one of the rewrite's design goals is strict >> conformance to the specification. > (but not necessarily on JNI layer) > >> The 50 mS polling interval is just a placeholder. The final >> design of that is yet to be decided. > I though no polling would be wanted; what could be the placeholder stand > for? Do you mean a different interval duration or do you mean something > completely different? > >> In Windows, you have two choices for I/O: overlapped and >> non-overlapped. >> In overlapped I/O a thread is blocked, waiting for something >> to happen. >> In non-overlapped I/O a thread does not block. I chose >> non-overlapped I/O to avoid thread blocking at the OS level - >> instead, the thread blocking is kept in Java. > Isn't "overlapped" (asynchronous) I/O meaning that you invoke some > ReadFile(...,&overlapped, ...) > INSTEAD of performing a synchronous (blocking) function call blocking > the thread? > > As far as I see, W32_Support.cpp uses CreateFile without > FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O > operations are serialized, even if the calls to the read and write > functions specify an OVERLAPPED structure." [1] and "A synchronous > handle behaves such that I/O function calls using that handle are > blocked until they complete" [2] > > Given that CCOMTIMEOUTS get: > "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values > for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier > members, specifies that the read operation is to return immediately with > the bytes that have already been received, even if no bytes have been > received." [3] > > It looks likes this implementation relies on polling, which probably > would waste much computing power. > > What did I miss? > > oki, > > Steffen > > [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx > [2] > http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro > nous_and_asynchronous_i_o_handles > [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at sandglass-software.com Tue Mar 1 09:55:29 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:55:29 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <1142-1298983027-957144@sneakemail.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> Message-ID: <4D6D2501.1020803@sandglass-software.com> That code duplicates what is in Dispatcher.cpp. A Unix port would only need to implement CommPortFactory::getInstance(portName, portType). -Adrian On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 15:07:46 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 2 Mar 2011 09:07:46 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6D2501.1020803@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> <4D6D2501.1020803@sandglass-software.com> Message-ID: <23749-1299017266-991798@sneakemail.com> What is this duplicating? A Unix port will need to call open() anyways (just so we're talking about the same thing here: open() is the Unix equivalent of CreateFile()) On Wed, Mar 2, 2011 at 3:55 AM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > That code duplicates what is in Dispatcher.cpp. A Unix port would only > need to implement CommPortFactory::getInstance(portName, portType). > > -Adrian > > > On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Tue Mar 1 22:53:07 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 00:53:07 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: Hi, I haven't seen any response to my question below. Is this not the right place to ask? If not, where would be a better place to ask? Any suggestions? Thanks, Ryan On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >> Hi, >> >> I have a receive thread that does nothing but call read() on the serial >> port input stream. It works fine for a while but after running for a long >> time it eventually returns -1 which means EOF. This is my first problem, as >> the device I'm talking to runs forever, I don't know why it would return -1. >> I am calling disableReceiveThreshold() and disableReceiveTimeout() at >> initialization which according to the documentation means read will return >> as soon as any data is available and it will block forever when data is not >> available, so -1 should never be returned from read, right? >> >> I have been unable to figure out why read returns -1 after a long while >> but I have found that if I kill my application and restart it everything >> works fine again. Therefore I tried to work around the problem by having my >> code close the port and reopen it when read returns -1. My second problem is >> that in this case when I call close() on the port it blocks forever. I did >> find this old bug >> >> http://bugzilla.qbang.org/show_bug.cgi?id=53 >> >> which describes close() hanging on OSX, but it says that bug was fixed >> with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have >> any idea why read might be returning -1 in the first place? If I can avoid >> that I don't care about close() hanging because I would never close the >> port. If not, does anyone know why close() might block forever and how I can >> prevent this? I'm using RXTX version 2.1-7. >> >> Thanks, >> -- >> Ryan >> >> > > > -- > Ryan Boder > 1 614 598-6339 > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Mar 2 01:34:48 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 2 Mar 2011 10:34:48 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/2/11 07:53, "Ryan Boder" wrote: Can you / have you made a simple test to ensure that rxtx is the issue? Can you write a simple C-program to see if this exhibits the same problem? I've never encountered this sort of problem with rxtx, it mostly just works. But I'm on Mac so can't say about Windows (7) br Kusti >Hi, > >I haven't seen any response to my question below. Is this not the right >place to ask? If not, where would be a better place to ask? Any >suggestions? > >Thanks, >Ryan > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > >I mis-spoke, I don't have my own thread calling read, I am calling >read in the event handler after receiving a >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be >accurate though. > >Ryan > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >Hi, > >I have a receive thread that does nothing but call read() on the serial >port input stream. It works fine for a while but after running for a long >time it eventually returns -1 which means EOF. This is my first problem, >as the device I'm talking to runs forever, I don't know why it would >return -1. I am calling disableReceiveThreshold() and >disableReceiveTimeout() at initialization which according to the >documentation means read will return as soon as any data is available and >it will block forever when data is not available, so -1 should never be >returned from read, right? > >I have been unable to figure out why read returns -1 after a long while >but I have found that if I kill my application and restart it everything >works fine again. Therefore I tried to work around the problem by having >my code close the port and reopen it when read returns -1. My second >problem is that in this case when I call close() on the port it blocks >forever. I did find this old bug > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > >which describes close() hanging on OSX, but it says that bug was fixed >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone >have any idea why read might be returning -1 in the first place? If I can >avoid that I don't care about close() hanging because I would never close >the port. If not, does anyone know why close() might block forever and >how I can prevent this? I'm using RXTX version 2.1-7. > >Thanks, >-- >Ryan > > > > > > > > > >-- >Ryan Boder >1 614 598-6339 > > > > > > >-- >Ryan Boder >1 614 598-6339 > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From Steffen.DETTMER at ingenico.com Wed Mar 2 03:08:57 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:08:57 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <32684-1298981297-704398@sneakemail.com> References: <4D6CD4DE.7040501@sandglass-software.com> <32684-1298981297-704398@sneakemail.com> Message-ID: <20110302100857.GB8030@elberon.bln.de.ingenico.com> * iqzw2r602 at sneakemail.com wrote on Tue, Mar 01, 2011 at 23:08 +1100: > This reminds me of a nasty problem I had with overlapped I/O on windows Yeah, those thousands of complex, difficult to use and exception-containing WinAPI is really hard to use... About strange effects on overlapped&multithreading, MSDN has: `the calling thread uses the GetOverlappedResult function or one of the wait functions' [1] also also mentiones I/O Completion Ports [2], and later continues: `If an application reuses OVERLAPPED structures on multiple threads and calls GetOverlappedResult with the bWait parameter set to TRUE, the application must ensure that the associated event is set before the application reuses the structure. This can be accomplished by using the WaitForSingleObject function after calling GetOverlappedResult to force the thread to wait until the operation completes. Note that the event object must be a manual-reset event object. If an autoreset event object is used, calling GetOverlappedResult with the bWait parameter set to TRUE causes the function to be blocked indefinitely.' also [1] oki, Steffen [1] http://msdn.microsoft.com/en-us/library/ms686358%28v=vs.85%29.aspx [2] http://msdn.microsoft.com/en-us/library/aa365198%28v=vs.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:15:11 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:15:11 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6D1D93.6090306@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> <4D6D1D93.6090306@sandglass-software.com> Message-ID: <20110302101511.GC8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 08:23 -0800: > Unfortunately, the javax.comm API specification includes a lot of > implementation details. That is one of the weaknesses of the > specification in my opinion. The bottom line is, anyone wanting to use > RxTx as a javax.comm implementation is going to expect it to do the > things the specification says it does. Yeah ok, but even then the implementation could check for the TooManyListenersException situations (if it really is required to support applications relying on that exception) but internally use just a single I/O thread waiting for events on any open file descriptors. Of course an implementation supporting all sort of concurrency could become quite complex (especially if open-read-close should work fast, I think would be difficult to implement, because a new file descriptors had to be added to the waitFor/select list, and who knows how systems behave here in detail...). oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:25:15 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:25:15 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6CDB22.9070401@sandglass-software.com> References: <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> <4D6CDB22.9070401@sandglass-software.com> Message-ID: <20110302102515.GD8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 03:40 -0800: > * from some older mail: > > My question would be: Why would you do that? The rewrite does > > most of the work for you - all you have to do is implement > > two C++ virtual classes and two C++ functions. > > > > In Windows that took me a few hours. > > Every journey begins with a single step. Yes, of course, but then it shouldn't be used as base for new effort estimations like `In Windows that took a few hours' ;-) (BTW, calling a single step `the rewrite' may sound a bit ambitious ;)) But of course a prototype demonstrating something can be really helpful, sure. I just wanted to tell that interfaces should be easy to use and powerful at the same time and may non-trivial initial considerations before starting to implement them. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Kustaa.Nyholm at planmeca.com Tue Mar 1 00:54:17 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 09:54:17 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> Message-ID: Adrian, had a look at your code/rewrite and it looks rather clean/nice. I was looking at the code to gain insight (not related to the rewrite) into what is involved in serial port programming in Windows. Or rather, to refresh my memory and see how others have done, because I've been there done that. So my questions are just to satisfy my curiosity, not to criticize or suggest improvements. 1) It looks like a new thread (EventMonitor) is created for each Serial port, is that correct? Many people seem to try to avoid using many threads in this sort of situation, and like to use something like unix select(). I personally find using threads more natural and better impedance match to the problem being solved here. I guess 'many people' above refers to those implementing thousands of connections and who cannot live with the overhead and limited number of threads available. 2) The EventMonitor basically polls for events at 50 msec interval? 3) There is a comment in the source code near the sleep(50) : // Sufficient up to 19200 baud I'm sure you thought about this carefully, so again not criticizing, but seeking to understand how or why, because at 50 msec would seem to limit through in some cases. Like if you send one byte and need to wait for one to return, then this limits speed to 200 chars/sec? 4) I've done something similar to a few years back from Java using JNI to access Win32 API serial port, and I seem to recall that I had threading issues ie when I submitted a read (ReadFile) and there was no data coming in, the thread would not only block but also consume a lot of CPU cycles ie it was not sleeping properly inside the ReadFile call when the serial port blocked. Im a bit fuzzy about the details after five years, so my question is have you checked if there an issue here? 5) AFAIK the select() on Windows does not work serial ports but there is some other mechanism (events?) to implement the same functionality, did you consider that? Probably, so you decided against it, why? br Kusti From adrian.crum at sandglass-software.com Tue Mar 1 04:13:34 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:13:34 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: References: Message-ID: <4D6CD4DE.7040501@sandglass-software.com> The javax.comm API specification requires one event monitor thread per port. I don't like the idea of having a thread per port either, but one of the rewrite's design goals is strict conformance to the specification. The 50 mS polling interval is just a placeholder. The final design of that is yet to be decided. In Windows, you have two choices for I/O: overlapped and non-overlapped. In overlapped I/O a thread is blocked, waiting for something to happen. In non-overlapped I/O a thread does not block. I chose non-overlapped I/O to avoid thread blocking at the OS level - instead, the thread blocking is kept in Java. -Adrian On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > Adrian, > > had a look at your code/rewrite and it looks rather clean/nice. > > I was looking at the code to gain insight (not related to the > rewrite) into what is involved in serial port programming > in Windows. Or rather, to refresh my memory and see how others have > done, because I've been there done that. > > So my questions are just to satisfy my curiosity, not to criticize > or suggest improvements. > > 1) It looks like a new thread (EventMonitor) is created for > each Serial port, is that correct? > > Many people seem to try to avoid using many threads in this sort > of situation, and like to use something like unix select(). > I personally find using threads more natural and better impedance > match to the problem being solved here. I guess 'many people' above > > refers to those implementing thousands of connections and > who cannot live with the overhead and limited number of threads > available. > > 2) The EventMonitor basically polls for events at 50 msec interval? > > 3) There is a comment in the source code near the sleep(50) : > > // Sufficient up to 19200 baud > > > I'm sure you thought about this carefully, so again not > criticizing, but seeking to understand how or why, because > at 50 msec would seem to limit through in some cases. Like > if you send one byte and need to wait for one to return, > then this limits speed to 200 chars/sec? > > 4) I've done something similar to a few years back from > Java using JNI to access Win32 API serial port, and > I seem to recall that I had threading issues ie when > I submitted a read (ReadFile) and there was no data coming > in, the thread would not only block but also consume a > lot of CPU cycles ie it was not sleeping properly inside > the ReadFile call when the serial port blocked. > > Im a bit fuzzy about the details after five years, so my question is > have you checked if there an issue here? > > > 5) AFAIK the select() on Windows does not work serial ports > but there is some other mechanism (events?) to implement the > same functionality, did you consider that? Probably, so you > decided against it, why? > > > br Kusti > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Tue Mar 1 04:25:23 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:25:23 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C2E90.9010601@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > My question would be: Why would you do that? The rewrite does > most of the work for you - all you have to do is implement > two C++ virtual classes and two C++ functions. You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? I just took a short look, maybe it could be discussed further, but I don't think I like it much. BTW, the main interface defined there is called gnu.io.Dispatcher? I thought the package names should be used in a way to avoid clashes, e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name space authority :)). > In Windows that took me a few hours. where is the implementation? I found commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp with things like const bool SerialPortImpl::isDataAvailable() const { // Needs implementation return true; } and timeouts.ReadIntervalTimeout = MAXDWORD;* timeouts.ReadTotalTimeoutMultiplier = 0; timeouts.ReadTotalTimeoutConstant = 0; timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 0; if (!SetCommTimeouts(hComm, &timeouts)) throw IOException(); which seems to be oversimplified or some prototype only? I think (and I wrote about this already in the past years) that correct timeout handling is one of the challenges, so I think this should be prototyped first - for each system flavor - before cementation of the (JNI-) interfaces. Personally, I would vote to form it in a way allowing to be implemented on embedded devices, for example. Another big challenge is to prove a rewrite fully working (and probably compatible to the old implementation) on "all" the supported OSes. Not a big problem for linux and windows, just use some thousand lines test code, test drivers and serial loopbacks etc, but for the exotic platforms, probably a high number of, this probably won't be too easy... (there are more challenges, such as being comfortable and threadsafe [are read and write permitted at the same time?], detailed and helpful exceptions on user API level [not necessarily on JNI/JNA layer], how to have a configurable threadsafe logging/tracing [maybe also from native code to assist porting / testing on exotic OSes, such as OSes where the developers have no direct access too, which can be quite hard to usually leads to good log messages], just to name a few.). So even it might seem easy for one platform and I agree with Micheal that > > * yay! let's start a rewrite is unlikely to succeede soon... However, when considering this, before IMHO a powerful Java API has to be defined, because according to my experiences for implementing non-trivial protocols InputStream/OutputStream might not be comfortable/powerfull enough (eventually I consider both wrong) and have some InputStream derivation available as wrapper (so applications can use InputStream and whatever high-level-API they want). The JNI interface shall make such a powerful implementation possible, thus the interface of it is driving the JNI interface design and thus I think it had to be done first. All this surely requires much work: agreements on the APIs, safeness for the users, design, documentation, all the implementations and the testing. As long as such bug amount of work cannot be spent, for example if some employee would get half a year time paid for it or so :-), probably it is unlikely to progress on this. Otherwise, I'm afraid, patches, improvements, new design ideas and even rewrites wouldn't become complete and thus won't form a new rxtx version (3.0); thus either collect dust in some forgotten CVS branch or could generate a split... > I can't imagine other ports taking > much longer than that - especially since POSIX-based code can > be shared between ports. Things are more complex than they seem to be... I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select on serial ports isn't supported; maybe it is non-trivial to "map" (like mapping select() to WaitForMultipleObjects() which might have different semantics etc.) or maybe some different approach has to be used. A system may have POSIX like termios interfaces but not support timeouts or have any other interoperability bug... You never run out of things that can go wrong. And if something can go wrong, it will... :-) Or, as Michael wrote: > > I seriously don't believe anyone will come up with anything better anytime soon. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue Mar 1 04:39:37 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:39:37 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com><13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED6B@COSNPREXC3.usr.ingenico.loc> > 3. Write all of the native (or non-native) code to implement > the native interface. > > Is that correct? If yes, how is that easier than the simple > implementation the current rewrite design uses? To have it complete, reliable, traceable, maintainable and well tested, it is much more work, I'm afraid. A prototype can be done within a few days (maybe on one day), but getting it right (including a passed review) IMHO is a completely different story. In the end you may end up with an average of ten lines per day, when assuming four major native packs (common, win, mac, termios/select) with let's say just 5000 lines each (with logging messages and detailed exceptions this is not much) we would have to estimate a total effort of nine man-years (20000/10/220)... oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 04:40:18 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:40:18 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6CDB22.9070401@sandglass-software.com> Every journey begins with a single step. -Adrian On 3/1/2011 3:25 AM, Steffen DETTMER wrote: > * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> My question would be: Why would you do that? The rewrite does >> most of the work for you - all you have to do is implement >> two C++ virtual classes and two C++ functions. > You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? > I just took a short look, maybe it could be discussed further, > but I don't think I like it much. > BTW, the main interface defined there is called gnu.io.Dispatcher? > I thought the package names should be used in a way to avoid clashes, > e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name > space authority :)). > >> In Windows that took me a few hours. > where is the implementation? > I found > commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp > with things like > > const bool SerialPortImpl::isDataAvailable() const > { > // Needs implementation > return true; > } > > and > > timeouts.ReadIntervalTimeout = MAXDWORD;* > timeouts.ReadTotalTimeoutMultiplier = 0; > timeouts.ReadTotalTimeoutConstant = 0; > timeouts.WriteTotalTimeoutMultiplier = 0; > timeouts.WriteTotalTimeoutConstant = 0; > if (!SetCommTimeouts(hComm,&timeouts)) > throw IOException(); > > which seems to be oversimplified or some prototype only? > > I think (and I wrote about this already in the past years) that correct > timeout handling is one of the challenges, so I think this should be > prototyped first - for each system flavor - before cementation of the > (JNI-) interfaces. Personally, I would vote to form it in a way allowing > to be implemented on embedded devices, for example. > > Another big challenge is to prove a rewrite fully working (and probably > compatible to the old implementation) on "all" the supported OSes. Not a > big problem for linux and windows, just use some thousand lines test > code, test drivers and serial loopbacks etc, but for the exotic > platforms, probably a high number of, this probably won't be too easy... > (there are more challenges, such as being comfortable and threadsafe > [are read and write permitted at the same time?], detailed and helpful > exceptions on user API level [not necessarily on JNI/JNA layer], how to > have a configurable threadsafe logging/tracing [maybe also from native > code to assist porting / testing on exotic OSes, such as OSes where the > developers have no direct access too, which can be quite hard to usually > leads to good log messages], just to name a few.). > > So even it might seem easy for one platform and I agree with Micheal > that > >>> * yay! let's start a rewrite > is unlikely to succeede soon... > > However, when considering this, before IMHO a powerful Java API has to > be defined, because according to my experiences for implementing > non-trivial protocols InputStream/OutputStream might not be > comfortable/powerfull enough (eventually I consider both wrong) and have > some InputStream derivation available as wrapper (so applications can > use InputStream and whatever high-level-API they want). > The JNI interface shall make such a powerful implementation possible, > thus the interface of it is driving the JNI interface design and thus I > think it had to be done first. > > All this surely requires much work: agreements on the APIs, safeness for > the users, design, documentation, all the implementations and the > testing. As long as such bug amount of work cannot be spent, for example > if some employee would get half a year time paid for it or so :-), > probably it is unlikely to progress on this. > > Otherwise, I'm afraid, patches, improvements, new design ideas and even > rewrites wouldn't become complete and thus won't form a new rxtx version > (3.0); thus either collect dust in some forgotten CVS branch or could > generate a split... > >> I can't imagine other ports taking >> much longer than that - especially since POSIX-based code can >> be shared between ports. > Things are more complex than they seem to be... > > I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select > on serial ports isn't supported; maybe it is non-trivial to "map" (like > mapping select() to WaitForMultipleObjects() which might have different > semantics etc.) or maybe some different approach has to be used. A > system may have POSIX like termios interfaces but not support timeouts > or have any other interoperability bug... > You never run out of things that can go wrong. And if something can go > wrong, it will... :-) > > Or, as Michael wrote: > >>> I seriously don't believe anyone will come up with anything better > anytime soon. > > oki, > > Steffen > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Kustaa.Nyholm at planmeca.com Tue Mar 1 04:57:02 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 13:57:02 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: On 3/1/11 13:13, "Adrian Crum" wrote: >The javax.comm API specification requires one event monitor thread per >port. I don't like the idea of having a thread per port either, but one >of the rewrite's design goals is strict conformance to the specification. Ah, had not spotted that requirement. > >The 50 mS polling interval is just a placeholder. The final design of >that is yet to be decided. > >In Windows, you have two choices for I/O: overlapped and non-overlapped. >In overlapped I/O a thread is blocked, waiting for something to happen. >In non-overlapped I/O a thread does not block. I chose non-overlapped >I/O to avoid thread blocking at the OS level - instead, the thread >blocking is kept in Java. > >-Adrian thanks for the explanation. br Kusti From iqzw2r602 at sneakemail.com Tue Mar 1 05:08:17 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:08:17 +1100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <32684-1298981297-704398@sneakemail.com> This reminds me of a nasty problem I had with overlapped I/O on windows with jpathwatch. You can't start an I/O request in one thread and then do the check if that request completed in another thread. Very strange things happen when you attempt that; made me change the design of the Windows implementation quite drastically (one thread on a command queue that executes requests from other threads instead of letting them wildly call into GetOverlappedResult()). Out of curiosity: Did you come across that too? Or are all requests handled in the same thread they're issued? Cheers, Uwe On Tue, Mar 1, 2011 at 10:13 PM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > The javax.comm API specification requires one event monitor thread per > port. I don't like the idea of having a thread per port either, but one of > the rewrite's design goals is strict conformance to the specification. > > The 50 mS polling interval is just a placeholder. The final design of that > is yet to be decided. > > In Windows, you have two choices for I/O: overlapped and non-overlapped. In > overlapped I/O a thread is blocked, waiting for something to happen. In > non-overlapped I/O a thread does not block. I chose non-overlapped I/O to > avoid thread blocking at the OS level - instead, the thread blocking is kept > in Java. > > -Adrian > > > On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > >> Adrian, >> >> had a look at your code/rewrite and it looks rather clean/nice. >> >> I was looking at the code to gain insight (not related to the >> rewrite) into what is involved in serial port programming >> in Windows. Or rather, to refresh my memory and see how others have >> done, because I've been there done that. >> >> So my questions are just to satisfy my curiosity, not to criticize >> or suggest improvements. >> >> 1) It looks like a new thread (EventMonitor) is created for >> each Serial port, is that correct? >> >> Many people seem to try to avoid using many threads in this sort >> of situation, and like to use something like unix select(). >> I personally find using threads more natural and better impedance >> match to the problem being solved here. I guess 'many people' above >> >> refers to those implementing thousands of connections and >> who cannot live with the overhead and limited number of threads >> available. >> >> 2) The EventMonitor basically polls for events at 50 msec interval? >> >> 3) There is a comment in the source code near the sleep(50) : >> >> // Sufficient up to 19200 baud >> >> >> I'm sure you thought about this carefully, so again not >> criticizing, but seeking to understand how or why, because >> at 50 msec would seem to limit through in some cases. Like >> if you send one byte and need to wait for one to return, >> then this limits speed to 200 chars/sec? >> >> 4) I've done something similar to a few years back from >> Java using JNI to access Win32 API serial port, and >> I seem to recall that I had threading issues ie when >> I submitted a read (ReadFile) and there was no data coming >> in, the thread would not only block but also consume a >> lot of CPU cycles ie it was not sleeping properly inside >> the ReadFile call when the serial port blocked. >> >> Im a bit fuzzy about the details after five years, so my question is >> have you checked if there an issue here? >> >> >> 5) AFAIK the select() on Windows does not work serial ports >> but there is some other mechanism (events?) to implement the >> same functionality, did you consider that? Probably, so you >> decided against it, why? >> >> >> br Kusti >> >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 05:37:07 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:37:07 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <1142-1298983027-957144@sneakemail.com> On Tue, Mar 1, 2011 at 1:32 PM, Adrian Crum wrote: > Just to make sure I'm understanding you correctly, anyone porting RxTx to > a new platform would have to do the following: > > 1. Write their own Java implementation of an abstract Dispatcher class. > yep. I'd probably put all my calls to native OS wrappers in there two, looks the most straight-forward to me. > 2. Write a native (JNI or JNA) interface for the abstract class > implementation. > yes. For POSIX you'd probably only write one piece of code that provides implementations for open(), close(), and friends. You can compile that on all posix platforms (yeah, the devil is in the detail, but it's very little code, still). So this does open() (when using ***, but you can also use +++) // Unix.java class Unix{ public static native int open(String filename, int flags, int mode); .... } // Unix.cpp JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) { const char* pathname = env->GetStringUTFChars(jpathname, 0); if(pathname == 0) return -1; // java throws an out of memory error in this case int result = open(pathname, flags, mode); Unix_cacheErrno(); // handle interference between JVM and errno; env->ReleaseStringUTFChars(jpathname, pathname); return result; } .... 3. Write all of the native (or non-native) code to implement the native > interface. > Not sure what you mean by that. I've done the OS wrappers in step 2. step 1. implements that Dispatcher. What else do I need? > Is that correct? If yes, how is that easier than the simple implementation > the current rewrite design uses? > Yes, except for 3 (see above). How it is easier: I can debug the Java code directly. I can step from the read() call of an input stream directly into the guts of the RXTX implementation on my platform and see e.g. why it's hanging, because I see all the way up the call stack right where it calls Unix.read(). You can't easily do that with a fat native library, especially if you have no second set of devtools installed (the ones for native development). And I bet anyone knowing both languages can write it faster in Java, with less bugs. > On a side note: there is no requirement to write native code using C++. If > C++ is a real obstacle to adoption, then regular C could be used instead. In > that case, there would be a Dispatcher.c file that contains function > protoypes that need to be implemented. Dispatcher.c would still maintain the > same role as Dispatcher.cpp - which is to shield native code developers from > the details of JNI. Just build out the missing functions using C data types > and you're ready to go. > As I said, whatever works for you. Java works for me better than C++ in this case... Cheers, Uwe -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Mar 1 08:26:41 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 16:26:41 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> > The javax.comm API specification requires one event monitor > thread per port. Where does it require this? Do you mean "All the events received by this listener are generated by one dedicated thread that belongs to the SerialPort object. "? I think this is an implementation detail, isn't it? At least it is mentioned after "The current implementation only allows one listener per SerialPort". A bit bad that javadoc does not distinguish between API spec and implementation documentation. Also I don't think that TooManyListenersException MUST be thrown (I think it CAN be thrown). > I don't like the idea of having a thread per > port either, but one of the rewrite's design goals is strict > conformance to the specification. (but not necessarily on JNI layer) > The 50 mS polling interval is just a placeholder. The final > design of that is yet to be decided. I though no polling would be wanted; what could be the placeholder stand for? Do you mean a different interval duration or do you mean something completely different? > In Windows, you have two choices for I/O: overlapped and > non-overlapped. > In overlapped I/O a thread is blocked, waiting for something > to happen. > In non-overlapped I/O a thread does not block. I chose > non-overlapped I/O to avoid thread blocking at the OS level - > instead, the thread blocking is kept in Java. Isn't "overlapped" (asynchronous) I/O meaning that you invoke some ReadFile(..., &overlapped, ...) INSTEAD of performing a synchronous (blocking) function call blocking the thread? As far as I see, W32_Support.cpp uses CreateFile without FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O operations are serialized, even if the calls to the read and write functions specify an OVERLAPPED structure." [1] and "A synchronous handle behaves such that I/O function calls using that handle are blocked until they complete" [2] Given that CCOMTIMEOUTS get: "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the bytes that have already been received, even if no bytes have been received." [3] It looks likes this implementation relies on polling, which probably would waste much computing power. What did I miss? oki, Steffen [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro nous_and_asynchronous_i_o_handles [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 09:23:47 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:23:47 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6D1D93.6090306@sandglass-software.com> Unfortunately, the javax.comm API specification includes a lot of implementation details. That is one of the weaknesses of the specification in my opinion. The bottom line is, anyone wanting to use RxTx as a javax.comm implementation is going to expect it to do the things the specification says it does. -Adrian On 3/1/2011 7:26 AM, Steffen DETTMER wrote: >> The javax.comm API specification requires one event monitor >> thread per port. > Where does it require this? > > Do you mean "All the events received by this listener are generated > by one dedicated thread that belongs to the SerialPort object. "? > > I think this is an implementation detail, isn't it? At least it is > mentioned after "The current implementation only allows one listener per > SerialPort". A bit bad that javadoc does not distinguish between API > spec and implementation documentation. Also I don't think that > TooManyListenersException MUST be thrown (I think it CAN be thrown). > >> I don't like the idea of having a thread per >> port either, but one of the rewrite's design goals is strict >> conformance to the specification. > (but not necessarily on JNI layer) > >> The 50 mS polling interval is just a placeholder. The final >> design of that is yet to be decided. > I though no polling would be wanted; what could be the placeholder stand > for? Do you mean a different interval duration or do you mean something > completely different? > >> In Windows, you have two choices for I/O: overlapped and >> non-overlapped. >> In overlapped I/O a thread is blocked, waiting for something >> to happen. >> In non-overlapped I/O a thread does not block. I chose >> non-overlapped I/O to avoid thread blocking at the OS level - >> instead, the thread blocking is kept in Java. > Isn't "overlapped" (asynchronous) I/O meaning that you invoke some > ReadFile(...,&overlapped, ...) > INSTEAD of performing a synchronous (blocking) function call blocking > the thread? > > As far as I see, W32_Support.cpp uses CreateFile without > FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O > operations are serialized, even if the calls to the read and write > functions specify an OVERLAPPED structure." [1] and "A synchronous > handle behaves such that I/O function calls using that handle are > blocked until they complete" [2] > > Given that CCOMTIMEOUTS get: > "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values > for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier > members, specifies that the read operation is to return immediately with > the bytes that have already been received, even if no bytes have been > received." [3] > > It looks likes this implementation relies on polling, which probably > would waste much computing power. > > What did I miss? > > oki, > > Steffen > > [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx > [2] > http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro > nous_and_asynchronous_i_o_handles > [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at sandglass-software.com Tue Mar 1 09:55:29 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:55:29 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <1142-1298983027-957144@sneakemail.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> Message-ID: <4D6D2501.1020803@sandglass-software.com> That code duplicates what is in Dispatcher.cpp. A Unix port would only need to implement CommPortFactory::getInstance(portName, portType). -Adrian On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 15:07:46 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 2 Mar 2011 09:07:46 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6D2501.1020803@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> <4D6D2501.1020803@sandglass-software.com> Message-ID: <23749-1299017266-991798@sneakemail.com> What is this duplicating? A Unix port will need to call open() anyways (just so we're talking about the same thing here: open() is the Unix equivalent of CreateFile()) On Wed, Mar 2, 2011 at 3:55 AM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > That code duplicates what is in Dispatcher.cpp. A Unix port would only > need to implement CommPortFactory::getInstance(portName, portType). > > -Adrian > > > On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Tue Mar 1 22:53:07 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 00:53:07 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: Hi, I haven't seen any response to my question below. Is this not the right place to ask? If not, where would be a better place to ask? Any suggestions? Thanks, Ryan On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >> Hi, >> >> I have a receive thread that does nothing but call read() on the serial >> port input stream. It works fine for a while but after running for a long >> time it eventually returns -1 which means EOF. This is my first problem, as >> the device I'm talking to runs forever, I don't know why it would return -1. >> I am calling disableReceiveThreshold() and disableReceiveTimeout() at >> initialization which according to the documentation means read will return >> as soon as any data is available and it will block forever when data is not >> available, so -1 should never be returned from read, right? >> >> I have been unable to figure out why read returns -1 after a long while >> but I have found that if I kill my application and restart it everything >> works fine again. Therefore I tried to work around the problem by having my >> code close the port and reopen it when read returns -1. My second problem is >> that in this case when I call close() on the port it blocks forever. I did >> find this old bug >> >> http://bugzilla.qbang.org/show_bug.cgi?id=53 >> >> which describes close() hanging on OSX, but it says that bug was fixed >> with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have >> any idea why read might be returning -1 in the first place? If I can avoid >> that I don't care about close() hanging because I would never close the >> port. If not, does anyone know why close() might block forever and how I can >> prevent this? I'm using RXTX version 2.1-7. >> >> Thanks, >> -- >> Ryan >> >> > > > -- > Ryan Boder > 1 614 598-6339 > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Mar 2 01:34:48 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 2 Mar 2011 10:34:48 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/2/11 07:53, "Ryan Boder" wrote: Can you / have you made a simple test to ensure that rxtx is the issue? Can you write a simple C-program to see if this exhibits the same problem? I've never encountered this sort of problem with rxtx, it mostly just works. But I'm on Mac so can't say about Windows (7) br Kusti >Hi, > >I haven't seen any response to my question below. Is this not the right >place to ask? If not, where would be a better place to ask? Any >suggestions? > >Thanks, >Ryan > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > >I mis-spoke, I don't have my own thread calling read, I am calling >read in the event handler after receiving a >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be >accurate though. > >Ryan > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >Hi, > >I have a receive thread that does nothing but call read() on the serial >port input stream. It works fine for a while but after running for a long >time it eventually returns -1 which means EOF. This is my first problem, >as the device I'm talking to runs forever, I don't know why it would >return -1. I am calling disableReceiveThreshold() and >disableReceiveTimeout() at initialization which according to the >documentation means read will return as soon as any data is available and >it will block forever when data is not available, so -1 should never be >returned from read, right? > >I have been unable to figure out why read returns -1 after a long while >but I have found that if I kill my application and restart it everything >works fine again. Therefore I tried to work around the problem by having >my code close the port and reopen it when read returns -1. My second >problem is that in this case when I call close() on the port it blocks >forever. I did find this old bug > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > >which describes close() hanging on OSX, but it says that bug was fixed >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone >have any idea why read might be returning -1 in the first place? If I can >avoid that I don't care about close() hanging because I would never close >the port. If not, does anyone know why close() might block forever and >how I can prevent this? I'm using RXTX version 2.1-7. > >Thanks, >-- >Ryan > > > > > > > > > >-- >Ryan Boder >1 614 598-6339 > > > > > > >-- >Ryan Boder >1 614 598-6339 > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From Steffen.DETTMER at ingenico.com Wed Mar 2 03:08:57 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:08:57 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <32684-1298981297-704398@sneakemail.com> References: <4D6CD4DE.7040501@sandglass-software.com> <32684-1298981297-704398@sneakemail.com> Message-ID: <20110302100857.GB8030@elberon.bln.de.ingenico.com> * iqzw2r602 at sneakemail.com wrote on Tue, Mar 01, 2011 at 23:08 +1100: > This reminds me of a nasty problem I had with overlapped I/O on windows Yeah, those thousands of complex, difficult to use and exception-containing WinAPI is really hard to use... About strange effects on overlapped&multithreading, MSDN has: `the calling thread uses the GetOverlappedResult function or one of the wait functions' [1] also also mentiones I/O Completion Ports [2], and later continues: `If an application reuses OVERLAPPED structures on multiple threads and calls GetOverlappedResult with the bWait parameter set to TRUE, the application must ensure that the associated event is set before the application reuses the structure. This can be accomplished by using the WaitForSingleObject function after calling GetOverlappedResult to force the thread to wait until the operation completes. Note that the event object must be a manual-reset event object. If an autoreset event object is used, calling GetOverlappedResult with the bWait parameter set to TRUE causes the function to be blocked indefinitely.' also [1] oki, Steffen [1] http://msdn.microsoft.com/en-us/library/ms686358%28v=vs.85%29.aspx [2] http://msdn.microsoft.com/en-us/library/aa365198%28v=vs.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:15:11 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:15:11 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6D1D93.6090306@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> <4D6D1D93.6090306@sandglass-software.com> Message-ID: <20110302101511.GC8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 08:23 -0800: > Unfortunately, the javax.comm API specification includes a lot of > implementation details. That is one of the weaknesses of the > specification in my opinion. The bottom line is, anyone wanting to use > RxTx as a javax.comm implementation is going to expect it to do the > things the specification says it does. Yeah ok, but even then the implementation could check for the TooManyListenersException situations (if it really is required to support applications relying on that exception) but internally use just a single I/O thread waiting for events on any open file descriptors. Of course an implementation supporting all sort of concurrency could become quite complex (especially if open-read-close should work fast, I think would be difficult to implement, because a new file descriptors had to be added to the waitFor/select list, and who knows how systems behave here in detail...). oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:25:15 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:25:15 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6CDB22.9070401@sandglass-software.com> References: <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> <4D6CDB22.9070401@sandglass-software.com> Message-ID: <20110302102515.GD8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 03:40 -0800: > * from some older mail: > > My question would be: Why would you do that? The rewrite does > > most of the work for you - all you have to do is implement > > two C++ virtual classes and two C++ functions. > > > > In Windows that took me a few hours. > > Every journey begins with a single step. Yes, of course, but then it shouldn't be used as base for new effort estimations like `In Windows that took a few hours' ;-) (BTW, calling a single step `the rewrite' may sound a bit ambitious ;)) But of course a prototype demonstrating something can be really helpful, sure. I just wanted to tell that interfaces should be easy to use and powerful at the same time and may non-trivial initial considerations before starting to implement them. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From ryan.boder at gmail.com Wed Mar 2 18:44:35 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:44:35 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: While running the tests you requested I may have stumbled on the problem, I just don't know how to fix it. According to the documentation, if both the receive timeout and receive threshold are disabled then read() should block forever until data is available. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#getInputStream%28%29 On my system using RXTX read() is returning -1 when no data is available even though I have disabled both thresholds. The reason my program was running fine for a while without this problem showing up is that I was using the DATA_AVAILABLE event to be notified when data is available and only calling read() to read an entire frame whenever the DATA_AVAILABLE event occurred, until eventually my device (I'm guessing) probably took longer than normal to send the entire data frame and therefore I called read when no data was available and it returned -1. The following Java program demonstrates my problem, it returns -1 as soon as no data is available, even though I think it should block until data is available. import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; public class Main implements SerialPortEventListener { public static void main(String[] args) throws Exception { new Main().run(); } private void run() throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier("COM4"); SerialPort port = (SerialPort) portIdentifier.open(Main.class.getName(), 2000); port.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); port.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); port.disableReceiveThreshold(); port.disableReceiveTimeout(); BufferedInputStream in = new BufferedInputStream(port.getInputStream()); BufferedOutputStream out = new BufferedOutputStream(port.getOutputStream()); port.addEventListener(this); Thread.sleep(1000); out.write(new byte[] {0x02, 0x60}); out.flush(); while (true) { int x = in.read(); if (x == -1) { System.out.println("EOF"); Thread.sleep(1000000000); } String s = Integer.toHexString(x & 0xFF); if (s.length() == 1) s = "0" + s; System.out.print(s + " "); System.out.flush(); } } public void serialEvent(SerialPortEvent arg0) { System.out.println("Serial port event"); } } However, the follow C# program ran all day today without ever read ever returning -1, as I would expect. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.IO.Ports; using System.Threading; namespace RXTXReadTest1 { class Program { static void Main(string[] args) { new Program().run(); } private void run() { SerialPort port = new SerialPort("COM4", 19200, Parity.None, 8, StopBits.One); port.Open(); port.Write(new byte[] { 0x02, 0x60 }, 0, 2); while (true) { int x = port.ReadByte(); if (x == -1) { Console.WriteLine("EOF"); Thread.Sleep(1000000000); } String s = x.ToString("X"); if (s.Length == 1 ) s = "0" + s; Console.Out.Write(s + " "); Console.Out.Flush(); } } } } Now I am experimenting with what happens if I set the receive timeout to it's maximum value (apparently 1600ms) and only call read() when I am expecting data. Hopefully it will never be more than 1600ms late. This is still only a work around, not solving the problem. Am I doing something wrong in my code above or is RXTX retuning -1 when it should be blocking? Thanks, Ryan On Wed, Mar 2, 2011 at 3:34 AM, Kustaa Nyholm wrote: > On 3/2/11 07:53, "Ryan Boder" wrote: > Can you / have you made a simple test to ensure that rxtx is the issue? > > Can you write a simple C-program to see if this exhibits the same problem? > > I've never encountered this sort of problem with rxtx, it mostly just > works. > > But I'm on Mac so can't say about Windows (7) > > br Kusti > > > > > >Hi, > > > >I haven't seen any response to my question below. Is this not the right > >place to ask? If not, where would be a better place to ask? Any > >suggestions? > > > >Thanks, > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder > wrote: > > > >I mis-spoke, I don't have my own thread calling read, I am calling > >read in the event handler after receiving a > >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be > >accurate though. > > > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder > wrote: > > > >Hi, > > > >I have a receive thread that does nothing but call read() on the serial > >port input stream. It works fine for a while but after running for a long > >time it eventually returns -1 which means EOF. This is my first problem, > >as the device I'm talking to runs forever, I don't know why it would > >return -1. I am calling disableReceiveThreshold() and > >disableReceiveTimeout() at initialization which according to the > >documentation means read will return as soon as any data is available and > >it will block forever when data is not available, so -1 should never be > >returned from read, right? > > > >I have been unable to figure out why read returns -1 after a long while > >but I have found that if I kill my application and restart it everything > >works fine again. Therefore I tried to work around the problem by having > >my code close the port and reopen it when read returns -1. My second > >problem is that in this case when I call close() on the port it blocks > >forever. I did find this old bug > > > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > > > >which describes close() hanging on OSX, but it says that bug was fixed > >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone > >have any idea why read might be returning -1 in the first place? If I can > >avoid that I don't care about close() hanging because I would never close > >the port. If not, does anyone know why close() might block forever and > >how I can prevent this? I'm using RXTX version 2.1-7. > > > >Thanks, > >-- > >Ryan > > > > > > > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Wed Mar 2 18:46:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:46:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: <-1051064942000733580@unknownmsgid> References: <-1051064942000733580@unknownmsgid> Message-ID: It is USB and seems very reliable with the C# test program in my previous email. On Wed, Mar 2, 2011 at 6:58 PM, Bruce Griffith wrote: > How reliable is your serial port ? is it USB or Bluetooth? > > > > Bruce Griffith > > 303-532-4778 > > > > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On Behalf > Of *Ryan Boder > *Sent:* Tuesday, 01 March 2011 10:53 PM > *To:* rxtx at qbang.org > *Subject:* Re: [Rxtx] RXTX serial port read() returns -1 unexpectedly and > then blocks forever on close() > > > > Hi, > > I haven't seen any response to my question below. Is this not the right > place to ask? If not, where would be a better place to ask? Any suggestions? > > Thanks, > Ryan > > On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > > Hi, > > I have a receive thread that does nothing but call read() on the serial > port input stream. It works fine for a while but after running for a long > time it eventually returns -1 which means EOF. This is my first problem, as > the device I'm talking to runs forever, I don't know why it would return -1. > I am calling disableReceiveThreshold() and disableReceiveTimeout() at > initialization which according to the documentation means read will return > as soon as any data is available and it will block forever when data is not > available, so -1 should never be returned from read, right? > > I have been unable to figure out why read returns -1 after a long while but > I have found that if I kill my application and restart it everything works > fine again. Therefore I tried to work around the problem by having my code > close the port and reopen it when read returns -1. My second problem is that > in this case when I call close() on the port it blocks forever. I did find > this old bug > > http://bugzilla.qbang.org/show_bug.cgi?id=53 > > which describes close() hanging on OSX, but it says that bug was fixed with > a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have any > idea why read might be returning -1 in the first place? If I can avoid that > I don't care about close() hanging because I would never close the port. If > not, does anyone know why close() might block forever and how I can prevent > this? I'm using RXTX version 2.1-7. > > Thanks, > -- > Ryan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Mar 3 02:50:20 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 3 Mar 2011 09:50:20 +0000 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: So if -1 is unexpectedly returned from read, and we have demonstrated that your USB-serial adapter can actually causes this to happen in RXTX, why not just ignore the -1 value? What happens when you try this? As for a hang on close, are your closing your port from within your serial event handler? I know that this can cause some serious problems. Regards, Michael Erskine. From Kustaa.Nyholm at planmeca.com Thu Mar 3 03:39:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 12:39:34 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 03:44, "Ryan Boder" wrote: >While running the tests you requested I may have stumbled on the problem, >I just don't know how to fix it. According to the documentation, if both >the receive timeout and receive threshold are disabled then read() should >block forever until data is available. > >http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/re >ference/api/javax/comm/CommPort.html#getInputStream%28%29 > >On my system using RXTX read() is returning -1 when no data is available >even though I have disabled both thresholds. The reason my program was >running fine for a while without this problem showing up is that I was >using the DATA_AVAILABLE event to be notified when data is available and >only calling read() to read an entire frame whenever the DATA_AVAILABLE >event occurred, until eventually my device (I'm guessing) probably took >longer than normal to send the entire data frame and therefore I called >read when no data was available and it returned -1. As a workaround have you tried to perform another read() if it returns -1? The javadoc says (see getInputStream): "Note, however, that framing errors may cause the Timeout and Threshold values to complete prematurely without raising an exception." I read this as a hint that read might return even if no data is available. Because of the above and that read() can only return -1 or the byte received it would be somewhat logical to return -1 in case of framing error ? I'm not claiming that my interpretation of the specification, such as it is, is correct, just speculating that the behavior could be something like that. It might give you some more insight if you used the read(bytes[],int,int) method, because this can and will return 0 in case of timeout (and presumably might do so in case of framing error, maybe some other error condition too). That might allow you to handle or work around the problem in this case. You have not shown your complete code (no need) but your comments and the example makes me wonder if the code is otherwise as it should be, meaning are you assuming that when you get the DATA_AVAILABLE event all of your frame has arrived and that you can just blindly read it away from the input stream? That is not guaranteed of course. Also using read(), instead of read(bytes[],int,int), is not very efficient and might be masking other problems as mused above. BTE you can print a byte in hex with leading zeros more easily with: System.out.printf("%02X",x); br Kusti From ryan.boder at gmail.com Thu Mar 3 07:56:16 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:56:16 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 5:39 AM, Kustaa Nyholm wrote: > > As a workaround have you tried to perform another read() if it returns -1? > I tried that and it did work sometimes but not all the time. > > The javadoc says (see getInputStream): > > "Note, however, that framing errors may cause the Timeout and Threshold > values to complete prematurely without raising an exception." > > I read this as a hint that read might return even if no data is available. > > Because of the above and that read() can only return -1 or the byte > received > it would be somewhat logical to return -1 in case of framing error ? > > I'm not claiming that my interpretation of the specification, such as it > is, > is correct, just speculating that the behavior could be something like > that. > Receive framing is not enabled by default. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#enableReceiveFraming%28int%29 My choice of word might be misleading, when I said frame I just meant a contiguous message from the device. I am not enabling receive framing. Can you have a framing error when receive framing is disabled? > > It might give you some more insight if you used the read(bytes[],int,int) > method, because > this can and will return 0 in case of timeout (and presumably might do so > in case of framing > error, maybe some other error condition too). > > That might allow you to handle or work around the problem in this case. > > You have not shown your complete code (no need) but your comments and the > example > makes me wonder if the code is otherwise as it should be, meaning are you > assuming > that when you get the DATA_AVAILABLE event all of your frame has arrived > and that > you can just blindly read it away from the input stream? That is not > guaranteed of course. > I'm not assuming the entire message has arrived, I'm just assuming it either has arrived or will arrive soon which is why I'm using a (supposedly) blocking read(). > > Also using read(), instead of read(bytes[],int,int), is not very efficient > and > might be masking other problems as mused above. > True, I'm reading one byte at a time because I don't know how long the message will be until I read and parse some of it. I suppose I can use read(bytes[],int,int) once I figure out how long the message will be. > > BTE you can print a byte in hex with leading zeros more easily with: > > > System.out.printf("%02X",x); > I did it the dumb way in that test program so I could copy and paste the code from C# to Java without having to figure out how to do the same in C# which I'm not as familiar with. Thanks and BR, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 07:58:24 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:58:24 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: Yes I was doing the close in the serial event handler, I didn't realize that caused a problem. Thanks, I'll fix it. On Thu, Mar 3, 2011 at 4:50 AM, Michael Erskine wrote: > So if -1 is unexpectedly returned from read, and we have demonstrated > that your USB-serial adapter can actually causes this to happen in > RXTX, why not just ignore the -1 value? What happens when you try > this? As for a hang on close, are your closing your port from within > your serial event handler? I know that this can cause some serious > problems. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Mar 1 00:54:17 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 09:54:17 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> Message-ID: Adrian, had a look at your code/rewrite and it looks rather clean/nice. I was looking at the code to gain insight (not related to the rewrite) into what is involved in serial port programming in Windows. Or rather, to refresh my memory and see how others have done, because I've been there done that. So my questions are just to satisfy my curiosity, not to criticize or suggest improvements. 1) It looks like a new thread (EventMonitor) is created for each Serial port, is that correct? Many people seem to try to avoid using many threads in this sort of situation, and like to use something like unix select(). I personally find using threads more natural and better impedance match to the problem being solved here. I guess 'many people' above refers to those implementing thousands of connections and who cannot live with the overhead and limited number of threads available. 2) The EventMonitor basically polls for events at 50 msec interval? 3) There is a comment in the source code near the sleep(50) : // Sufficient up to 19200 baud I'm sure you thought about this carefully, so again not criticizing, but seeking to understand how or why, because at 50 msec would seem to limit through in some cases. Like if you send one byte and need to wait for one to return, then this limits speed to 200 chars/sec? 4) I've done something similar to a few years back from Java using JNI to access Win32 API serial port, and I seem to recall that I had threading issues ie when I submitted a read (ReadFile) and there was no data coming in, the thread would not only block but also consume a lot of CPU cycles ie it was not sleeping properly inside the ReadFile call when the serial port blocked. Im a bit fuzzy about the details after five years, so my question is have you checked if there an issue here? 5) AFAIK the select() on Windows does not work serial ports but there is some other mechanism (events?) to implement the same functionality, did you consider that? Probably, so you decided against it, why? br Kusti From adrian.crum at sandglass-software.com Tue Mar 1 04:13:34 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:13:34 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: References: Message-ID: <4D6CD4DE.7040501@sandglass-software.com> The javax.comm API specification requires one event monitor thread per port. I don't like the idea of having a thread per port either, but one of the rewrite's design goals is strict conformance to the specification. The 50 mS polling interval is just a placeholder. The final design of that is yet to be decided. In Windows, you have two choices for I/O: overlapped and non-overlapped. In overlapped I/O a thread is blocked, waiting for something to happen. In non-overlapped I/O a thread does not block. I chose non-overlapped I/O to avoid thread blocking at the OS level - instead, the thread blocking is kept in Java. -Adrian On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > Adrian, > > had a look at your code/rewrite and it looks rather clean/nice. > > I was looking at the code to gain insight (not related to the > rewrite) into what is involved in serial port programming > in Windows. Or rather, to refresh my memory and see how others have > done, because I've been there done that. > > So my questions are just to satisfy my curiosity, not to criticize > or suggest improvements. > > 1) It looks like a new thread (EventMonitor) is created for > each Serial port, is that correct? > > Many people seem to try to avoid using many threads in this sort > of situation, and like to use something like unix select(). > I personally find using threads more natural and better impedance > match to the problem being solved here. I guess 'many people' above > > refers to those implementing thousands of connections and > who cannot live with the overhead and limited number of threads > available. > > 2) The EventMonitor basically polls for events at 50 msec interval? > > 3) There is a comment in the source code near the sleep(50) : > > // Sufficient up to 19200 baud > > > I'm sure you thought about this carefully, so again not > criticizing, but seeking to understand how or why, because > at 50 msec would seem to limit through in some cases. Like > if you send one byte and need to wait for one to return, > then this limits speed to 200 chars/sec? > > 4) I've done something similar to a few years back from > Java using JNI to access Win32 API serial port, and > I seem to recall that I had threading issues ie when > I submitted a read (ReadFile) and there was no data coming > in, the thread would not only block but also consume a > lot of CPU cycles ie it was not sleeping properly inside > the ReadFile call when the serial port blocked. > > Im a bit fuzzy about the details after five years, so my question is > have you checked if there an issue here? > > > 5) AFAIK the select() on Windows does not work serial ports > but there is some other mechanism (events?) to implement the > same functionality, did you consider that? Probably, so you > decided against it, why? > > > br Kusti > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Tue Mar 1 04:25:23 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:25:23 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C2E90.9010601@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > My question would be: Why would you do that? The rewrite does > most of the work for you - all you have to do is implement > two C++ virtual classes and two C++ functions. You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? I just took a short look, maybe it could be discussed further, but I don't think I like it much. BTW, the main interface defined there is called gnu.io.Dispatcher? I thought the package names should be used in a way to avoid clashes, e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name space authority :)). > In Windows that took me a few hours. where is the implementation? I found commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp with things like const bool SerialPortImpl::isDataAvailable() const { // Needs implementation return true; } and timeouts.ReadIntervalTimeout = MAXDWORD;* timeouts.ReadTotalTimeoutMultiplier = 0; timeouts.ReadTotalTimeoutConstant = 0; timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 0; if (!SetCommTimeouts(hComm, &timeouts)) throw IOException(); which seems to be oversimplified or some prototype only? I think (and I wrote about this already in the past years) that correct timeout handling is one of the challenges, so I think this should be prototyped first - for each system flavor - before cementation of the (JNI-) interfaces. Personally, I would vote to form it in a way allowing to be implemented on embedded devices, for example. Another big challenge is to prove a rewrite fully working (and probably compatible to the old implementation) on "all" the supported OSes. Not a big problem for linux and windows, just use some thousand lines test code, test drivers and serial loopbacks etc, but for the exotic platforms, probably a high number of, this probably won't be too easy... (there are more challenges, such as being comfortable and threadsafe [are read and write permitted at the same time?], detailed and helpful exceptions on user API level [not necessarily on JNI/JNA layer], how to have a configurable threadsafe logging/tracing [maybe also from native code to assist porting / testing on exotic OSes, such as OSes where the developers have no direct access too, which can be quite hard to usually leads to good log messages], just to name a few.). So even it might seem easy for one platform and I agree with Micheal that > > * yay! let's start a rewrite is unlikely to succeede soon... However, when considering this, before IMHO a powerful Java API has to be defined, because according to my experiences for implementing non-trivial protocols InputStream/OutputStream might not be comfortable/powerfull enough (eventually I consider both wrong) and have some InputStream derivation available as wrapper (so applications can use InputStream and whatever high-level-API they want). The JNI interface shall make such a powerful implementation possible, thus the interface of it is driving the JNI interface design and thus I think it had to be done first. All this surely requires much work: agreements on the APIs, safeness for the users, design, documentation, all the implementations and the testing. As long as such bug amount of work cannot be spent, for example if some employee would get half a year time paid for it or so :-), probably it is unlikely to progress on this. Otherwise, I'm afraid, patches, improvements, new design ideas and even rewrites wouldn't become complete and thus won't form a new rxtx version (3.0); thus either collect dust in some forgotten CVS branch or could generate a split... > I can't imagine other ports taking > much longer than that - especially since POSIX-based code can > be shared between ports. Things are more complex than they seem to be... I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select on serial ports isn't supported; maybe it is non-trivial to "map" (like mapping select() to WaitForMultipleObjects() which might have different semantics etc.) or maybe some different approach has to be used. A system may have POSIX like termios interfaces but not support timeouts or have any other interoperability bug... You never run out of things that can go wrong. And if something can go wrong, it will... :-) Or, as Michael wrote: > > I seriously don't believe anyone will come up with anything better anytime soon. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue Mar 1 04:39:37 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:39:37 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com><13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED6B@COSNPREXC3.usr.ingenico.loc> > 3. Write all of the native (or non-native) code to implement > the native interface. > > Is that correct? If yes, how is that easier than the simple > implementation the current rewrite design uses? To have it complete, reliable, traceable, maintainable and well tested, it is much more work, I'm afraid. A prototype can be done within a few days (maybe on one day), but getting it right (including a passed review) IMHO is a completely different story. In the end you may end up with an average of ten lines per day, when assuming four major native packs (common, win, mac, termios/select) with let's say just 5000 lines each (with logging messages and detailed exceptions this is not much) we would have to estimate a total effort of nine man-years (20000/10/220)... oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 04:40:18 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:40:18 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6CDB22.9070401@sandglass-software.com> Every journey begins with a single step. -Adrian On 3/1/2011 3:25 AM, Steffen DETTMER wrote: > * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> My question would be: Why would you do that? The rewrite does >> most of the work for you - all you have to do is implement >> two C++ virtual classes and two C++ functions. > You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? > I just took a short look, maybe it could be discussed further, > but I don't think I like it much. > BTW, the main interface defined there is called gnu.io.Dispatcher? > I thought the package names should be used in a way to avoid clashes, > e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name > space authority :)). > >> In Windows that took me a few hours. > where is the implementation? > I found > commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp > with things like > > const bool SerialPortImpl::isDataAvailable() const > { > // Needs implementation > return true; > } > > and > > timeouts.ReadIntervalTimeout = MAXDWORD;* > timeouts.ReadTotalTimeoutMultiplier = 0; > timeouts.ReadTotalTimeoutConstant = 0; > timeouts.WriteTotalTimeoutMultiplier = 0; > timeouts.WriteTotalTimeoutConstant = 0; > if (!SetCommTimeouts(hComm,&timeouts)) > throw IOException(); > > which seems to be oversimplified or some prototype only? > > I think (and I wrote about this already in the past years) that correct > timeout handling is one of the challenges, so I think this should be > prototyped first - for each system flavor - before cementation of the > (JNI-) interfaces. Personally, I would vote to form it in a way allowing > to be implemented on embedded devices, for example. > > Another big challenge is to prove a rewrite fully working (and probably > compatible to the old implementation) on "all" the supported OSes. Not a > big problem for linux and windows, just use some thousand lines test > code, test drivers and serial loopbacks etc, but for the exotic > platforms, probably a high number of, this probably won't be too easy... > (there are more challenges, such as being comfortable and threadsafe > [are read and write permitted at the same time?], detailed and helpful > exceptions on user API level [not necessarily on JNI/JNA layer], how to > have a configurable threadsafe logging/tracing [maybe also from native > code to assist porting / testing on exotic OSes, such as OSes where the > developers have no direct access too, which can be quite hard to usually > leads to good log messages], just to name a few.). > > So even it might seem easy for one platform and I agree with Micheal > that > >>> * yay! let's start a rewrite > is unlikely to succeede soon... > > However, when considering this, before IMHO a powerful Java API has to > be defined, because according to my experiences for implementing > non-trivial protocols InputStream/OutputStream might not be > comfortable/powerfull enough (eventually I consider both wrong) and have > some InputStream derivation available as wrapper (so applications can > use InputStream and whatever high-level-API they want). > The JNI interface shall make such a powerful implementation possible, > thus the interface of it is driving the JNI interface design and thus I > think it had to be done first. > > All this surely requires much work: agreements on the APIs, safeness for > the users, design, documentation, all the implementations and the > testing. As long as such bug amount of work cannot be spent, for example > if some employee would get half a year time paid for it or so :-), > probably it is unlikely to progress on this. > > Otherwise, I'm afraid, patches, improvements, new design ideas and even > rewrites wouldn't become complete and thus won't form a new rxtx version > (3.0); thus either collect dust in some forgotten CVS branch or could > generate a split... > >> I can't imagine other ports taking >> much longer than that - especially since POSIX-based code can >> be shared between ports. > Things are more complex than they seem to be... > > I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select > on serial ports isn't supported; maybe it is non-trivial to "map" (like > mapping select() to WaitForMultipleObjects() which might have different > semantics etc.) or maybe some different approach has to be used. A > system may have POSIX like termios interfaces but not support timeouts > or have any other interoperability bug... > You never run out of things that can go wrong. And if something can go > wrong, it will... :-) > > Or, as Michael wrote: > >>> I seriously don't believe anyone will come up with anything better > anytime soon. > > oki, > > Steffen > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Kustaa.Nyholm at planmeca.com Tue Mar 1 04:57:02 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 13:57:02 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: On 3/1/11 13:13, "Adrian Crum" wrote: >The javax.comm API specification requires one event monitor thread per >port. I don't like the idea of having a thread per port either, but one >of the rewrite's design goals is strict conformance to the specification. Ah, had not spotted that requirement. > >The 50 mS polling interval is just a placeholder. The final design of >that is yet to be decided. > >In Windows, you have two choices for I/O: overlapped and non-overlapped. >In overlapped I/O a thread is blocked, waiting for something to happen. >In non-overlapped I/O a thread does not block. I chose non-overlapped >I/O to avoid thread blocking at the OS level - instead, the thread >blocking is kept in Java. > >-Adrian thanks for the explanation. br Kusti From iqzw2r602 at sneakemail.com Tue Mar 1 05:08:17 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:08:17 +1100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <32684-1298981297-704398@sneakemail.com> This reminds me of a nasty problem I had with overlapped I/O on windows with jpathwatch. You can't start an I/O request in one thread and then do the check if that request completed in another thread. Very strange things happen when you attempt that; made me change the design of the Windows implementation quite drastically (one thread on a command queue that executes requests from other threads instead of letting them wildly call into GetOverlappedResult()). Out of curiosity: Did you come across that too? Or are all requests handled in the same thread they're issued? Cheers, Uwe On Tue, Mar 1, 2011 at 10:13 PM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > The javax.comm API specification requires one event monitor thread per > port. I don't like the idea of having a thread per port either, but one of > the rewrite's design goals is strict conformance to the specification. > > The 50 mS polling interval is just a placeholder. The final design of that > is yet to be decided. > > In Windows, you have two choices for I/O: overlapped and non-overlapped. In > overlapped I/O a thread is blocked, waiting for something to happen. In > non-overlapped I/O a thread does not block. I chose non-overlapped I/O to > avoid thread blocking at the OS level - instead, the thread blocking is kept > in Java. > > -Adrian > > > On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > >> Adrian, >> >> had a look at your code/rewrite and it looks rather clean/nice. >> >> I was looking at the code to gain insight (not related to the >> rewrite) into what is involved in serial port programming >> in Windows. Or rather, to refresh my memory and see how others have >> done, because I've been there done that. >> >> So my questions are just to satisfy my curiosity, not to criticize >> or suggest improvements. >> >> 1) It looks like a new thread (EventMonitor) is created for >> each Serial port, is that correct? >> >> Many people seem to try to avoid using many threads in this sort >> of situation, and like to use something like unix select(). >> I personally find using threads more natural and better impedance >> match to the problem being solved here. I guess 'many people' above >> >> refers to those implementing thousands of connections and >> who cannot live with the overhead and limited number of threads >> available. >> >> 2) The EventMonitor basically polls for events at 50 msec interval? >> >> 3) There is a comment in the source code near the sleep(50) : >> >> // Sufficient up to 19200 baud >> >> >> I'm sure you thought about this carefully, so again not >> criticizing, but seeking to understand how or why, because >> at 50 msec would seem to limit through in some cases. Like >> if you send one byte and need to wait for one to return, >> then this limits speed to 200 chars/sec? >> >> 4) I've done something similar to a few years back from >> Java using JNI to access Win32 API serial port, and >> I seem to recall that I had threading issues ie when >> I submitted a read (ReadFile) and there was no data coming >> in, the thread would not only block but also consume a >> lot of CPU cycles ie it was not sleeping properly inside >> the ReadFile call when the serial port blocked. >> >> Im a bit fuzzy about the details after five years, so my question is >> have you checked if there an issue here? >> >> >> 5) AFAIK the select() on Windows does not work serial ports >> but there is some other mechanism (events?) to implement the >> same functionality, did you consider that? Probably, so you >> decided against it, why? >> >> >> br Kusti >> >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 05:37:07 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:37:07 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <1142-1298983027-957144@sneakemail.com> On Tue, Mar 1, 2011 at 1:32 PM, Adrian Crum wrote: > Just to make sure I'm understanding you correctly, anyone porting RxTx to > a new platform would have to do the following: > > 1. Write their own Java implementation of an abstract Dispatcher class. > yep. I'd probably put all my calls to native OS wrappers in there two, looks the most straight-forward to me. > 2. Write a native (JNI or JNA) interface for the abstract class > implementation. > yes. For POSIX you'd probably only write one piece of code that provides implementations for open(), close(), and friends. You can compile that on all posix platforms (yeah, the devil is in the detail, but it's very little code, still). So this does open() (when using ***, but you can also use +++) // Unix.java class Unix{ public static native int open(String filename, int flags, int mode); .... } // Unix.cpp JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) { const char* pathname = env->GetStringUTFChars(jpathname, 0); if(pathname == 0) return -1; // java throws an out of memory error in this case int result = open(pathname, flags, mode); Unix_cacheErrno(); // handle interference between JVM and errno; env->ReleaseStringUTFChars(jpathname, pathname); return result; } .... 3. Write all of the native (or non-native) code to implement the native > interface. > Not sure what you mean by that. I've done the OS wrappers in step 2. step 1. implements that Dispatcher. What else do I need? > Is that correct? If yes, how is that easier than the simple implementation > the current rewrite design uses? > Yes, except for 3 (see above). How it is easier: I can debug the Java code directly. I can step from the read() call of an input stream directly into the guts of the RXTX implementation on my platform and see e.g. why it's hanging, because I see all the way up the call stack right where it calls Unix.read(). You can't easily do that with a fat native library, especially if you have no second set of devtools installed (the ones for native development). And I bet anyone knowing both languages can write it faster in Java, with less bugs. > On a side note: there is no requirement to write native code using C++. If > C++ is a real obstacle to adoption, then regular C could be used instead. In > that case, there would be a Dispatcher.c file that contains function > protoypes that need to be implemented. Dispatcher.c would still maintain the > same role as Dispatcher.cpp - which is to shield native code developers from > the details of JNI. Just build out the missing functions using C data types > and you're ready to go. > As I said, whatever works for you. Java works for me better than C++ in this case... Cheers, Uwe -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Mar 1 08:26:41 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 16:26:41 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> > The javax.comm API specification requires one event monitor > thread per port. Where does it require this? Do you mean "All the events received by this listener are generated by one dedicated thread that belongs to the SerialPort object. "? I think this is an implementation detail, isn't it? At least it is mentioned after "The current implementation only allows one listener per SerialPort". A bit bad that javadoc does not distinguish between API spec and implementation documentation. Also I don't think that TooManyListenersException MUST be thrown (I think it CAN be thrown). > I don't like the idea of having a thread per > port either, but one of the rewrite's design goals is strict > conformance to the specification. (but not necessarily on JNI layer) > The 50 mS polling interval is just a placeholder. The final > design of that is yet to be decided. I though no polling would be wanted; what could be the placeholder stand for? Do you mean a different interval duration or do you mean something completely different? > In Windows, you have two choices for I/O: overlapped and > non-overlapped. > In overlapped I/O a thread is blocked, waiting for something > to happen. > In non-overlapped I/O a thread does not block. I chose > non-overlapped I/O to avoid thread blocking at the OS level - > instead, the thread blocking is kept in Java. Isn't "overlapped" (asynchronous) I/O meaning that you invoke some ReadFile(..., &overlapped, ...) INSTEAD of performing a synchronous (blocking) function call blocking the thread? As far as I see, W32_Support.cpp uses CreateFile without FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O operations are serialized, even if the calls to the read and write functions specify an OVERLAPPED structure." [1] and "A synchronous handle behaves such that I/O function calls using that handle are blocked until they complete" [2] Given that CCOMTIMEOUTS get: "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the bytes that have already been received, even if no bytes have been received." [3] It looks likes this implementation relies on polling, which probably would waste much computing power. What did I miss? oki, Steffen [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro nous_and_asynchronous_i_o_handles [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 09:23:47 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:23:47 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6D1D93.6090306@sandglass-software.com> Unfortunately, the javax.comm API specification includes a lot of implementation details. That is one of the weaknesses of the specification in my opinion. The bottom line is, anyone wanting to use RxTx as a javax.comm implementation is going to expect it to do the things the specification says it does. -Adrian On 3/1/2011 7:26 AM, Steffen DETTMER wrote: >> The javax.comm API specification requires one event monitor >> thread per port. > Where does it require this? > > Do you mean "All the events received by this listener are generated > by one dedicated thread that belongs to the SerialPort object. "? > > I think this is an implementation detail, isn't it? At least it is > mentioned after "The current implementation only allows one listener per > SerialPort". A bit bad that javadoc does not distinguish between API > spec and implementation documentation. Also I don't think that > TooManyListenersException MUST be thrown (I think it CAN be thrown). > >> I don't like the idea of having a thread per >> port either, but one of the rewrite's design goals is strict >> conformance to the specification. > (but not necessarily on JNI layer) > >> The 50 mS polling interval is just a placeholder. The final >> design of that is yet to be decided. > I though no polling would be wanted; what could be the placeholder stand > for? Do you mean a different interval duration or do you mean something > completely different? > >> In Windows, you have two choices for I/O: overlapped and >> non-overlapped. >> In overlapped I/O a thread is blocked, waiting for something >> to happen. >> In non-overlapped I/O a thread does not block. I chose >> non-overlapped I/O to avoid thread blocking at the OS level - >> instead, the thread blocking is kept in Java. > Isn't "overlapped" (asynchronous) I/O meaning that you invoke some > ReadFile(...,&overlapped, ...) > INSTEAD of performing a synchronous (blocking) function call blocking > the thread? > > As far as I see, W32_Support.cpp uses CreateFile without > FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O > operations are serialized, even if the calls to the read and write > functions specify an OVERLAPPED structure." [1] and "A synchronous > handle behaves such that I/O function calls using that handle are > blocked until they complete" [2] > > Given that CCOMTIMEOUTS get: > "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values > for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier > members, specifies that the read operation is to return immediately with > the bytes that have already been received, even if no bytes have been > received." [3] > > It looks likes this implementation relies on polling, which probably > would waste much computing power. > > What did I miss? > > oki, > > Steffen > > [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx > [2] > http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro > nous_and_asynchronous_i_o_handles > [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at sandglass-software.com Tue Mar 1 09:55:29 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:55:29 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <1142-1298983027-957144@sneakemail.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> Message-ID: <4D6D2501.1020803@sandglass-software.com> That code duplicates what is in Dispatcher.cpp. A Unix port would only need to implement CommPortFactory::getInstance(portName, portType). -Adrian On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 15:07:46 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 2 Mar 2011 09:07:46 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6D2501.1020803@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> <4D6D2501.1020803@sandglass-software.com> Message-ID: <23749-1299017266-991798@sneakemail.com> What is this duplicating? A Unix port will need to call open() anyways (just so we're talking about the same thing here: open() is the Unix equivalent of CreateFile()) On Wed, Mar 2, 2011 at 3:55 AM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > That code duplicates what is in Dispatcher.cpp. A Unix port would only > need to implement CommPortFactory::getInstance(portName, portType). > > -Adrian > > > On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Tue Mar 1 22:53:07 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 00:53:07 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: Hi, I haven't seen any response to my question below. Is this not the right place to ask? If not, where would be a better place to ask? Any suggestions? Thanks, Ryan On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >> Hi, >> >> I have a receive thread that does nothing but call read() on the serial >> port input stream. It works fine for a while but after running for a long >> time it eventually returns -1 which means EOF. This is my first problem, as >> the device I'm talking to runs forever, I don't know why it would return -1. >> I am calling disableReceiveThreshold() and disableReceiveTimeout() at >> initialization which according to the documentation means read will return >> as soon as any data is available and it will block forever when data is not >> available, so -1 should never be returned from read, right? >> >> I have been unable to figure out why read returns -1 after a long while >> but I have found that if I kill my application and restart it everything >> works fine again. Therefore I tried to work around the problem by having my >> code close the port and reopen it when read returns -1. My second problem is >> that in this case when I call close() on the port it blocks forever. I did >> find this old bug >> >> http://bugzilla.qbang.org/show_bug.cgi?id=53 >> >> which describes close() hanging on OSX, but it says that bug was fixed >> with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have >> any idea why read might be returning -1 in the first place? If I can avoid >> that I don't care about close() hanging because I would never close the >> port. If not, does anyone know why close() might block forever and how I can >> prevent this? I'm using RXTX version 2.1-7. >> >> Thanks, >> -- >> Ryan >> >> > > > -- > Ryan Boder > 1 614 598-6339 > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Mar 2 01:34:48 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 2 Mar 2011 10:34:48 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/2/11 07:53, "Ryan Boder" wrote: Can you / have you made a simple test to ensure that rxtx is the issue? Can you write a simple C-program to see if this exhibits the same problem? I've never encountered this sort of problem with rxtx, it mostly just works. But I'm on Mac so can't say about Windows (7) br Kusti >Hi, > >I haven't seen any response to my question below. Is this not the right >place to ask? If not, where would be a better place to ask? Any >suggestions? > >Thanks, >Ryan > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > >I mis-spoke, I don't have my own thread calling read, I am calling >read in the event handler after receiving a >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be >accurate though. > >Ryan > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >Hi, > >I have a receive thread that does nothing but call read() on the serial >port input stream. It works fine for a while but after running for a long >time it eventually returns -1 which means EOF. This is my first problem, >as the device I'm talking to runs forever, I don't know why it would >return -1. I am calling disableReceiveThreshold() and >disableReceiveTimeout() at initialization which according to the >documentation means read will return as soon as any data is available and >it will block forever when data is not available, so -1 should never be >returned from read, right? > >I have been unable to figure out why read returns -1 after a long while >but I have found that if I kill my application and restart it everything >works fine again. Therefore I tried to work around the problem by having >my code close the port and reopen it when read returns -1. My second >problem is that in this case when I call close() on the port it blocks >forever. I did find this old bug > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > >which describes close() hanging on OSX, but it says that bug was fixed >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone >have any idea why read might be returning -1 in the first place? If I can >avoid that I don't care about close() hanging because I would never close >the port. If not, does anyone know why close() might block forever and >how I can prevent this? I'm using RXTX version 2.1-7. > >Thanks, >-- >Ryan > > > > > > > > > >-- >Ryan Boder >1 614 598-6339 > > > > > > >-- >Ryan Boder >1 614 598-6339 > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From Steffen.DETTMER at ingenico.com Wed Mar 2 03:08:57 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:08:57 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <32684-1298981297-704398@sneakemail.com> References: <4D6CD4DE.7040501@sandglass-software.com> <32684-1298981297-704398@sneakemail.com> Message-ID: <20110302100857.GB8030@elberon.bln.de.ingenico.com> * iqzw2r602 at sneakemail.com wrote on Tue, Mar 01, 2011 at 23:08 +1100: > This reminds me of a nasty problem I had with overlapped I/O on windows Yeah, those thousands of complex, difficult to use and exception-containing WinAPI is really hard to use... About strange effects on overlapped&multithreading, MSDN has: `the calling thread uses the GetOverlappedResult function or one of the wait functions' [1] also also mentiones I/O Completion Ports [2], and later continues: `If an application reuses OVERLAPPED structures on multiple threads and calls GetOverlappedResult with the bWait parameter set to TRUE, the application must ensure that the associated event is set before the application reuses the structure. This can be accomplished by using the WaitForSingleObject function after calling GetOverlappedResult to force the thread to wait until the operation completes. Note that the event object must be a manual-reset event object. If an autoreset event object is used, calling GetOverlappedResult with the bWait parameter set to TRUE causes the function to be blocked indefinitely.' also [1] oki, Steffen [1] http://msdn.microsoft.com/en-us/library/ms686358%28v=vs.85%29.aspx [2] http://msdn.microsoft.com/en-us/library/aa365198%28v=vs.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:15:11 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:15:11 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6D1D93.6090306@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> <4D6D1D93.6090306@sandglass-software.com> Message-ID: <20110302101511.GC8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 08:23 -0800: > Unfortunately, the javax.comm API specification includes a lot of > implementation details. That is one of the weaknesses of the > specification in my opinion. The bottom line is, anyone wanting to use > RxTx as a javax.comm implementation is going to expect it to do the > things the specification says it does. Yeah ok, but even then the implementation could check for the TooManyListenersException situations (if it really is required to support applications relying on that exception) but internally use just a single I/O thread waiting for events on any open file descriptors. Of course an implementation supporting all sort of concurrency could become quite complex (especially if open-read-close should work fast, I think would be difficult to implement, because a new file descriptors had to be added to the waitFor/select list, and who knows how systems behave here in detail...). oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:25:15 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:25:15 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6CDB22.9070401@sandglass-software.com> References: <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> <4D6CDB22.9070401@sandglass-software.com> Message-ID: <20110302102515.GD8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 03:40 -0800: > * from some older mail: > > My question would be: Why would you do that? The rewrite does > > most of the work for you - all you have to do is implement > > two C++ virtual classes and two C++ functions. > > > > In Windows that took me a few hours. > > Every journey begins with a single step. Yes, of course, but then it shouldn't be used as base for new effort estimations like `In Windows that took a few hours' ;-) (BTW, calling a single step `the rewrite' may sound a bit ambitious ;)) But of course a prototype demonstrating something can be really helpful, sure. I just wanted to tell that interfaces should be easy to use and powerful at the same time and may non-trivial initial considerations before starting to implement them. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From ryan.boder at gmail.com Wed Mar 2 18:44:35 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:44:35 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: While running the tests you requested I may have stumbled on the problem, I just don't know how to fix it. According to the documentation, if both the receive timeout and receive threshold are disabled then read() should block forever until data is available. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#getInputStream%28%29 On my system using RXTX read() is returning -1 when no data is available even though I have disabled both thresholds. The reason my program was running fine for a while without this problem showing up is that I was using the DATA_AVAILABLE event to be notified when data is available and only calling read() to read an entire frame whenever the DATA_AVAILABLE event occurred, until eventually my device (I'm guessing) probably took longer than normal to send the entire data frame and therefore I called read when no data was available and it returned -1. The following Java program demonstrates my problem, it returns -1 as soon as no data is available, even though I think it should block until data is available. import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; public class Main implements SerialPortEventListener { public static void main(String[] args) throws Exception { new Main().run(); } private void run() throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier("COM4"); SerialPort port = (SerialPort) portIdentifier.open(Main.class.getName(), 2000); port.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); port.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); port.disableReceiveThreshold(); port.disableReceiveTimeout(); BufferedInputStream in = new BufferedInputStream(port.getInputStream()); BufferedOutputStream out = new BufferedOutputStream(port.getOutputStream()); port.addEventListener(this); Thread.sleep(1000); out.write(new byte[] {0x02, 0x60}); out.flush(); while (true) { int x = in.read(); if (x == -1) { System.out.println("EOF"); Thread.sleep(1000000000); } String s = Integer.toHexString(x & 0xFF); if (s.length() == 1) s = "0" + s; System.out.print(s + " "); System.out.flush(); } } public void serialEvent(SerialPortEvent arg0) { System.out.println("Serial port event"); } } However, the follow C# program ran all day today without ever read ever returning -1, as I would expect. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.IO.Ports; using System.Threading; namespace RXTXReadTest1 { class Program { static void Main(string[] args) { new Program().run(); } private void run() { SerialPort port = new SerialPort("COM4", 19200, Parity.None, 8, StopBits.One); port.Open(); port.Write(new byte[] { 0x02, 0x60 }, 0, 2); while (true) { int x = port.ReadByte(); if (x == -1) { Console.WriteLine("EOF"); Thread.Sleep(1000000000); } String s = x.ToString("X"); if (s.Length == 1 ) s = "0" + s; Console.Out.Write(s + " "); Console.Out.Flush(); } } } } Now I am experimenting with what happens if I set the receive timeout to it's maximum value (apparently 1600ms) and only call read() when I am expecting data. Hopefully it will never be more than 1600ms late. This is still only a work around, not solving the problem. Am I doing something wrong in my code above or is RXTX retuning -1 when it should be blocking? Thanks, Ryan On Wed, Mar 2, 2011 at 3:34 AM, Kustaa Nyholm wrote: > On 3/2/11 07:53, "Ryan Boder" wrote: > Can you / have you made a simple test to ensure that rxtx is the issue? > > Can you write a simple C-program to see if this exhibits the same problem? > > I've never encountered this sort of problem with rxtx, it mostly just > works. > > But I'm on Mac so can't say about Windows (7) > > br Kusti > > > > > >Hi, > > > >I haven't seen any response to my question below. Is this not the right > >place to ask? If not, where would be a better place to ask? Any > >suggestions? > > > >Thanks, > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder > wrote: > > > >I mis-spoke, I don't have my own thread calling read, I am calling > >read in the event handler after receiving a > >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be > >accurate though. > > > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder > wrote: > > > >Hi, > > > >I have a receive thread that does nothing but call read() on the serial > >port input stream. It works fine for a while but after running for a long > >time it eventually returns -1 which means EOF. This is my first problem, > >as the device I'm talking to runs forever, I don't know why it would > >return -1. I am calling disableReceiveThreshold() and > >disableReceiveTimeout() at initialization which according to the > >documentation means read will return as soon as any data is available and > >it will block forever when data is not available, so -1 should never be > >returned from read, right? > > > >I have been unable to figure out why read returns -1 after a long while > >but I have found that if I kill my application and restart it everything > >works fine again. Therefore I tried to work around the problem by having > >my code close the port and reopen it when read returns -1. My second > >problem is that in this case when I call close() on the port it blocks > >forever. I did find this old bug > > > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > > > >which describes close() hanging on OSX, but it says that bug was fixed > >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone > >have any idea why read might be returning -1 in the first place? If I can > >avoid that I don't care about close() hanging because I would never close > >the port. If not, does anyone know why close() might block forever and > >how I can prevent this? I'm using RXTX version 2.1-7. > > > >Thanks, > >-- > >Ryan > > > > > > > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Wed Mar 2 18:46:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:46:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: <-1051064942000733580@unknownmsgid> References: <-1051064942000733580@unknownmsgid> Message-ID: It is USB and seems very reliable with the C# test program in my previous email. On Wed, Mar 2, 2011 at 6:58 PM, Bruce Griffith wrote: > How reliable is your serial port ? is it USB or Bluetooth? > > > > Bruce Griffith > > 303-532-4778 > > > > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On Behalf > Of *Ryan Boder > *Sent:* Tuesday, 01 March 2011 10:53 PM > *To:* rxtx at qbang.org > *Subject:* Re: [Rxtx] RXTX serial port read() returns -1 unexpectedly and > then blocks forever on close() > > > > Hi, > > I haven't seen any response to my question below. Is this not the right > place to ask? If not, where would be a better place to ask? Any suggestions? > > Thanks, > Ryan > > On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > > Hi, > > I have a receive thread that does nothing but call read() on the serial > port input stream. It works fine for a while but after running for a long > time it eventually returns -1 which means EOF. This is my first problem, as > the device I'm talking to runs forever, I don't know why it would return -1. > I am calling disableReceiveThreshold() and disableReceiveTimeout() at > initialization which according to the documentation means read will return > as soon as any data is available and it will block forever when data is not > available, so -1 should never be returned from read, right? > > I have been unable to figure out why read returns -1 after a long while but > I have found that if I kill my application and restart it everything works > fine again. Therefore I tried to work around the problem by having my code > close the port and reopen it when read returns -1. My second problem is that > in this case when I call close() on the port it blocks forever. I did find > this old bug > > http://bugzilla.qbang.org/show_bug.cgi?id=53 > > which describes close() hanging on OSX, but it says that bug was fixed with > a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have any > idea why read might be returning -1 in the first place? If I can avoid that > I don't care about close() hanging because I would never close the port. If > not, does anyone know why close() might block forever and how I can prevent > this? I'm using RXTX version 2.1-7. > > Thanks, > -- > Ryan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Mar 3 02:50:20 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 3 Mar 2011 09:50:20 +0000 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: So if -1 is unexpectedly returned from read, and we have demonstrated that your USB-serial adapter can actually causes this to happen in RXTX, why not just ignore the -1 value? What happens when you try this? As for a hang on close, are your closing your port from within your serial event handler? I know that this can cause some serious problems. Regards, Michael Erskine. From Kustaa.Nyholm at planmeca.com Thu Mar 3 03:39:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 12:39:34 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 03:44, "Ryan Boder" wrote: >While running the tests you requested I may have stumbled on the problem, >I just don't know how to fix it. According to the documentation, if both >the receive timeout and receive threshold are disabled then read() should >block forever until data is available. > >http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/re >ference/api/javax/comm/CommPort.html#getInputStream%28%29 > >On my system using RXTX read() is returning -1 when no data is available >even though I have disabled both thresholds. The reason my program was >running fine for a while without this problem showing up is that I was >using the DATA_AVAILABLE event to be notified when data is available and >only calling read() to read an entire frame whenever the DATA_AVAILABLE >event occurred, until eventually my device (I'm guessing) probably took >longer than normal to send the entire data frame and therefore I called >read when no data was available and it returned -1. As a workaround have you tried to perform another read() if it returns -1? The javadoc says (see getInputStream): "Note, however, that framing errors may cause the Timeout and Threshold values to complete prematurely without raising an exception." I read this as a hint that read might return even if no data is available. Because of the above and that read() can only return -1 or the byte received it would be somewhat logical to return -1 in case of framing error ? I'm not claiming that my interpretation of the specification, such as it is, is correct, just speculating that the behavior could be something like that. It might give you some more insight if you used the read(bytes[],int,int) method, because this can and will return 0 in case of timeout (and presumably might do so in case of framing error, maybe some other error condition too). That might allow you to handle or work around the problem in this case. You have not shown your complete code (no need) but your comments and the example makes me wonder if the code is otherwise as it should be, meaning are you assuming that when you get the DATA_AVAILABLE event all of your frame has arrived and that you can just blindly read it away from the input stream? That is not guaranteed of course. Also using read(), instead of read(bytes[],int,int), is not very efficient and might be masking other problems as mused above. BTE you can print a byte in hex with leading zeros more easily with: System.out.printf("%02X",x); br Kusti From ryan.boder at gmail.com Thu Mar 3 07:56:16 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:56:16 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 5:39 AM, Kustaa Nyholm wrote: > > As a workaround have you tried to perform another read() if it returns -1? > I tried that and it did work sometimes but not all the time. > > The javadoc says (see getInputStream): > > "Note, however, that framing errors may cause the Timeout and Threshold > values to complete prematurely without raising an exception." > > I read this as a hint that read might return even if no data is available. > > Because of the above and that read() can only return -1 or the byte > received > it would be somewhat logical to return -1 in case of framing error ? > > I'm not claiming that my interpretation of the specification, such as it > is, > is correct, just speculating that the behavior could be something like > that. > Receive framing is not enabled by default. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#enableReceiveFraming%28int%29 My choice of word might be misleading, when I said frame I just meant a contiguous message from the device. I am not enabling receive framing. Can you have a framing error when receive framing is disabled? > > It might give you some more insight if you used the read(bytes[],int,int) > method, because > this can and will return 0 in case of timeout (and presumably might do so > in case of framing > error, maybe some other error condition too). > > That might allow you to handle or work around the problem in this case. > > You have not shown your complete code (no need) but your comments and the > example > makes me wonder if the code is otherwise as it should be, meaning are you > assuming > that when you get the DATA_AVAILABLE event all of your frame has arrived > and that > you can just blindly read it away from the input stream? That is not > guaranteed of course. > I'm not assuming the entire message has arrived, I'm just assuming it either has arrived or will arrive soon which is why I'm using a (supposedly) blocking read(). > > Also using read(), instead of read(bytes[],int,int), is not very efficient > and > might be masking other problems as mused above. > True, I'm reading one byte at a time because I don't know how long the message will be until I read and parse some of it. I suppose I can use read(bytes[],int,int) once I figure out how long the message will be. > > BTE you can print a byte in hex with leading zeros more easily with: > > > System.out.printf("%02X",x); > I did it the dumb way in that test program so I could copy and paste the code from C# to Java without having to figure out how to do the same in C# which I'm not as familiar with. Thanks and BR, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 07:58:24 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:58:24 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: Yes I was doing the close in the serial event handler, I didn't realize that caused a problem. Thanks, I'll fix it. On Thu, Mar 3, 2011 at 4:50 AM, Michael Erskine wrote: > So if -1 is unexpectedly returned from read, and we have demonstrated > that your USB-serial adapter can actually causes this to happen in > RXTX, why not just ignore the -1 value? What happens when you try > this? As for a hang on close, are your closing your port from within > your serial event handler? I know that this can cause some serious > problems. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 11:48:20 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 13:48:20 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm wrote: > On 3/3/11 16:56, "Ryan Boder" wrote: > > > >I'm not assuming the entire message has arrived, I'm just assuming it > >either has arrived or will arrive soon which is why I'm using a > >(supposedly) blocking read(). > > > I've been giving this some further thought. > > It does not feel healthy to block without timeout, especially > from within a thread that is essentially internal to the rxtx. > > I've never done that, I always use a time out, read(byte[],int,int) > for the expected number of bytes, check how much I got and issue > more reads until I get everything. > > You have not described how your communication works so I'm only > speculating. > > If your device needs some response to send more bytes (from your > code it looks like this is not the case) then a missing byte > would block your read and prevent you from responding and > getting more data. But as said, looks like that is not the case. > > Anyway, if this was my problem, I would enable the timeout > and use read(byte[],int,int) and loop until I get what I need. > You are right, I should and will use a timeout. In fact, my program has been running flawlessly for 12 hours and the only change I made was to enable a timeout, no change in the logic at all. Without the timeout read() was returning -1 usually after it ran for an hour or two. I will change the code to make use of the timeout and handle it appropriately. It still seems to me that RXTX's behavior doesn't match the documentation when rx timeout and rx threshold are disabled read() should block until data is available instead of immediately returning -1. I don't believe that a framing error is occurring immediately every time data is not available causing read() to return -1. Especially since the C# test program above runs all day with no error and the Java program above runs all day with no error when a timeout is enabled. To me it seems like enabling the timeout is what is causing read() to block until data is available, even if only for 1600ms, and without the timeout read() is returning -1 immediately when it should be blocking. Thanks for all the help and best regards, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Thu Mar 3 13:02:30 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 22:02:30 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 20:48, "Ryan Boder" wrote: >On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm > wrote: > >On 3/3/11 16:56, "Ryan Boder" wrote: >> > >>I'm not assuming the entire message has arrived, I'm just assuming it >>either has arrived or will arrive soon which is why I'm using a >>(supposedly) blocking read(). > > > >I've been giving this some further thought. > >It does not feel healthy to block without timeout, especially >from within a thread that is essentially internal to the rxtx. > >I've never done that, I always use a time out, read(byte[],int,int) >for the expected number of bytes, check how much I got and issue >more reads until I get everything. > >You have not described how your communication works so I'm only >speculating. > >If your device needs some response to send more bytes (from your >code it looks like this is not the case) then a missing byte >would block your read and prevent you from responding and >getting more data. But as said, looks like that is not the case. > >Anyway, if this was my problem, I would enable the timeout >and use read(byte[],int,int) and loop until I get what I need. > > > > >You are right, I should and will use a timeout. In fact, my program has >been running flawlessly for 12 hours and the only change I made was to >enable a timeout, no change in the logic at all. Without the timeout >read() was returning -1 usually after it ran for an hour or two. I will >change the code to make use of the timeout and handle it appropriately. That's nice! > >It still seems to me that RXTX's behavior doesn't match the documentation >when rx timeout and rx threshold are disabled read() should block until >data is available instead of immediately returning -1. Yeah, it does look like bug. However this might be related to some Windows specific serial port issue. Years ago I had issues with JavaComm (not RxTx) where I did a blocking read and I had huge issues with my program consuming all resources. I curser the Sun and JavaComm and re-code my own SerialPort using JNI to access the Win32 API directly. And I run into the same problems as with the Sun's implementation! So I ditched my code, changed my code to use timeouts and problems disappeared. > I don't believe that a framing error is occurring immediately every time >data is not available causing read() to return -1. Especially since the >C# test program above runs all day with no error and the Java program >above runs all day with no error when a timeout is enabled. I think so too, all things considered I don't really believe in framing errors in this case. > To me it seems like enabling the timeout is what is causing read() to >block until data is available, even if only for 1600ms, and without the >timeout read() is returning -1 immediately when it should be blocking. Yeah, I had a peek at the innards of RxTx Windows serial port a week or so ago and also read MSDN documentation about serial ports and the way overlapped and non-overlapped (non blocking and blocking) IO is handled is a way different. So yeah, it can well be that there is an issue lurking there somewhere inside RxTx in Windows. > > >Thanks for all the help and best regards, >-- >Ryan Boder I'm happy if I was of any assistance. br Kusti From tjarvi at qbang.org Thu Mar 3 18:52:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Mar 2011 18:52:50 -0700 (MST) Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: >> Without the timeout >> read() was returning -1 usually after it ran for an hour or two. There is a big hammer in rxtx causing that behavior. >> It still seems to me that RXTX's behavior doesn't match the documentation >> when rx timeout and rx threshold are disabled read() should block until >> data is available instead of immediately returning -1. > > Yeah, it does look like bug. However this might be related to some > Windows specific serial port issue. Years ago I had issues with > JavaComm (not RxTx) where I did a blocking read and I had huge > issues with my program consuming all resources. I curser the Sun > and JavaComm and re-code my own SerialPort using JNI to access > the Win32 API directly. And I run into the same problems as > with the Sun's implementation! So I ditched my code, changed > my code to use timeouts and problems disappeared. > > >> To me it seems like enabling the timeout is what is causing read() to >> block until data is available, even if only for 1600ms, and without the >> timeout read() is returning -1 immediately when it should be blocking. > > Yeah, I had a peek at the innards of RxTx Windows serial port a week > or so ago and also read MSDN documentation about serial ports and > the way overlapped and non-overlapped (non blocking and blocking) > IO is handled is a way different. So yeah, it can well be that > there is an issue lurking there somewhere inside RxTx in Windows. > > Yes. RXTX was patched to behave the way it does. I don't fully understand the issue behind the patch. Marc noticed the odd behavior as well and offered a fix which was greeted with resistance. The windows implementation was done without real documentatino of the windows API. I think I had an example from the late 80's early 90's on Microsoft's site and some API documentation that was obviously not microsofts in Europe. Wayne Roberts had a real need for windows support and fixed some major issues it had. My interest at the time was mingw32. I then cleaned it up for some specific uses I had later. The read returning -1 when it should block didn't impact anybody and appeared to help some people. It isnt the documented behavior though. There could be all sorts of latent bugs in that code but in the real world, it gets by in almost all use cases. Its a hack but it worked for 100's of thousands of people over a 14 year period. Maybe its time to revisit the code but there is more risk than gain for most people. How do you move forward and avoid the risk? Some have expressed interests in coding C++ or other efforts. I'm all for such efforts but feel some unit tests that work with a null modem cables are the only thing that will move rxtx (and perhaps CommAPI) forward. If we have a test suite in place as a qualification for implementations, progress can be made in the right direction regardless of the implementation details. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Fri Mar 4 02:57:16 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 4 Mar 2011 11:57:16 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/4/11 03:52, "Trent Jarvi" wrote: >Yes. RXTX was patched to behave the way it does. I don't fully >understand the issue behind the patch. Marc noticed the odd behavior as >well and offered a fix which was greeted with resistance. > >The windows implementation was done without real documentatino of the >windows API. I think I had an example from the late 80's early 90's on >Microsoft's site and some API documentation that was obviously not >microsofts in Europe. Wayne Roberts had a real need for windows support >and fixed some major issues it had. My interest at the time was mingw32. >I then cleaned it up for some specific uses I had later. The read >returning -1 when it should block didn't impact anybody and appeared to >help some people. It isnt the documented behavior though. > >There could be all sorts of latent bugs in that code but in the real >world, it gets by in almost all use cases. I think so too, never had any problems with it. > Its a hack but it worked for 100's of thousands of people over a 14 year >period. Yeah! Thanks for everyone who has contributed over the years, job well done! >Maybe its time to >revisit the code but there is more risk than gain for most people. How >do >you move forward and avoid the risk? My view is that it is quite risky and rather pointless to move forward, other than fixing bugs that really affect people. At the moment the major issue IMO is just that it seems (not been following this too carefully, so maybe I'm wrong, so in case this FUD, my apologies) that 'official' binaries are not available. I think the rewrite, tempting as it is in some respects is not the way forward. Just gentle maintenance to iron out real issues and then get the binaries out. br Kusti From ryan.boder at gmail.com Fri Mar 4 07:24:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Fri, 4 Mar 2011 09:24:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 8:52 PM, Trent Jarvi wrote: > > The windows implementation was done without real documentatino of the > windows API. I think I had an example from the late 80's early 90's on > Microsoft's site and some API documentation that was obviously not > microsofts in Europe. Wayne Roberts had a real need for windows support and > fixed some major issues it had. My interest at the time was mingw32. I then > cleaned it up for some specific uses I had later. The read returning -1 > when it should block didn't impact anybody and appeared to help some people. > It isnt the documented behavior though. > > There could be all sorts of latent bugs in that code but in the real world, > it gets by in almost all use cases. Its a hack but it worked for 100's of > thousands of people over a 14 year period. Maybe its time to revisit the > code but there is more risk than gain for most people. How do you move > forward and avoid the risk? > The safest and easiest solution would be to add a javadoc comment to disableReceiveTimeout explaining the difference between the RXTX behavior and Sunacle's documented behavior so that when someone uses the method in an IDE like Eclipse a little box would pop up informing them. Generating javadoc HTML and hosting it on the RXTX website would go a long way too, when something behaves differently than I expect the first thing I do is look for the javadoc online. -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Mar 1 00:54:17 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 09:54:17 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> Message-ID: Adrian, had a look at your code/rewrite and it looks rather clean/nice. I was looking at the code to gain insight (not related to the rewrite) into what is involved in serial port programming in Windows. Or rather, to refresh my memory and see how others have done, because I've been there done that. So my questions are just to satisfy my curiosity, not to criticize or suggest improvements. 1) It looks like a new thread (EventMonitor) is created for each Serial port, is that correct? Many people seem to try to avoid using many threads in this sort of situation, and like to use something like unix select(). I personally find using threads more natural and better impedance match to the problem being solved here. I guess 'many people' above refers to those implementing thousands of connections and who cannot live with the overhead and limited number of threads available. 2) The EventMonitor basically polls for events at 50 msec interval? 3) There is a comment in the source code near the sleep(50) : // Sufficient up to 19200 baud I'm sure you thought about this carefully, so again not criticizing, but seeking to understand how or why, because at 50 msec would seem to limit through in some cases. Like if you send one byte and need to wait for one to return, then this limits speed to 200 chars/sec? 4) I've done something similar to a few years back from Java using JNI to access Win32 API serial port, and I seem to recall that I had threading issues ie when I submitted a read (ReadFile) and there was no data coming in, the thread would not only block but also consume a lot of CPU cycles ie it was not sleeping properly inside the ReadFile call when the serial port blocked. Im a bit fuzzy about the details after five years, so my question is have you checked if there an issue here? 5) AFAIK the select() on Windows does not work serial ports but there is some other mechanism (events?) to implement the same functionality, did you consider that? Probably, so you decided against it, why? br Kusti From adrian.crum at sandglass-software.com Tue Mar 1 04:13:34 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:13:34 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: References: Message-ID: <4D6CD4DE.7040501@sandglass-software.com> The javax.comm API specification requires one event monitor thread per port. I don't like the idea of having a thread per port either, but one of the rewrite's design goals is strict conformance to the specification. The 50 mS polling interval is just a placeholder. The final design of that is yet to be decided. In Windows, you have two choices for I/O: overlapped and non-overlapped. In overlapped I/O a thread is blocked, waiting for something to happen. In non-overlapped I/O a thread does not block. I chose non-overlapped I/O to avoid thread blocking at the OS level - instead, the thread blocking is kept in Java. -Adrian On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > Adrian, > > had a look at your code/rewrite and it looks rather clean/nice. > > I was looking at the code to gain insight (not related to the > rewrite) into what is involved in serial port programming > in Windows. Or rather, to refresh my memory and see how others have > done, because I've been there done that. > > So my questions are just to satisfy my curiosity, not to criticize > or suggest improvements. > > 1) It looks like a new thread (EventMonitor) is created for > each Serial port, is that correct? > > Many people seem to try to avoid using many threads in this sort > of situation, and like to use something like unix select(). > I personally find using threads more natural and better impedance > match to the problem being solved here. I guess 'many people' above > > refers to those implementing thousands of connections and > who cannot live with the overhead and limited number of threads > available. > > 2) The EventMonitor basically polls for events at 50 msec interval? > > 3) There is a comment in the source code near the sleep(50) : > > // Sufficient up to 19200 baud > > > I'm sure you thought about this carefully, so again not > criticizing, but seeking to understand how or why, because > at 50 msec would seem to limit through in some cases. Like > if you send one byte and need to wait for one to return, > then this limits speed to 200 chars/sec? > > 4) I've done something similar to a few years back from > Java using JNI to access Win32 API serial port, and > I seem to recall that I had threading issues ie when > I submitted a read (ReadFile) and there was no data coming > in, the thread would not only block but also consume a > lot of CPU cycles ie it was not sleeping properly inside > the ReadFile call when the serial port blocked. > > Im a bit fuzzy about the details after five years, so my question is > have you checked if there an issue here? > > > 5) AFAIK the select() on Windows does not work serial ports > but there is some other mechanism (events?) to implement the > same functionality, did you consider that? Probably, so you > decided against it, why? > > > br Kusti > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Tue Mar 1 04:25:23 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:25:23 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C2E90.9010601@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > My question would be: Why would you do that? The rewrite does > most of the work for you - all you have to do is implement > two C++ virtual classes and two C++ functions. You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? I just took a short look, maybe it could be discussed further, but I don't think I like it much. BTW, the main interface defined there is called gnu.io.Dispatcher? I thought the package names should be used in a way to avoid clashes, e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name space authority :)). > In Windows that took me a few hours. where is the implementation? I found commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp with things like const bool SerialPortImpl::isDataAvailable() const { // Needs implementation return true; } and timeouts.ReadIntervalTimeout = MAXDWORD;* timeouts.ReadTotalTimeoutMultiplier = 0; timeouts.ReadTotalTimeoutConstant = 0; timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 0; if (!SetCommTimeouts(hComm, &timeouts)) throw IOException(); which seems to be oversimplified or some prototype only? I think (and I wrote about this already in the past years) that correct timeout handling is one of the challenges, so I think this should be prototyped first - for each system flavor - before cementation of the (JNI-) interfaces. Personally, I would vote to form it in a way allowing to be implemented on embedded devices, for example. Another big challenge is to prove a rewrite fully working (and probably compatible to the old implementation) on "all" the supported OSes. Not a big problem for linux and windows, just use some thousand lines test code, test drivers and serial loopbacks etc, but for the exotic platforms, probably a high number of, this probably won't be too easy... (there are more challenges, such as being comfortable and threadsafe [are read and write permitted at the same time?], detailed and helpful exceptions on user API level [not necessarily on JNI/JNA layer], how to have a configurable threadsafe logging/tracing [maybe also from native code to assist porting / testing on exotic OSes, such as OSes where the developers have no direct access too, which can be quite hard to usually leads to good log messages], just to name a few.). So even it might seem easy for one platform and I agree with Micheal that > > * yay! let's start a rewrite is unlikely to succeede soon... However, when considering this, before IMHO a powerful Java API has to be defined, because according to my experiences for implementing non-trivial protocols InputStream/OutputStream might not be comfortable/powerfull enough (eventually I consider both wrong) and have some InputStream derivation available as wrapper (so applications can use InputStream and whatever high-level-API they want). The JNI interface shall make such a powerful implementation possible, thus the interface of it is driving the JNI interface design and thus I think it had to be done first. All this surely requires much work: agreements on the APIs, safeness for the users, design, documentation, all the implementations and the testing. As long as such bug amount of work cannot be spent, for example if some employee would get half a year time paid for it or so :-), probably it is unlikely to progress on this. Otherwise, I'm afraid, patches, improvements, new design ideas and even rewrites wouldn't become complete and thus won't form a new rxtx version (3.0); thus either collect dust in some forgotten CVS branch or could generate a split... > I can't imagine other ports taking > much longer than that - especially since POSIX-based code can > be shared between ports. Things are more complex than they seem to be... I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select on serial ports isn't supported; maybe it is non-trivial to "map" (like mapping select() to WaitForMultipleObjects() which might have different semantics etc.) or maybe some different approach has to be used. A system may have POSIX like termios interfaces but not support timeouts or have any other interoperability bug... You never run out of things that can go wrong. And if something can go wrong, it will... :-) Or, as Michael wrote: > > I seriously don't believe anyone will come up with anything better anytime soon. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue Mar 1 04:39:37 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:39:37 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com><13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED6B@COSNPREXC3.usr.ingenico.loc> > 3. Write all of the native (or non-native) code to implement > the native interface. > > Is that correct? If yes, how is that easier than the simple > implementation the current rewrite design uses? To have it complete, reliable, traceable, maintainable and well tested, it is much more work, I'm afraid. A prototype can be done within a few days (maybe on one day), but getting it right (including a passed review) IMHO is a completely different story. In the end you may end up with an average of ten lines per day, when assuming four major native packs (common, win, mac, termios/select) with let's say just 5000 lines each (with logging messages and detailed exceptions this is not much) we would have to estimate a total effort of nine man-years (20000/10/220)... oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 04:40:18 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:40:18 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6CDB22.9070401@sandglass-software.com> Every journey begins with a single step. -Adrian On 3/1/2011 3:25 AM, Steffen DETTMER wrote: > * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> My question would be: Why would you do that? The rewrite does >> most of the work for you - all you have to do is implement >> two C++ virtual classes and two C++ functions. > You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? > I just took a short look, maybe it could be discussed further, > but I don't think I like it much. > BTW, the main interface defined there is called gnu.io.Dispatcher? > I thought the package names should be used in a way to avoid clashes, > e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name > space authority :)). > >> In Windows that took me a few hours. > where is the implementation? > I found > commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp > with things like > > const bool SerialPortImpl::isDataAvailable() const > { > // Needs implementation > return true; > } > > and > > timeouts.ReadIntervalTimeout = MAXDWORD;* > timeouts.ReadTotalTimeoutMultiplier = 0; > timeouts.ReadTotalTimeoutConstant = 0; > timeouts.WriteTotalTimeoutMultiplier = 0; > timeouts.WriteTotalTimeoutConstant = 0; > if (!SetCommTimeouts(hComm,&timeouts)) > throw IOException(); > > which seems to be oversimplified or some prototype only? > > I think (and I wrote about this already in the past years) that correct > timeout handling is one of the challenges, so I think this should be > prototyped first - for each system flavor - before cementation of the > (JNI-) interfaces. Personally, I would vote to form it in a way allowing > to be implemented on embedded devices, for example. > > Another big challenge is to prove a rewrite fully working (and probably > compatible to the old implementation) on "all" the supported OSes. Not a > big problem for linux and windows, just use some thousand lines test > code, test drivers and serial loopbacks etc, but for the exotic > platforms, probably a high number of, this probably won't be too easy... > (there are more challenges, such as being comfortable and threadsafe > [are read and write permitted at the same time?], detailed and helpful > exceptions on user API level [not necessarily on JNI/JNA layer], how to > have a configurable threadsafe logging/tracing [maybe also from native > code to assist porting / testing on exotic OSes, such as OSes where the > developers have no direct access too, which can be quite hard to usually > leads to good log messages], just to name a few.). > > So even it might seem easy for one platform and I agree with Micheal > that > >>> * yay! let's start a rewrite > is unlikely to succeede soon... > > However, when considering this, before IMHO a powerful Java API has to > be defined, because according to my experiences for implementing > non-trivial protocols InputStream/OutputStream might not be > comfortable/powerfull enough (eventually I consider both wrong) and have > some InputStream derivation available as wrapper (so applications can > use InputStream and whatever high-level-API they want). > The JNI interface shall make such a powerful implementation possible, > thus the interface of it is driving the JNI interface design and thus I > think it had to be done first. > > All this surely requires much work: agreements on the APIs, safeness for > the users, design, documentation, all the implementations and the > testing. As long as such bug amount of work cannot be spent, for example > if some employee would get half a year time paid for it or so :-), > probably it is unlikely to progress on this. > > Otherwise, I'm afraid, patches, improvements, new design ideas and even > rewrites wouldn't become complete and thus won't form a new rxtx version > (3.0); thus either collect dust in some forgotten CVS branch or could > generate a split... > >> I can't imagine other ports taking >> much longer than that - especially since POSIX-based code can >> be shared between ports. > Things are more complex than they seem to be... > > I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select > on serial ports isn't supported; maybe it is non-trivial to "map" (like > mapping select() to WaitForMultipleObjects() which might have different > semantics etc.) or maybe some different approach has to be used. A > system may have POSIX like termios interfaces but not support timeouts > or have any other interoperability bug... > You never run out of things that can go wrong. And if something can go > wrong, it will... :-) > > Or, as Michael wrote: > >>> I seriously don't believe anyone will come up with anything better > anytime soon. > > oki, > > Steffen > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Kustaa.Nyholm at planmeca.com Tue Mar 1 04:57:02 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 13:57:02 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: On 3/1/11 13:13, "Adrian Crum" wrote: >The javax.comm API specification requires one event monitor thread per >port. I don't like the idea of having a thread per port either, but one >of the rewrite's design goals is strict conformance to the specification. Ah, had not spotted that requirement. > >The 50 mS polling interval is just a placeholder. The final design of >that is yet to be decided. > >In Windows, you have two choices for I/O: overlapped and non-overlapped. >In overlapped I/O a thread is blocked, waiting for something to happen. >In non-overlapped I/O a thread does not block. I chose non-overlapped >I/O to avoid thread blocking at the OS level - instead, the thread >blocking is kept in Java. > >-Adrian thanks for the explanation. br Kusti From iqzw2r602 at sneakemail.com Tue Mar 1 05:08:17 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:08:17 +1100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <32684-1298981297-704398@sneakemail.com> This reminds me of a nasty problem I had with overlapped I/O on windows with jpathwatch. You can't start an I/O request in one thread and then do the check if that request completed in another thread. Very strange things happen when you attempt that; made me change the design of the Windows implementation quite drastically (one thread on a command queue that executes requests from other threads instead of letting them wildly call into GetOverlappedResult()). Out of curiosity: Did you come across that too? Or are all requests handled in the same thread they're issued? Cheers, Uwe On Tue, Mar 1, 2011 at 10:13 PM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > The javax.comm API specification requires one event monitor thread per > port. I don't like the idea of having a thread per port either, but one of > the rewrite's design goals is strict conformance to the specification. > > The 50 mS polling interval is just a placeholder. The final design of that > is yet to be decided. > > In Windows, you have two choices for I/O: overlapped and non-overlapped. In > overlapped I/O a thread is blocked, waiting for something to happen. In > non-overlapped I/O a thread does not block. I chose non-overlapped I/O to > avoid thread blocking at the OS level - instead, the thread blocking is kept > in Java. > > -Adrian > > > On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > >> Adrian, >> >> had a look at your code/rewrite and it looks rather clean/nice. >> >> I was looking at the code to gain insight (not related to the >> rewrite) into what is involved in serial port programming >> in Windows. Or rather, to refresh my memory and see how others have >> done, because I've been there done that. >> >> So my questions are just to satisfy my curiosity, not to criticize >> or suggest improvements. >> >> 1) It looks like a new thread (EventMonitor) is created for >> each Serial port, is that correct? >> >> Many people seem to try to avoid using many threads in this sort >> of situation, and like to use something like unix select(). >> I personally find using threads more natural and better impedance >> match to the problem being solved here. I guess 'many people' above >> >> refers to those implementing thousands of connections and >> who cannot live with the overhead and limited number of threads >> available. >> >> 2) The EventMonitor basically polls for events at 50 msec interval? >> >> 3) There is a comment in the source code near the sleep(50) : >> >> // Sufficient up to 19200 baud >> >> >> I'm sure you thought about this carefully, so again not >> criticizing, but seeking to understand how or why, because >> at 50 msec would seem to limit through in some cases. Like >> if you send one byte and need to wait for one to return, >> then this limits speed to 200 chars/sec? >> >> 4) I've done something similar to a few years back from >> Java using JNI to access Win32 API serial port, and >> I seem to recall that I had threading issues ie when >> I submitted a read (ReadFile) and there was no data coming >> in, the thread would not only block but also consume a >> lot of CPU cycles ie it was not sleeping properly inside >> the ReadFile call when the serial port blocked. >> >> Im a bit fuzzy about the details after five years, so my question is >> have you checked if there an issue here? >> >> >> 5) AFAIK the select() on Windows does not work serial ports >> but there is some other mechanism (events?) to implement the >> same functionality, did you consider that? Probably, so you >> decided against it, why? >> >> >> br Kusti >> >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 05:37:07 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:37:07 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <1142-1298983027-957144@sneakemail.com> On Tue, Mar 1, 2011 at 1:32 PM, Adrian Crum wrote: > Just to make sure I'm understanding you correctly, anyone porting RxTx to > a new platform would have to do the following: > > 1. Write their own Java implementation of an abstract Dispatcher class. > yep. I'd probably put all my calls to native OS wrappers in there two, looks the most straight-forward to me. > 2. Write a native (JNI or JNA) interface for the abstract class > implementation. > yes. For POSIX you'd probably only write one piece of code that provides implementations for open(), close(), and friends. You can compile that on all posix platforms (yeah, the devil is in the detail, but it's very little code, still). So this does open() (when using ***, but you can also use +++) // Unix.java class Unix{ public static native int open(String filename, int flags, int mode); .... } // Unix.cpp JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) { const char* pathname = env->GetStringUTFChars(jpathname, 0); if(pathname == 0) return -1; // java throws an out of memory error in this case int result = open(pathname, flags, mode); Unix_cacheErrno(); // handle interference between JVM and errno; env->ReleaseStringUTFChars(jpathname, pathname); return result; } .... 3. Write all of the native (or non-native) code to implement the native > interface. > Not sure what you mean by that. I've done the OS wrappers in step 2. step 1. implements that Dispatcher. What else do I need? > Is that correct? If yes, how is that easier than the simple implementation > the current rewrite design uses? > Yes, except for 3 (see above). How it is easier: I can debug the Java code directly. I can step from the read() call of an input stream directly into the guts of the RXTX implementation on my platform and see e.g. why it's hanging, because I see all the way up the call stack right where it calls Unix.read(). You can't easily do that with a fat native library, especially if you have no second set of devtools installed (the ones for native development). And I bet anyone knowing both languages can write it faster in Java, with less bugs. > On a side note: there is no requirement to write native code using C++. If > C++ is a real obstacle to adoption, then regular C could be used instead. In > that case, there would be a Dispatcher.c file that contains function > protoypes that need to be implemented. Dispatcher.c would still maintain the > same role as Dispatcher.cpp - which is to shield native code developers from > the details of JNI. Just build out the missing functions using C data types > and you're ready to go. > As I said, whatever works for you. Java works for me better than C++ in this case... Cheers, Uwe -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Mar 1 08:26:41 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 16:26:41 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> > The javax.comm API specification requires one event monitor > thread per port. Where does it require this? Do you mean "All the events received by this listener are generated by one dedicated thread that belongs to the SerialPort object. "? I think this is an implementation detail, isn't it? At least it is mentioned after "The current implementation only allows one listener per SerialPort". A bit bad that javadoc does not distinguish between API spec and implementation documentation. Also I don't think that TooManyListenersException MUST be thrown (I think it CAN be thrown). > I don't like the idea of having a thread per > port either, but one of the rewrite's design goals is strict > conformance to the specification. (but not necessarily on JNI layer) > The 50 mS polling interval is just a placeholder. The final > design of that is yet to be decided. I though no polling would be wanted; what could be the placeholder stand for? Do you mean a different interval duration or do you mean something completely different? > In Windows, you have two choices for I/O: overlapped and > non-overlapped. > In overlapped I/O a thread is blocked, waiting for something > to happen. > In non-overlapped I/O a thread does not block. I chose > non-overlapped I/O to avoid thread blocking at the OS level - > instead, the thread blocking is kept in Java. Isn't "overlapped" (asynchronous) I/O meaning that you invoke some ReadFile(..., &overlapped, ...) INSTEAD of performing a synchronous (blocking) function call blocking the thread? As far as I see, W32_Support.cpp uses CreateFile without FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O operations are serialized, even if the calls to the read and write functions specify an OVERLAPPED structure." [1] and "A synchronous handle behaves such that I/O function calls using that handle are blocked until they complete" [2] Given that CCOMTIMEOUTS get: "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the bytes that have already been received, even if no bytes have been received." [3] It looks likes this implementation relies on polling, which probably would waste much computing power. What did I miss? oki, Steffen [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro nous_and_asynchronous_i_o_handles [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 09:23:47 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:23:47 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6D1D93.6090306@sandglass-software.com> Unfortunately, the javax.comm API specification includes a lot of implementation details. That is one of the weaknesses of the specification in my opinion. The bottom line is, anyone wanting to use RxTx as a javax.comm implementation is going to expect it to do the things the specification says it does. -Adrian On 3/1/2011 7:26 AM, Steffen DETTMER wrote: >> The javax.comm API specification requires one event monitor >> thread per port. > Where does it require this? > > Do you mean "All the events received by this listener are generated > by one dedicated thread that belongs to the SerialPort object. "? > > I think this is an implementation detail, isn't it? At least it is > mentioned after "The current implementation only allows one listener per > SerialPort". A bit bad that javadoc does not distinguish between API > spec and implementation documentation. Also I don't think that > TooManyListenersException MUST be thrown (I think it CAN be thrown). > >> I don't like the idea of having a thread per >> port either, but one of the rewrite's design goals is strict >> conformance to the specification. > (but not necessarily on JNI layer) > >> The 50 mS polling interval is just a placeholder. The final >> design of that is yet to be decided. > I though no polling would be wanted; what could be the placeholder stand > for? Do you mean a different interval duration or do you mean something > completely different? > >> In Windows, you have two choices for I/O: overlapped and >> non-overlapped. >> In overlapped I/O a thread is blocked, waiting for something >> to happen. >> In non-overlapped I/O a thread does not block. I chose >> non-overlapped I/O to avoid thread blocking at the OS level - >> instead, the thread blocking is kept in Java. > Isn't "overlapped" (asynchronous) I/O meaning that you invoke some > ReadFile(...,&overlapped, ...) > INSTEAD of performing a synchronous (blocking) function call blocking > the thread? > > As far as I see, W32_Support.cpp uses CreateFile without > FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O > operations are serialized, even if the calls to the read and write > functions specify an OVERLAPPED structure." [1] and "A synchronous > handle behaves such that I/O function calls using that handle are > blocked until they complete" [2] > > Given that CCOMTIMEOUTS get: > "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values > for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier > members, specifies that the read operation is to return immediately with > the bytes that have already been received, even if no bytes have been > received." [3] > > It looks likes this implementation relies on polling, which probably > would waste much computing power. > > What did I miss? > > oki, > > Steffen > > [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx > [2] > http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro > nous_and_asynchronous_i_o_handles > [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at sandglass-software.com Tue Mar 1 09:55:29 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:55:29 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <1142-1298983027-957144@sneakemail.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> Message-ID: <4D6D2501.1020803@sandglass-software.com> That code duplicates what is in Dispatcher.cpp. A Unix port would only need to implement CommPortFactory::getInstance(portName, portType). -Adrian On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 15:07:46 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 2 Mar 2011 09:07:46 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6D2501.1020803@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> <4D6D2501.1020803@sandglass-software.com> Message-ID: <23749-1299017266-991798@sneakemail.com> What is this duplicating? A Unix port will need to call open() anyways (just so we're talking about the same thing here: open() is the Unix equivalent of CreateFile()) On Wed, Mar 2, 2011 at 3:55 AM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > That code duplicates what is in Dispatcher.cpp. A Unix port would only > need to implement CommPortFactory::getInstance(portName, portType). > > -Adrian > > > On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Tue Mar 1 22:53:07 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 00:53:07 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: Hi, I haven't seen any response to my question below. Is this not the right place to ask? If not, where would be a better place to ask? Any suggestions? Thanks, Ryan On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >> Hi, >> >> I have a receive thread that does nothing but call read() on the serial >> port input stream. It works fine for a while but after running for a long >> time it eventually returns -1 which means EOF. This is my first problem, as >> the device I'm talking to runs forever, I don't know why it would return -1. >> I am calling disableReceiveThreshold() and disableReceiveTimeout() at >> initialization which according to the documentation means read will return >> as soon as any data is available and it will block forever when data is not >> available, so -1 should never be returned from read, right? >> >> I have been unable to figure out why read returns -1 after a long while >> but I have found that if I kill my application and restart it everything >> works fine again. Therefore I tried to work around the problem by having my >> code close the port and reopen it when read returns -1. My second problem is >> that in this case when I call close() on the port it blocks forever. I did >> find this old bug >> >> http://bugzilla.qbang.org/show_bug.cgi?id=53 >> >> which describes close() hanging on OSX, but it says that bug was fixed >> with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have >> any idea why read might be returning -1 in the first place? If I can avoid >> that I don't care about close() hanging because I would never close the >> port. If not, does anyone know why close() might block forever and how I can >> prevent this? I'm using RXTX version 2.1-7. >> >> Thanks, >> -- >> Ryan >> >> > > > -- > Ryan Boder > 1 614 598-6339 > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Mar 2 01:34:48 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 2 Mar 2011 10:34:48 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/2/11 07:53, "Ryan Boder" wrote: Can you / have you made a simple test to ensure that rxtx is the issue? Can you write a simple C-program to see if this exhibits the same problem? I've never encountered this sort of problem with rxtx, it mostly just works. But I'm on Mac so can't say about Windows (7) br Kusti >Hi, > >I haven't seen any response to my question below. Is this not the right >place to ask? If not, where would be a better place to ask? Any >suggestions? > >Thanks, >Ryan > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > >I mis-spoke, I don't have my own thread calling read, I am calling >read in the event handler after receiving a >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be >accurate though. > >Ryan > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >Hi, > >I have a receive thread that does nothing but call read() on the serial >port input stream. It works fine for a while but after running for a long >time it eventually returns -1 which means EOF. This is my first problem, >as the device I'm talking to runs forever, I don't know why it would >return -1. I am calling disableReceiveThreshold() and >disableReceiveTimeout() at initialization which according to the >documentation means read will return as soon as any data is available and >it will block forever when data is not available, so -1 should never be >returned from read, right? > >I have been unable to figure out why read returns -1 after a long while >but I have found that if I kill my application and restart it everything >works fine again. Therefore I tried to work around the problem by having >my code close the port and reopen it when read returns -1. My second >problem is that in this case when I call close() on the port it blocks >forever. I did find this old bug > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > >which describes close() hanging on OSX, but it says that bug was fixed >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone >have any idea why read might be returning -1 in the first place? If I can >avoid that I don't care about close() hanging because I would never close >the port. If not, does anyone know why close() might block forever and >how I can prevent this? I'm using RXTX version 2.1-7. > >Thanks, >-- >Ryan > > > > > > > > > >-- >Ryan Boder >1 614 598-6339 > > > > > > >-- >Ryan Boder >1 614 598-6339 > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From Steffen.DETTMER at ingenico.com Wed Mar 2 03:08:57 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:08:57 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <32684-1298981297-704398@sneakemail.com> References: <4D6CD4DE.7040501@sandglass-software.com> <32684-1298981297-704398@sneakemail.com> Message-ID: <20110302100857.GB8030@elberon.bln.de.ingenico.com> * iqzw2r602 at sneakemail.com wrote on Tue, Mar 01, 2011 at 23:08 +1100: > This reminds me of a nasty problem I had with overlapped I/O on windows Yeah, those thousands of complex, difficult to use and exception-containing WinAPI is really hard to use... About strange effects on overlapped&multithreading, MSDN has: `the calling thread uses the GetOverlappedResult function or one of the wait functions' [1] also also mentiones I/O Completion Ports [2], and later continues: `If an application reuses OVERLAPPED structures on multiple threads and calls GetOverlappedResult with the bWait parameter set to TRUE, the application must ensure that the associated event is set before the application reuses the structure. This can be accomplished by using the WaitForSingleObject function after calling GetOverlappedResult to force the thread to wait until the operation completes. Note that the event object must be a manual-reset event object. If an autoreset event object is used, calling GetOverlappedResult with the bWait parameter set to TRUE causes the function to be blocked indefinitely.' also [1] oki, Steffen [1] http://msdn.microsoft.com/en-us/library/ms686358%28v=vs.85%29.aspx [2] http://msdn.microsoft.com/en-us/library/aa365198%28v=vs.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:15:11 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:15:11 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6D1D93.6090306@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> <4D6D1D93.6090306@sandglass-software.com> Message-ID: <20110302101511.GC8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 08:23 -0800: > Unfortunately, the javax.comm API specification includes a lot of > implementation details. That is one of the weaknesses of the > specification in my opinion. The bottom line is, anyone wanting to use > RxTx as a javax.comm implementation is going to expect it to do the > things the specification says it does. Yeah ok, but even then the implementation could check for the TooManyListenersException situations (if it really is required to support applications relying on that exception) but internally use just a single I/O thread waiting for events on any open file descriptors. Of course an implementation supporting all sort of concurrency could become quite complex (especially if open-read-close should work fast, I think would be difficult to implement, because a new file descriptors had to be added to the waitFor/select list, and who knows how systems behave here in detail...). oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:25:15 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:25:15 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6CDB22.9070401@sandglass-software.com> References: <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> <4D6CDB22.9070401@sandglass-software.com> Message-ID: <20110302102515.GD8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 03:40 -0800: > * from some older mail: > > My question would be: Why would you do that? The rewrite does > > most of the work for you - all you have to do is implement > > two C++ virtual classes and two C++ functions. > > > > In Windows that took me a few hours. > > Every journey begins with a single step. Yes, of course, but then it shouldn't be used as base for new effort estimations like `In Windows that took a few hours' ;-) (BTW, calling a single step `the rewrite' may sound a bit ambitious ;)) But of course a prototype demonstrating something can be really helpful, sure. I just wanted to tell that interfaces should be easy to use and powerful at the same time and may non-trivial initial considerations before starting to implement them. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From ryan.boder at gmail.com Wed Mar 2 18:44:35 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:44:35 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: While running the tests you requested I may have stumbled on the problem, I just don't know how to fix it. According to the documentation, if both the receive timeout and receive threshold are disabled then read() should block forever until data is available. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#getInputStream%28%29 On my system using RXTX read() is returning -1 when no data is available even though I have disabled both thresholds. The reason my program was running fine for a while without this problem showing up is that I was using the DATA_AVAILABLE event to be notified when data is available and only calling read() to read an entire frame whenever the DATA_AVAILABLE event occurred, until eventually my device (I'm guessing) probably took longer than normal to send the entire data frame and therefore I called read when no data was available and it returned -1. The following Java program demonstrates my problem, it returns -1 as soon as no data is available, even though I think it should block until data is available. import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; public class Main implements SerialPortEventListener { public static void main(String[] args) throws Exception { new Main().run(); } private void run() throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier("COM4"); SerialPort port = (SerialPort) portIdentifier.open(Main.class.getName(), 2000); port.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); port.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); port.disableReceiveThreshold(); port.disableReceiveTimeout(); BufferedInputStream in = new BufferedInputStream(port.getInputStream()); BufferedOutputStream out = new BufferedOutputStream(port.getOutputStream()); port.addEventListener(this); Thread.sleep(1000); out.write(new byte[] {0x02, 0x60}); out.flush(); while (true) { int x = in.read(); if (x == -1) { System.out.println("EOF"); Thread.sleep(1000000000); } String s = Integer.toHexString(x & 0xFF); if (s.length() == 1) s = "0" + s; System.out.print(s + " "); System.out.flush(); } } public void serialEvent(SerialPortEvent arg0) { System.out.println("Serial port event"); } } However, the follow C# program ran all day today without ever read ever returning -1, as I would expect. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.IO.Ports; using System.Threading; namespace RXTXReadTest1 { class Program { static void Main(string[] args) { new Program().run(); } private void run() { SerialPort port = new SerialPort("COM4", 19200, Parity.None, 8, StopBits.One); port.Open(); port.Write(new byte[] { 0x02, 0x60 }, 0, 2); while (true) { int x = port.ReadByte(); if (x == -1) { Console.WriteLine("EOF"); Thread.Sleep(1000000000); } String s = x.ToString("X"); if (s.Length == 1 ) s = "0" + s; Console.Out.Write(s + " "); Console.Out.Flush(); } } } } Now I am experimenting with what happens if I set the receive timeout to it's maximum value (apparently 1600ms) and only call read() when I am expecting data. Hopefully it will never be more than 1600ms late. This is still only a work around, not solving the problem. Am I doing something wrong in my code above or is RXTX retuning -1 when it should be blocking? Thanks, Ryan On Wed, Mar 2, 2011 at 3:34 AM, Kustaa Nyholm wrote: > On 3/2/11 07:53, "Ryan Boder" wrote: > Can you / have you made a simple test to ensure that rxtx is the issue? > > Can you write a simple C-program to see if this exhibits the same problem? > > I've never encountered this sort of problem with rxtx, it mostly just > works. > > But I'm on Mac so can't say about Windows (7) > > br Kusti > > > > > >Hi, > > > >I haven't seen any response to my question below. Is this not the right > >place to ask? If not, where would be a better place to ask? Any > >suggestions? > > > >Thanks, > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder > wrote: > > > >I mis-spoke, I don't have my own thread calling read, I am calling > >read in the event handler after receiving a > >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be > >accurate though. > > > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder > wrote: > > > >Hi, > > > >I have a receive thread that does nothing but call read() on the serial > >port input stream. It works fine for a while but after running for a long > >time it eventually returns -1 which means EOF. This is my first problem, > >as the device I'm talking to runs forever, I don't know why it would > >return -1. I am calling disableReceiveThreshold() and > >disableReceiveTimeout() at initialization which according to the > >documentation means read will return as soon as any data is available and > >it will block forever when data is not available, so -1 should never be > >returned from read, right? > > > >I have been unable to figure out why read returns -1 after a long while > >but I have found that if I kill my application and restart it everything > >works fine again. Therefore I tried to work around the problem by having > >my code close the port and reopen it when read returns -1. My second > >problem is that in this case when I call close() on the port it blocks > >forever. I did find this old bug > > > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > > > >which describes close() hanging on OSX, but it says that bug was fixed > >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone > >have any idea why read might be returning -1 in the first place? If I can > >avoid that I don't care about close() hanging because I would never close > >the port. If not, does anyone know why close() might block forever and > >how I can prevent this? I'm using RXTX version 2.1-7. > > > >Thanks, > >-- > >Ryan > > > > > > > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Wed Mar 2 18:46:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:46:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: <-1051064942000733580@unknownmsgid> References: <-1051064942000733580@unknownmsgid> Message-ID: It is USB and seems very reliable with the C# test program in my previous email. On Wed, Mar 2, 2011 at 6:58 PM, Bruce Griffith wrote: > How reliable is your serial port ? is it USB or Bluetooth? > > > > Bruce Griffith > > 303-532-4778 > > > > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On Behalf > Of *Ryan Boder > *Sent:* Tuesday, 01 March 2011 10:53 PM > *To:* rxtx at qbang.org > *Subject:* Re: [Rxtx] RXTX serial port read() returns -1 unexpectedly and > then blocks forever on close() > > > > Hi, > > I haven't seen any response to my question below. Is this not the right > place to ask? If not, where would be a better place to ask? Any suggestions? > > Thanks, > Ryan > > On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > > Hi, > > I have a receive thread that does nothing but call read() on the serial > port input stream. It works fine for a while but after running for a long > time it eventually returns -1 which means EOF. This is my first problem, as > the device I'm talking to runs forever, I don't know why it would return -1. > I am calling disableReceiveThreshold() and disableReceiveTimeout() at > initialization which according to the documentation means read will return > as soon as any data is available and it will block forever when data is not > available, so -1 should never be returned from read, right? > > I have been unable to figure out why read returns -1 after a long while but > I have found that if I kill my application and restart it everything works > fine again. Therefore I tried to work around the problem by having my code > close the port and reopen it when read returns -1. My second problem is that > in this case when I call close() on the port it blocks forever. I did find > this old bug > > http://bugzilla.qbang.org/show_bug.cgi?id=53 > > which describes close() hanging on OSX, but it says that bug was fixed with > a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have any > idea why read might be returning -1 in the first place? If I can avoid that > I don't care about close() hanging because I would never close the port. If > not, does anyone know why close() might block forever and how I can prevent > this? I'm using RXTX version 2.1-7. > > Thanks, > -- > Ryan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Mar 3 02:50:20 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 3 Mar 2011 09:50:20 +0000 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: So if -1 is unexpectedly returned from read, and we have demonstrated that your USB-serial adapter can actually causes this to happen in RXTX, why not just ignore the -1 value? What happens when you try this? As for a hang on close, are your closing your port from within your serial event handler? I know that this can cause some serious problems. Regards, Michael Erskine. From Kustaa.Nyholm at planmeca.com Thu Mar 3 03:39:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 12:39:34 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 03:44, "Ryan Boder" wrote: >While running the tests you requested I may have stumbled on the problem, >I just don't know how to fix it. According to the documentation, if both >the receive timeout and receive threshold are disabled then read() should >block forever until data is available. > >http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/re >ference/api/javax/comm/CommPort.html#getInputStream%28%29 > >On my system using RXTX read() is returning -1 when no data is available >even though I have disabled both thresholds. The reason my program was >running fine for a while without this problem showing up is that I was >using the DATA_AVAILABLE event to be notified when data is available and >only calling read() to read an entire frame whenever the DATA_AVAILABLE >event occurred, until eventually my device (I'm guessing) probably took >longer than normal to send the entire data frame and therefore I called >read when no data was available and it returned -1. As a workaround have you tried to perform another read() if it returns -1? The javadoc says (see getInputStream): "Note, however, that framing errors may cause the Timeout and Threshold values to complete prematurely without raising an exception." I read this as a hint that read might return even if no data is available. Because of the above and that read() can only return -1 or the byte received it would be somewhat logical to return -1 in case of framing error ? I'm not claiming that my interpretation of the specification, such as it is, is correct, just speculating that the behavior could be something like that. It might give you some more insight if you used the read(bytes[],int,int) method, because this can and will return 0 in case of timeout (and presumably might do so in case of framing error, maybe some other error condition too). That might allow you to handle or work around the problem in this case. You have not shown your complete code (no need) but your comments and the example makes me wonder if the code is otherwise as it should be, meaning are you assuming that when you get the DATA_AVAILABLE event all of your frame has arrived and that you can just blindly read it away from the input stream? That is not guaranteed of course. Also using read(), instead of read(bytes[],int,int), is not very efficient and might be masking other problems as mused above. BTE you can print a byte in hex with leading zeros more easily with: System.out.printf("%02X",x); br Kusti From ryan.boder at gmail.com Thu Mar 3 07:56:16 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:56:16 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 5:39 AM, Kustaa Nyholm wrote: > > As a workaround have you tried to perform another read() if it returns -1? > I tried that and it did work sometimes but not all the time. > > The javadoc says (see getInputStream): > > "Note, however, that framing errors may cause the Timeout and Threshold > values to complete prematurely without raising an exception." > > I read this as a hint that read might return even if no data is available. > > Because of the above and that read() can only return -1 or the byte > received > it would be somewhat logical to return -1 in case of framing error ? > > I'm not claiming that my interpretation of the specification, such as it > is, > is correct, just speculating that the behavior could be something like > that. > Receive framing is not enabled by default. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#enableReceiveFraming%28int%29 My choice of word might be misleading, when I said frame I just meant a contiguous message from the device. I am not enabling receive framing. Can you have a framing error when receive framing is disabled? > > It might give you some more insight if you used the read(bytes[],int,int) > method, because > this can and will return 0 in case of timeout (and presumably might do so > in case of framing > error, maybe some other error condition too). > > That might allow you to handle or work around the problem in this case. > > You have not shown your complete code (no need) but your comments and the > example > makes me wonder if the code is otherwise as it should be, meaning are you > assuming > that when you get the DATA_AVAILABLE event all of your frame has arrived > and that > you can just blindly read it away from the input stream? That is not > guaranteed of course. > I'm not assuming the entire message has arrived, I'm just assuming it either has arrived or will arrive soon which is why I'm using a (supposedly) blocking read(). > > Also using read(), instead of read(bytes[],int,int), is not very efficient > and > might be masking other problems as mused above. > True, I'm reading one byte at a time because I don't know how long the message will be until I read and parse some of it. I suppose I can use read(bytes[],int,int) once I figure out how long the message will be. > > BTE you can print a byte in hex with leading zeros more easily with: > > > System.out.printf("%02X",x); > I did it the dumb way in that test program so I could copy and paste the code from C# to Java without having to figure out how to do the same in C# which I'm not as familiar with. Thanks and BR, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 07:58:24 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:58:24 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: Yes I was doing the close in the serial event handler, I didn't realize that caused a problem. Thanks, I'll fix it. On Thu, Mar 3, 2011 at 4:50 AM, Michael Erskine wrote: > So if -1 is unexpectedly returned from read, and we have demonstrated > that your USB-serial adapter can actually causes this to happen in > RXTX, why not just ignore the -1 value? What happens when you try > this? As for a hang on close, are your closing your port from within > your serial event handler? I know that this can cause some serious > problems. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 11:48:20 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 13:48:20 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm wrote: > On 3/3/11 16:56, "Ryan Boder" wrote: > > > >I'm not assuming the entire message has arrived, I'm just assuming it > >either has arrived or will arrive soon which is why I'm using a > >(supposedly) blocking read(). > > > I've been giving this some further thought. > > It does not feel healthy to block without timeout, especially > from within a thread that is essentially internal to the rxtx. > > I've never done that, I always use a time out, read(byte[],int,int) > for the expected number of bytes, check how much I got and issue > more reads until I get everything. > > You have not described how your communication works so I'm only > speculating. > > If your device needs some response to send more bytes (from your > code it looks like this is not the case) then a missing byte > would block your read and prevent you from responding and > getting more data. But as said, looks like that is not the case. > > Anyway, if this was my problem, I would enable the timeout > and use read(byte[],int,int) and loop until I get what I need. > You are right, I should and will use a timeout. In fact, my program has been running flawlessly for 12 hours and the only change I made was to enable a timeout, no change in the logic at all. Without the timeout read() was returning -1 usually after it ran for an hour or two. I will change the code to make use of the timeout and handle it appropriately. It still seems to me that RXTX's behavior doesn't match the documentation when rx timeout and rx threshold are disabled read() should block until data is available instead of immediately returning -1. I don't believe that a framing error is occurring immediately every time data is not available causing read() to return -1. Especially since the C# test program above runs all day with no error and the Java program above runs all day with no error when a timeout is enabled. To me it seems like enabling the timeout is what is causing read() to block until data is available, even if only for 1600ms, and without the timeout read() is returning -1 immediately when it should be blocking. Thanks for all the help and best regards, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Thu Mar 3 13:02:30 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 22:02:30 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 20:48, "Ryan Boder" wrote: >On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm > wrote: > >On 3/3/11 16:56, "Ryan Boder" wrote: >> > >>I'm not assuming the entire message has arrived, I'm just assuming it >>either has arrived or will arrive soon which is why I'm using a >>(supposedly) blocking read(). > > > >I've been giving this some further thought. > >It does not feel healthy to block without timeout, especially >from within a thread that is essentially internal to the rxtx. > >I've never done that, I always use a time out, read(byte[],int,int) >for the expected number of bytes, check how much I got and issue >more reads until I get everything. > >You have not described how your communication works so I'm only >speculating. > >If your device needs some response to send more bytes (from your >code it looks like this is not the case) then a missing byte >would block your read and prevent you from responding and >getting more data. But as said, looks like that is not the case. > >Anyway, if this was my problem, I would enable the timeout >and use read(byte[],int,int) and loop until I get what I need. > > > > >You are right, I should and will use a timeout. In fact, my program has >been running flawlessly for 12 hours and the only change I made was to >enable a timeout, no change in the logic at all. Without the timeout >read() was returning -1 usually after it ran for an hour or two. I will >change the code to make use of the timeout and handle it appropriately. That's nice! > >It still seems to me that RXTX's behavior doesn't match the documentation >when rx timeout and rx threshold are disabled read() should block until >data is available instead of immediately returning -1. Yeah, it does look like bug. However this might be related to some Windows specific serial port issue. Years ago I had issues with JavaComm (not RxTx) where I did a blocking read and I had huge issues with my program consuming all resources. I curser the Sun and JavaComm and re-code my own SerialPort using JNI to access the Win32 API directly. And I run into the same problems as with the Sun's implementation! So I ditched my code, changed my code to use timeouts and problems disappeared. > I don't believe that a framing error is occurring immediately every time >data is not available causing read() to return -1. Especially since the >C# test program above runs all day with no error and the Java program >above runs all day with no error when a timeout is enabled. I think so too, all things considered I don't really believe in framing errors in this case. > To me it seems like enabling the timeout is what is causing read() to >block until data is available, even if only for 1600ms, and without the >timeout read() is returning -1 immediately when it should be blocking. Yeah, I had a peek at the innards of RxTx Windows serial port a week or so ago and also read MSDN documentation about serial ports and the way overlapped and non-overlapped (non blocking and blocking) IO is handled is a way different. So yeah, it can well be that there is an issue lurking there somewhere inside RxTx in Windows. > > >Thanks for all the help and best regards, >-- >Ryan Boder I'm happy if I was of any assistance. br Kusti From tjarvi at qbang.org Thu Mar 3 18:52:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Mar 2011 18:52:50 -0700 (MST) Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: >> Without the timeout >> read() was returning -1 usually after it ran for an hour or two. There is a big hammer in rxtx causing that behavior. >> It still seems to me that RXTX's behavior doesn't match the documentation >> when rx timeout and rx threshold are disabled read() should block until >> data is available instead of immediately returning -1. > > Yeah, it does look like bug. However this might be related to some > Windows specific serial port issue. Years ago I had issues with > JavaComm (not RxTx) where I did a blocking read and I had huge > issues with my program consuming all resources. I curser the Sun > and JavaComm and re-code my own SerialPort using JNI to access > the Win32 API directly. And I run into the same problems as > with the Sun's implementation! So I ditched my code, changed > my code to use timeouts and problems disappeared. > > >> To me it seems like enabling the timeout is what is causing read() to >> block until data is available, even if only for 1600ms, and without the >> timeout read() is returning -1 immediately when it should be blocking. > > Yeah, I had a peek at the innards of RxTx Windows serial port a week > or so ago and also read MSDN documentation about serial ports and > the way overlapped and non-overlapped (non blocking and blocking) > IO is handled is a way different. So yeah, it can well be that > there is an issue lurking there somewhere inside RxTx in Windows. > > Yes. RXTX was patched to behave the way it does. I don't fully understand the issue behind the patch. Marc noticed the odd behavior as well and offered a fix which was greeted with resistance. The windows implementation was done without real documentatino of the windows API. I think I had an example from the late 80's early 90's on Microsoft's site and some API documentation that was obviously not microsofts in Europe. Wayne Roberts had a real need for windows support and fixed some major issues it had. My interest at the time was mingw32. I then cleaned it up for some specific uses I had later. The read returning -1 when it should block didn't impact anybody and appeared to help some people. It isnt the documented behavior though. There could be all sorts of latent bugs in that code but in the real world, it gets by in almost all use cases. Its a hack but it worked for 100's of thousands of people over a 14 year period. Maybe its time to revisit the code but there is more risk than gain for most people. How do you move forward and avoid the risk? Some have expressed interests in coding C++ or other efforts. I'm all for such efforts but feel some unit tests that work with a null modem cables are the only thing that will move rxtx (and perhaps CommAPI) forward. If we have a test suite in place as a qualification for implementations, progress can be made in the right direction regardless of the implementation details. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Fri Mar 4 02:57:16 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 4 Mar 2011 11:57:16 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/4/11 03:52, "Trent Jarvi" wrote: >Yes. RXTX was patched to behave the way it does. I don't fully >understand the issue behind the patch. Marc noticed the odd behavior as >well and offered a fix which was greeted with resistance. > >The windows implementation was done without real documentatino of the >windows API. I think I had an example from the late 80's early 90's on >Microsoft's site and some API documentation that was obviously not >microsofts in Europe. Wayne Roberts had a real need for windows support >and fixed some major issues it had. My interest at the time was mingw32. >I then cleaned it up for some specific uses I had later. The read >returning -1 when it should block didn't impact anybody and appeared to >help some people. It isnt the documented behavior though. > >There could be all sorts of latent bugs in that code but in the real >world, it gets by in almost all use cases. I think so too, never had any problems with it. > Its a hack but it worked for 100's of thousands of people over a 14 year >period. Yeah! Thanks for everyone who has contributed over the years, job well done! >Maybe its time to >revisit the code but there is more risk than gain for most people. How >do >you move forward and avoid the risk? My view is that it is quite risky and rather pointless to move forward, other than fixing bugs that really affect people. At the moment the major issue IMO is just that it seems (not been following this too carefully, so maybe I'm wrong, so in case this FUD, my apologies) that 'official' binaries are not available. I think the rewrite, tempting as it is in some respects is not the way forward. Just gentle maintenance to iron out real issues and then get the binaries out. br Kusti From ryan.boder at gmail.com Fri Mar 4 07:24:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Fri, 4 Mar 2011 09:24:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 8:52 PM, Trent Jarvi wrote: > > The windows implementation was done without real documentatino of the > windows API. I think I had an example from the late 80's early 90's on > Microsoft's site and some API documentation that was obviously not > microsofts in Europe. Wayne Roberts had a real need for windows support and > fixed some major issues it had. My interest at the time was mingw32. I then > cleaned it up for some specific uses I had later. The read returning -1 > when it should block didn't impact anybody and appeared to help some people. > It isnt the documented behavior though. > > There could be all sorts of latent bugs in that code but in the real world, > it gets by in almost all use cases. Its a hack but it worked for 100's of > thousands of people over a 14 year period. Maybe its time to revisit the > code but there is more risk than gain for most people. How do you move > forward and avoid the risk? > The safest and easiest solution would be to add a javadoc comment to disableReceiveTimeout explaining the difference between the RXTX behavior and Sunacle's documented behavior so that when someone uses the method in an IDE like Eclipse a little box would pop up informing them. Generating javadoc HTML and hosting it on the RXTX website would go a long way too, when something behaves differently than I expect the first thing I do is look for the javadoc online. -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Mar 1 00:54:17 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 09:54:17 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> Message-ID: Adrian, had a look at your code/rewrite and it looks rather clean/nice. I was looking at the code to gain insight (not related to the rewrite) into what is involved in serial port programming in Windows. Or rather, to refresh my memory and see how others have done, because I've been there done that. So my questions are just to satisfy my curiosity, not to criticize or suggest improvements. 1) It looks like a new thread (EventMonitor) is created for each Serial port, is that correct? Many people seem to try to avoid using many threads in this sort of situation, and like to use something like unix select(). I personally find using threads more natural and better impedance match to the problem being solved here. I guess 'many people' above refers to those implementing thousands of connections and who cannot live with the overhead and limited number of threads available. 2) The EventMonitor basically polls for events at 50 msec interval? 3) There is a comment in the source code near the sleep(50) : // Sufficient up to 19200 baud I'm sure you thought about this carefully, so again not criticizing, but seeking to understand how or why, because at 50 msec would seem to limit through in some cases. Like if you send one byte and need to wait for one to return, then this limits speed to 200 chars/sec? 4) I've done something similar to a few years back from Java using JNI to access Win32 API serial port, and I seem to recall that I had threading issues ie when I submitted a read (ReadFile) and there was no data coming in, the thread would not only block but also consume a lot of CPU cycles ie it was not sleeping properly inside the ReadFile call when the serial port blocked. Im a bit fuzzy about the details after five years, so my question is have you checked if there an issue here? 5) AFAIK the select() on Windows does not work serial ports but there is some other mechanism (events?) to implement the same functionality, did you consider that? Probably, so you decided against it, why? br Kusti From adrian.crum at sandglass-software.com Tue Mar 1 04:13:34 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:13:34 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: References: Message-ID: <4D6CD4DE.7040501@sandglass-software.com> The javax.comm API specification requires one event monitor thread per port. I don't like the idea of having a thread per port either, but one of the rewrite's design goals is strict conformance to the specification. The 50 mS polling interval is just a placeholder. The final design of that is yet to be decided. In Windows, you have two choices for I/O: overlapped and non-overlapped. In overlapped I/O a thread is blocked, waiting for something to happen. In non-overlapped I/O a thread does not block. I chose non-overlapped I/O to avoid thread blocking at the OS level - instead, the thread blocking is kept in Java. -Adrian On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > Adrian, > > had a look at your code/rewrite and it looks rather clean/nice. > > I was looking at the code to gain insight (not related to the > rewrite) into what is involved in serial port programming > in Windows. Or rather, to refresh my memory and see how others have > done, because I've been there done that. > > So my questions are just to satisfy my curiosity, not to criticize > or suggest improvements. > > 1) It looks like a new thread (EventMonitor) is created for > each Serial port, is that correct? > > Many people seem to try to avoid using many threads in this sort > of situation, and like to use something like unix select(). > I personally find using threads more natural and better impedance > match to the problem being solved here. I guess 'many people' above > > refers to those implementing thousands of connections and > who cannot live with the overhead and limited number of threads > available. > > 2) The EventMonitor basically polls for events at 50 msec interval? > > 3) There is a comment in the source code near the sleep(50) : > > // Sufficient up to 19200 baud > > > I'm sure you thought about this carefully, so again not > criticizing, but seeking to understand how or why, because > at 50 msec would seem to limit through in some cases. Like > if you send one byte and need to wait for one to return, > then this limits speed to 200 chars/sec? > > 4) I've done something similar to a few years back from > Java using JNI to access Win32 API serial port, and > I seem to recall that I had threading issues ie when > I submitted a read (ReadFile) and there was no data coming > in, the thread would not only block but also consume a > lot of CPU cycles ie it was not sleeping properly inside > the ReadFile call when the serial port blocked. > > Im a bit fuzzy about the details after five years, so my question is > have you checked if there an issue here? > > > 5) AFAIK the select() on Windows does not work serial ports > but there is some other mechanism (events?) to implement the > same functionality, did you consider that? Probably, so you > decided against it, why? > > > br Kusti > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Tue Mar 1 04:25:23 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:25:23 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C2E90.9010601@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > My question would be: Why would you do that? The rewrite does > most of the work for you - all you have to do is implement > two C++ virtual classes and two C++ functions. You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? I just took a short look, maybe it could be discussed further, but I don't think I like it much. BTW, the main interface defined there is called gnu.io.Dispatcher? I thought the package names should be used in a way to avoid clashes, e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name space authority :)). > In Windows that took me a few hours. where is the implementation? I found commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp with things like const bool SerialPortImpl::isDataAvailable() const { // Needs implementation return true; } and timeouts.ReadIntervalTimeout = MAXDWORD;* timeouts.ReadTotalTimeoutMultiplier = 0; timeouts.ReadTotalTimeoutConstant = 0; timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 0; if (!SetCommTimeouts(hComm, &timeouts)) throw IOException(); which seems to be oversimplified or some prototype only? I think (and I wrote about this already in the past years) that correct timeout handling is one of the challenges, so I think this should be prototyped first - for each system flavor - before cementation of the (JNI-) interfaces. Personally, I would vote to form it in a way allowing to be implemented on embedded devices, for example. Another big challenge is to prove a rewrite fully working (and probably compatible to the old implementation) on "all" the supported OSes. Not a big problem for linux and windows, just use some thousand lines test code, test drivers and serial loopbacks etc, but for the exotic platforms, probably a high number of, this probably won't be too easy... (there are more challenges, such as being comfortable and threadsafe [are read and write permitted at the same time?], detailed and helpful exceptions on user API level [not necessarily on JNI/JNA layer], how to have a configurable threadsafe logging/tracing [maybe also from native code to assist porting / testing on exotic OSes, such as OSes where the developers have no direct access too, which can be quite hard to usually leads to good log messages], just to name a few.). So even it might seem easy for one platform and I agree with Micheal that > > * yay! let's start a rewrite is unlikely to succeede soon... However, when considering this, before IMHO a powerful Java API has to be defined, because according to my experiences for implementing non-trivial protocols InputStream/OutputStream might not be comfortable/powerfull enough (eventually I consider both wrong) and have some InputStream derivation available as wrapper (so applications can use InputStream and whatever high-level-API they want). The JNI interface shall make such a powerful implementation possible, thus the interface of it is driving the JNI interface design and thus I think it had to be done first. All this surely requires much work: agreements on the APIs, safeness for the users, design, documentation, all the implementations and the testing. As long as such bug amount of work cannot be spent, for example if some employee would get half a year time paid for it or so :-), probably it is unlikely to progress on this. Otherwise, I'm afraid, patches, improvements, new design ideas and even rewrites wouldn't become complete and thus won't form a new rxtx version (3.0); thus either collect dust in some forgotten CVS branch or could generate a split... > I can't imagine other ports taking > much longer than that - especially since POSIX-based code can > be shared between ports. Things are more complex than they seem to be... I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select on serial ports isn't supported; maybe it is non-trivial to "map" (like mapping select() to WaitForMultipleObjects() which might have different semantics etc.) or maybe some different approach has to be used. A system may have POSIX like termios interfaces but not support timeouts or have any other interoperability bug... You never run out of things that can go wrong. And if something can go wrong, it will... :-) Or, as Michael wrote: > > I seriously don't believe anyone will come up with anything better anytime soon. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue Mar 1 04:39:37 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:39:37 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com><13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED6B@COSNPREXC3.usr.ingenico.loc> > 3. Write all of the native (or non-native) code to implement > the native interface. > > Is that correct? If yes, how is that easier than the simple > implementation the current rewrite design uses? To have it complete, reliable, traceable, maintainable and well tested, it is much more work, I'm afraid. A prototype can be done within a few days (maybe on one day), but getting it right (including a passed review) IMHO is a completely different story. In the end you may end up with an average of ten lines per day, when assuming four major native packs (common, win, mac, termios/select) with let's say just 5000 lines each (with logging messages and detailed exceptions this is not much) we would have to estimate a total effort of nine man-years (20000/10/220)... oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 04:40:18 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:40:18 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6CDB22.9070401@sandglass-software.com> Every journey begins with a single step. -Adrian On 3/1/2011 3:25 AM, Steffen DETTMER wrote: > * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> My question would be: Why would you do that? The rewrite does >> most of the work for you - all you have to do is implement >> two C++ virtual classes and two C++ functions. > You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? > I just took a short look, maybe it could be discussed further, > but I don't think I like it much. > BTW, the main interface defined there is called gnu.io.Dispatcher? > I thought the package names should be used in a way to avoid clashes, > e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name > space authority :)). > >> In Windows that took me a few hours. > where is the implementation? > I found > commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp > with things like > > const bool SerialPortImpl::isDataAvailable() const > { > // Needs implementation > return true; > } > > and > > timeouts.ReadIntervalTimeout = MAXDWORD;* > timeouts.ReadTotalTimeoutMultiplier = 0; > timeouts.ReadTotalTimeoutConstant = 0; > timeouts.WriteTotalTimeoutMultiplier = 0; > timeouts.WriteTotalTimeoutConstant = 0; > if (!SetCommTimeouts(hComm,&timeouts)) > throw IOException(); > > which seems to be oversimplified or some prototype only? > > I think (and I wrote about this already in the past years) that correct > timeout handling is one of the challenges, so I think this should be > prototyped first - for each system flavor - before cementation of the > (JNI-) interfaces. Personally, I would vote to form it in a way allowing > to be implemented on embedded devices, for example. > > Another big challenge is to prove a rewrite fully working (and probably > compatible to the old implementation) on "all" the supported OSes. Not a > big problem for linux and windows, just use some thousand lines test > code, test drivers and serial loopbacks etc, but for the exotic > platforms, probably a high number of, this probably won't be too easy... > (there are more challenges, such as being comfortable and threadsafe > [are read and write permitted at the same time?], detailed and helpful > exceptions on user API level [not necessarily on JNI/JNA layer], how to > have a configurable threadsafe logging/tracing [maybe also from native > code to assist porting / testing on exotic OSes, such as OSes where the > developers have no direct access too, which can be quite hard to usually > leads to good log messages], just to name a few.). > > So even it might seem easy for one platform and I agree with Micheal > that > >>> * yay! let's start a rewrite > is unlikely to succeede soon... > > However, when considering this, before IMHO a powerful Java API has to > be defined, because according to my experiences for implementing > non-trivial protocols InputStream/OutputStream might not be > comfortable/powerfull enough (eventually I consider both wrong) and have > some InputStream derivation available as wrapper (so applications can > use InputStream and whatever high-level-API they want). > The JNI interface shall make such a powerful implementation possible, > thus the interface of it is driving the JNI interface design and thus I > think it had to be done first. > > All this surely requires much work: agreements on the APIs, safeness for > the users, design, documentation, all the implementations and the > testing. As long as such bug amount of work cannot be spent, for example > if some employee would get half a year time paid for it or so :-), > probably it is unlikely to progress on this. > > Otherwise, I'm afraid, patches, improvements, new design ideas and even > rewrites wouldn't become complete and thus won't form a new rxtx version > (3.0); thus either collect dust in some forgotten CVS branch or could > generate a split... > >> I can't imagine other ports taking >> much longer than that - especially since POSIX-based code can >> be shared between ports. > Things are more complex than they seem to be... > > I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select > on serial ports isn't supported; maybe it is non-trivial to "map" (like > mapping select() to WaitForMultipleObjects() which might have different > semantics etc.) or maybe some different approach has to be used. A > system may have POSIX like termios interfaces but not support timeouts > or have any other interoperability bug... > You never run out of things that can go wrong. And if something can go > wrong, it will... :-) > > Or, as Michael wrote: > >>> I seriously don't believe anyone will come up with anything better > anytime soon. > > oki, > > Steffen > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Kustaa.Nyholm at planmeca.com Tue Mar 1 04:57:02 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 13:57:02 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: On 3/1/11 13:13, "Adrian Crum" wrote: >The javax.comm API specification requires one event monitor thread per >port. I don't like the idea of having a thread per port either, but one >of the rewrite's design goals is strict conformance to the specification. Ah, had not spotted that requirement. > >The 50 mS polling interval is just a placeholder. The final design of >that is yet to be decided. > >In Windows, you have two choices for I/O: overlapped and non-overlapped. >In overlapped I/O a thread is blocked, waiting for something to happen. >In non-overlapped I/O a thread does not block. I chose non-overlapped >I/O to avoid thread blocking at the OS level - instead, the thread >blocking is kept in Java. > >-Adrian thanks for the explanation. br Kusti From iqzw2r602 at sneakemail.com Tue Mar 1 05:08:17 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:08:17 +1100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <32684-1298981297-704398@sneakemail.com> This reminds me of a nasty problem I had with overlapped I/O on windows with jpathwatch. You can't start an I/O request in one thread and then do the check if that request completed in another thread. Very strange things happen when you attempt that; made me change the design of the Windows implementation quite drastically (one thread on a command queue that executes requests from other threads instead of letting them wildly call into GetOverlappedResult()). Out of curiosity: Did you come across that too? Or are all requests handled in the same thread they're issued? Cheers, Uwe On Tue, Mar 1, 2011 at 10:13 PM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > The javax.comm API specification requires one event monitor thread per > port. I don't like the idea of having a thread per port either, but one of > the rewrite's design goals is strict conformance to the specification. > > The 50 mS polling interval is just a placeholder. The final design of that > is yet to be decided. > > In Windows, you have two choices for I/O: overlapped and non-overlapped. In > overlapped I/O a thread is blocked, waiting for something to happen. In > non-overlapped I/O a thread does not block. I chose non-overlapped I/O to > avoid thread blocking at the OS level - instead, the thread blocking is kept > in Java. > > -Adrian > > > On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > >> Adrian, >> >> had a look at your code/rewrite and it looks rather clean/nice. >> >> I was looking at the code to gain insight (not related to the >> rewrite) into what is involved in serial port programming >> in Windows. Or rather, to refresh my memory and see how others have >> done, because I've been there done that. >> >> So my questions are just to satisfy my curiosity, not to criticize >> or suggest improvements. >> >> 1) It looks like a new thread (EventMonitor) is created for >> each Serial port, is that correct? >> >> Many people seem to try to avoid using many threads in this sort >> of situation, and like to use something like unix select(). >> I personally find using threads more natural and better impedance >> match to the problem being solved here. I guess 'many people' above >> >> refers to those implementing thousands of connections and >> who cannot live with the overhead and limited number of threads >> available. >> >> 2) The EventMonitor basically polls for events at 50 msec interval? >> >> 3) There is a comment in the source code near the sleep(50) : >> >> // Sufficient up to 19200 baud >> >> >> I'm sure you thought about this carefully, so again not >> criticizing, but seeking to understand how or why, because >> at 50 msec would seem to limit through in some cases. Like >> if you send one byte and need to wait for one to return, >> then this limits speed to 200 chars/sec? >> >> 4) I've done something similar to a few years back from >> Java using JNI to access Win32 API serial port, and >> I seem to recall that I had threading issues ie when >> I submitted a read (ReadFile) and there was no data coming >> in, the thread would not only block but also consume a >> lot of CPU cycles ie it was not sleeping properly inside >> the ReadFile call when the serial port blocked. >> >> Im a bit fuzzy about the details after five years, so my question is >> have you checked if there an issue here? >> >> >> 5) AFAIK the select() on Windows does not work serial ports >> but there is some other mechanism (events?) to implement the >> same functionality, did you consider that? Probably, so you >> decided against it, why? >> >> >> br Kusti >> >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 05:37:07 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:37:07 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <1142-1298983027-957144@sneakemail.com> On Tue, Mar 1, 2011 at 1:32 PM, Adrian Crum wrote: > Just to make sure I'm understanding you correctly, anyone porting RxTx to > a new platform would have to do the following: > > 1. Write their own Java implementation of an abstract Dispatcher class. > yep. I'd probably put all my calls to native OS wrappers in there two, looks the most straight-forward to me. > 2. Write a native (JNI or JNA) interface for the abstract class > implementation. > yes. For POSIX you'd probably only write one piece of code that provides implementations for open(), close(), and friends. You can compile that on all posix platforms (yeah, the devil is in the detail, but it's very little code, still). So this does open() (when using ***, but you can also use +++) // Unix.java class Unix{ public static native int open(String filename, int flags, int mode); .... } // Unix.cpp JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) { const char* pathname = env->GetStringUTFChars(jpathname, 0); if(pathname == 0) return -1; // java throws an out of memory error in this case int result = open(pathname, flags, mode); Unix_cacheErrno(); // handle interference between JVM and errno; env->ReleaseStringUTFChars(jpathname, pathname); return result; } .... 3. Write all of the native (or non-native) code to implement the native > interface. > Not sure what you mean by that. I've done the OS wrappers in step 2. step 1. implements that Dispatcher. What else do I need? > Is that correct? If yes, how is that easier than the simple implementation > the current rewrite design uses? > Yes, except for 3 (see above). How it is easier: I can debug the Java code directly. I can step from the read() call of an input stream directly into the guts of the RXTX implementation on my platform and see e.g. why it's hanging, because I see all the way up the call stack right where it calls Unix.read(). You can't easily do that with a fat native library, especially if you have no second set of devtools installed (the ones for native development). And I bet anyone knowing both languages can write it faster in Java, with less bugs. > On a side note: there is no requirement to write native code using C++. If > C++ is a real obstacle to adoption, then regular C could be used instead. In > that case, there would be a Dispatcher.c file that contains function > protoypes that need to be implemented. Dispatcher.c would still maintain the > same role as Dispatcher.cpp - which is to shield native code developers from > the details of JNI. Just build out the missing functions using C data types > and you're ready to go. > As I said, whatever works for you. Java works for me better than C++ in this case... Cheers, Uwe -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Mar 1 08:26:41 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 16:26:41 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> > The javax.comm API specification requires one event monitor > thread per port. Where does it require this? Do you mean "All the events received by this listener are generated by one dedicated thread that belongs to the SerialPort object. "? I think this is an implementation detail, isn't it? At least it is mentioned after "The current implementation only allows one listener per SerialPort". A bit bad that javadoc does not distinguish between API spec and implementation documentation. Also I don't think that TooManyListenersException MUST be thrown (I think it CAN be thrown). > I don't like the idea of having a thread per > port either, but one of the rewrite's design goals is strict > conformance to the specification. (but not necessarily on JNI layer) > The 50 mS polling interval is just a placeholder. The final > design of that is yet to be decided. I though no polling would be wanted; what could be the placeholder stand for? Do you mean a different interval duration or do you mean something completely different? > In Windows, you have two choices for I/O: overlapped and > non-overlapped. > In overlapped I/O a thread is blocked, waiting for something > to happen. > In non-overlapped I/O a thread does not block. I chose > non-overlapped I/O to avoid thread blocking at the OS level - > instead, the thread blocking is kept in Java. Isn't "overlapped" (asynchronous) I/O meaning that you invoke some ReadFile(..., &overlapped, ...) INSTEAD of performing a synchronous (blocking) function call blocking the thread? As far as I see, W32_Support.cpp uses CreateFile without FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O operations are serialized, even if the calls to the read and write functions specify an OVERLAPPED structure." [1] and "A synchronous handle behaves such that I/O function calls using that handle are blocked until they complete" [2] Given that CCOMTIMEOUTS get: "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the bytes that have already been received, even if no bytes have been received." [3] It looks likes this implementation relies on polling, which probably would waste much computing power. What did I miss? oki, Steffen [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro nous_and_asynchronous_i_o_handles [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 09:23:47 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:23:47 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6D1D93.6090306@sandglass-software.com> Unfortunately, the javax.comm API specification includes a lot of implementation details. That is one of the weaknesses of the specification in my opinion. The bottom line is, anyone wanting to use RxTx as a javax.comm implementation is going to expect it to do the things the specification says it does. -Adrian On 3/1/2011 7:26 AM, Steffen DETTMER wrote: >> The javax.comm API specification requires one event monitor >> thread per port. > Where does it require this? > > Do you mean "All the events received by this listener are generated > by one dedicated thread that belongs to the SerialPort object. "? > > I think this is an implementation detail, isn't it? At least it is > mentioned after "The current implementation only allows one listener per > SerialPort". A bit bad that javadoc does not distinguish between API > spec and implementation documentation. Also I don't think that > TooManyListenersException MUST be thrown (I think it CAN be thrown). > >> I don't like the idea of having a thread per >> port either, but one of the rewrite's design goals is strict >> conformance to the specification. > (but not necessarily on JNI layer) > >> The 50 mS polling interval is just a placeholder. The final >> design of that is yet to be decided. > I though no polling would be wanted; what could be the placeholder stand > for? Do you mean a different interval duration or do you mean something > completely different? > >> In Windows, you have two choices for I/O: overlapped and >> non-overlapped. >> In overlapped I/O a thread is blocked, waiting for something >> to happen. >> In non-overlapped I/O a thread does not block. I chose >> non-overlapped I/O to avoid thread blocking at the OS level - >> instead, the thread blocking is kept in Java. > Isn't "overlapped" (asynchronous) I/O meaning that you invoke some > ReadFile(...,&overlapped, ...) > INSTEAD of performing a synchronous (blocking) function call blocking > the thread? > > As far as I see, W32_Support.cpp uses CreateFile without > FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O > operations are serialized, even if the calls to the read and write > functions specify an OVERLAPPED structure." [1] and "A synchronous > handle behaves such that I/O function calls using that handle are > blocked until they complete" [2] > > Given that CCOMTIMEOUTS get: > "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values > for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier > members, specifies that the read operation is to return immediately with > the bytes that have already been received, even if no bytes have been > received." [3] > > It looks likes this implementation relies on polling, which probably > would waste much computing power. > > What did I miss? > > oki, > > Steffen > > [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx > [2] > http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro > nous_and_asynchronous_i_o_handles > [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at sandglass-software.com Tue Mar 1 09:55:29 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:55:29 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <1142-1298983027-957144@sneakemail.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> Message-ID: <4D6D2501.1020803@sandglass-software.com> That code duplicates what is in Dispatcher.cpp. A Unix port would only need to implement CommPortFactory::getInstance(portName, portType). -Adrian On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 15:07:46 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 2 Mar 2011 09:07:46 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6D2501.1020803@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> <4D6D2501.1020803@sandglass-software.com> Message-ID: <23749-1299017266-991798@sneakemail.com> What is this duplicating? A Unix port will need to call open() anyways (just so we're talking about the same thing here: open() is the Unix equivalent of CreateFile()) On Wed, Mar 2, 2011 at 3:55 AM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > That code duplicates what is in Dispatcher.cpp. A Unix port would only > need to implement CommPortFactory::getInstance(portName, portType). > > -Adrian > > > On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Tue Mar 1 22:53:07 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 00:53:07 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: Hi, I haven't seen any response to my question below. Is this not the right place to ask? If not, where would be a better place to ask? Any suggestions? Thanks, Ryan On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >> Hi, >> >> I have a receive thread that does nothing but call read() on the serial >> port input stream. It works fine for a while but after running for a long >> time it eventually returns -1 which means EOF. This is my first problem, as >> the device I'm talking to runs forever, I don't know why it would return -1. >> I am calling disableReceiveThreshold() and disableReceiveTimeout() at >> initialization which according to the documentation means read will return >> as soon as any data is available and it will block forever when data is not >> available, so -1 should never be returned from read, right? >> >> I have been unable to figure out why read returns -1 after a long while >> but I have found that if I kill my application and restart it everything >> works fine again. Therefore I tried to work around the problem by having my >> code close the port and reopen it when read returns -1. My second problem is >> that in this case when I call close() on the port it blocks forever. I did >> find this old bug >> >> http://bugzilla.qbang.org/show_bug.cgi?id=53 >> >> which describes close() hanging on OSX, but it says that bug was fixed >> with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have >> any idea why read might be returning -1 in the first place? If I can avoid >> that I don't care about close() hanging because I would never close the >> port. If not, does anyone know why close() might block forever and how I can >> prevent this? I'm using RXTX version 2.1-7. >> >> Thanks, >> -- >> Ryan >> >> > > > -- > Ryan Boder > 1 614 598-6339 > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Mar 2 01:34:48 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 2 Mar 2011 10:34:48 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/2/11 07:53, "Ryan Boder" wrote: Can you / have you made a simple test to ensure that rxtx is the issue? Can you write a simple C-program to see if this exhibits the same problem? I've never encountered this sort of problem with rxtx, it mostly just works. But I'm on Mac so can't say about Windows (7) br Kusti >Hi, > >I haven't seen any response to my question below. Is this not the right >place to ask? If not, where would be a better place to ask? Any >suggestions? > >Thanks, >Ryan > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > >I mis-spoke, I don't have my own thread calling read, I am calling >read in the event handler after receiving a >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be >accurate though. > >Ryan > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >Hi, > >I have a receive thread that does nothing but call read() on the serial >port input stream. It works fine for a while but after running for a long >time it eventually returns -1 which means EOF. This is my first problem, >as the device I'm talking to runs forever, I don't know why it would >return -1. I am calling disableReceiveThreshold() and >disableReceiveTimeout() at initialization which according to the >documentation means read will return as soon as any data is available and >it will block forever when data is not available, so -1 should never be >returned from read, right? > >I have been unable to figure out why read returns -1 after a long while >but I have found that if I kill my application and restart it everything >works fine again. Therefore I tried to work around the problem by having >my code close the port and reopen it when read returns -1. My second >problem is that in this case when I call close() on the port it blocks >forever. I did find this old bug > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > >which describes close() hanging on OSX, but it says that bug was fixed >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone >have any idea why read might be returning -1 in the first place? If I can >avoid that I don't care about close() hanging because I would never close >the port. If not, does anyone know why close() might block forever and >how I can prevent this? I'm using RXTX version 2.1-7. > >Thanks, >-- >Ryan > > > > > > > > > >-- >Ryan Boder >1 614 598-6339 > > > > > > >-- >Ryan Boder >1 614 598-6339 > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From Steffen.DETTMER at ingenico.com Wed Mar 2 03:08:57 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:08:57 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <32684-1298981297-704398@sneakemail.com> References: <4D6CD4DE.7040501@sandglass-software.com> <32684-1298981297-704398@sneakemail.com> Message-ID: <20110302100857.GB8030@elberon.bln.de.ingenico.com> * iqzw2r602 at sneakemail.com wrote on Tue, Mar 01, 2011 at 23:08 +1100: > This reminds me of a nasty problem I had with overlapped I/O on windows Yeah, those thousands of complex, difficult to use and exception-containing WinAPI is really hard to use... About strange effects on overlapped&multithreading, MSDN has: `the calling thread uses the GetOverlappedResult function or one of the wait functions' [1] also also mentiones I/O Completion Ports [2], and later continues: `If an application reuses OVERLAPPED structures on multiple threads and calls GetOverlappedResult with the bWait parameter set to TRUE, the application must ensure that the associated event is set before the application reuses the structure. This can be accomplished by using the WaitForSingleObject function after calling GetOverlappedResult to force the thread to wait until the operation completes. Note that the event object must be a manual-reset event object. If an autoreset event object is used, calling GetOverlappedResult with the bWait parameter set to TRUE causes the function to be blocked indefinitely.' also [1] oki, Steffen [1] http://msdn.microsoft.com/en-us/library/ms686358%28v=vs.85%29.aspx [2] http://msdn.microsoft.com/en-us/library/aa365198%28v=vs.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:15:11 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:15:11 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6D1D93.6090306@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> <4D6D1D93.6090306@sandglass-software.com> Message-ID: <20110302101511.GC8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 08:23 -0800: > Unfortunately, the javax.comm API specification includes a lot of > implementation details. That is one of the weaknesses of the > specification in my opinion. The bottom line is, anyone wanting to use > RxTx as a javax.comm implementation is going to expect it to do the > things the specification says it does. Yeah ok, but even then the implementation could check for the TooManyListenersException situations (if it really is required to support applications relying on that exception) but internally use just a single I/O thread waiting for events on any open file descriptors. Of course an implementation supporting all sort of concurrency could become quite complex (especially if open-read-close should work fast, I think would be difficult to implement, because a new file descriptors had to be added to the waitFor/select list, and who knows how systems behave here in detail...). oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:25:15 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:25:15 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6CDB22.9070401@sandglass-software.com> References: <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> <4D6CDB22.9070401@sandglass-software.com> Message-ID: <20110302102515.GD8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 03:40 -0800: > * from some older mail: > > My question would be: Why would you do that? The rewrite does > > most of the work for you - all you have to do is implement > > two C++ virtual classes and two C++ functions. > > > > In Windows that took me a few hours. > > Every journey begins with a single step. Yes, of course, but then it shouldn't be used as base for new effort estimations like `In Windows that took a few hours' ;-) (BTW, calling a single step `the rewrite' may sound a bit ambitious ;)) But of course a prototype demonstrating something can be really helpful, sure. I just wanted to tell that interfaces should be easy to use and powerful at the same time and may non-trivial initial considerations before starting to implement them. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From ryan.boder at gmail.com Wed Mar 2 18:44:35 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:44:35 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: While running the tests you requested I may have stumbled on the problem, I just don't know how to fix it. According to the documentation, if both the receive timeout and receive threshold are disabled then read() should block forever until data is available. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#getInputStream%28%29 On my system using RXTX read() is returning -1 when no data is available even though I have disabled both thresholds. The reason my program was running fine for a while without this problem showing up is that I was using the DATA_AVAILABLE event to be notified when data is available and only calling read() to read an entire frame whenever the DATA_AVAILABLE event occurred, until eventually my device (I'm guessing) probably took longer than normal to send the entire data frame and therefore I called read when no data was available and it returned -1. The following Java program demonstrates my problem, it returns -1 as soon as no data is available, even though I think it should block until data is available. import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; public class Main implements SerialPortEventListener { public static void main(String[] args) throws Exception { new Main().run(); } private void run() throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier("COM4"); SerialPort port = (SerialPort) portIdentifier.open(Main.class.getName(), 2000); port.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); port.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); port.disableReceiveThreshold(); port.disableReceiveTimeout(); BufferedInputStream in = new BufferedInputStream(port.getInputStream()); BufferedOutputStream out = new BufferedOutputStream(port.getOutputStream()); port.addEventListener(this); Thread.sleep(1000); out.write(new byte[] {0x02, 0x60}); out.flush(); while (true) { int x = in.read(); if (x == -1) { System.out.println("EOF"); Thread.sleep(1000000000); } String s = Integer.toHexString(x & 0xFF); if (s.length() == 1) s = "0" + s; System.out.print(s + " "); System.out.flush(); } } public void serialEvent(SerialPortEvent arg0) { System.out.println("Serial port event"); } } However, the follow C# program ran all day today without ever read ever returning -1, as I would expect. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.IO.Ports; using System.Threading; namespace RXTXReadTest1 { class Program { static void Main(string[] args) { new Program().run(); } private void run() { SerialPort port = new SerialPort("COM4", 19200, Parity.None, 8, StopBits.One); port.Open(); port.Write(new byte[] { 0x02, 0x60 }, 0, 2); while (true) { int x = port.ReadByte(); if (x == -1) { Console.WriteLine("EOF"); Thread.Sleep(1000000000); } String s = x.ToString("X"); if (s.Length == 1 ) s = "0" + s; Console.Out.Write(s + " "); Console.Out.Flush(); } } } } Now I am experimenting with what happens if I set the receive timeout to it's maximum value (apparently 1600ms) and only call read() when I am expecting data. Hopefully it will never be more than 1600ms late. This is still only a work around, not solving the problem. Am I doing something wrong in my code above or is RXTX retuning -1 when it should be blocking? Thanks, Ryan On Wed, Mar 2, 2011 at 3:34 AM, Kustaa Nyholm wrote: > On 3/2/11 07:53, "Ryan Boder" wrote: > Can you / have you made a simple test to ensure that rxtx is the issue? > > Can you write a simple C-program to see if this exhibits the same problem? > > I've never encountered this sort of problem with rxtx, it mostly just > works. > > But I'm on Mac so can't say about Windows (7) > > br Kusti > > > > > >Hi, > > > >I haven't seen any response to my question below. Is this not the right > >place to ask? If not, where would be a better place to ask? Any > >suggestions? > > > >Thanks, > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder > wrote: > > > >I mis-spoke, I don't have my own thread calling read, I am calling > >read in the event handler after receiving a > >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be > >accurate though. > > > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder > wrote: > > > >Hi, > > > >I have a receive thread that does nothing but call read() on the serial > >port input stream. It works fine for a while but after running for a long > >time it eventually returns -1 which means EOF. This is my first problem, > >as the device I'm talking to runs forever, I don't know why it would > >return -1. I am calling disableReceiveThreshold() and > >disableReceiveTimeout() at initialization which according to the > >documentation means read will return as soon as any data is available and > >it will block forever when data is not available, so -1 should never be > >returned from read, right? > > > >I have been unable to figure out why read returns -1 after a long while > >but I have found that if I kill my application and restart it everything > >works fine again. Therefore I tried to work around the problem by having > >my code close the port and reopen it when read returns -1. My second > >problem is that in this case when I call close() on the port it blocks > >forever. I did find this old bug > > > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > > > >which describes close() hanging on OSX, but it says that bug was fixed > >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone > >have any idea why read might be returning -1 in the first place? If I can > >avoid that I don't care about close() hanging because I would never close > >the port. If not, does anyone know why close() might block forever and > >how I can prevent this? I'm using RXTX version 2.1-7. > > > >Thanks, > >-- > >Ryan > > > > > > > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Wed Mar 2 18:46:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:46:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: <-1051064942000733580@unknownmsgid> References: <-1051064942000733580@unknownmsgid> Message-ID: It is USB and seems very reliable with the C# test program in my previous email. On Wed, Mar 2, 2011 at 6:58 PM, Bruce Griffith wrote: > How reliable is your serial port ? is it USB or Bluetooth? > > > > Bruce Griffith > > 303-532-4778 > > > > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On Behalf > Of *Ryan Boder > *Sent:* Tuesday, 01 March 2011 10:53 PM > *To:* rxtx at qbang.org > *Subject:* Re: [Rxtx] RXTX serial port read() returns -1 unexpectedly and > then blocks forever on close() > > > > Hi, > > I haven't seen any response to my question below. Is this not the right > place to ask? If not, where would be a better place to ask? Any suggestions? > > Thanks, > Ryan > > On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > > Hi, > > I have a receive thread that does nothing but call read() on the serial > port input stream. It works fine for a while but after running for a long > time it eventually returns -1 which means EOF. This is my first problem, as > the device I'm talking to runs forever, I don't know why it would return -1. > I am calling disableReceiveThreshold() and disableReceiveTimeout() at > initialization which according to the documentation means read will return > as soon as any data is available and it will block forever when data is not > available, so -1 should never be returned from read, right? > > I have been unable to figure out why read returns -1 after a long while but > I have found that if I kill my application and restart it everything works > fine again. Therefore I tried to work around the problem by having my code > close the port and reopen it when read returns -1. My second problem is that > in this case when I call close() on the port it blocks forever. I did find > this old bug > > http://bugzilla.qbang.org/show_bug.cgi?id=53 > > which describes close() hanging on OSX, but it says that bug was fixed with > a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have any > idea why read might be returning -1 in the first place? If I can avoid that > I don't care about close() hanging because I would never close the port. If > not, does anyone know why close() might block forever and how I can prevent > this? I'm using RXTX version 2.1-7. > > Thanks, > -- > Ryan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Mar 3 02:50:20 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 3 Mar 2011 09:50:20 +0000 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: So if -1 is unexpectedly returned from read, and we have demonstrated that your USB-serial adapter can actually causes this to happen in RXTX, why not just ignore the -1 value? What happens when you try this? As for a hang on close, are your closing your port from within your serial event handler? I know that this can cause some serious problems. Regards, Michael Erskine. From Kustaa.Nyholm at planmeca.com Thu Mar 3 03:39:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 12:39:34 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 03:44, "Ryan Boder" wrote: >While running the tests you requested I may have stumbled on the problem, >I just don't know how to fix it. According to the documentation, if both >the receive timeout and receive threshold are disabled then read() should >block forever until data is available. > >http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/re >ference/api/javax/comm/CommPort.html#getInputStream%28%29 > >On my system using RXTX read() is returning -1 when no data is available >even though I have disabled both thresholds. The reason my program was >running fine for a while without this problem showing up is that I was >using the DATA_AVAILABLE event to be notified when data is available and >only calling read() to read an entire frame whenever the DATA_AVAILABLE >event occurred, until eventually my device (I'm guessing) probably took >longer than normal to send the entire data frame and therefore I called >read when no data was available and it returned -1. As a workaround have you tried to perform another read() if it returns -1? The javadoc says (see getInputStream): "Note, however, that framing errors may cause the Timeout and Threshold values to complete prematurely without raising an exception." I read this as a hint that read might return even if no data is available. Because of the above and that read() can only return -1 or the byte received it would be somewhat logical to return -1 in case of framing error ? I'm not claiming that my interpretation of the specification, such as it is, is correct, just speculating that the behavior could be something like that. It might give you some more insight if you used the read(bytes[],int,int) method, because this can and will return 0 in case of timeout (and presumably might do so in case of framing error, maybe some other error condition too). That might allow you to handle or work around the problem in this case. You have not shown your complete code (no need) but your comments and the example makes me wonder if the code is otherwise as it should be, meaning are you assuming that when you get the DATA_AVAILABLE event all of your frame has arrived and that you can just blindly read it away from the input stream? That is not guaranteed of course. Also using read(), instead of read(bytes[],int,int), is not very efficient and might be masking other problems as mused above. BTE you can print a byte in hex with leading zeros more easily with: System.out.printf("%02X",x); br Kusti From ryan.boder at gmail.com Thu Mar 3 07:56:16 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:56:16 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 5:39 AM, Kustaa Nyholm wrote: > > As a workaround have you tried to perform another read() if it returns -1? > I tried that and it did work sometimes but not all the time. > > The javadoc says (see getInputStream): > > "Note, however, that framing errors may cause the Timeout and Threshold > values to complete prematurely without raising an exception." > > I read this as a hint that read might return even if no data is available. > > Because of the above and that read() can only return -1 or the byte > received > it would be somewhat logical to return -1 in case of framing error ? > > I'm not claiming that my interpretation of the specification, such as it > is, > is correct, just speculating that the behavior could be something like > that. > Receive framing is not enabled by default. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#enableReceiveFraming%28int%29 My choice of word might be misleading, when I said frame I just meant a contiguous message from the device. I am not enabling receive framing. Can you have a framing error when receive framing is disabled? > > It might give you some more insight if you used the read(bytes[],int,int) > method, because > this can and will return 0 in case of timeout (and presumably might do so > in case of framing > error, maybe some other error condition too). > > That might allow you to handle or work around the problem in this case. > > You have not shown your complete code (no need) but your comments and the > example > makes me wonder if the code is otherwise as it should be, meaning are you > assuming > that when you get the DATA_AVAILABLE event all of your frame has arrived > and that > you can just blindly read it away from the input stream? That is not > guaranteed of course. > I'm not assuming the entire message has arrived, I'm just assuming it either has arrived or will arrive soon which is why I'm using a (supposedly) blocking read(). > > Also using read(), instead of read(bytes[],int,int), is not very efficient > and > might be masking other problems as mused above. > True, I'm reading one byte at a time because I don't know how long the message will be until I read and parse some of it. I suppose I can use read(bytes[],int,int) once I figure out how long the message will be. > > BTE you can print a byte in hex with leading zeros more easily with: > > > System.out.printf("%02X",x); > I did it the dumb way in that test program so I could copy and paste the code from C# to Java without having to figure out how to do the same in C# which I'm not as familiar with. Thanks and BR, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 07:58:24 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:58:24 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: Yes I was doing the close in the serial event handler, I didn't realize that caused a problem. Thanks, I'll fix it. On Thu, Mar 3, 2011 at 4:50 AM, Michael Erskine wrote: > So if -1 is unexpectedly returned from read, and we have demonstrated > that your USB-serial adapter can actually causes this to happen in > RXTX, why not just ignore the -1 value? What happens when you try > this? As for a hang on close, are your closing your port from within > your serial event handler? I know that this can cause some serious > problems. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 11:48:20 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 13:48:20 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm wrote: > On 3/3/11 16:56, "Ryan Boder" wrote: > > > >I'm not assuming the entire message has arrived, I'm just assuming it > >either has arrived or will arrive soon which is why I'm using a > >(supposedly) blocking read(). > > > I've been giving this some further thought. > > It does not feel healthy to block without timeout, especially > from within a thread that is essentially internal to the rxtx. > > I've never done that, I always use a time out, read(byte[],int,int) > for the expected number of bytes, check how much I got and issue > more reads until I get everything. > > You have not described how your communication works so I'm only > speculating. > > If your device needs some response to send more bytes (from your > code it looks like this is not the case) then a missing byte > would block your read and prevent you from responding and > getting more data. But as said, looks like that is not the case. > > Anyway, if this was my problem, I would enable the timeout > and use read(byte[],int,int) and loop until I get what I need. > You are right, I should and will use a timeout. In fact, my program has been running flawlessly for 12 hours and the only change I made was to enable a timeout, no change in the logic at all. Without the timeout read() was returning -1 usually after it ran for an hour or two. I will change the code to make use of the timeout and handle it appropriately. It still seems to me that RXTX's behavior doesn't match the documentation when rx timeout and rx threshold are disabled read() should block until data is available instead of immediately returning -1. I don't believe that a framing error is occurring immediately every time data is not available causing read() to return -1. Especially since the C# test program above runs all day with no error and the Java program above runs all day with no error when a timeout is enabled. To me it seems like enabling the timeout is what is causing read() to block until data is available, even if only for 1600ms, and without the timeout read() is returning -1 immediately when it should be blocking. Thanks for all the help and best regards, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Thu Mar 3 13:02:30 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 22:02:30 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 20:48, "Ryan Boder" wrote: >On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm > wrote: > >On 3/3/11 16:56, "Ryan Boder" wrote: >> > >>I'm not assuming the entire message has arrived, I'm just assuming it >>either has arrived or will arrive soon which is why I'm using a >>(supposedly) blocking read(). > > > >I've been giving this some further thought. > >It does not feel healthy to block without timeout, especially >from within a thread that is essentially internal to the rxtx. > >I've never done that, I always use a time out, read(byte[],int,int) >for the expected number of bytes, check how much I got and issue >more reads until I get everything. > >You have not described how your communication works so I'm only >speculating. > >If your device needs some response to send more bytes (from your >code it looks like this is not the case) then a missing byte >would block your read and prevent you from responding and >getting more data. But as said, looks like that is not the case. > >Anyway, if this was my problem, I would enable the timeout >and use read(byte[],int,int) and loop until I get what I need. > > > > >You are right, I should and will use a timeout. In fact, my program has >been running flawlessly for 12 hours and the only change I made was to >enable a timeout, no change in the logic at all. Without the timeout >read() was returning -1 usually after it ran for an hour or two. I will >change the code to make use of the timeout and handle it appropriately. That's nice! > >It still seems to me that RXTX's behavior doesn't match the documentation >when rx timeout and rx threshold are disabled read() should block until >data is available instead of immediately returning -1. Yeah, it does look like bug. However this might be related to some Windows specific serial port issue. Years ago I had issues with JavaComm (not RxTx) where I did a blocking read and I had huge issues with my program consuming all resources. I curser the Sun and JavaComm and re-code my own SerialPort using JNI to access the Win32 API directly. And I run into the same problems as with the Sun's implementation! So I ditched my code, changed my code to use timeouts and problems disappeared. > I don't believe that a framing error is occurring immediately every time >data is not available causing read() to return -1. Especially since the >C# test program above runs all day with no error and the Java program >above runs all day with no error when a timeout is enabled. I think so too, all things considered I don't really believe in framing errors in this case. > To me it seems like enabling the timeout is what is causing read() to >block until data is available, even if only for 1600ms, and without the >timeout read() is returning -1 immediately when it should be blocking. Yeah, I had a peek at the innards of RxTx Windows serial port a week or so ago and also read MSDN documentation about serial ports and the way overlapped and non-overlapped (non blocking and blocking) IO is handled is a way different. So yeah, it can well be that there is an issue lurking there somewhere inside RxTx in Windows. > > >Thanks for all the help and best regards, >-- >Ryan Boder I'm happy if I was of any assistance. br Kusti From tjarvi at qbang.org Thu Mar 3 18:52:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Mar 2011 18:52:50 -0700 (MST) Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: >> Without the timeout >> read() was returning -1 usually after it ran for an hour or two. There is a big hammer in rxtx causing that behavior. >> It still seems to me that RXTX's behavior doesn't match the documentation >> when rx timeout and rx threshold are disabled read() should block until >> data is available instead of immediately returning -1. > > Yeah, it does look like bug. However this might be related to some > Windows specific serial port issue. Years ago I had issues with > JavaComm (not RxTx) where I did a blocking read and I had huge > issues with my program consuming all resources. I curser the Sun > and JavaComm and re-code my own SerialPort using JNI to access > the Win32 API directly. And I run into the same problems as > with the Sun's implementation! So I ditched my code, changed > my code to use timeouts and problems disappeared. > > >> To me it seems like enabling the timeout is what is causing read() to >> block until data is available, even if only for 1600ms, and without the >> timeout read() is returning -1 immediately when it should be blocking. > > Yeah, I had a peek at the innards of RxTx Windows serial port a week > or so ago and also read MSDN documentation about serial ports and > the way overlapped and non-overlapped (non blocking and blocking) > IO is handled is a way different. So yeah, it can well be that > there is an issue lurking there somewhere inside RxTx in Windows. > > Yes. RXTX was patched to behave the way it does. I don't fully understand the issue behind the patch. Marc noticed the odd behavior as well and offered a fix which was greeted with resistance. The windows implementation was done without real documentatino of the windows API. I think I had an example from the late 80's early 90's on Microsoft's site and some API documentation that was obviously not microsofts in Europe. Wayne Roberts had a real need for windows support and fixed some major issues it had. My interest at the time was mingw32. I then cleaned it up for some specific uses I had later. The read returning -1 when it should block didn't impact anybody and appeared to help some people. It isnt the documented behavior though. There could be all sorts of latent bugs in that code but in the real world, it gets by in almost all use cases. Its a hack but it worked for 100's of thousands of people over a 14 year period. Maybe its time to revisit the code but there is more risk than gain for most people. How do you move forward and avoid the risk? Some have expressed interests in coding C++ or other efforts. I'm all for such efforts but feel some unit tests that work with a null modem cables are the only thing that will move rxtx (and perhaps CommAPI) forward. If we have a test suite in place as a qualification for implementations, progress can be made in the right direction regardless of the implementation details. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Fri Mar 4 02:57:16 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 4 Mar 2011 11:57:16 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/4/11 03:52, "Trent Jarvi" wrote: >Yes. RXTX was patched to behave the way it does. I don't fully >understand the issue behind the patch. Marc noticed the odd behavior as >well and offered a fix which was greeted with resistance. > >The windows implementation was done without real documentatino of the >windows API. I think I had an example from the late 80's early 90's on >Microsoft's site and some API documentation that was obviously not >microsofts in Europe. Wayne Roberts had a real need for windows support >and fixed some major issues it had. My interest at the time was mingw32. >I then cleaned it up for some specific uses I had later. The read >returning -1 when it should block didn't impact anybody and appeared to >help some people. It isnt the documented behavior though. > >There could be all sorts of latent bugs in that code but in the real >world, it gets by in almost all use cases. I think so too, never had any problems with it. > Its a hack but it worked for 100's of thousands of people over a 14 year >period. Yeah! Thanks for everyone who has contributed over the years, job well done! >Maybe its time to >revisit the code but there is more risk than gain for most people. How >do >you move forward and avoid the risk? My view is that it is quite risky and rather pointless to move forward, other than fixing bugs that really affect people. At the moment the major issue IMO is just that it seems (not been following this too carefully, so maybe I'm wrong, so in case this FUD, my apologies) that 'official' binaries are not available. I think the rewrite, tempting as it is in some respects is not the way forward. Just gentle maintenance to iron out real issues and then get the binaries out. br Kusti From ryan.boder at gmail.com Fri Mar 4 07:24:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Fri, 4 Mar 2011 09:24:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 8:52 PM, Trent Jarvi wrote: > > The windows implementation was done without real documentatino of the > windows API. I think I had an example from the late 80's early 90's on > Microsoft's site and some API documentation that was obviously not > microsofts in Europe. Wayne Roberts had a real need for windows support and > fixed some major issues it had. My interest at the time was mingw32. I then > cleaned it up for some specific uses I had later. The read returning -1 > when it should block didn't impact anybody and appeared to help some people. > It isnt the documented behavior though. > > There could be all sorts of latent bugs in that code but in the real world, > it gets by in almost all use cases. Its a hack but it worked for 100's of > thousands of people over a 14 year period. Maybe its time to revisit the > code but there is more risk than gain for most people. How do you move > forward and avoid the risk? > The safest and easiest solution would be to add a javadoc comment to disableReceiveTimeout explaining the difference between the RXTX behavior and Sunacle's documented behavior so that when someone uses the method in an IDE like Eclipse a little box would pop up informing them. Generating javadoc HTML and hosting it on the RXTX website would go a long way too, when something behaves differently than I expect the first thing I do is look for the javadoc online. -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Mar 1 00:54:17 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 09:54:17 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> Message-ID: Adrian, had a look at your code/rewrite and it looks rather clean/nice. I was looking at the code to gain insight (not related to the rewrite) into what is involved in serial port programming in Windows. Or rather, to refresh my memory and see how others have done, because I've been there done that. So my questions are just to satisfy my curiosity, not to criticize or suggest improvements. 1) It looks like a new thread (EventMonitor) is created for each Serial port, is that correct? Many people seem to try to avoid using many threads in this sort of situation, and like to use something like unix select(). I personally find using threads more natural and better impedance match to the problem being solved here. I guess 'many people' above refers to those implementing thousands of connections and who cannot live with the overhead and limited number of threads available. 2) The EventMonitor basically polls for events at 50 msec interval? 3) There is a comment in the source code near the sleep(50) : // Sufficient up to 19200 baud I'm sure you thought about this carefully, so again not criticizing, but seeking to understand how or why, because at 50 msec would seem to limit through in some cases. Like if you send one byte and need to wait for one to return, then this limits speed to 200 chars/sec? 4) I've done something similar to a few years back from Java using JNI to access Win32 API serial port, and I seem to recall that I had threading issues ie when I submitted a read (ReadFile) and there was no data coming in, the thread would not only block but also consume a lot of CPU cycles ie it was not sleeping properly inside the ReadFile call when the serial port blocked. Im a bit fuzzy about the details after five years, so my question is have you checked if there an issue here? 5) AFAIK the select() on Windows does not work serial ports but there is some other mechanism (events?) to implement the same functionality, did you consider that? Probably, so you decided against it, why? br Kusti From adrian.crum at sandglass-software.com Tue Mar 1 04:13:34 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:13:34 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: References: Message-ID: <4D6CD4DE.7040501@sandglass-software.com> The javax.comm API specification requires one event monitor thread per port. I don't like the idea of having a thread per port either, but one of the rewrite's design goals is strict conformance to the specification. The 50 mS polling interval is just a placeholder. The final design of that is yet to be decided. In Windows, you have two choices for I/O: overlapped and non-overlapped. In overlapped I/O a thread is blocked, waiting for something to happen. In non-overlapped I/O a thread does not block. I chose non-overlapped I/O to avoid thread blocking at the OS level - instead, the thread blocking is kept in Java. -Adrian On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > Adrian, > > had a look at your code/rewrite and it looks rather clean/nice. > > I was looking at the code to gain insight (not related to the > rewrite) into what is involved in serial port programming > in Windows. Or rather, to refresh my memory and see how others have > done, because I've been there done that. > > So my questions are just to satisfy my curiosity, not to criticize > or suggest improvements. > > 1) It looks like a new thread (EventMonitor) is created for > each Serial port, is that correct? > > Many people seem to try to avoid using many threads in this sort > of situation, and like to use something like unix select(). > I personally find using threads more natural and better impedance > match to the problem being solved here. I guess 'many people' above > > refers to those implementing thousands of connections and > who cannot live with the overhead and limited number of threads > available. > > 2) The EventMonitor basically polls for events at 50 msec interval? > > 3) There is a comment in the source code near the sleep(50) : > > // Sufficient up to 19200 baud > > > I'm sure you thought about this carefully, so again not > criticizing, but seeking to understand how or why, because > at 50 msec would seem to limit through in some cases. Like > if you send one byte and need to wait for one to return, > then this limits speed to 200 chars/sec? > > 4) I've done something similar to a few years back from > Java using JNI to access Win32 API serial port, and > I seem to recall that I had threading issues ie when > I submitted a read (ReadFile) and there was no data coming > in, the thread would not only block but also consume a > lot of CPU cycles ie it was not sleeping properly inside > the ReadFile call when the serial port blocked. > > Im a bit fuzzy about the details after five years, so my question is > have you checked if there an issue here? > > > 5) AFAIK the select() on Windows does not work serial ports > but there is some other mechanism (events?) to implement the > same functionality, did you consider that? Probably, so you > decided against it, why? > > > br Kusti > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Tue Mar 1 04:25:23 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:25:23 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C2E90.9010601@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > My question would be: Why would you do that? The rewrite does > most of the work for you - all you have to do is implement > two C++ virtual classes and two C++ functions. You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? I just took a short look, maybe it could be discussed further, but I don't think I like it much. BTW, the main interface defined there is called gnu.io.Dispatcher? I thought the package names should be used in a way to avoid clashes, e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name space authority :)). > In Windows that took me a few hours. where is the implementation? I found commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp with things like const bool SerialPortImpl::isDataAvailable() const { // Needs implementation return true; } and timeouts.ReadIntervalTimeout = MAXDWORD;* timeouts.ReadTotalTimeoutMultiplier = 0; timeouts.ReadTotalTimeoutConstant = 0; timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 0; if (!SetCommTimeouts(hComm, &timeouts)) throw IOException(); which seems to be oversimplified or some prototype only? I think (and I wrote about this already in the past years) that correct timeout handling is one of the challenges, so I think this should be prototyped first - for each system flavor - before cementation of the (JNI-) interfaces. Personally, I would vote to form it in a way allowing to be implemented on embedded devices, for example. Another big challenge is to prove a rewrite fully working (and probably compatible to the old implementation) on "all" the supported OSes. Not a big problem for linux and windows, just use some thousand lines test code, test drivers and serial loopbacks etc, but for the exotic platforms, probably a high number of, this probably won't be too easy... (there are more challenges, such as being comfortable and threadsafe [are read and write permitted at the same time?], detailed and helpful exceptions on user API level [not necessarily on JNI/JNA layer], how to have a configurable threadsafe logging/tracing [maybe also from native code to assist porting / testing on exotic OSes, such as OSes where the developers have no direct access too, which can be quite hard to usually leads to good log messages], just to name a few.). So even it might seem easy for one platform and I agree with Micheal that > > * yay! let's start a rewrite is unlikely to succeede soon... However, when considering this, before IMHO a powerful Java API has to be defined, because according to my experiences for implementing non-trivial protocols InputStream/OutputStream might not be comfortable/powerfull enough (eventually I consider both wrong) and have some InputStream derivation available as wrapper (so applications can use InputStream and whatever high-level-API they want). The JNI interface shall make such a powerful implementation possible, thus the interface of it is driving the JNI interface design and thus I think it had to be done first. All this surely requires much work: agreements on the APIs, safeness for the users, design, documentation, all the implementations and the testing. As long as such bug amount of work cannot be spent, for example if some employee would get half a year time paid for it or so :-), probably it is unlikely to progress on this. Otherwise, I'm afraid, patches, improvements, new design ideas and even rewrites wouldn't become complete and thus won't form a new rxtx version (3.0); thus either collect dust in some forgotten CVS branch or could generate a split... > I can't imagine other ports taking > much longer than that - especially since POSIX-based code can > be shared between ports. Things are more complex than they seem to be... I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select on serial ports isn't supported; maybe it is non-trivial to "map" (like mapping select() to WaitForMultipleObjects() which might have different semantics etc.) or maybe some different approach has to be used. A system may have POSIX like termios interfaces but not support timeouts or have any other interoperability bug... You never run out of things that can go wrong. And if something can go wrong, it will... :-) Or, as Michael wrote: > > I seriously don't believe anyone will come up with anything better anytime soon. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue Mar 1 04:39:37 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:39:37 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com><13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED6B@COSNPREXC3.usr.ingenico.loc> > 3. Write all of the native (or non-native) code to implement > the native interface. > > Is that correct? If yes, how is that easier than the simple > implementation the current rewrite design uses? To have it complete, reliable, traceable, maintainable and well tested, it is much more work, I'm afraid. A prototype can be done within a few days (maybe on one day), but getting it right (including a passed review) IMHO is a completely different story. In the end you may end up with an average of ten lines per day, when assuming four major native packs (common, win, mac, termios/select) with let's say just 5000 lines each (with logging messages and detailed exceptions this is not much) we would have to estimate a total effort of nine man-years (20000/10/220)... oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 04:40:18 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:40:18 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6CDB22.9070401@sandglass-software.com> Every journey begins with a single step. -Adrian On 3/1/2011 3:25 AM, Steffen DETTMER wrote: > * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> My question would be: Why would you do that? The rewrite does >> most of the work for you - all you have to do is implement >> two C++ virtual classes and two C++ functions. > You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? > I just took a short look, maybe it could be discussed further, > but I don't think I like it much. > BTW, the main interface defined there is called gnu.io.Dispatcher? > I thought the package names should be used in a way to avoid clashes, > e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name > space authority :)). > >> In Windows that took me a few hours. > where is the implementation? > I found > commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp > with things like > > const bool SerialPortImpl::isDataAvailable() const > { > // Needs implementation > return true; > } > > and > > timeouts.ReadIntervalTimeout = MAXDWORD;* > timeouts.ReadTotalTimeoutMultiplier = 0; > timeouts.ReadTotalTimeoutConstant = 0; > timeouts.WriteTotalTimeoutMultiplier = 0; > timeouts.WriteTotalTimeoutConstant = 0; > if (!SetCommTimeouts(hComm,&timeouts)) > throw IOException(); > > which seems to be oversimplified or some prototype only? > > I think (and I wrote about this already in the past years) that correct > timeout handling is one of the challenges, so I think this should be > prototyped first - for each system flavor - before cementation of the > (JNI-) interfaces. Personally, I would vote to form it in a way allowing > to be implemented on embedded devices, for example. > > Another big challenge is to prove a rewrite fully working (and probably > compatible to the old implementation) on "all" the supported OSes. Not a > big problem for linux and windows, just use some thousand lines test > code, test drivers and serial loopbacks etc, but for the exotic > platforms, probably a high number of, this probably won't be too easy... > (there are more challenges, such as being comfortable and threadsafe > [are read and write permitted at the same time?], detailed and helpful > exceptions on user API level [not necessarily on JNI/JNA layer], how to > have a configurable threadsafe logging/tracing [maybe also from native > code to assist porting / testing on exotic OSes, such as OSes where the > developers have no direct access too, which can be quite hard to usually > leads to good log messages], just to name a few.). > > So even it might seem easy for one platform and I agree with Micheal > that > >>> * yay! let's start a rewrite > is unlikely to succeede soon... > > However, when considering this, before IMHO a powerful Java API has to > be defined, because according to my experiences for implementing > non-trivial protocols InputStream/OutputStream might not be > comfortable/powerfull enough (eventually I consider both wrong) and have > some InputStream derivation available as wrapper (so applications can > use InputStream and whatever high-level-API they want). > The JNI interface shall make such a powerful implementation possible, > thus the interface of it is driving the JNI interface design and thus I > think it had to be done first. > > All this surely requires much work: agreements on the APIs, safeness for > the users, design, documentation, all the implementations and the > testing. As long as such bug amount of work cannot be spent, for example > if some employee would get half a year time paid for it or so :-), > probably it is unlikely to progress on this. > > Otherwise, I'm afraid, patches, improvements, new design ideas and even > rewrites wouldn't become complete and thus won't form a new rxtx version > (3.0); thus either collect dust in some forgotten CVS branch or could > generate a split... > >> I can't imagine other ports taking >> much longer than that - especially since POSIX-based code can >> be shared between ports. > Things are more complex than they seem to be... > > I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select > on serial ports isn't supported; maybe it is non-trivial to "map" (like > mapping select() to WaitForMultipleObjects() which might have different > semantics etc.) or maybe some different approach has to be used. A > system may have POSIX like termios interfaces but not support timeouts > or have any other interoperability bug... > You never run out of things that can go wrong. And if something can go > wrong, it will... :-) > > Or, as Michael wrote: > >>> I seriously don't believe anyone will come up with anything better > anytime soon. > > oki, > > Steffen > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Kustaa.Nyholm at planmeca.com Tue Mar 1 04:57:02 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 13:57:02 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: On 3/1/11 13:13, "Adrian Crum" wrote: >The javax.comm API specification requires one event monitor thread per >port. I don't like the idea of having a thread per port either, but one >of the rewrite's design goals is strict conformance to the specification. Ah, had not spotted that requirement. > >The 50 mS polling interval is just a placeholder. The final design of >that is yet to be decided. > >In Windows, you have two choices for I/O: overlapped and non-overlapped. >In overlapped I/O a thread is blocked, waiting for something to happen. >In non-overlapped I/O a thread does not block. I chose non-overlapped >I/O to avoid thread blocking at the OS level - instead, the thread >blocking is kept in Java. > >-Adrian thanks for the explanation. br Kusti From iqzw2r602 at sneakemail.com Tue Mar 1 05:08:17 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:08:17 +1100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <32684-1298981297-704398@sneakemail.com> This reminds me of a nasty problem I had with overlapped I/O on windows with jpathwatch. You can't start an I/O request in one thread and then do the check if that request completed in another thread. Very strange things happen when you attempt that; made me change the design of the Windows implementation quite drastically (one thread on a command queue that executes requests from other threads instead of letting them wildly call into GetOverlappedResult()). Out of curiosity: Did you come across that too? Or are all requests handled in the same thread they're issued? Cheers, Uwe On Tue, Mar 1, 2011 at 10:13 PM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > The javax.comm API specification requires one event monitor thread per > port. I don't like the idea of having a thread per port either, but one of > the rewrite's design goals is strict conformance to the specification. > > The 50 mS polling interval is just a placeholder. The final design of that > is yet to be decided. > > In Windows, you have two choices for I/O: overlapped and non-overlapped. In > overlapped I/O a thread is blocked, waiting for something to happen. In > non-overlapped I/O a thread does not block. I chose non-overlapped I/O to > avoid thread blocking at the OS level - instead, the thread blocking is kept > in Java. > > -Adrian > > > On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > >> Adrian, >> >> had a look at your code/rewrite and it looks rather clean/nice. >> >> I was looking at the code to gain insight (not related to the >> rewrite) into what is involved in serial port programming >> in Windows. Or rather, to refresh my memory and see how others have >> done, because I've been there done that. >> >> So my questions are just to satisfy my curiosity, not to criticize >> or suggest improvements. >> >> 1) It looks like a new thread (EventMonitor) is created for >> each Serial port, is that correct? >> >> Many people seem to try to avoid using many threads in this sort >> of situation, and like to use something like unix select(). >> I personally find using threads more natural and better impedance >> match to the problem being solved here. I guess 'many people' above >> >> refers to those implementing thousands of connections and >> who cannot live with the overhead and limited number of threads >> available. >> >> 2) The EventMonitor basically polls for events at 50 msec interval? >> >> 3) There is a comment in the source code near the sleep(50) : >> >> // Sufficient up to 19200 baud >> >> >> I'm sure you thought about this carefully, so again not >> criticizing, but seeking to understand how or why, because >> at 50 msec would seem to limit through in some cases. Like >> if you send one byte and need to wait for one to return, >> then this limits speed to 200 chars/sec? >> >> 4) I've done something similar to a few years back from >> Java using JNI to access Win32 API serial port, and >> I seem to recall that I had threading issues ie when >> I submitted a read (ReadFile) and there was no data coming >> in, the thread would not only block but also consume a >> lot of CPU cycles ie it was not sleeping properly inside >> the ReadFile call when the serial port blocked. >> >> Im a bit fuzzy about the details after five years, so my question is >> have you checked if there an issue here? >> >> >> 5) AFAIK the select() on Windows does not work serial ports >> but there is some other mechanism (events?) to implement the >> same functionality, did you consider that? Probably, so you >> decided against it, why? >> >> >> br Kusti >> >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 05:37:07 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:37:07 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <1142-1298983027-957144@sneakemail.com> On Tue, Mar 1, 2011 at 1:32 PM, Adrian Crum wrote: > Just to make sure I'm understanding you correctly, anyone porting RxTx to > a new platform would have to do the following: > > 1. Write their own Java implementation of an abstract Dispatcher class. > yep. I'd probably put all my calls to native OS wrappers in there two, looks the most straight-forward to me. > 2. Write a native (JNI or JNA) interface for the abstract class > implementation. > yes. For POSIX you'd probably only write one piece of code that provides implementations for open(), close(), and friends. You can compile that on all posix platforms (yeah, the devil is in the detail, but it's very little code, still). So this does open() (when using ***, but you can also use +++) // Unix.java class Unix{ public static native int open(String filename, int flags, int mode); .... } // Unix.cpp JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) { const char* pathname = env->GetStringUTFChars(jpathname, 0); if(pathname == 0) return -1; // java throws an out of memory error in this case int result = open(pathname, flags, mode); Unix_cacheErrno(); // handle interference between JVM and errno; env->ReleaseStringUTFChars(jpathname, pathname); return result; } .... 3. Write all of the native (or non-native) code to implement the native > interface. > Not sure what you mean by that. I've done the OS wrappers in step 2. step 1. implements that Dispatcher. What else do I need? > Is that correct? If yes, how is that easier than the simple implementation > the current rewrite design uses? > Yes, except for 3 (see above). How it is easier: I can debug the Java code directly. I can step from the read() call of an input stream directly into the guts of the RXTX implementation on my platform and see e.g. why it's hanging, because I see all the way up the call stack right where it calls Unix.read(). You can't easily do that with a fat native library, especially if you have no second set of devtools installed (the ones for native development). And I bet anyone knowing both languages can write it faster in Java, with less bugs. > On a side note: there is no requirement to write native code using C++. If > C++ is a real obstacle to adoption, then regular C could be used instead. In > that case, there would be a Dispatcher.c file that contains function > protoypes that need to be implemented. Dispatcher.c would still maintain the > same role as Dispatcher.cpp - which is to shield native code developers from > the details of JNI. Just build out the missing functions using C data types > and you're ready to go. > As I said, whatever works for you. Java works for me better than C++ in this case... Cheers, Uwe -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Mar 1 08:26:41 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 16:26:41 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> > The javax.comm API specification requires one event monitor > thread per port. Where does it require this? Do you mean "All the events received by this listener are generated by one dedicated thread that belongs to the SerialPort object. "? I think this is an implementation detail, isn't it? At least it is mentioned after "The current implementation only allows one listener per SerialPort". A bit bad that javadoc does not distinguish between API spec and implementation documentation. Also I don't think that TooManyListenersException MUST be thrown (I think it CAN be thrown). > I don't like the idea of having a thread per > port either, but one of the rewrite's design goals is strict > conformance to the specification. (but not necessarily on JNI layer) > The 50 mS polling interval is just a placeholder. The final > design of that is yet to be decided. I though no polling would be wanted; what could be the placeholder stand for? Do you mean a different interval duration or do you mean something completely different? > In Windows, you have two choices for I/O: overlapped and > non-overlapped. > In overlapped I/O a thread is blocked, waiting for something > to happen. > In non-overlapped I/O a thread does not block. I chose > non-overlapped I/O to avoid thread blocking at the OS level - > instead, the thread blocking is kept in Java. Isn't "overlapped" (asynchronous) I/O meaning that you invoke some ReadFile(..., &overlapped, ...) INSTEAD of performing a synchronous (blocking) function call blocking the thread? As far as I see, W32_Support.cpp uses CreateFile without FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O operations are serialized, even if the calls to the read and write functions specify an OVERLAPPED structure." [1] and "A synchronous handle behaves such that I/O function calls using that handle are blocked until they complete" [2] Given that CCOMTIMEOUTS get: "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the bytes that have already been received, even if no bytes have been received." [3] It looks likes this implementation relies on polling, which probably would waste much computing power. What did I miss? oki, Steffen [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro nous_and_asynchronous_i_o_handles [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 09:23:47 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:23:47 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6D1D93.6090306@sandglass-software.com> Unfortunately, the javax.comm API specification includes a lot of implementation details. That is one of the weaknesses of the specification in my opinion. The bottom line is, anyone wanting to use RxTx as a javax.comm implementation is going to expect it to do the things the specification says it does. -Adrian On 3/1/2011 7:26 AM, Steffen DETTMER wrote: >> The javax.comm API specification requires one event monitor >> thread per port. > Where does it require this? > > Do you mean "All the events received by this listener are generated > by one dedicated thread that belongs to the SerialPort object. "? > > I think this is an implementation detail, isn't it? At least it is > mentioned after "The current implementation only allows one listener per > SerialPort". A bit bad that javadoc does not distinguish between API > spec and implementation documentation. Also I don't think that > TooManyListenersException MUST be thrown (I think it CAN be thrown). > >> I don't like the idea of having a thread per >> port either, but one of the rewrite's design goals is strict >> conformance to the specification. > (but not necessarily on JNI layer) > >> The 50 mS polling interval is just a placeholder. The final >> design of that is yet to be decided. > I though no polling would be wanted; what could be the placeholder stand > for? Do you mean a different interval duration or do you mean something > completely different? > >> In Windows, you have two choices for I/O: overlapped and >> non-overlapped. >> In overlapped I/O a thread is blocked, waiting for something >> to happen. >> In non-overlapped I/O a thread does not block. I chose >> non-overlapped I/O to avoid thread blocking at the OS level - >> instead, the thread blocking is kept in Java. > Isn't "overlapped" (asynchronous) I/O meaning that you invoke some > ReadFile(...,&overlapped, ...) > INSTEAD of performing a synchronous (blocking) function call blocking > the thread? > > As far as I see, W32_Support.cpp uses CreateFile without > FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O > operations are serialized, even if the calls to the read and write > functions specify an OVERLAPPED structure." [1] and "A synchronous > handle behaves such that I/O function calls using that handle are > blocked until they complete" [2] > > Given that CCOMTIMEOUTS get: > "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values > for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier > members, specifies that the read operation is to return immediately with > the bytes that have already been received, even if no bytes have been > received." [3] > > It looks likes this implementation relies on polling, which probably > would waste much computing power. > > What did I miss? > > oki, > > Steffen > > [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx > [2] > http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro > nous_and_asynchronous_i_o_handles > [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at sandglass-software.com Tue Mar 1 09:55:29 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:55:29 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <1142-1298983027-957144@sneakemail.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> Message-ID: <4D6D2501.1020803@sandglass-software.com> That code duplicates what is in Dispatcher.cpp. A Unix port would only need to implement CommPortFactory::getInstance(portName, portType). -Adrian On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 15:07:46 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 2 Mar 2011 09:07:46 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6D2501.1020803@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> <4D6D2501.1020803@sandglass-software.com> Message-ID: <23749-1299017266-991798@sneakemail.com> What is this duplicating? A Unix port will need to call open() anyways (just so we're talking about the same thing here: open() is the Unix equivalent of CreateFile()) On Wed, Mar 2, 2011 at 3:55 AM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > That code duplicates what is in Dispatcher.cpp. A Unix port would only > need to implement CommPortFactory::getInstance(portName, portType). > > -Adrian > > > On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Tue Mar 1 22:53:07 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 00:53:07 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: Hi, I haven't seen any response to my question below. Is this not the right place to ask? If not, where would be a better place to ask? Any suggestions? Thanks, Ryan On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >> Hi, >> >> I have a receive thread that does nothing but call read() on the serial >> port input stream. It works fine for a while but after running for a long >> time it eventually returns -1 which means EOF. This is my first problem, as >> the device I'm talking to runs forever, I don't know why it would return -1. >> I am calling disableReceiveThreshold() and disableReceiveTimeout() at >> initialization which according to the documentation means read will return >> as soon as any data is available and it will block forever when data is not >> available, so -1 should never be returned from read, right? >> >> I have been unable to figure out why read returns -1 after a long while >> but I have found that if I kill my application and restart it everything >> works fine again. Therefore I tried to work around the problem by having my >> code close the port and reopen it when read returns -1. My second problem is >> that in this case when I call close() on the port it blocks forever. I did >> find this old bug >> >> http://bugzilla.qbang.org/show_bug.cgi?id=53 >> >> which describes close() hanging on OSX, but it says that bug was fixed >> with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have >> any idea why read might be returning -1 in the first place? If I can avoid >> that I don't care about close() hanging because I would never close the >> port. If not, does anyone know why close() might block forever and how I can >> prevent this? I'm using RXTX version 2.1-7. >> >> Thanks, >> -- >> Ryan >> >> > > > -- > Ryan Boder > 1 614 598-6339 > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Mar 2 01:34:48 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 2 Mar 2011 10:34:48 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/2/11 07:53, "Ryan Boder" wrote: Can you / have you made a simple test to ensure that rxtx is the issue? Can you write a simple C-program to see if this exhibits the same problem? I've never encountered this sort of problem with rxtx, it mostly just works. But I'm on Mac so can't say about Windows (7) br Kusti >Hi, > >I haven't seen any response to my question below. Is this not the right >place to ask? If not, where would be a better place to ask? Any >suggestions? > >Thanks, >Ryan > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > >I mis-spoke, I don't have my own thread calling read, I am calling >read in the event handler after receiving a >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be >accurate though. > >Ryan > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >Hi, > >I have a receive thread that does nothing but call read() on the serial >port input stream. It works fine for a while but after running for a long >time it eventually returns -1 which means EOF. This is my first problem, >as the device I'm talking to runs forever, I don't know why it would >return -1. I am calling disableReceiveThreshold() and >disableReceiveTimeout() at initialization which according to the >documentation means read will return as soon as any data is available and >it will block forever when data is not available, so -1 should never be >returned from read, right? > >I have been unable to figure out why read returns -1 after a long while >but I have found that if I kill my application and restart it everything >works fine again. Therefore I tried to work around the problem by having >my code close the port and reopen it when read returns -1. My second >problem is that in this case when I call close() on the port it blocks >forever. I did find this old bug > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > >which describes close() hanging on OSX, but it says that bug was fixed >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone >have any idea why read might be returning -1 in the first place? If I can >avoid that I don't care about close() hanging because I would never close >the port. If not, does anyone know why close() might block forever and >how I can prevent this? I'm using RXTX version 2.1-7. > >Thanks, >-- >Ryan > > > > > > > > > >-- >Ryan Boder >1 614 598-6339 > > > > > > >-- >Ryan Boder >1 614 598-6339 > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From Steffen.DETTMER at ingenico.com Wed Mar 2 03:08:57 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:08:57 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <32684-1298981297-704398@sneakemail.com> References: <4D6CD4DE.7040501@sandglass-software.com> <32684-1298981297-704398@sneakemail.com> Message-ID: <20110302100857.GB8030@elberon.bln.de.ingenico.com> * iqzw2r602 at sneakemail.com wrote on Tue, Mar 01, 2011 at 23:08 +1100: > This reminds me of a nasty problem I had with overlapped I/O on windows Yeah, those thousands of complex, difficult to use and exception-containing WinAPI is really hard to use... About strange effects on overlapped&multithreading, MSDN has: `the calling thread uses the GetOverlappedResult function or one of the wait functions' [1] also also mentiones I/O Completion Ports [2], and later continues: `If an application reuses OVERLAPPED structures on multiple threads and calls GetOverlappedResult with the bWait parameter set to TRUE, the application must ensure that the associated event is set before the application reuses the structure. This can be accomplished by using the WaitForSingleObject function after calling GetOverlappedResult to force the thread to wait until the operation completes. Note that the event object must be a manual-reset event object. If an autoreset event object is used, calling GetOverlappedResult with the bWait parameter set to TRUE causes the function to be blocked indefinitely.' also [1] oki, Steffen [1] http://msdn.microsoft.com/en-us/library/ms686358%28v=vs.85%29.aspx [2] http://msdn.microsoft.com/en-us/library/aa365198%28v=vs.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:15:11 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:15:11 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6D1D93.6090306@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> <4D6D1D93.6090306@sandglass-software.com> Message-ID: <20110302101511.GC8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 08:23 -0800: > Unfortunately, the javax.comm API specification includes a lot of > implementation details. That is one of the weaknesses of the > specification in my opinion. The bottom line is, anyone wanting to use > RxTx as a javax.comm implementation is going to expect it to do the > things the specification says it does. Yeah ok, but even then the implementation could check for the TooManyListenersException situations (if it really is required to support applications relying on that exception) but internally use just a single I/O thread waiting for events on any open file descriptors. Of course an implementation supporting all sort of concurrency could become quite complex (especially if open-read-close should work fast, I think would be difficult to implement, because a new file descriptors had to be added to the waitFor/select list, and who knows how systems behave here in detail...). oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:25:15 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:25:15 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6CDB22.9070401@sandglass-software.com> References: <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> <4D6CDB22.9070401@sandglass-software.com> Message-ID: <20110302102515.GD8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 03:40 -0800: > * from some older mail: > > My question would be: Why would you do that? The rewrite does > > most of the work for you - all you have to do is implement > > two C++ virtual classes and two C++ functions. > > > > In Windows that took me a few hours. > > Every journey begins with a single step. Yes, of course, but then it shouldn't be used as base for new effort estimations like `In Windows that took a few hours' ;-) (BTW, calling a single step `the rewrite' may sound a bit ambitious ;)) But of course a prototype demonstrating something can be really helpful, sure. I just wanted to tell that interfaces should be easy to use and powerful at the same time and may non-trivial initial considerations before starting to implement them. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From ryan.boder at gmail.com Wed Mar 2 18:44:35 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:44:35 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: While running the tests you requested I may have stumbled on the problem, I just don't know how to fix it. According to the documentation, if both the receive timeout and receive threshold are disabled then read() should block forever until data is available. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#getInputStream%28%29 On my system using RXTX read() is returning -1 when no data is available even though I have disabled both thresholds. The reason my program was running fine for a while without this problem showing up is that I was using the DATA_AVAILABLE event to be notified when data is available and only calling read() to read an entire frame whenever the DATA_AVAILABLE event occurred, until eventually my device (I'm guessing) probably took longer than normal to send the entire data frame and therefore I called read when no data was available and it returned -1. The following Java program demonstrates my problem, it returns -1 as soon as no data is available, even though I think it should block until data is available. import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; public class Main implements SerialPortEventListener { public static void main(String[] args) throws Exception { new Main().run(); } private void run() throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier("COM4"); SerialPort port = (SerialPort) portIdentifier.open(Main.class.getName(), 2000); port.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); port.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); port.disableReceiveThreshold(); port.disableReceiveTimeout(); BufferedInputStream in = new BufferedInputStream(port.getInputStream()); BufferedOutputStream out = new BufferedOutputStream(port.getOutputStream()); port.addEventListener(this); Thread.sleep(1000); out.write(new byte[] {0x02, 0x60}); out.flush(); while (true) { int x = in.read(); if (x == -1) { System.out.println("EOF"); Thread.sleep(1000000000); } String s = Integer.toHexString(x & 0xFF); if (s.length() == 1) s = "0" + s; System.out.print(s + " "); System.out.flush(); } } public void serialEvent(SerialPortEvent arg0) { System.out.println("Serial port event"); } } However, the follow C# program ran all day today without ever read ever returning -1, as I would expect. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.IO.Ports; using System.Threading; namespace RXTXReadTest1 { class Program { static void Main(string[] args) { new Program().run(); } private void run() { SerialPort port = new SerialPort("COM4", 19200, Parity.None, 8, StopBits.One); port.Open(); port.Write(new byte[] { 0x02, 0x60 }, 0, 2); while (true) { int x = port.ReadByte(); if (x == -1) { Console.WriteLine("EOF"); Thread.Sleep(1000000000); } String s = x.ToString("X"); if (s.Length == 1 ) s = "0" + s; Console.Out.Write(s + " "); Console.Out.Flush(); } } } } Now I am experimenting with what happens if I set the receive timeout to it's maximum value (apparently 1600ms) and only call read() when I am expecting data. Hopefully it will never be more than 1600ms late. This is still only a work around, not solving the problem. Am I doing something wrong in my code above or is RXTX retuning -1 when it should be blocking? Thanks, Ryan On Wed, Mar 2, 2011 at 3:34 AM, Kustaa Nyholm wrote: > On 3/2/11 07:53, "Ryan Boder" wrote: > Can you / have you made a simple test to ensure that rxtx is the issue? > > Can you write a simple C-program to see if this exhibits the same problem? > > I've never encountered this sort of problem with rxtx, it mostly just > works. > > But I'm on Mac so can't say about Windows (7) > > br Kusti > > > > > >Hi, > > > >I haven't seen any response to my question below. Is this not the right > >place to ask? If not, where would be a better place to ask? Any > >suggestions? > > > >Thanks, > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder > wrote: > > > >I mis-spoke, I don't have my own thread calling read, I am calling > >read in the event handler after receiving a > >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be > >accurate though. > > > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder > wrote: > > > >Hi, > > > >I have a receive thread that does nothing but call read() on the serial > >port input stream. It works fine for a while but after running for a long > >time it eventually returns -1 which means EOF. This is my first problem, > >as the device I'm talking to runs forever, I don't know why it would > >return -1. I am calling disableReceiveThreshold() and > >disableReceiveTimeout() at initialization which according to the > >documentation means read will return as soon as any data is available and > >it will block forever when data is not available, so -1 should never be > >returned from read, right? > > > >I have been unable to figure out why read returns -1 after a long while > >but I have found that if I kill my application and restart it everything > >works fine again. Therefore I tried to work around the problem by having > >my code close the port and reopen it when read returns -1. My second > >problem is that in this case when I call close() on the port it blocks > >forever. I did find this old bug > > > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > > > >which describes close() hanging on OSX, but it says that bug was fixed > >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone > >have any idea why read might be returning -1 in the first place? If I can > >avoid that I don't care about close() hanging because I would never close > >the port. If not, does anyone know why close() might block forever and > >how I can prevent this? I'm using RXTX version 2.1-7. > > > >Thanks, > >-- > >Ryan > > > > > > > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Wed Mar 2 18:46:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:46:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: <-1051064942000733580@unknownmsgid> References: <-1051064942000733580@unknownmsgid> Message-ID: It is USB and seems very reliable with the C# test program in my previous email. On Wed, Mar 2, 2011 at 6:58 PM, Bruce Griffith wrote: > How reliable is your serial port ? is it USB or Bluetooth? > > > > Bruce Griffith > > 303-532-4778 > > > > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On Behalf > Of *Ryan Boder > *Sent:* Tuesday, 01 March 2011 10:53 PM > *To:* rxtx at qbang.org > *Subject:* Re: [Rxtx] RXTX serial port read() returns -1 unexpectedly and > then blocks forever on close() > > > > Hi, > > I haven't seen any response to my question below. Is this not the right > place to ask? If not, where would be a better place to ask? Any suggestions? > > Thanks, > Ryan > > On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > > Hi, > > I have a receive thread that does nothing but call read() on the serial > port input stream. It works fine for a while but after running for a long > time it eventually returns -1 which means EOF. This is my first problem, as > the device I'm talking to runs forever, I don't know why it would return -1. > I am calling disableReceiveThreshold() and disableReceiveTimeout() at > initialization which according to the documentation means read will return > as soon as any data is available and it will block forever when data is not > available, so -1 should never be returned from read, right? > > I have been unable to figure out why read returns -1 after a long while but > I have found that if I kill my application and restart it everything works > fine again. Therefore I tried to work around the problem by having my code > close the port and reopen it when read returns -1. My second problem is that > in this case when I call close() on the port it blocks forever. I did find > this old bug > > http://bugzilla.qbang.org/show_bug.cgi?id=53 > > which describes close() hanging on OSX, but it says that bug was fixed with > a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have any > idea why read might be returning -1 in the first place? If I can avoid that > I don't care about close() hanging because I would never close the port. If > not, does anyone know why close() might block forever and how I can prevent > this? I'm using RXTX version 2.1-7. > > Thanks, > -- > Ryan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Mar 3 02:50:20 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 3 Mar 2011 09:50:20 +0000 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: So if -1 is unexpectedly returned from read, and we have demonstrated that your USB-serial adapter can actually causes this to happen in RXTX, why not just ignore the -1 value? What happens when you try this? As for a hang on close, are your closing your port from within your serial event handler? I know that this can cause some serious problems. Regards, Michael Erskine. From Kustaa.Nyholm at planmeca.com Thu Mar 3 03:39:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 12:39:34 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 03:44, "Ryan Boder" wrote: >While running the tests you requested I may have stumbled on the problem, >I just don't know how to fix it. According to the documentation, if both >the receive timeout and receive threshold are disabled then read() should >block forever until data is available. > >http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/re >ference/api/javax/comm/CommPort.html#getInputStream%28%29 > >On my system using RXTX read() is returning -1 when no data is available >even though I have disabled both thresholds. The reason my program was >running fine for a while without this problem showing up is that I was >using the DATA_AVAILABLE event to be notified when data is available and >only calling read() to read an entire frame whenever the DATA_AVAILABLE >event occurred, until eventually my device (I'm guessing) probably took >longer than normal to send the entire data frame and therefore I called >read when no data was available and it returned -1. As a workaround have you tried to perform another read() if it returns -1? The javadoc says (see getInputStream): "Note, however, that framing errors may cause the Timeout and Threshold values to complete prematurely without raising an exception." I read this as a hint that read might return even if no data is available. Because of the above and that read() can only return -1 or the byte received it would be somewhat logical to return -1 in case of framing error ? I'm not claiming that my interpretation of the specification, such as it is, is correct, just speculating that the behavior could be something like that. It might give you some more insight if you used the read(bytes[],int,int) method, because this can and will return 0 in case of timeout (and presumably might do so in case of framing error, maybe some other error condition too). That might allow you to handle or work around the problem in this case. You have not shown your complete code (no need) but your comments and the example makes me wonder if the code is otherwise as it should be, meaning are you assuming that when you get the DATA_AVAILABLE event all of your frame has arrived and that you can just blindly read it away from the input stream? That is not guaranteed of course. Also using read(), instead of read(bytes[],int,int), is not very efficient and might be masking other problems as mused above. BTE you can print a byte in hex with leading zeros more easily with: System.out.printf("%02X",x); br Kusti From ryan.boder at gmail.com Thu Mar 3 07:56:16 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:56:16 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 5:39 AM, Kustaa Nyholm wrote: > > As a workaround have you tried to perform another read() if it returns -1? > I tried that and it did work sometimes but not all the time. > > The javadoc says (see getInputStream): > > "Note, however, that framing errors may cause the Timeout and Threshold > values to complete prematurely without raising an exception." > > I read this as a hint that read might return even if no data is available. > > Because of the above and that read() can only return -1 or the byte > received > it would be somewhat logical to return -1 in case of framing error ? > > I'm not claiming that my interpretation of the specification, such as it > is, > is correct, just speculating that the behavior could be something like > that. > Receive framing is not enabled by default. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#enableReceiveFraming%28int%29 My choice of word might be misleading, when I said frame I just meant a contiguous message from the device. I am not enabling receive framing. Can you have a framing error when receive framing is disabled? > > It might give you some more insight if you used the read(bytes[],int,int) > method, because > this can and will return 0 in case of timeout (and presumably might do so > in case of framing > error, maybe some other error condition too). > > That might allow you to handle or work around the problem in this case. > > You have not shown your complete code (no need) but your comments and the > example > makes me wonder if the code is otherwise as it should be, meaning are you > assuming > that when you get the DATA_AVAILABLE event all of your frame has arrived > and that > you can just blindly read it away from the input stream? That is not > guaranteed of course. > I'm not assuming the entire message has arrived, I'm just assuming it either has arrived or will arrive soon which is why I'm using a (supposedly) blocking read(). > > Also using read(), instead of read(bytes[],int,int), is not very efficient > and > might be masking other problems as mused above. > True, I'm reading one byte at a time because I don't know how long the message will be until I read and parse some of it. I suppose I can use read(bytes[],int,int) once I figure out how long the message will be. > > BTE you can print a byte in hex with leading zeros more easily with: > > > System.out.printf("%02X",x); > I did it the dumb way in that test program so I could copy and paste the code from C# to Java without having to figure out how to do the same in C# which I'm not as familiar with. Thanks and BR, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 07:58:24 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:58:24 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: Yes I was doing the close in the serial event handler, I didn't realize that caused a problem. Thanks, I'll fix it. On Thu, Mar 3, 2011 at 4:50 AM, Michael Erskine wrote: > So if -1 is unexpectedly returned from read, and we have demonstrated > that your USB-serial adapter can actually causes this to happen in > RXTX, why not just ignore the -1 value? What happens when you try > this? As for a hang on close, are your closing your port from within > your serial event handler? I know that this can cause some serious > problems. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 11:48:20 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 13:48:20 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm wrote: > On 3/3/11 16:56, "Ryan Boder" wrote: > > > >I'm not assuming the entire message has arrived, I'm just assuming it > >either has arrived or will arrive soon which is why I'm using a > >(supposedly) blocking read(). > > > I've been giving this some further thought. > > It does not feel healthy to block without timeout, especially > from within a thread that is essentially internal to the rxtx. > > I've never done that, I always use a time out, read(byte[],int,int) > for the expected number of bytes, check how much I got and issue > more reads until I get everything. > > You have not described how your communication works so I'm only > speculating. > > If your device needs some response to send more bytes (from your > code it looks like this is not the case) then a missing byte > would block your read and prevent you from responding and > getting more data. But as said, looks like that is not the case. > > Anyway, if this was my problem, I would enable the timeout > and use read(byte[],int,int) and loop until I get what I need. > You are right, I should and will use a timeout. In fact, my program has been running flawlessly for 12 hours and the only change I made was to enable a timeout, no change in the logic at all. Without the timeout read() was returning -1 usually after it ran for an hour or two. I will change the code to make use of the timeout and handle it appropriately. It still seems to me that RXTX's behavior doesn't match the documentation when rx timeout and rx threshold are disabled read() should block until data is available instead of immediately returning -1. I don't believe that a framing error is occurring immediately every time data is not available causing read() to return -1. Especially since the C# test program above runs all day with no error and the Java program above runs all day with no error when a timeout is enabled. To me it seems like enabling the timeout is what is causing read() to block until data is available, even if only for 1600ms, and without the timeout read() is returning -1 immediately when it should be blocking. Thanks for all the help and best regards, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Thu Mar 3 13:02:30 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 22:02:30 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 20:48, "Ryan Boder" wrote: >On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm > wrote: > >On 3/3/11 16:56, "Ryan Boder" wrote: >> > >>I'm not assuming the entire message has arrived, I'm just assuming it >>either has arrived or will arrive soon which is why I'm using a >>(supposedly) blocking read(). > > > >I've been giving this some further thought. > >It does not feel healthy to block without timeout, especially >from within a thread that is essentially internal to the rxtx. > >I've never done that, I always use a time out, read(byte[],int,int) >for the expected number of bytes, check how much I got and issue >more reads until I get everything. > >You have not described how your communication works so I'm only >speculating. > >If your device needs some response to send more bytes (from your >code it looks like this is not the case) then a missing byte >would block your read and prevent you from responding and >getting more data. But as said, looks like that is not the case. > >Anyway, if this was my problem, I would enable the timeout >and use read(byte[],int,int) and loop until I get what I need. > > > > >You are right, I should and will use a timeout. In fact, my program has >been running flawlessly for 12 hours and the only change I made was to >enable a timeout, no change in the logic at all. Without the timeout >read() was returning -1 usually after it ran for an hour or two. I will >change the code to make use of the timeout and handle it appropriately. That's nice! > >It still seems to me that RXTX's behavior doesn't match the documentation >when rx timeout and rx threshold are disabled read() should block until >data is available instead of immediately returning -1. Yeah, it does look like bug. However this might be related to some Windows specific serial port issue. Years ago I had issues with JavaComm (not RxTx) where I did a blocking read and I had huge issues with my program consuming all resources. I curser the Sun and JavaComm and re-code my own SerialPort using JNI to access the Win32 API directly. And I run into the same problems as with the Sun's implementation! So I ditched my code, changed my code to use timeouts and problems disappeared. > I don't believe that a framing error is occurring immediately every time >data is not available causing read() to return -1. Especially since the >C# test program above runs all day with no error and the Java program >above runs all day with no error when a timeout is enabled. I think so too, all things considered I don't really believe in framing errors in this case. > To me it seems like enabling the timeout is what is causing read() to >block until data is available, even if only for 1600ms, and without the >timeout read() is returning -1 immediately when it should be blocking. Yeah, I had a peek at the innards of RxTx Windows serial port a week or so ago and also read MSDN documentation about serial ports and the way overlapped and non-overlapped (non blocking and blocking) IO is handled is a way different. So yeah, it can well be that there is an issue lurking there somewhere inside RxTx in Windows. > > >Thanks for all the help and best regards, >-- >Ryan Boder I'm happy if I was of any assistance. br Kusti From tjarvi at qbang.org Thu Mar 3 18:52:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Mar 2011 18:52:50 -0700 (MST) Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: >> Without the timeout >> read() was returning -1 usually after it ran for an hour or two. There is a big hammer in rxtx causing that behavior. >> It still seems to me that RXTX's behavior doesn't match the documentation >> when rx timeout and rx threshold are disabled read() should block until >> data is available instead of immediately returning -1. > > Yeah, it does look like bug. However this might be related to some > Windows specific serial port issue. Years ago I had issues with > JavaComm (not RxTx) where I did a blocking read and I had huge > issues with my program consuming all resources. I curser the Sun > and JavaComm and re-code my own SerialPort using JNI to access > the Win32 API directly. And I run into the same problems as > with the Sun's implementation! So I ditched my code, changed > my code to use timeouts and problems disappeared. > > >> To me it seems like enabling the timeout is what is causing read() to >> block until data is available, even if only for 1600ms, and without the >> timeout read() is returning -1 immediately when it should be blocking. > > Yeah, I had a peek at the innards of RxTx Windows serial port a week > or so ago and also read MSDN documentation about serial ports and > the way overlapped and non-overlapped (non blocking and blocking) > IO is handled is a way different. So yeah, it can well be that > there is an issue lurking there somewhere inside RxTx in Windows. > > Yes. RXTX was patched to behave the way it does. I don't fully understand the issue behind the patch. Marc noticed the odd behavior as well and offered a fix which was greeted with resistance. The windows implementation was done without real documentatino of the windows API. I think I had an example from the late 80's early 90's on Microsoft's site and some API documentation that was obviously not microsofts in Europe. Wayne Roberts had a real need for windows support and fixed some major issues it had. My interest at the time was mingw32. I then cleaned it up for some specific uses I had later. The read returning -1 when it should block didn't impact anybody and appeared to help some people. It isnt the documented behavior though. There could be all sorts of latent bugs in that code but in the real world, it gets by in almost all use cases. Its a hack but it worked for 100's of thousands of people over a 14 year period. Maybe its time to revisit the code but there is more risk than gain for most people. How do you move forward and avoid the risk? Some have expressed interests in coding C++ or other efforts. I'm all for such efforts but feel some unit tests that work with a null modem cables are the only thing that will move rxtx (and perhaps CommAPI) forward. If we have a test suite in place as a qualification for implementations, progress can be made in the right direction regardless of the implementation details. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Fri Mar 4 02:57:16 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 4 Mar 2011 11:57:16 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/4/11 03:52, "Trent Jarvi" wrote: >Yes. RXTX was patched to behave the way it does. I don't fully >understand the issue behind the patch. Marc noticed the odd behavior as >well and offered a fix which was greeted with resistance. > >The windows implementation was done without real documentatino of the >windows API. I think I had an example from the late 80's early 90's on >Microsoft's site and some API documentation that was obviously not >microsofts in Europe. Wayne Roberts had a real need for windows support >and fixed some major issues it had. My interest at the time was mingw32. >I then cleaned it up for some specific uses I had later. The read >returning -1 when it should block didn't impact anybody and appeared to >help some people. It isnt the documented behavior though. > >There could be all sorts of latent bugs in that code but in the real >world, it gets by in almost all use cases. I think so too, never had any problems with it. > Its a hack but it worked for 100's of thousands of people over a 14 year >period. Yeah! Thanks for everyone who has contributed over the years, job well done! >Maybe its time to >revisit the code but there is more risk than gain for most people. How >do >you move forward and avoid the risk? My view is that it is quite risky and rather pointless to move forward, other than fixing bugs that really affect people. At the moment the major issue IMO is just that it seems (not been following this too carefully, so maybe I'm wrong, so in case this FUD, my apologies) that 'official' binaries are not available. I think the rewrite, tempting as it is in some respects is not the way forward. Just gentle maintenance to iron out real issues and then get the binaries out. br Kusti From ryan.boder at gmail.com Fri Mar 4 07:24:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Fri, 4 Mar 2011 09:24:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 8:52 PM, Trent Jarvi wrote: > > The windows implementation was done without real documentatino of the > windows API. I think I had an example from the late 80's early 90's on > Microsoft's site and some API documentation that was obviously not > microsofts in Europe. Wayne Roberts had a real need for windows support and > fixed some major issues it had. My interest at the time was mingw32. I then > cleaned it up for some specific uses I had later. The read returning -1 > when it should block didn't impact anybody and appeared to help some people. > It isnt the documented behavior though. > > There could be all sorts of latent bugs in that code but in the real world, > it gets by in almost all use cases. Its a hack but it worked for 100's of > thousands of people over a 14 year period. Maybe its time to revisit the > code but there is more risk than gain for most people. How do you move > forward and avoid the risk? > The safest and easiest solution would be to add a javadoc comment to disableReceiveTimeout explaining the difference between the RXTX behavior and Sunacle's documented behavior so that when someone uses the method in an IDE like Eclipse a little box would pop up informing them. Generating javadoc HTML and hosting it on the RXTX website would go a long way too, when something behaves differently than I expect the first thing I do is look for the javadoc online. -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Mar 1 00:54:17 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 09:54:17 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> Message-ID: Adrian, had a look at your code/rewrite and it looks rather clean/nice. I was looking at the code to gain insight (not related to the rewrite) into what is involved in serial port programming in Windows. Or rather, to refresh my memory and see how others have done, because I've been there done that. So my questions are just to satisfy my curiosity, not to criticize or suggest improvements. 1) It looks like a new thread (EventMonitor) is created for each Serial port, is that correct? Many people seem to try to avoid using many threads in this sort of situation, and like to use something like unix select(). I personally find using threads more natural and better impedance match to the problem being solved here. I guess 'many people' above refers to those implementing thousands of connections and who cannot live with the overhead and limited number of threads available. 2) The EventMonitor basically polls for events at 50 msec interval? 3) There is a comment in the source code near the sleep(50) : // Sufficient up to 19200 baud I'm sure you thought about this carefully, so again not criticizing, but seeking to understand how or why, because at 50 msec would seem to limit through in some cases. Like if you send one byte and need to wait for one to return, then this limits speed to 200 chars/sec? 4) I've done something similar to a few years back from Java using JNI to access Win32 API serial port, and I seem to recall that I had threading issues ie when I submitted a read (ReadFile) and there was no data coming in, the thread would not only block but also consume a lot of CPU cycles ie it was not sleeping properly inside the ReadFile call when the serial port blocked. Im a bit fuzzy about the details after five years, so my question is have you checked if there an issue here? 5) AFAIK the select() on Windows does not work serial ports but there is some other mechanism (events?) to implement the same functionality, did you consider that? Probably, so you decided against it, why? br Kusti From adrian.crum at sandglass-software.com Tue Mar 1 04:13:34 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:13:34 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: References: Message-ID: <4D6CD4DE.7040501@sandglass-software.com> The javax.comm API specification requires one event monitor thread per port. I don't like the idea of having a thread per port either, but one of the rewrite's design goals is strict conformance to the specification. The 50 mS polling interval is just a placeholder. The final design of that is yet to be decided. In Windows, you have two choices for I/O: overlapped and non-overlapped. In overlapped I/O a thread is blocked, waiting for something to happen. In non-overlapped I/O a thread does not block. I chose non-overlapped I/O to avoid thread blocking at the OS level - instead, the thread blocking is kept in Java. -Adrian On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > Adrian, > > had a look at your code/rewrite and it looks rather clean/nice. > > I was looking at the code to gain insight (not related to the > rewrite) into what is involved in serial port programming > in Windows. Or rather, to refresh my memory and see how others have > done, because I've been there done that. > > So my questions are just to satisfy my curiosity, not to criticize > or suggest improvements. > > 1) It looks like a new thread (EventMonitor) is created for > each Serial port, is that correct? > > Many people seem to try to avoid using many threads in this sort > of situation, and like to use something like unix select(). > I personally find using threads more natural and better impedance > match to the problem being solved here. I guess 'many people' above > > refers to those implementing thousands of connections and > who cannot live with the overhead and limited number of threads > available. > > 2) The EventMonitor basically polls for events at 50 msec interval? > > 3) There is a comment in the source code near the sleep(50) : > > // Sufficient up to 19200 baud > > > I'm sure you thought about this carefully, so again not > criticizing, but seeking to understand how or why, because > at 50 msec would seem to limit through in some cases. Like > if you send one byte and need to wait for one to return, > then this limits speed to 200 chars/sec? > > 4) I've done something similar to a few years back from > Java using JNI to access Win32 API serial port, and > I seem to recall that I had threading issues ie when > I submitted a read (ReadFile) and there was no data coming > in, the thread would not only block but also consume a > lot of CPU cycles ie it was not sleeping properly inside > the ReadFile call when the serial port blocked. > > Im a bit fuzzy about the details after five years, so my question is > have you checked if there an issue here? > > > 5) AFAIK the select() on Windows does not work serial ports > but there is some other mechanism (events?) to implement the > same functionality, did you consider that? Probably, so you > decided against it, why? > > > br Kusti > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Tue Mar 1 04:25:23 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:25:23 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C2E90.9010601@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > My question would be: Why would you do that? The rewrite does > most of the work for you - all you have to do is implement > two C++ virtual classes and two C++ functions. You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? I just took a short look, maybe it could be discussed further, but I don't think I like it much. BTW, the main interface defined there is called gnu.io.Dispatcher? I thought the package names should be used in a way to avoid clashes, e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name space authority :)). > In Windows that took me a few hours. where is the implementation? I found commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp with things like const bool SerialPortImpl::isDataAvailable() const { // Needs implementation return true; } and timeouts.ReadIntervalTimeout = MAXDWORD;* timeouts.ReadTotalTimeoutMultiplier = 0; timeouts.ReadTotalTimeoutConstant = 0; timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 0; if (!SetCommTimeouts(hComm, &timeouts)) throw IOException(); which seems to be oversimplified or some prototype only? I think (and I wrote about this already in the past years) that correct timeout handling is one of the challenges, so I think this should be prototyped first - for each system flavor - before cementation of the (JNI-) interfaces. Personally, I would vote to form it in a way allowing to be implemented on embedded devices, for example. Another big challenge is to prove a rewrite fully working (and probably compatible to the old implementation) on "all" the supported OSes. Not a big problem for linux and windows, just use some thousand lines test code, test drivers and serial loopbacks etc, but for the exotic platforms, probably a high number of, this probably won't be too easy... (there are more challenges, such as being comfortable and threadsafe [are read and write permitted at the same time?], detailed and helpful exceptions on user API level [not necessarily on JNI/JNA layer], how to have a configurable threadsafe logging/tracing [maybe also from native code to assist porting / testing on exotic OSes, such as OSes where the developers have no direct access too, which can be quite hard to usually leads to good log messages], just to name a few.). So even it might seem easy for one platform and I agree with Micheal that > > * yay! let's start a rewrite is unlikely to succeede soon... However, when considering this, before IMHO a powerful Java API has to be defined, because according to my experiences for implementing non-trivial protocols InputStream/OutputStream might not be comfortable/powerfull enough (eventually I consider both wrong) and have some InputStream derivation available as wrapper (so applications can use InputStream and whatever high-level-API they want). The JNI interface shall make such a powerful implementation possible, thus the interface of it is driving the JNI interface design and thus I think it had to be done first. All this surely requires much work: agreements on the APIs, safeness for the users, design, documentation, all the implementations and the testing. As long as such bug amount of work cannot be spent, for example if some employee would get half a year time paid for it or so :-), probably it is unlikely to progress on this. Otherwise, I'm afraid, patches, improvements, new design ideas and even rewrites wouldn't become complete and thus won't form a new rxtx version (3.0); thus either collect dust in some forgotten CVS branch or could generate a split... > I can't imagine other ports taking > much longer than that - especially since POSIX-based code can > be shared between ports. Things are more complex than they seem to be... I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select on serial ports isn't supported; maybe it is non-trivial to "map" (like mapping select() to WaitForMultipleObjects() which might have different semantics etc.) or maybe some different approach has to be used. A system may have POSIX like termios interfaces but not support timeouts or have any other interoperability bug... You never run out of things that can go wrong. And if something can go wrong, it will... :-) Or, as Michael wrote: > > I seriously don't believe anyone will come up with anything better anytime soon. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue Mar 1 04:39:37 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:39:37 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com><13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED6B@COSNPREXC3.usr.ingenico.loc> > 3. Write all of the native (or non-native) code to implement > the native interface. > > Is that correct? If yes, how is that easier than the simple > implementation the current rewrite design uses? To have it complete, reliable, traceable, maintainable and well tested, it is much more work, I'm afraid. A prototype can be done within a few days (maybe on one day), but getting it right (including a passed review) IMHO is a completely different story. In the end you may end up with an average of ten lines per day, when assuming four major native packs (common, win, mac, termios/select) with let's say just 5000 lines each (with logging messages and detailed exceptions this is not much) we would have to estimate a total effort of nine man-years (20000/10/220)... oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 04:40:18 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:40:18 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6CDB22.9070401@sandglass-software.com> Every journey begins with a single step. -Adrian On 3/1/2011 3:25 AM, Steffen DETTMER wrote: > * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> My question would be: Why would you do that? The rewrite does >> most of the work for you - all you have to do is implement >> two C++ virtual classes and two C++ functions. > You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? > I just took a short look, maybe it could be discussed further, > but I don't think I like it much. > BTW, the main interface defined there is called gnu.io.Dispatcher? > I thought the package names should be used in a way to avoid clashes, > e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name > space authority :)). > >> In Windows that took me a few hours. > where is the implementation? > I found > commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp > with things like > > const bool SerialPortImpl::isDataAvailable() const > { > // Needs implementation > return true; > } > > and > > timeouts.ReadIntervalTimeout = MAXDWORD;* > timeouts.ReadTotalTimeoutMultiplier = 0; > timeouts.ReadTotalTimeoutConstant = 0; > timeouts.WriteTotalTimeoutMultiplier = 0; > timeouts.WriteTotalTimeoutConstant = 0; > if (!SetCommTimeouts(hComm,&timeouts)) > throw IOException(); > > which seems to be oversimplified or some prototype only? > > I think (and I wrote about this already in the past years) that correct > timeout handling is one of the challenges, so I think this should be > prototyped first - for each system flavor - before cementation of the > (JNI-) interfaces. Personally, I would vote to form it in a way allowing > to be implemented on embedded devices, for example. > > Another big challenge is to prove a rewrite fully working (and probably > compatible to the old implementation) on "all" the supported OSes. Not a > big problem for linux and windows, just use some thousand lines test > code, test drivers and serial loopbacks etc, but for the exotic > platforms, probably a high number of, this probably won't be too easy... > (there are more challenges, such as being comfortable and threadsafe > [are read and write permitted at the same time?], detailed and helpful > exceptions on user API level [not necessarily on JNI/JNA layer], how to > have a configurable threadsafe logging/tracing [maybe also from native > code to assist porting / testing on exotic OSes, such as OSes where the > developers have no direct access too, which can be quite hard to usually > leads to good log messages], just to name a few.). > > So even it might seem easy for one platform and I agree with Micheal > that > >>> * yay! let's start a rewrite > is unlikely to succeede soon... > > However, when considering this, before IMHO a powerful Java API has to > be defined, because according to my experiences for implementing > non-trivial protocols InputStream/OutputStream might not be > comfortable/powerfull enough (eventually I consider both wrong) and have > some InputStream derivation available as wrapper (so applications can > use InputStream and whatever high-level-API they want). > The JNI interface shall make such a powerful implementation possible, > thus the interface of it is driving the JNI interface design and thus I > think it had to be done first. > > All this surely requires much work: agreements on the APIs, safeness for > the users, design, documentation, all the implementations and the > testing. As long as such bug amount of work cannot be spent, for example > if some employee would get half a year time paid for it or so :-), > probably it is unlikely to progress on this. > > Otherwise, I'm afraid, patches, improvements, new design ideas and even > rewrites wouldn't become complete and thus won't form a new rxtx version > (3.0); thus either collect dust in some forgotten CVS branch or could > generate a split... > >> I can't imagine other ports taking >> much longer than that - especially since POSIX-based code can >> be shared between ports. > Things are more complex than they seem to be... > > I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select > on serial ports isn't supported; maybe it is non-trivial to "map" (like > mapping select() to WaitForMultipleObjects() which might have different > semantics etc.) or maybe some different approach has to be used. A > system may have POSIX like termios interfaces but not support timeouts > or have any other interoperability bug... > You never run out of things that can go wrong. And if something can go > wrong, it will... :-) > > Or, as Michael wrote: > >>> I seriously don't believe anyone will come up with anything better > anytime soon. > > oki, > > Steffen > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Kustaa.Nyholm at planmeca.com Tue Mar 1 04:57:02 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 13:57:02 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: On 3/1/11 13:13, "Adrian Crum" wrote: >The javax.comm API specification requires one event monitor thread per >port. I don't like the idea of having a thread per port either, but one >of the rewrite's design goals is strict conformance to the specification. Ah, had not spotted that requirement. > >The 50 mS polling interval is just a placeholder. The final design of >that is yet to be decided. > >In Windows, you have two choices for I/O: overlapped and non-overlapped. >In overlapped I/O a thread is blocked, waiting for something to happen. >In non-overlapped I/O a thread does not block. I chose non-overlapped >I/O to avoid thread blocking at the OS level - instead, the thread >blocking is kept in Java. > >-Adrian thanks for the explanation. br Kusti From iqzw2r602 at sneakemail.com Tue Mar 1 05:08:17 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:08:17 +1100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <32684-1298981297-704398@sneakemail.com> This reminds me of a nasty problem I had with overlapped I/O on windows with jpathwatch. You can't start an I/O request in one thread and then do the check if that request completed in another thread. Very strange things happen when you attempt that; made me change the design of the Windows implementation quite drastically (one thread on a command queue that executes requests from other threads instead of letting them wildly call into GetOverlappedResult()). Out of curiosity: Did you come across that too? Or are all requests handled in the same thread they're issued? Cheers, Uwe On Tue, Mar 1, 2011 at 10:13 PM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > The javax.comm API specification requires one event monitor thread per > port. I don't like the idea of having a thread per port either, but one of > the rewrite's design goals is strict conformance to the specification. > > The 50 mS polling interval is just a placeholder. The final design of that > is yet to be decided. > > In Windows, you have two choices for I/O: overlapped and non-overlapped. In > overlapped I/O a thread is blocked, waiting for something to happen. In > non-overlapped I/O a thread does not block. I chose non-overlapped I/O to > avoid thread blocking at the OS level - instead, the thread blocking is kept > in Java. > > -Adrian > > > On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > >> Adrian, >> >> had a look at your code/rewrite and it looks rather clean/nice. >> >> I was looking at the code to gain insight (not related to the >> rewrite) into what is involved in serial port programming >> in Windows. Or rather, to refresh my memory and see how others have >> done, because I've been there done that. >> >> So my questions are just to satisfy my curiosity, not to criticize >> or suggest improvements. >> >> 1) It looks like a new thread (EventMonitor) is created for >> each Serial port, is that correct? >> >> Many people seem to try to avoid using many threads in this sort >> of situation, and like to use something like unix select(). >> I personally find using threads more natural and better impedance >> match to the problem being solved here. I guess 'many people' above >> >> refers to those implementing thousands of connections and >> who cannot live with the overhead and limited number of threads >> available. >> >> 2) The EventMonitor basically polls for events at 50 msec interval? >> >> 3) There is a comment in the source code near the sleep(50) : >> >> // Sufficient up to 19200 baud >> >> >> I'm sure you thought about this carefully, so again not >> criticizing, but seeking to understand how or why, because >> at 50 msec would seem to limit through in some cases. Like >> if you send one byte and need to wait for one to return, >> then this limits speed to 200 chars/sec? >> >> 4) I've done something similar to a few years back from >> Java using JNI to access Win32 API serial port, and >> I seem to recall that I had threading issues ie when >> I submitted a read (ReadFile) and there was no data coming >> in, the thread would not only block but also consume a >> lot of CPU cycles ie it was not sleeping properly inside >> the ReadFile call when the serial port blocked. >> >> Im a bit fuzzy about the details after five years, so my question is >> have you checked if there an issue here? >> >> >> 5) AFAIK the select() on Windows does not work serial ports >> but there is some other mechanism (events?) to implement the >> same functionality, did you consider that? Probably, so you >> decided against it, why? >> >> >> br Kusti >> >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 05:37:07 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:37:07 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <1142-1298983027-957144@sneakemail.com> On Tue, Mar 1, 2011 at 1:32 PM, Adrian Crum wrote: > Just to make sure I'm understanding you correctly, anyone porting RxTx to > a new platform would have to do the following: > > 1. Write their own Java implementation of an abstract Dispatcher class. > yep. I'd probably put all my calls to native OS wrappers in there two, looks the most straight-forward to me. > 2. Write a native (JNI or JNA) interface for the abstract class > implementation. > yes. For POSIX you'd probably only write one piece of code that provides implementations for open(), close(), and friends. You can compile that on all posix platforms (yeah, the devil is in the detail, but it's very little code, still). So this does open() (when using ***, but you can also use +++) // Unix.java class Unix{ public static native int open(String filename, int flags, int mode); .... } // Unix.cpp JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) { const char* pathname = env->GetStringUTFChars(jpathname, 0); if(pathname == 0) return -1; // java throws an out of memory error in this case int result = open(pathname, flags, mode); Unix_cacheErrno(); // handle interference between JVM and errno; env->ReleaseStringUTFChars(jpathname, pathname); return result; } .... 3. Write all of the native (or non-native) code to implement the native > interface. > Not sure what you mean by that. I've done the OS wrappers in step 2. step 1. implements that Dispatcher. What else do I need? > Is that correct? If yes, how is that easier than the simple implementation > the current rewrite design uses? > Yes, except for 3 (see above). How it is easier: I can debug the Java code directly. I can step from the read() call of an input stream directly into the guts of the RXTX implementation on my platform and see e.g. why it's hanging, because I see all the way up the call stack right where it calls Unix.read(). You can't easily do that with a fat native library, especially if you have no second set of devtools installed (the ones for native development). And I bet anyone knowing both languages can write it faster in Java, with less bugs. > On a side note: there is no requirement to write native code using C++. If > C++ is a real obstacle to adoption, then regular C could be used instead. In > that case, there would be a Dispatcher.c file that contains function > protoypes that need to be implemented. Dispatcher.c would still maintain the > same role as Dispatcher.cpp - which is to shield native code developers from > the details of JNI. Just build out the missing functions using C data types > and you're ready to go. > As I said, whatever works for you. Java works for me better than C++ in this case... Cheers, Uwe -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Mar 1 08:26:41 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 16:26:41 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> > The javax.comm API specification requires one event monitor > thread per port. Where does it require this? Do you mean "All the events received by this listener are generated by one dedicated thread that belongs to the SerialPort object. "? I think this is an implementation detail, isn't it? At least it is mentioned after "The current implementation only allows one listener per SerialPort". A bit bad that javadoc does not distinguish between API spec and implementation documentation. Also I don't think that TooManyListenersException MUST be thrown (I think it CAN be thrown). > I don't like the idea of having a thread per > port either, but one of the rewrite's design goals is strict > conformance to the specification. (but not necessarily on JNI layer) > The 50 mS polling interval is just a placeholder. The final > design of that is yet to be decided. I though no polling would be wanted; what could be the placeholder stand for? Do you mean a different interval duration or do you mean something completely different? > In Windows, you have two choices for I/O: overlapped and > non-overlapped. > In overlapped I/O a thread is blocked, waiting for something > to happen. > In non-overlapped I/O a thread does not block. I chose > non-overlapped I/O to avoid thread blocking at the OS level - > instead, the thread blocking is kept in Java. Isn't "overlapped" (asynchronous) I/O meaning that you invoke some ReadFile(..., &overlapped, ...) INSTEAD of performing a synchronous (blocking) function call blocking the thread? As far as I see, W32_Support.cpp uses CreateFile without FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O operations are serialized, even if the calls to the read and write functions specify an OVERLAPPED structure." [1] and "A synchronous handle behaves such that I/O function calls using that handle are blocked until they complete" [2] Given that CCOMTIMEOUTS get: "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the bytes that have already been received, even if no bytes have been received." [3] It looks likes this implementation relies on polling, which probably would waste much computing power. What did I miss? oki, Steffen [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro nous_and_asynchronous_i_o_handles [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 09:23:47 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:23:47 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6D1D93.6090306@sandglass-software.com> Unfortunately, the javax.comm API specification includes a lot of implementation details. That is one of the weaknesses of the specification in my opinion. The bottom line is, anyone wanting to use RxTx as a javax.comm implementation is going to expect it to do the things the specification says it does. -Adrian On 3/1/2011 7:26 AM, Steffen DETTMER wrote: >> The javax.comm API specification requires one event monitor >> thread per port. > Where does it require this? > > Do you mean "All the events received by this listener are generated > by one dedicated thread that belongs to the SerialPort object. "? > > I think this is an implementation detail, isn't it? At least it is > mentioned after "The current implementation only allows one listener per > SerialPort". A bit bad that javadoc does not distinguish between API > spec and implementation documentation. Also I don't think that > TooManyListenersException MUST be thrown (I think it CAN be thrown). > >> I don't like the idea of having a thread per >> port either, but one of the rewrite's design goals is strict >> conformance to the specification. > (but not necessarily on JNI layer) > >> The 50 mS polling interval is just a placeholder. The final >> design of that is yet to be decided. > I though no polling would be wanted; what could be the placeholder stand > for? Do you mean a different interval duration or do you mean something > completely different? > >> In Windows, you have two choices for I/O: overlapped and >> non-overlapped. >> In overlapped I/O a thread is blocked, waiting for something >> to happen. >> In non-overlapped I/O a thread does not block. I chose >> non-overlapped I/O to avoid thread blocking at the OS level - >> instead, the thread blocking is kept in Java. > Isn't "overlapped" (asynchronous) I/O meaning that you invoke some > ReadFile(...,&overlapped, ...) > INSTEAD of performing a synchronous (blocking) function call blocking > the thread? > > As far as I see, W32_Support.cpp uses CreateFile without > FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O > operations are serialized, even if the calls to the read and write > functions specify an OVERLAPPED structure." [1] and "A synchronous > handle behaves such that I/O function calls using that handle are > blocked until they complete" [2] > > Given that CCOMTIMEOUTS get: > "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values > for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier > members, specifies that the read operation is to return immediately with > the bytes that have already been received, even if no bytes have been > received." [3] > > It looks likes this implementation relies on polling, which probably > would waste much computing power. > > What did I miss? > > oki, > > Steffen > > [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx > [2] > http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro > nous_and_asynchronous_i_o_handles > [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at sandglass-software.com Tue Mar 1 09:55:29 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:55:29 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <1142-1298983027-957144@sneakemail.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> Message-ID: <4D6D2501.1020803@sandglass-software.com> That code duplicates what is in Dispatcher.cpp. A Unix port would only need to implement CommPortFactory::getInstance(portName, portType). -Adrian On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 15:07:46 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 2 Mar 2011 09:07:46 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6D2501.1020803@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> <4D6D2501.1020803@sandglass-software.com> Message-ID: <23749-1299017266-991798@sneakemail.com> What is this duplicating? A Unix port will need to call open() anyways (just so we're talking about the same thing here: open() is the Unix equivalent of CreateFile()) On Wed, Mar 2, 2011 at 3:55 AM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > That code duplicates what is in Dispatcher.cpp. A Unix port would only > need to implement CommPortFactory::getInstance(portName, portType). > > -Adrian > > > On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Tue Mar 1 22:53:07 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 00:53:07 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: Hi, I haven't seen any response to my question below. Is this not the right place to ask? If not, where would be a better place to ask? Any suggestions? Thanks, Ryan On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >> Hi, >> >> I have a receive thread that does nothing but call read() on the serial >> port input stream. It works fine for a while but after running for a long >> time it eventually returns -1 which means EOF. This is my first problem, as >> the device I'm talking to runs forever, I don't know why it would return -1. >> I am calling disableReceiveThreshold() and disableReceiveTimeout() at >> initialization which according to the documentation means read will return >> as soon as any data is available and it will block forever when data is not >> available, so -1 should never be returned from read, right? >> >> I have been unable to figure out why read returns -1 after a long while >> but I have found that if I kill my application and restart it everything >> works fine again. Therefore I tried to work around the problem by having my >> code close the port and reopen it when read returns -1. My second problem is >> that in this case when I call close() on the port it blocks forever. I did >> find this old bug >> >> http://bugzilla.qbang.org/show_bug.cgi?id=53 >> >> which describes close() hanging on OSX, but it says that bug was fixed >> with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have >> any idea why read might be returning -1 in the first place? If I can avoid >> that I don't care about close() hanging because I would never close the >> port. If not, does anyone know why close() might block forever and how I can >> prevent this? I'm using RXTX version 2.1-7. >> >> Thanks, >> -- >> Ryan >> >> > > > -- > Ryan Boder > 1 614 598-6339 > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Mar 2 01:34:48 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 2 Mar 2011 10:34:48 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/2/11 07:53, "Ryan Boder" wrote: Can you / have you made a simple test to ensure that rxtx is the issue? Can you write a simple C-program to see if this exhibits the same problem? I've never encountered this sort of problem with rxtx, it mostly just works. But I'm on Mac so can't say about Windows (7) br Kusti >Hi, > >I haven't seen any response to my question below. Is this not the right >place to ask? If not, where would be a better place to ask? Any >suggestions? > >Thanks, >Ryan > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > >I mis-spoke, I don't have my own thread calling read, I am calling >read in the event handler after receiving a >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be >accurate though. > >Ryan > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >Hi, > >I have a receive thread that does nothing but call read() on the serial >port input stream. It works fine for a while but after running for a long >time it eventually returns -1 which means EOF. This is my first problem, >as the device I'm talking to runs forever, I don't know why it would >return -1. I am calling disableReceiveThreshold() and >disableReceiveTimeout() at initialization which according to the >documentation means read will return as soon as any data is available and >it will block forever when data is not available, so -1 should never be >returned from read, right? > >I have been unable to figure out why read returns -1 after a long while >but I have found that if I kill my application and restart it everything >works fine again. Therefore I tried to work around the problem by having >my code close the port and reopen it when read returns -1. My second >problem is that in this case when I call close() on the port it blocks >forever. I did find this old bug > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > >which describes close() hanging on OSX, but it says that bug was fixed >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone >have any idea why read might be returning -1 in the first place? If I can >avoid that I don't care about close() hanging because I would never close >the port. If not, does anyone know why close() might block forever and >how I can prevent this? I'm using RXTX version 2.1-7. > >Thanks, >-- >Ryan > > > > > > > > > >-- >Ryan Boder >1 614 598-6339 > > > > > > >-- >Ryan Boder >1 614 598-6339 > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From Steffen.DETTMER at ingenico.com Wed Mar 2 03:08:57 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:08:57 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <32684-1298981297-704398@sneakemail.com> References: <4D6CD4DE.7040501@sandglass-software.com> <32684-1298981297-704398@sneakemail.com> Message-ID: <20110302100857.GB8030@elberon.bln.de.ingenico.com> * iqzw2r602 at sneakemail.com wrote on Tue, Mar 01, 2011 at 23:08 +1100: > This reminds me of a nasty problem I had with overlapped I/O on windows Yeah, those thousands of complex, difficult to use and exception-containing WinAPI is really hard to use... About strange effects on overlapped&multithreading, MSDN has: `the calling thread uses the GetOverlappedResult function or one of the wait functions' [1] also also mentiones I/O Completion Ports [2], and later continues: `If an application reuses OVERLAPPED structures on multiple threads and calls GetOverlappedResult with the bWait parameter set to TRUE, the application must ensure that the associated event is set before the application reuses the structure. This can be accomplished by using the WaitForSingleObject function after calling GetOverlappedResult to force the thread to wait until the operation completes. Note that the event object must be a manual-reset event object. If an autoreset event object is used, calling GetOverlappedResult with the bWait parameter set to TRUE causes the function to be blocked indefinitely.' also [1] oki, Steffen [1] http://msdn.microsoft.com/en-us/library/ms686358%28v=vs.85%29.aspx [2] http://msdn.microsoft.com/en-us/library/aa365198%28v=vs.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:15:11 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:15:11 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6D1D93.6090306@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> <4D6D1D93.6090306@sandglass-software.com> Message-ID: <20110302101511.GC8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 08:23 -0800: > Unfortunately, the javax.comm API specification includes a lot of > implementation details. That is one of the weaknesses of the > specification in my opinion. The bottom line is, anyone wanting to use > RxTx as a javax.comm implementation is going to expect it to do the > things the specification says it does. Yeah ok, but even then the implementation could check for the TooManyListenersException situations (if it really is required to support applications relying on that exception) but internally use just a single I/O thread waiting for events on any open file descriptors. Of course an implementation supporting all sort of concurrency could become quite complex (especially if open-read-close should work fast, I think would be difficult to implement, because a new file descriptors had to be added to the waitFor/select list, and who knows how systems behave here in detail...). oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:25:15 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:25:15 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6CDB22.9070401@sandglass-software.com> References: <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> <4D6CDB22.9070401@sandglass-software.com> Message-ID: <20110302102515.GD8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 03:40 -0800: > * from some older mail: > > My question would be: Why would you do that? The rewrite does > > most of the work for you - all you have to do is implement > > two C++ virtual classes and two C++ functions. > > > > In Windows that took me a few hours. > > Every journey begins with a single step. Yes, of course, but then it shouldn't be used as base for new effort estimations like `In Windows that took a few hours' ;-) (BTW, calling a single step `the rewrite' may sound a bit ambitious ;)) But of course a prototype demonstrating something can be really helpful, sure. I just wanted to tell that interfaces should be easy to use and powerful at the same time and may non-trivial initial considerations before starting to implement them. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From ryan.boder at gmail.com Wed Mar 2 18:44:35 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:44:35 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: While running the tests you requested I may have stumbled on the problem, I just don't know how to fix it. According to the documentation, if both the receive timeout and receive threshold are disabled then read() should block forever until data is available. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#getInputStream%28%29 On my system using RXTX read() is returning -1 when no data is available even though I have disabled both thresholds. The reason my program was running fine for a while without this problem showing up is that I was using the DATA_AVAILABLE event to be notified when data is available and only calling read() to read an entire frame whenever the DATA_AVAILABLE event occurred, until eventually my device (I'm guessing) probably took longer than normal to send the entire data frame and therefore I called read when no data was available and it returned -1. The following Java program demonstrates my problem, it returns -1 as soon as no data is available, even though I think it should block until data is available. import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; public class Main implements SerialPortEventListener { public static void main(String[] args) throws Exception { new Main().run(); } private void run() throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier("COM4"); SerialPort port = (SerialPort) portIdentifier.open(Main.class.getName(), 2000); port.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); port.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); port.disableReceiveThreshold(); port.disableReceiveTimeout(); BufferedInputStream in = new BufferedInputStream(port.getInputStream()); BufferedOutputStream out = new BufferedOutputStream(port.getOutputStream()); port.addEventListener(this); Thread.sleep(1000); out.write(new byte[] {0x02, 0x60}); out.flush(); while (true) { int x = in.read(); if (x == -1) { System.out.println("EOF"); Thread.sleep(1000000000); } String s = Integer.toHexString(x & 0xFF); if (s.length() == 1) s = "0" + s; System.out.print(s + " "); System.out.flush(); } } public void serialEvent(SerialPortEvent arg0) { System.out.println("Serial port event"); } } However, the follow C# program ran all day today without ever read ever returning -1, as I would expect. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.IO.Ports; using System.Threading; namespace RXTXReadTest1 { class Program { static void Main(string[] args) { new Program().run(); } private void run() { SerialPort port = new SerialPort("COM4", 19200, Parity.None, 8, StopBits.One); port.Open(); port.Write(new byte[] { 0x02, 0x60 }, 0, 2); while (true) { int x = port.ReadByte(); if (x == -1) { Console.WriteLine("EOF"); Thread.Sleep(1000000000); } String s = x.ToString("X"); if (s.Length == 1 ) s = "0" + s; Console.Out.Write(s + " "); Console.Out.Flush(); } } } } Now I am experimenting with what happens if I set the receive timeout to it's maximum value (apparently 1600ms) and only call read() when I am expecting data. Hopefully it will never be more than 1600ms late. This is still only a work around, not solving the problem. Am I doing something wrong in my code above or is RXTX retuning -1 when it should be blocking? Thanks, Ryan On Wed, Mar 2, 2011 at 3:34 AM, Kustaa Nyholm wrote: > On 3/2/11 07:53, "Ryan Boder" wrote: > Can you / have you made a simple test to ensure that rxtx is the issue? > > Can you write a simple C-program to see if this exhibits the same problem? > > I've never encountered this sort of problem with rxtx, it mostly just > works. > > But I'm on Mac so can't say about Windows (7) > > br Kusti > > > > > >Hi, > > > >I haven't seen any response to my question below. Is this not the right > >place to ask? If not, where would be a better place to ask? Any > >suggestions? > > > >Thanks, > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder > wrote: > > > >I mis-spoke, I don't have my own thread calling read, I am calling > >read in the event handler after receiving a > >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be > >accurate though. > > > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder > wrote: > > > >Hi, > > > >I have a receive thread that does nothing but call read() on the serial > >port input stream. It works fine for a while but after running for a long > >time it eventually returns -1 which means EOF. This is my first problem, > >as the device I'm talking to runs forever, I don't know why it would > >return -1. I am calling disableReceiveThreshold() and > >disableReceiveTimeout() at initialization which according to the > >documentation means read will return as soon as any data is available and > >it will block forever when data is not available, so -1 should never be > >returned from read, right? > > > >I have been unable to figure out why read returns -1 after a long while > >but I have found that if I kill my application and restart it everything > >works fine again. Therefore I tried to work around the problem by having > >my code close the port and reopen it when read returns -1. My second > >problem is that in this case when I call close() on the port it blocks > >forever. I did find this old bug > > > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > > > >which describes close() hanging on OSX, but it says that bug was fixed > >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone > >have any idea why read might be returning -1 in the first place? If I can > >avoid that I don't care about close() hanging because I would never close > >the port. If not, does anyone know why close() might block forever and > >how I can prevent this? I'm using RXTX version 2.1-7. > > > >Thanks, > >-- > >Ryan > > > > > > > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Wed Mar 2 18:46:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:46:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: <-1051064942000733580@unknownmsgid> References: <-1051064942000733580@unknownmsgid> Message-ID: It is USB and seems very reliable with the C# test program in my previous email. On Wed, Mar 2, 2011 at 6:58 PM, Bruce Griffith wrote: > How reliable is your serial port ? is it USB or Bluetooth? > > > > Bruce Griffith > > 303-532-4778 > > > > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On Behalf > Of *Ryan Boder > *Sent:* Tuesday, 01 March 2011 10:53 PM > *To:* rxtx at qbang.org > *Subject:* Re: [Rxtx] RXTX serial port read() returns -1 unexpectedly and > then blocks forever on close() > > > > Hi, > > I haven't seen any response to my question below. Is this not the right > place to ask? If not, where would be a better place to ask? Any suggestions? > > Thanks, > Ryan > > On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > > Hi, > > I have a receive thread that does nothing but call read() on the serial > port input stream. It works fine for a while but after running for a long > time it eventually returns -1 which means EOF. This is my first problem, as > the device I'm talking to runs forever, I don't know why it would return -1. > I am calling disableReceiveThreshold() and disableReceiveTimeout() at > initialization which according to the documentation means read will return > as soon as any data is available and it will block forever when data is not > available, so -1 should never be returned from read, right? > > I have been unable to figure out why read returns -1 after a long while but > I have found that if I kill my application and restart it everything works > fine again. Therefore I tried to work around the problem by having my code > close the port and reopen it when read returns -1. My second problem is that > in this case when I call close() on the port it blocks forever. I did find > this old bug > > http://bugzilla.qbang.org/show_bug.cgi?id=53 > > which describes close() hanging on OSX, but it says that bug was fixed with > a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have any > idea why read might be returning -1 in the first place? If I can avoid that > I don't care about close() hanging because I would never close the port. If > not, does anyone know why close() might block forever and how I can prevent > this? I'm using RXTX version 2.1-7. > > Thanks, > -- > Ryan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Mar 3 02:50:20 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 3 Mar 2011 09:50:20 +0000 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: So if -1 is unexpectedly returned from read, and we have demonstrated that your USB-serial adapter can actually causes this to happen in RXTX, why not just ignore the -1 value? What happens when you try this? As for a hang on close, are your closing your port from within your serial event handler? I know that this can cause some serious problems. Regards, Michael Erskine. From Kustaa.Nyholm at planmeca.com Thu Mar 3 03:39:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 12:39:34 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 03:44, "Ryan Boder" wrote: >While running the tests you requested I may have stumbled on the problem, >I just don't know how to fix it. According to the documentation, if both >the receive timeout and receive threshold are disabled then read() should >block forever until data is available. > >http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/re >ference/api/javax/comm/CommPort.html#getInputStream%28%29 > >On my system using RXTX read() is returning -1 when no data is available >even though I have disabled both thresholds. The reason my program was >running fine for a while without this problem showing up is that I was >using the DATA_AVAILABLE event to be notified when data is available and >only calling read() to read an entire frame whenever the DATA_AVAILABLE >event occurred, until eventually my device (I'm guessing) probably took >longer than normal to send the entire data frame and therefore I called >read when no data was available and it returned -1. As a workaround have you tried to perform another read() if it returns -1? The javadoc says (see getInputStream): "Note, however, that framing errors may cause the Timeout and Threshold values to complete prematurely without raising an exception." I read this as a hint that read might return even if no data is available. Because of the above and that read() can only return -1 or the byte received it would be somewhat logical to return -1 in case of framing error ? I'm not claiming that my interpretation of the specification, such as it is, is correct, just speculating that the behavior could be something like that. It might give you some more insight if you used the read(bytes[],int,int) method, because this can and will return 0 in case of timeout (and presumably might do so in case of framing error, maybe some other error condition too). That might allow you to handle or work around the problem in this case. You have not shown your complete code (no need) but your comments and the example makes me wonder if the code is otherwise as it should be, meaning are you assuming that when you get the DATA_AVAILABLE event all of your frame has arrived and that you can just blindly read it away from the input stream? That is not guaranteed of course. Also using read(), instead of read(bytes[],int,int), is not very efficient and might be masking other problems as mused above. BTE you can print a byte in hex with leading zeros more easily with: System.out.printf("%02X",x); br Kusti From ryan.boder at gmail.com Thu Mar 3 07:56:16 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:56:16 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 5:39 AM, Kustaa Nyholm wrote: > > As a workaround have you tried to perform another read() if it returns -1? > I tried that and it did work sometimes but not all the time. > > The javadoc says (see getInputStream): > > "Note, however, that framing errors may cause the Timeout and Threshold > values to complete prematurely without raising an exception." > > I read this as a hint that read might return even if no data is available. > > Because of the above and that read() can only return -1 or the byte > received > it would be somewhat logical to return -1 in case of framing error ? > > I'm not claiming that my interpretation of the specification, such as it > is, > is correct, just speculating that the behavior could be something like > that. > Receive framing is not enabled by default. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#enableReceiveFraming%28int%29 My choice of word might be misleading, when I said frame I just meant a contiguous message from the device. I am not enabling receive framing. Can you have a framing error when receive framing is disabled? > > It might give you some more insight if you used the read(bytes[],int,int) > method, because > this can and will return 0 in case of timeout (and presumably might do so > in case of framing > error, maybe some other error condition too). > > That might allow you to handle or work around the problem in this case. > > You have not shown your complete code (no need) but your comments and the > example > makes me wonder if the code is otherwise as it should be, meaning are you > assuming > that when you get the DATA_AVAILABLE event all of your frame has arrived > and that > you can just blindly read it away from the input stream? That is not > guaranteed of course. > I'm not assuming the entire message has arrived, I'm just assuming it either has arrived or will arrive soon which is why I'm using a (supposedly) blocking read(). > > Also using read(), instead of read(bytes[],int,int), is not very efficient > and > might be masking other problems as mused above. > True, I'm reading one byte at a time because I don't know how long the message will be until I read and parse some of it. I suppose I can use read(bytes[],int,int) once I figure out how long the message will be. > > BTE you can print a byte in hex with leading zeros more easily with: > > > System.out.printf("%02X",x); > I did it the dumb way in that test program so I could copy and paste the code from C# to Java without having to figure out how to do the same in C# which I'm not as familiar with. Thanks and BR, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 07:58:24 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:58:24 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: Yes I was doing the close in the serial event handler, I didn't realize that caused a problem. Thanks, I'll fix it. On Thu, Mar 3, 2011 at 4:50 AM, Michael Erskine wrote: > So if -1 is unexpectedly returned from read, and we have demonstrated > that your USB-serial adapter can actually causes this to happen in > RXTX, why not just ignore the -1 value? What happens when you try > this? As for a hang on close, are your closing your port from within > your serial event handler? I know that this can cause some serious > problems. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 11:48:20 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 13:48:20 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm wrote: > On 3/3/11 16:56, "Ryan Boder" wrote: > > > >I'm not assuming the entire message has arrived, I'm just assuming it > >either has arrived or will arrive soon which is why I'm using a > >(supposedly) blocking read(). > > > I've been giving this some further thought. > > It does not feel healthy to block without timeout, especially > from within a thread that is essentially internal to the rxtx. > > I've never done that, I always use a time out, read(byte[],int,int) > for the expected number of bytes, check how much I got and issue > more reads until I get everything. > > You have not described how your communication works so I'm only > speculating. > > If your device needs some response to send more bytes (from your > code it looks like this is not the case) then a missing byte > would block your read and prevent you from responding and > getting more data. But as said, looks like that is not the case. > > Anyway, if this was my problem, I would enable the timeout > and use read(byte[],int,int) and loop until I get what I need. > You are right, I should and will use a timeout. In fact, my program has been running flawlessly for 12 hours and the only change I made was to enable a timeout, no change in the logic at all. Without the timeout read() was returning -1 usually after it ran for an hour or two. I will change the code to make use of the timeout and handle it appropriately. It still seems to me that RXTX's behavior doesn't match the documentation when rx timeout and rx threshold are disabled read() should block until data is available instead of immediately returning -1. I don't believe that a framing error is occurring immediately every time data is not available causing read() to return -1. Especially since the C# test program above runs all day with no error and the Java program above runs all day with no error when a timeout is enabled. To me it seems like enabling the timeout is what is causing read() to block until data is available, even if only for 1600ms, and without the timeout read() is returning -1 immediately when it should be blocking. Thanks for all the help and best regards, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Thu Mar 3 13:02:30 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 22:02:30 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 20:48, "Ryan Boder" wrote: >On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm > wrote: > >On 3/3/11 16:56, "Ryan Boder" wrote: >> > >>I'm not assuming the entire message has arrived, I'm just assuming it >>either has arrived or will arrive soon which is why I'm using a >>(supposedly) blocking read(). > > > >I've been giving this some further thought. > >It does not feel healthy to block without timeout, especially >from within a thread that is essentially internal to the rxtx. > >I've never done that, I always use a time out, read(byte[],int,int) >for the expected number of bytes, check how much I got and issue >more reads until I get everything. > >You have not described how your communication works so I'm only >speculating. > >If your device needs some response to send more bytes (from your >code it looks like this is not the case) then a missing byte >would block your read and prevent you from responding and >getting more data. But as said, looks like that is not the case. > >Anyway, if this was my problem, I would enable the timeout >and use read(byte[],int,int) and loop until I get what I need. > > > > >You are right, I should and will use a timeout. In fact, my program has >been running flawlessly for 12 hours and the only change I made was to >enable a timeout, no change in the logic at all. Without the timeout >read() was returning -1 usually after it ran for an hour or two. I will >change the code to make use of the timeout and handle it appropriately. That's nice! > >It still seems to me that RXTX's behavior doesn't match the documentation >when rx timeout and rx threshold are disabled read() should block until >data is available instead of immediately returning -1. Yeah, it does look like bug. However this might be related to some Windows specific serial port issue. Years ago I had issues with JavaComm (not RxTx) where I did a blocking read and I had huge issues with my program consuming all resources. I curser the Sun and JavaComm and re-code my own SerialPort using JNI to access the Win32 API directly. And I run into the same problems as with the Sun's implementation! So I ditched my code, changed my code to use timeouts and problems disappeared. > I don't believe that a framing error is occurring immediately every time >data is not available causing read() to return -1. Especially since the >C# test program above runs all day with no error and the Java program >above runs all day with no error when a timeout is enabled. I think so too, all things considered I don't really believe in framing errors in this case. > To me it seems like enabling the timeout is what is causing read() to >block until data is available, even if only for 1600ms, and without the >timeout read() is returning -1 immediately when it should be blocking. Yeah, I had a peek at the innards of RxTx Windows serial port a week or so ago and also read MSDN documentation about serial ports and the way overlapped and non-overlapped (non blocking and blocking) IO is handled is a way different. So yeah, it can well be that there is an issue lurking there somewhere inside RxTx in Windows. > > >Thanks for all the help and best regards, >-- >Ryan Boder I'm happy if I was of any assistance. br Kusti From tjarvi at qbang.org Thu Mar 3 18:52:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Mar 2011 18:52:50 -0700 (MST) Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: >> Without the timeout >> read() was returning -1 usually after it ran for an hour or two. There is a big hammer in rxtx causing that behavior. >> It still seems to me that RXTX's behavior doesn't match the documentation >> when rx timeout and rx threshold are disabled read() should block until >> data is available instead of immediately returning -1. > > Yeah, it does look like bug. However this might be related to some > Windows specific serial port issue. Years ago I had issues with > JavaComm (not RxTx) where I did a blocking read and I had huge > issues with my program consuming all resources. I curser the Sun > and JavaComm and re-code my own SerialPort using JNI to access > the Win32 API directly. And I run into the same problems as > with the Sun's implementation! So I ditched my code, changed > my code to use timeouts and problems disappeared. > > >> To me it seems like enabling the timeout is what is causing read() to >> block until data is available, even if only for 1600ms, and without the >> timeout read() is returning -1 immediately when it should be blocking. > > Yeah, I had a peek at the innards of RxTx Windows serial port a week > or so ago and also read MSDN documentation about serial ports and > the way overlapped and non-overlapped (non blocking and blocking) > IO is handled is a way different. So yeah, it can well be that > there is an issue lurking there somewhere inside RxTx in Windows. > > Yes. RXTX was patched to behave the way it does. I don't fully understand the issue behind the patch. Marc noticed the odd behavior as well and offered a fix which was greeted with resistance. The windows implementation was done without real documentatino of the windows API. I think I had an example from the late 80's early 90's on Microsoft's site and some API documentation that was obviously not microsofts in Europe. Wayne Roberts had a real need for windows support and fixed some major issues it had. My interest at the time was mingw32. I then cleaned it up for some specific uses I had later. The read returning -1 when it should block didn't impact anybody and appeared to help some people. It isnt the documented behavior though. There could be all sorts of latent bugs in that code but in the real world, it gets by in almost all use cases. Its a hack but it worked for 100's of thousands of people over a 14 year period. Maybe its time to revisit the code but there is more risk than gain for most people. How do you move forward and avoid the risk? Some have expressed interests in coding C++ or other efforts. I'm all for such efforts but feel some unit tests that work with a null modem cables are the only thing that will move rxtx (and perhaps CommAPI) forward. If we have a test suite in place as a qualification for implementations, progress can be made in the right direction regardless of the implementation details. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Fri Mar 4 02:57:16 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 4 Mar 2011 11:57:16 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/4/11 03:52, "Trent Jarvi" wrote: >Yes. RXTX was patched to behave the way it does. I don't fully >understand the issue behind the patch. Marc noticed the odd behavior as >well and offered a fix which was greeted with resistance. > >The windows implementation was done without real documentatino of the >windows API. I think I had an example from the late 80's early 90's on >Microsoft's site and some API documentation that was obviously not >microsofts in Europe. Wayne Roberts had a real need for windows support >and fixed some major issues it had. My interest at the time was mingw32. >I then cleaned it up for some specific uses I had later. The read >returning -1 when it should block didn't impact anybody and appeared to >help some people. It isnt the documented behavior though. > >There could be all sorts of latent bugs in that code but in the real >world, it gets by in almost all use cases. I think so too, never had any problems with it. > Its a hack but it worked for 100's of thousands of people over a 14 year >period. Yeah! Thanks for everyone who has contributed over the years, job well done! >Maybe its time to >revisit the code but there is more risk than gain for most people. How >do >you move forward and avoid the risk? My view is that it is quite risky and rather pointless to move forward, other than fixing bugs that really affect people. At the moment the major issue IMO is just that it seems (not been following this too carefully, so maybe I'm wrong, so in case this FUD, my apologies) that 'official' binaries are not available. I think the rewrite, tempting as it is in some respects is not the way forward. Just gentle maintenance to iron out real issues and then get the binaries out. br Kusti From ryan.boder at gmail.com Fri Mar 4 07:24:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Fri, 4 Mar 2011 09:24:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 8:52 PM, Trent Jarvi wrote: > > The windows implementation was done without real documentatino of the > windows API. I think I had an example from the late 80's early 90's on > Microsoft's site and some API documentation that was obviously not > microsofts in Europe. Wayne Roberts had a real need for windows support and > fixed some major issues it had. My interest at the time was mingw32. I then > cleaned it up for some specific uses I had later. The read returning -1 > when it should block didn't impact anybody and appeared to help some people. > It isnt the documented behavior though. > > There could be all sorts of latent bugs in that code but in the real world, > it gets by in almost all use cases. Its a hack but it worked for 100's of > thousands of people over a 14 year period. Maybe its time to revisit the > code but there is more risk than gain for most people. How do you move > forward and avoid the risk? > The safest and easiest solution would be to add a javadoc comment to disableReceiveTimeout explaining the difference between the RXTX behavior and Sunacle's documented behavior so that when someone uses the method in an IDE like Eclipse a little box would pop up informing them. Generating javadoc HTML and hosting it on the RXTX website would go a long way too, when something behaves differently than I expect the first thing I do is look for the javadoc online. -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From kharrington at neuronrobotics.com Mon Mar 7 10:47:26 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 12:47:26 -0500 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! Message-ID: Hey all, this is just a heads up that i have made a fork of rxtxSerial. Some of the features we have added: * Self deployment of native libraries ( all native code is stored inside the jar and deployed at runtime). No more manual install of native code. * Arm Cortex support (Gumstix) * Android Support (requires a rooted phone for now) * Google Code (SVN) repository for easy code and jar access * Single makefile compile (simplifies the compilation of project binaries) * Ant build script for jar creation * Removal of partialy implemented code to streamline the lib for just serial port access * Full Eclipse integration, for testing application code against sources. And a bunch of bug fixes: * Fixed the memory access error that causes OSX to crash the JVM when serial.close() is cvalled * Fixed the windows serial port zombie bind that prevents re-accessing serial ports when exiting on an exception * Fixed erronious printouts of native library mis-match To check it out, take a look at our page here: http://code.google.com/p/nrjavaserial/ From Kustaa.Nyholm at planmeca.com Mon Mar 7 11:46:26 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Mar 2011 20:46:26 +0200 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: Message-ID: On 3/7/11 19:47, "Kevin Harrington NR" wrote: >Hey all, this is just a heads up that i have made a fork of >rxtxSerial. Some of the features we have added great! If also does what it says on the tin: brilliant! Congrats and thanks. br Kusti From jmsachs at gmail.com Mon Mar 7 12:50:33 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 14:50:33 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: > From: Kevin Harrington NR > To: rxtx at qbang.org > Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > Hey all, this is just a heads up that i have made a fork of > rxtxSerial. Some of the features we have added: > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with a ten-foot pole. From Kustaa.Nyholm at planmeca.com Mon Mar 7 13:10:43 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Mar 2011 22:10:43 +0200 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: Message-ID: On 3/7/11 21:50, "Jason Sachs" wrote: > >Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >a ten-foot pole. >_______________________________________________ Oh crap, makes it useless for me and many others. Also I see no provision in RxTx license to change it so how could anyone change it to GPLv3? br Kusti From showard314 at gmail.com Mon Mar 7 13:24:08 2011 From: showard314 at gmail.com (Scott Howard) Date: Mon, 7 Mar 2011 15:24:08 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 3:10 PM, Kustaa Nyholm wrote: > Also I see no provision in RxTx license to change > it so how could anyone change it to GPLv3? I think this is allowed: 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. From jmsachs at gmail.com Mon Mar 7 13:24:47 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 15:24:47 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 2:50 PM, Jason Sachs wrote: >> From: Kevin Harrington NR >> To: rxtx at qbang.org >> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> > > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with > a ten-foot pole. > Let me back up a second (perhaps to make up for my lack of diplomacy) and state that I think any progress w/ rxtx is good. If an rxtx fork were LGPL (or some other non-spreading open source license) and leading in a good direction, I'd gladly return the favor by posting any improvements or bugfixes I found to the community. --Jason From jmsachs at gmail.com Mon Mar 7 13:36:13 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 15:36:13 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: Kevin: could you clarify the license? http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java has the RXTX 2.1 license (LGPL v 2.1 + Linking Over Controlled Interface.) but http://code.google.com/p/nrjavaserial/ says GPLv3. --Jason From kharrington at neuronrobotics.com Mon Mar 7 14:00:02 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 16:00:02 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: The one downside to google code is that it does not allow custom licensing. You have to pick from a drop-down list. Treat the licences on the files themselves as the licence to be concerned with, and ignore the "project licence". Sorry for the confusion. On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: > Kevin: could you clarify the license? > > http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java > has the RXTX 2.1 license > (LGPL v 2.1 + Linking Over Controlled Interface.) > > but http://code.google.com/p/nrjavaserial/ says GPLv3. > > --Jason > From iqzw2r602 at sneakemail.com Mon Mar 7 14:08:18 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 8 Mar 2011 08:08:18 +1100 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: References: Message-ID: <11253-1299532098-811882@sneakemail.com> Nice! Out of curiosity, did you use the patch that I sent Trent about two years ago to do the native library loading, or did you implement your own solution? Cheers, Uwe On Tue, Mar 8, 2011 at 5:46 AM, Kustaa Nyholm Kustaa.Nyholm-at-planmeca.com| rxtx.org mailing list/Example Allow| wrote: > On 3/7/11 19:47, "Kevin Harrington NR" > wrote: > > >Hey all, this is just a heads up that i have made a fork of > >rxtxSerial. Some of the features we have added > > > > great! If also does what it says on the tin: brilliant! > > Congrats and thanks. > > br Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aawolfe at gmail.com Mon Mar 7 15:31:47 2011 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 7 Mar 2011 17:31:47 -0500 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR wrote: > Hey all, this is just a heads up that i have made a fork of > rxtxSerial. Some of the features we have added: > > * Self deployment of native libraries ( all native code is stored > inside the jar and deployed at runtime). No more manual install of > native code. > * Arm Cortex support (Gumstix) > * Android Support (requires a rooted phone for now) > * Google Code (SVN) repository for easy code and jar access > * Single makefile compile (simplifies the compilation of project binaries) > * Ant build script for jar creation > * Removal of partialy implemented code to streamline the lib for just > serial port access > * Full Eclipse integration, for testing application code against sources. > > And a bunch of bug fixes: > > * Fixed the memory access error that causes OSX to crash the JVM when > serial.close() is cvalled > * Fixed the windows serial port zombie bind that prevents re-accessing > serial ports when exiting on an exception > * Fixed erronious printouts of native library mis-match > > To check it out, take a look at our page here: > > http://code.google.com/p/nrjavaserial/ This is interesting, getting the native libs set up has been an issue for some of my users. Will have to check it out. Out of curiosity, what Android devices provide a serial port? Or are there some that allow USB host mode and then a usb-serial adapter? I have only an Android cell phone, don't think it can do anything serial but would love to be wrong about that. From jfh at greenhousepc.com Mon Mar 7 15:54:39 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 15:54:39 -0700 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! Message-ID: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Mon Mar 7 16:53:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Mar 2011 16:53:50 -0700 (MST) Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: Hi Kevin, Until Google fixes the options as developers have requested, I'd suggest the least misleading dropdown option is "Other Open Source" with a clarification about LGPL 2.1 on the project page. If you are not supporting the CommAPI SPI interface that was available prior to the current JSR so that applications work in the javax.comm namespace, there is no need for the linking over controlled interfaces exception. RXTX 2.0 is used in that fashion but RXTX 2.1 is not. The exception explicitly states it can be removed if the source has been modified. The license is then explicitly OSI reviewed and approved as Google requests but is not in their drop down box as it should be and is for the GPL v2. http://opensource.org/licenses/alphabetical http://opensource.org/licenses/lgpl-2.1 The drawback would be that the library effectively could never be used in that SPI/controlled interface fashion again. On Mon, 7 Mar 2011, Kevin Harrington NR wrote: > The one downside to google code is that it does not allow custom > licensing. You have to pick from a drop-down list. Treat the licences > on the files themselves as the licence to be concerned with, and > ignore the "project licence". Sorry for the confusion. > > On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >> Kevin: could you clarify the license? >> >> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >> has the RXTX 2.1 license >> (LGPL v 2.1 + Linking Over Controlled Interface.) >> >> but http://code.google.com/p/nrjavaserial/ says GPLv3. >> >> --Jason >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From hakcenter at gmail.com Mon Mar 7 18:55:57 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 17:55:57 -0800 Subject: [Rxtx] Latency Woes Message-ID: <4D758CAD.2010602@gmail.com> I have finally deduced my slow data logging to a latency issue. I write software for dsms, and the protocol is request / receive, you cannot do more than 1 sensor at a time. So when you log multiple sensors, +20ms per item, sampling rate drops like a rock. I was wondering if there is any ideas besides going completely native with my application to reduce latency. With or without events I don't care at this point I need to kill as much of the latency as possible. Realistically I need no more than 1ms. From adrian.crum at sandglass-software.com Mon Mar 7 19:08:21 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Mon, 07 Mar 2011 18:08:21 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D758CAD.2010602@gmail.com> References: <4D758CAD.2010602@gmail.com> Message-ID: <4D758F95.90800@sandglass-software.com> Drop the requests into a queue, and then have a separate thread service the queue. -Adrian On 3/7/2011 5:55 PM, Curtis Hacker wrote: > I have finally deduced my slow data logging to a latency issue. > > I write software for dsms, and the protocol is request / receive, you > cannot do more than 1 sensor at a time. So when you log multiple > sensors, +20ms per item, sampling rate drops like a rock. > > I was wondering if there is any ideas besides going completely native > with my application to reduce latency. With or without events I don't > care at this point I need to kill as much of the latency as possible. > Realistically I need no more than 1ms. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From hakcenter at gmail.com Mon Mar 7 19:24:16 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 18:24:16 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D758F95.90800@sandglass-software.com> References: <4D758CAD.2010602@gmail.com> <4D758F95.90800@sandglass-software.com> Message-ID: <4D759350.8060402@gmail.com> Sample code ? I don't necessarily want to read the byte I just wrote, but wait till the que depth is 2. Setup a thread without a sleep timer: if (in.available() > 1) { do_stuff(); } ?? On 03/07/11 18:08, Adrian Crum wrote: > Drop the requests into a queue, and then have a separate thread > service the queue. > > -Adrian > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: >> I have finally deduced my slow data logging to a latency issue. >> >> I write software for dsms, and the protocol is request / receive, you >> cannot do more than 1 sensor at a time. So when you log multiple >> sensors, +20ms per item, sampling rate drops like a rock. >> >> I was wondering if there is any ideas besides going completely native >> with my application to reduce latency. With or without events I don't >> care at this point I need to kill as much of the latency as possible. >> Realistically I need no more than 1ms. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adrian.crum at sandglass-software.com Mon Mar 7 19:46:02 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Mon, 07 Mar 2011 18:46:02 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D759350.8060402@gmail.com> References: <4D758CAD.2010602@gmail.com> <4D758F95.90800@sandglass-software.com> <4D759350.8060402@gmail.com> Message-ID: <4D75986A.6020003@sandglass-software.com> http://download.oracle.com/javase/tutorial/essential/concurrency/executors.html -Adrian On 3/7/2011 6:24 PM, Curtis Hacker wrote: > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: >> Drop the requests into a queue, and then have a separate thread >> service the queue. >> >> -Adrian >> >> On 3/7/2011 5:55 PM, Curtis Hacker wrote: >>> I have finally deduced my slow data logging to a latency issue. >>> >>> I write software for dsms, and the protocol is request / receive, >>> you cannot do more than 1 sensor at a time. So when you log multiple >>> sensors, +20ms per item, sampling rate drops like a rock. >>> >>> I was wondering if there is any ideas besides going completely >>> native with my application to reduce latency. With or without events >>> I don't care at this point I need to kill as much of the latency as >>> possible. Realistically I need no more than 1ms. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Mon Mar 7 19:50:45 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 19:50:45 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Mon Mar 7 20:04:01 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 19:04:01 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> Message-ID: <4D759CA1.8010903@gmail.com> I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. in.read(data, 0, 2); ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? On 03/07/11 18:50, jfh at greenhousepc.com wrote: > Curtis, > > No, I assume he means a real queue, not just "don't read all the bytes > at once." However, if you know you can process some number of > requests in some amount of time, allowing data to pile up (receiver > FIFO space permitting) can be a valid strategy. Inserting gobs of > Thread.yield() and notify() can help pep things up as well. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Mon, March 07, 2011 8:24 pm > To: rxtx at qbang.org > > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: > > Drop the requests into a queue, and then have a separate thread > > service the queue. > > > > -Adrian > > > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: > >> I have finally deduced my slow data logging to a latency issue. > >> > >> I write software for dsms, and the protocol is request / > receive, you > >> cannot do more than 1 sensor at a time. So when you log multiple > >> sensors, +20ms per item, sampling rate drops like a rock. > >> > >> I was wondering if there is any ideas besides going completely > native > >> with my application to reduce latency. With or without events I > don't > >> care at this point I need to kill as much of the latency as > possible. > >> Realistically I need no more than 1ms. > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From bartley at cmu.edu Mon Mar 7 20:08:05 2011 From: bartley at cmu.edu (Chris Bartley) Date: Mon, 7 Mar 2011 22:08:05 -0500 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> Message-ID: <9B1804F9-DBD0-476D-9345-806D00065A97@cmu.edu> We use a queue for all our request/response serial communications, and have found it really easy to work with. Code is here: http://code.google.com/p/create-lab-commons/source/browse/trunk/java/code/serial/src/edu/cmu/ri/createlab/serial/SerialPortCommandExecutionQueue.java It's assuming a command & response scheme that's specific to the protocol we use to talk to our robots, but it should be easy to modify for your needs. Hope this helps. Let me know if you have questions. Chris On Mar 7, 2011, at 9:50 PM, wrote: > Curtis, > > No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > Date: Mon, March 07, 2011 8:24 pm > To: rxtx at qbang.org > > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: > > Drop the requests into a queue, and then have a separate thread > > service the queue. > > > > -Adrian > > > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: > >> I have finally deduced my slow data logging to a latency issue. > >> > >> I write software for dsms, and the protocol is request / receive, you > >> cannot do more than 1 sensor at a time. So when you log multiple > >> sensors, +20ms per item, sampling rate drops like a rock. > >> > >> I was wondering if there is any ideas besides going completely native > >> with my application to reduce latency. With or without events I don't > >> care at this point I need to kill as much of the latency as possible. > >> Realistically I need no more than 1ms. > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Mon Mar 7 20:51:17 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 20:51:17 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110307205116.8ef0e5b4a80cef441275a6330ffad77d.9b325137d1.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From kharrington at neuronrobotics.com Mon Mar 7 20:55:23 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 22:55:23 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 7 In-Reply-To: References: Message-ID: To answer a few of you, I have changed the license to "Other open source license" as suggested. My company is modifying and maintaining this fork to support our robotics development library (http://code.google.com/p/nr-sdk/ http://dev.neuronrobotics.com). We will be implementing the standard serial port interface only, as it is the only one we need or care about. As for where the implementation came from, i would have to refer to my other developer to answer that. I wrote the build scripts and make files, as well as streamlining the C build process. I have remover the configure script, as it ends up being more confusing then compiling 3 C files needs to be. if you guys want to bring any of this into the main line, that's cool, but up to you to port over. Our fork will be focusing on polishing up the serial interface,and hopefully making it faster. I hope some of you will find our improvements useful! On Mon, Mar 7, 2011 at 6:53 PM, wrote: > Send Rxtx mailing list submissions to > ? ? ? ?rxtx at qbang.org > > To subscribe or unsubscribe via the World Wide Web, visit > ? ? ? ?http://mailman.qbang.org/mailman/listinfo/rxtx > or, via email, send a message with subject or body 'help' to > ? ? ? ?rxtx-request at qbang.org > > You can reach the person managing the list at > ? ? ? ?rxtx-owner at qbang.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Rxtx digest..." > > > Today's Topics: > > ? 1. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 2. Re: Rxtx Digest, Vol 43, Issue 6 (Kustaa Nyholm) > ? 3. Re: Rxtx Digest, Vol 43, Issue 6 (Scott Howard) > ? 4. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 5. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 6. Re: Rxtx Digest, Vol 43, Issue 6 (Kevin Harrington NR) > ? 7. Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! > ? ? ?(iqzw2r602 at sneakemail.com) > ? 8. Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! > ? ? ?(Aaron Wolfe) > ? 9. Re: [SPAM] Re: ?NRJavaSerial, a fork of rxtx that fixes the > ? ? ?papercuts! (jfh at greenhousepc.com) > ?10. Re: Rxtx Digest, Vol 43, Issue 6 (Trent Jarvi) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 7 Mar 2011 14:50:33 -0500 > From: Jason Sachs > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > >> From: Kevin Harrington NR >> To: rxtx at qbang.org >> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> > > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with > a ten-foot pole. > > > ------------------------------ > > Message: 2 > Date: Mon, 7 Mar 2011 22:10:43 +0200 > From: Kustaa Nyholm > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > On 3/7/11 21:50, "Jason Sachs" wrote: >> >>Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >>a ten-foot pole. >>_______________________________________________ > > Oh crap, makes it useless for me and many others. > > Also I see no provision in RxTx license to change > it so how could anyone change it to GPLv3? > > br Kusti > > > > ------------------------------ > > Message: 3 > Date: Mon, 7 Mar 2011 15:24:08 -0500 > From: Scott Howard > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 3:10 PM, Kustaa Nyholm > wrote: >> Also I see no provision in RxTx license to change >> it so how could anyone change it to GPLv3? > > I think this is allowed: > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. ?To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. ?(If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) ?Do not make any other change in > these notices. > > ? Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > ? This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > > ------------------------------ > > Message: 4 > Date: Mon, 7 Mar 2011 15:24:47 -0500 > From: Jason Sachs > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 2:50 PM, Jason Sachs wrote: >>> From: Kevin Harrington NR >>> To: rxtx at qbang.org >>> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >>> Message-ID: >>> ? ? ? ? >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> Hey all, this is just a heads up that i have made a fork of >>> rxtxSerial. Some of the features we have added: >>> >> >> Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >> a ten-foot pole. >> > > Let me back up a second (perhaps to make up for my lack of diplomacy) > and state that I think any progress w/ rxtx is good. > > If an rxtx fork were LGPL (or some other non-spreading open source > license) and leading in a good direction, I'd gladly return the favor > by posting any improvements or bugfixes I found to the community. > > --Jason > > > ------------------------------ > > Message: 5 > Date: Mon, 7 Mar 2011 15:36:13 -0500 > From: Jason Sachs > To: rxtx at qbang.org, kharrington at neuronrobotics.com > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > Kevin: could you clarify the license? > > http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java > has the RXTX 2.1 license > (LGPL v 2.1 + Linking Over Controlled Interface.) > > but http://code.google.com/p/nrjavaserial/ says GPLv3. > > --Jason > > > ------------------------------ > > Message: 6 > Date: Mon, 7 Mar 2011 16:00:02 -0500 > From: Kevin Harrington NR > To: Jason Sachs > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > The one downside to google code is that it does not allow custom > licensing. You have to pick from a drop-down list. Treat the licences > on the files themselves as the licence to be concerned with, and > ignore the "project licence". Sorry for the confusion. > > On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >> Kevin: could you clarify the license? >> >> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >> has the RXTX 2.1 license >> (LGPL v 2.1 + Linking Over Controlled Interface.) >> >> but http://code.google.com/p/nrjavaserial/ says GPLv3. >> >> --Jason >> > > > ------------------------------ > > Message: 7 > Date: Tue, 8 Mar 2011 08:08:18 +1100 > From: iqzw2r602 at sneakemail.com > To: Rxtx at qbang.org > Subject: Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > ? ? ? ?papercuts! > Message-ID: <11253-1299532098-811882 at sneakemail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Nice! > > Out of curiosity, did you use the patch that I sent Trent about two years > ago to do the native library loading, or did you implement your own > solution? > > Cheers, > > Uwe > > On Tue, Mar 8, 2011 at 5:46 AM, Kustaa Nyholm Kustaa.Nyholm-at-planmeca.com| > rxtx.org mailing list/Example Allow| wrote: > >> On 3/7/11 19:47, "Kevin Harrington NR" >> wrote: >> >> >Hey all, this is just a heads up that i have made a fork of >> >rxtxSerial. Some of the features we have added >> >> >> >> great! If also does what it says on the tin: brilliant! >> >> Congrats and thanks. >> >> br Kusti >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 8 > Date: Mon, 7 Mar 2011 17:31:47 -0500 > From: Aaron Wolfe > To: rxtx at qbang.org > Subject: Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > ? ? ? ?papercuts! > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR > wrote: >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> >> * Self deployment of native libraries ( all native code is stored >> inside the jar and deployed at runtime). No more manual install of >> native code. >> * Arm Cortex support (Gumstix) >> * Android Support (requires a rooted phone for now) >> * Google Code (SVN) repository for easy code and jar access >> * Single makefile compile (simplifies the compilation of project binaries) >> * Ant build script for jar creation >> * Removal of partialy implemented code to streamline the lib for just >> serial port access >> * Full Eclipse integration, for testing application code against sources. >> >> And a bunch of bug fixes: >> >> * Fixed the memory access error that causes OSX to crash the JVM when >> serial.close() is cvalled >> * Fixed the windows serial port zombie bind that prevents re-accessing >> serial ports when exiting on an exception >> * Fixed erronious printouts of native library mis-match >> >> To check it out, take a look at our page here: >> >> http://code.google.com/p/nrjavaserial/ > > This is interesting, getting the native libs set up has been an issue > for some of my users. ?Will have to check it out. > > Out of curiosity, what Android devices provide a serial port? ?Or are > there some that allow USB host mode and then a usb-serial adapter? ?I > have only an Android cell phone, don't think it can do anything serial > but would love to be wrong about that. > > > ------------------------------ > > Message: 9 > Date: Mon, 07 Mar 2011 15:54:39 -0700 > From: > To: aaron at aaronwolfe.com, rxtx at qbang.org > Subject: Re: [Rxtx] [SPAM] Re: ?NRJavaSerial, a fork of rxtx that > ? ? ? ?fixes the papercuts! > Message-ID: > ? ? ? ?<20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe at email13.secureserver.net> > > Content-Type: text/plain; charset="us-ascii" > > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 10 > Date: Mon, 7 Mar 2011 16:53:50 -0700 (MST) > From: Trent Jarvi > To: rxtx at qbang.org > Cc: Jason Sachs > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > Hi Kevin, > > Until Google fixes the options as developers have requested, I'd suggest > the least misleading dropdown option is "Other Open Source" with a > clarification about LGPL 2.1 on the project page. > > If you are not supporting the CommAPI SPI interface that was available > prior to the current JSR so that applications work in the javax.comm > namespace, there is no need for the linking over controlled interfaces > exception. ?RXTX 2.0 is used in that fashion but RXTX 2.1 is not. ?The > exception explicitly states it can be removed if the source has been > modified. ?The license is then explicitly OSI reviewed and approved as > Google requests but is not in their drop down box as it should be and is > for the GPL v2. > > ? ? ? ?http://opensource.org/licenses/alphabetical > ? ? ? ?http://opensource.org/licenses/lgpl-2.1 > > The drawback would be that the library effectively could never be used in > that SPI/controlled interface fashion again. > > On Mon, 7 Mar 2011, Kevin Harrington NR wrote: > >> The one downside to google code is that it does not allow custom >> licensing. You have to pick from a drop-down list. Treat the licences >> on the files themselves as the licence to be concerned with, and >> ignore the "project licence". Sorry for the confusion. >> >> On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >>> Kevin: could you clarify the license? >>> >>> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >>> has the RXTX 2.1 license >>> (LGPL v 2.1 + Linking Over Controlled Interface.) >>> >>> but http://code.google.com/p/nrjavaserial/ says GPLv3. >>> >>> --Jason >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > ------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > End of Rxtx Digest, Vol 43, Issue 7 > *********************************** > From Kustaa.Nyholm at planmeca.com Mon Mar 7 21:43:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 8 Mar 2011 06:43:57 +0200 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307205116.8ef0e5b4a80cef441275a6330ffad77d.9b325137d1.wbe@email13.secureserver.net> Message-ID: On 3/8/11 05:51, "jfh at greenhousepc.com" wrote: >Curtis, > > >None of that is relevant, as long as the UART is reasonable and the code >implements a proper half duplex protocol. > >If I understand correctly, you send a byte, the sensor sends back two >bytes. So long as you don't send the next byte until the two bytes are >in the UART receiver FIFO, you're fine. You don't have to actually >=read= them, just know they are available. To the OP, are you using a serial USB port, like FTDI? This has a built in latency of 10ms ie nothing is actually sent out of the device if you send less than 64 bytes until 10 msec timeout. This has nothing to do with RxTx. If you search the list archives you'll find more about this issue and IIRC someone reported that there is some diver parameter you can tweak to get rid of that latency. I'm sure the FTDI people had a good reason for this but it really brings down the communication speed if your protocol uses short messages and need to wait for a response. Sorry if this has already been mentioned or if this is not relevant, I've not been paying attention to this thread. br Kusti From bob_jacobsen at lbl.gov Tue Mar 8 00:02:28 2011 From: bob_jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 8 Mar 2011 00:02:28 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D759CA1.8010903@gmail.com> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> Message-ID: If you're transferring three bytes total at 1953 baud, it's going to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to wait 20msec to get the data back instead of 15.4 msec doesn't seem to be as big a problem as you're making it sound. Bob On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. > > To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. > > So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. > > in.read(data, 0, 2); > ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? > > On 03/07/11 18:50, jfh at greenhousepc.com wrote: >> Curtis, >> >> No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker >> Date: Mon, March 07, 2011 8:24 pm >> To: rxtx at qbang.org >> >> Sample code ? >> >> I don't necessarily want to read the byte I just wrote, but wait till >> the que depth is 2. >> >> Setup a thread without a sleep timer: >> if (in.available() > 1) { >> do_stuff(); >> } >> >> ?? >> >> On 03/07/11 18:08, Adrian Crum wrote: >> > Drop the requests into a queue, and then have a separate thread >> > service the queue. >> > >> > -Adrian >> > >> > On 3/7/2011 5:55 PM, Curtis Hacker wrote: >> >> I have finally deduced my slow data logging to a latency issue. >> >> >> >> I write software for dsms, and the protocol is request / receive, you >> >> cannot do more than 1 sensor at a time. So when you log multiple >> >> sensors, +20ms per item, sampling rate drops like a rock. >> >> >> >> I was wondering if there is any ideas besides going completely native >> >> with my application to reduce latency. With or without events I don't >> >> care at this point I need to kill as much of the latency as possible. >> >> Realistically I need no more than 1ms. >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From hakcenter at gmail.com Tue Mar 8 01:33:24 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 00:33:24 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> Message-ID: <4D75E9D4.5090307@gmail.com> I am going to try a couple things today and hopefully figure something out. Bob I don't want to pop your bubble, but a native application named 'TunerPro' can sample the same data, over 30 sensors, in less than 25ms. I've exchanged some emails with the author and it is a native C, polling, no events just timeouts. Kusta thanks for the FTDI notice, I believe that is tunable, however I have a particular user using a Keyspan converter and verified sampling rate with 'TunerPro' and its just off the charts. Chris thank you, I'll look into the queing. On 03/07/11 23:02, Bob Jacobsen wrote: > If you're transferring three bytes total at 1953 baud, it's going to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to wait 20msec to get the data back instead of 15.4 msec doesn't seem to be as big a problem as you're making it sound. > > Bob > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > >> I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. >> >> To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. >> >> So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. >> >> in.read(data, 0, 2); >> ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? >> >> On 03/07/11 18:50, jfh at greenhousepc.com wrote: >>> Curtis, >>> >>> No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. >>> -- >>> Julie Haugh >>> Senior Design Engineer >>> greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype From msemtd at googlemail.com Tue Mar 8 01:50:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 8 Mar 2011 08:50:15 +0000 Subject: [Rxtx] Latency Woes In-Reply-To: <4D75E9D4.5090307@gmail.com> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> <4D75E9D4.5090307@gmail.com> Message-ID: On 8 March 2011 08:33, Curtis Hacker wrote: > I am going to try a couple things today and hopefully figure something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than 25ms. > I've exchanged some emails with the author and it is a native C, polling, no > events just timeouts. Perhaps the author of TunerPro will let you use his native code - sounds just what you need. Regards, Michael Erskine. From jfh at greenhousepc.com Tue Mar 8 04:00:18 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 04:00:18 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Mar 1 00:54:17 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 09:54:17 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> Message-ID: Adrian, had a look at your code/rewrite and it looks rather clean/nice. I was looking at the code to gain insight (not related to the rewrite) into what is involved in serial port programming in Windows. Or rather, to refresh my memory and see how others have done, because I've been there done that. So my questions are just to satisfy my curiosity, not to criticize or suggest improvements. 1) It looks like a new thread (EventMonitor) is created for each Serial port, is that correct? Many people seem to try to avoid using many threads in this sort of situation, and like to use something like unix select(). I personally find using threads more natural and better impedance match to the problem being solved here. I guess 'many people' above refers to those implementing thousands of connections and who cannot live with the overhead and limited number of threads available. 2) The EventMonitor basically polls for events at 50 msec interval? 3) There is a comment in the source code near the sleep(50) : // Sufficient up to 19200 baud I'm sure you thought about this carefully, so again not criticizing, but seeking to understand how or why, because at 50 msec would seem to limit through in some cases. Like if you send one byte and need to wait for one to return, then this limits speed to 200 chars/sec? 4) I've done something similar to a few years back from Java using JNI to access Win32 API serial port, and I seem to recall that I had threading issues ie when I submitted a read (ReadFile) and there was no data coming in, the thread would not only block but also consume a lot of CPU cycles ie it was not sleeping properly inside the ReadFile call when the serial port blocked. Im a bit fuzzy about the details after five years, so my question is have you checked if there an issue here? 5) AFAIK the select() on Windows does not work serial ports but there is some other mechanism (events?) to implement the same functionality, did you consider that? Probably, so you decided against it, why? br Kusti From adrian.crum at sandglass-software.com Tue Mar 1 04:13:34 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:13:34 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: References: Message-ID: <4D6CD4DE.7040501@sandglass-software.com> The javax.comm API specification requires one event monitor thread per port. I don't like the idea of having a thread per port either, but one of the rewrite's design goals is strict conformance to the specification. The 50 mS polling interval is just a placeholder. The final design of that is yet to be decided. In Windows, you have two choices for I/O: overlapped and non-overlapped. In overlapped I/O a thread is blocked, waiting for something to happen. In non-overlapped I/O a thread does not block. I chose non-overlapped I/O to avoid thread blocking at the OS level - instead, the thread blocking is kept in Java. -Adrian On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > Adrian, > > had a look at your code/rewrite and it looks rather clean/nice. > > I was looking at the code to gain insight (not related to the > rewrite) into what is involved in serial port programming > in Windows. Or rather, to refresh my memory and see how others have > done, because I've been there done that. > > So my questions are just to satisfy my curiosity, not to criticize > or suggest improvements. > > 1) It looks like a new thread (EventMonitor) is created for > each Serial port, is that correct? > > Many people seem to try to avoid using many threads in this sort > of situation, and like to use something like unix select(). > I personally find using threads more natural and better impedance > match to the problem being solved here. I guess 'many people' above > > refers to those implementing thousands of connections and > who cannot live with the overhead and limited number of threads > available. > > 2) The EventMonitor basically polls for events at 50 msec interval? > > 3) There is a comment in the source code near the sleep(50) : > > // Sufficient up to 19200 baud > > > I'm sure you thought about this carefully, so again not > criticizing, but seeking to understand how or why, because > at 50 msec would seem to limit through in some cases. Like > if you send one byte and need to wait for one to return, > then this limits speed to 200 chars/sec? > > 4) I've done something similar to a few years back from > Java using JNI to access Win32 API serial port, and > I seem to recall that I had threading issues ie when > I submitted a read (ReadFile) and there was no data coming > in, the thread would not only block but also consume a > lot of CPU cycles ie it was not sleeping properly inside > the ReadFile call when the serial port blocked. > > Im a bit fuzzy about the details after five years, so my question is > have you checked if there an issue here? > > > 5) AFAIK the select() on Windows does not work serial ports > but there is some other mechanism (events?) to implement the > same functionality, did you consider that? Probably, so you > decided against it, why? > > > br Kusti > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Tue Mar 1 04:25:23 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:25:23 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C2E90.9010601@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > My question would be: Why would you do that? The rewrite does > most of the work for you - all you have to do is implement > two C++ virtual classes and two C++ functions. You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? I just took a short look, maybe it could be discussed further, but I don't think I like it much. BTW, the main interface defined there is called gnu.io.Dispatcher? I thought the package names should be used in a way to avoid clashes, e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name space authority :)). > In Windows that took me a few hours. where is the implementation? I found commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp with things like const bool SerialPortImpl::isDataAvailable() const { // Needs implementation return true; } and timeouts.ReadIntervalTimeout = MAXDWORD;* timeouts.ReadTotalTimeoutMultiplier = 0; timeouts.ReadTotalTimeoutConstant = 0; timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 0; if (!SetCommTimeouts(hComm, &timeouts)) throw IOException(); which seems to be oversimplified or some prototype only? I think (and I wrote about this already in the past years) that correct timeout handling is one of the challenges, so I think this should be prototyped first - for each system flavor - before cementation of the (JNI-) interfaces. Personally, I would vote to form it in a way allowing to be implemented on embedded devices, for example. Another big challenge is to prove a rewrite fully working (and probably compatible to the old implementation) on "all" the supported OSes. Not a big problem for linux and windows, just use some thousand lines test code, test drivers and serial loopbacks etc, but for the exotic platforms, probably a high number of, this probably won't be too easy... (there are more challenges, such as being comfortable and threadsafe [are read and write permitted at the same time?], detailed and helpful exceptions on user API level [not necessarily on JNI/JNA layer], how to have a configurable threadsafe logging/tracing [maybe also from native code to assist porting / testing on exotic OSes, such as OSes where the developers have no direct access too, which can be quite hard to usually leads to good log messages], just to name a few.). So even it might seem easy for one platform and I agree with Micheal that > > * yay! let's start a rewrite is unlikely to succeede soon... However, when considering this, before IMHO a powerful Java API has to be defined, because according to my experiences for implementing non-trivial protocols InputStream/OutputStream might not be comfortable/powerfull enough (eventually I consider both wrong) and have some InputStream derivation available as wrapper (so applications can use InputStream and whatever high-level-API they want). The JNI interface shall make such a powerful implementation possible, thus the interface of it is driving the JNI interface design and thus I think it had to be done first. All this surely requires much work: agreements on the APIs, safeness for the users, design, documentation, all the implementations and the testing. As long as such bug amount of work cannot be spent, for example if some employee would get half a year time paid for it or so :-), probably it is unlikely to progress on this. Otherwise, I'm afraid, patches, improvements, new design ideas and even rewrites wouldn't become complete and thus won't form a new rxtx version (3.0); thus either collect dust in some forgotten CVS branch or could generate a split... > I can't imagine other ports taking > much longer than that - especially since POSIX-based code can > be shared between ports. Things are more complex than they seem to be... I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select on serial ports isn't supported; maybe it is non-trivial to "map" (like mapping select() to WaitForMultipleObjects() which might have different semantics etc.) or maybe some different approach has to be used. A system may have POSIX like termios interfaces but not support timeouts or have any other interoperability bug... You never run out of things that can go wrong. And if something can go wrong, it will... :-) Or, as Michael wrote: > > I seriously don't believe anyone will come up with anything better anytime soon. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue Mar 1 04:39:37 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:39:37 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com><13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED6B@COSNPREXC3.usr.ingenico.loc> > 3. Write all of the native (or non-native) code to implement > the native interface. > > Is that correct? If yes, how is that easier than the simple > implementation the current rewrite design uses? To have it complete, reliable, traceable, maintainable and well tested, it is much more work, I'm afraid. A prototype can be done within a few days (maybe on one day), but getting it right (including a passed review) IMHO is a completely different story. In the end you may end up with an average of ten lines per day, when assuming four major native packs (common, win, mac, termios/select) with let's say just 5000 lines each (with logging messages and detailed exceptions this is not much) we would have to estimate a total effort of nine man-years (20000/10/220)... oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 04:40:18 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:40:18 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6CDB22.9070401@sandglass-software.com> Every journey begins with a single step. -Adrian On 3/1/2011 3:25 AM, Steffen DETTMER wrote: > * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> My question would be: Why would you do that? The rewrite does >> most of the work for you - all you have to do is implement >> two C++ virtual classes and two C++ functions. > You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? > I just took a short look, maybe it could be discussed further, > but I don't think I like it much. > BTW, the main interface defined there is called gnu.io.Dispatcher? > I thought the package names should be used in a way to avoid clashes, > e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name > space authority :)). > >> In Windows that took me a few hours. > where is the implementation? > I found > commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp > with things like > > const bool SerialPortImpl::isDataAvailable() const > { > // Needs implementation > return true; > } > > and > > timeouts.ReadIntervalTimeout = MAXDWORD;* > timeouts.ReadTotalTimeoutMultiplier = 0; > timeouts.ReadTotalTimeoutConstant = 0; > timeouts.WriteTotalTimeoutMultiplier = 0; > timeouts.WriteTotalTimeoutConstant = 0; > if (!SetCommTimeouts(hComm,&timeouts)) > throw IOException(); > > which seems to be oversimplified or some prototype only? > > I think (and I wrote about this already in the past years) that correct > timeout handling is one of the challenges, so I think this should be > prototyped first - for each system flavor - before cementation of the > (JNI-) interfaces. Personally, I would vote to form it in a way allowing > to be implemented on embedded devices, for example. > > Another big challenge is to prove a rewrite fully working (and probably > compatible to the old implementation) on "all" the supported OSes. Not a > big problem for linux and windows, just use some thousand lines test > code, test drivers and serial loopbacks etc, but for the exotic > platforms, probably a high number of, this probably won't be too easy... > (there are more challenges, such as being comfortable and threadsafe > [are read and write permitted at the same time?], detailed and helpful > exceptions on user API level [not necessarily on JNI/JNA layer], how to > have a configurable threadsafe logging/tracing [maybe also from native > code to assist porting / testing on exotic OSes, such as OSes where the > developers have no direct access too, which can be quite hard to usually > leads to good log messages], just to name a few.). > > So even it might seem easy for one platform and I agree with Micheal > that > >>> * yay! let's start a rewrite > is unlikely to succeede soon... > > However, when considering this, before IMHO a powerful Java API has to > be defined, because according to my experiences for implementing > non-trivial protocols InputStream/OutputStream might not be > comfortable/powerfull enough (eventually I consider both wrong) and have > some InputStream derivation available as wrapper (so applications can > use InputStream and whatever high-level-API they want). > The JNI interface shall make such a powerful implementation possible, > thus the interface of it is driving the JNI interface design and thus I > think it had to be done first. > > All this surely requires much work: agreements on the APIs, safeness for > the users, design, documentation, all the implementations and the > testing. As long as such bug amount of work cannot be spent, for example > if some employee would get half a year time paid for it or so :-), > probably it is unlikely to progress on this. > > Otherwise, I'm afraid, patches, improvements, new design ideas and even > rewrites wouldn't become complete and thus won't form a new rxtx version > (3.0); thus either collect dust in some forgotten CVS branch or could > generate a split... > >> I can't imagine other ports taking >> much longer than that - especially since POSIX-based code can >> be shared between ports. > Things are more complex than they seem to be... > > I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select > on serial ports isn't supported; maybe it is non-trivial to "map" (like > mapping select() to WaitForMultipleObjects() which might have different > semantics etc.) or maybe some different approach has to be used. A > system may have POSIX like termios interfaces but not support timeouts > or have any other interoperability bug... > You never run out of things that can go wrong. And if something can go > wrong, it will... :-) > > Or, as Michael wrote: > >>> I seriously don't believe anyone will come up with anything better > anytime soon. > > oki, > > Steffen > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Kustaa.Nyholm at planmeca.com Tue Mar 1 04:57:02 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 13:57:02 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: On 3/1/11 13:13, "Adrian Crum" wrote: >The javax.comm API specification requires one event monitor thread per >port. I don't like the idea of having a thread per port either, but one >of the rewrite's design goals is strict conformance to the specification. Ah, had not spotted that requirement. > >The 50 mS polling interval is just a placeholder. The final design of >that is yet to be decided. > >In Windows, you have two choices for I/O: overlapped and non-overlapped. >In overlapped I/O a thread is blocked, waiting for something to happen. >In non-overlapped I/O a thread does not block. I chose non-overlapped >I/O to avoid thread blocking at the OS level - instead, the thread >blocking is kept in Java. > >-Adrian thanks for the explanation. br Kusti From iqzw2r602 at sneakemail.com Tue Mar 1 05:08:17 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:08:17 +1100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <32684-1298981297-704398@sneakemail.com> This reminds me of a nasty problem I had with overlapped I/O on windows with jpathwatch. You can't start an I/O request in one thread and then do the check if that request completed in another thread. Very strange things happen when you attempt that; made me change the design of the Windows implementation quite drastically (one thread on a command queue that executes requests from other threads instead of letting them wildly call into GetOverlappedResult()). Out of curiosity: Did you come across that too? Or are all requests handled in the same thread they're issued? Cheers, Uwe On Tue, Mar 1, 2011 at 10:13 PM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > The javax.comm API specification requires one event monitor thread per > port. I don't like the idea of having a thread per port either, but one of > the rewrite's design goals is strict conformance to the specification. > > The 50 mS polling interval is just a placeholder. The final design of that > is yet to be decided. > > In Windows, you have two choices for I/O: overlapped and non-overlapped. In > overlapped I/O a thread is blocked, waiting for something to happen. In > non-overlapped I/O a thread does not block. I chose non-overlapped I/O to > avoid thread blocking at the OS level - instead, the thread blocking is kept > in Java. > > -Adrian > > > On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > >> Adrian, >> >> had a look at your code/rewrite and it looks rather clean/nice. >> >> I was looking at the code to gain insight (not related to the >> rewrite) into what is involved in serial port programming >> in Windows. Or rather, to refresh my memory and see how others have >> done, because I've been there done that. >> >> So my questions are just to satisfy my curiosity, not to criticize >> or suggest improvements. >> >> 1) It looks like a new thread (EventMonitor) is created for >> each Serial port, is that correct? >> >> Many people seem to try to avoid using many threads in this sort >> of situation, and like to use something like unix select(). >> I personally find using threads more natural and better impedance >> match to the problem being solved here. I guess 'many people' above >> >> refers to those implementing thousands of connections and >> who cannot live with the overhead and limited number of threads >> available. >> >> 2) The EventMonitor basically polls for events at 50 msec interval? >> >> 3) There is a comment in the source code near the sleep(50) : >> >> // Sufficient up to 19200 baud >> >> >> I'm sure you thought about this carefully, so again not >> criticizing, but seeking to understand how or why, because >> at 50 msec would seem to limit through in some cases. Like >> if you send one byte and need to wait for one to return, >> then this limits speed to 200 chars/sec? >> >> 4) I've done something similar to a few years back from >> Java using JNI to access Win32 API serial port, and >> I seem to recall that I had threading issues ie when >> I submitted a read (ReadFile) and there was no data coming >> in, the thread would not only block but also consume a >> lot of CPU cycles ie it was not sleeping properly inside >> the ReadFile call when the serial port blocked. >> >> Im a bit fuzzy about the details after five years, so my question is >> have you checked if there an issue here? >> >> >> 5) AFAIK the select() on Windows does not work serial ports >> but there is some other mechanism (events?) to implement the >> same functionality, did you consider that? Probably, so you >> decided against it, why? >> >> >> br Kusti >> >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 05:37:07 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:37:07 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <1142-1298983027-957144@sneakemail.com> On Tue, Mar 1, 2011 at 1:32 PM, Adrian Crum wrote: > Just to make sure I'm understanding you correctly, anyone porting RxTx to > a new platform would have to do the following: > > 1. Write their own Java implementation of an abstract Dispatcher class. > yep. I'd probably put all my calls to native OS wrappers in there two, looks the most straight-forward to me. > 2. Write a native (JNI or JNA) interface for the abstract class > implementation. > yes. For POSIX you'd probably only write one piece of code that provides implementations for open(), close(), and friends. You can compile that on all posix platforms (yeah, the devil is in the detail, but it's very little code, still). So this does open() (when using ***, but you can also use +++) // Unix.java class Unix{ public static native int open(String filename, int flags, int mode); .... } // Unix.cpp JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) { const char* pathname = env->GetStringUTFChars(jpathname, 0); if(pathname == 0) return -1; // java throws an out of memory error in this case int result = open(pathname, flags, mode); Unix_cacheErrno(); // handle interference between JVM and errno; env->ReleaseStringUTFChars(jpathname, pathname); return result; } .... 3. Write all of the native (or non-native) code to implement the native > interface. > Not sure what you mean by that. I've done the OS wrappers in step 2. step 1. implements that Dispatcher. What else do I need? > Is that correct? If yes, how is that easier than the simple implementation > the current rewrite design uses? > Yes, except for 3 (see above). How it is easier: I can debug the Java code directly. I can step from the read() call of an input stream directly into the guts of the RXTX implementation on my platform and see e.g. why it's hanging, because I see all the way up the call stack right where it calls Unix.read(). You can't easily do that with a fat native library, especially if you have no second set of devtools installed (the ones for native development). And I bet anyone knowing both languages can write it faster in Java, with less bugs. > On a side note: there is no requirement to write native code using C++. If > C++ is a real obstacle to adoption, then regular C could be used instead. In > that case, there would be a Dispatcher.c file that contains function > protoypes that need to be implemented. Dispatcher.c would still maintain the > same role as Dispatcher.cpp - which is to shield native code developers from > the details of JNI. Just build out the missing functions using C data types > and you're ready to go. > As I said, whatever works for you. Java works for me better than C++ in this case... Cheers, Uwe -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Mar 1 08:26:41 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 16:26:41 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> > The javax.comm API specification requires one event monitor > thread per port. Where does it require this? Do you mean "All the events received by this listener are generated by one dedicated thread that belongs to the SerialPort object. "? I think this is an implementation detail, isn't it? At least it is mentioned after "The current implementation only allows one listener per SerialPort". A bit bad that javadoc does not distinguish between API spec and implementation documentation. Also I don't think that TooManyListenersException MUST be thrown (I think it CAN be thrown). > I don't like the idea of having a thread per > port either, but one of the rewrite's design goals is strict > conformance to the specification. (but not necessarily on JNI layer) > The 50 mS polling interval is just a placeholder. The final > design of that is yet to be decided. I though no polling would be wanted; what could be the placeholder stand for? Do you mean a different interval duration or do you mean something completely different? > In Windows, you have two choices for I/O: overlapped and > non-overlapped. > In overlapped I/O a thread is blocked, waiting for something > to happen. > In non-overlapped I/O a thread does not block. I chose > non-overlapped I/O to avoid thread blocking at the OS level - > instead, the thread blocking is kept in Java. Isn't "overlapped" (asynchronous) I/O meaning that you invoke some ReadFile(..., &overlapped, ...) INSTEAD of performing a synchronous (blocking) function call blocking the thread? As far as I see, W32_Support.cpp uses CreateFile without FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O operations are serialized, even if the calls to the read and write functions specify an OVERLAPPED structure." [1] and "A synchronous handle behaves such that I/O function calls using that handle are blocked until they complete" [2] Given that CCOMTIMEOUTS get: "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the bytes that have already been received, even if no bytes have been received." [3] It looks likes this implementation relies on polling, which probably would waste much computing power. What did I miss? oki, Steffen [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro nous_and_asynchronous_i_o_handles [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 09:23:47 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:23:47 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6D1D93.6090306@sandglass-software.com> Unfortunately, the javax.comm API specification includes a lot of implementation details. That is one of the weaknesses of the specification in my opinion. The bottom line is, anyone wanting to use RxTx as a javax.comm implementation is going to expect it to do the things the specification says it does. -Adrian On 3/1/2011 7:26 AM, Steffen DETTMER wrote: >> The javax.comm API specification requires one event monitor >> thread per port. > Where does it require this? > > Do you mean "All the events received by this listener are generated > by one dedicated thread that belongs to the SerialPort object. "? > > I think this is an implementation detail, isn't it? At least it is > mentioned after "The current implementation only allows one listener per > SerialPort". A bit bad that javadoc does not distinguish between API > spec and implementation documentation. Also I don't think that > TooManyListenersException MUST be thrown (I think it CAN be thrown). > >> I don't like the idea of having a thread per >> port either, but one of the rewrite's design goals is strict >> conformance to the specification. > (but not necessarily on JNI layer) > >> The 50 mS polling interval is just a placeholder. The final >> design of that is yet to be decided. > I though no polling would be wanted; what could be the placeholder stand > for? Do you mean a different interval duration or do you mean something > completely different? > >> In Windows, you have two choices for I/O: overlapped and >> non-overlapped. >> In overlapped I/O a thread is blocked, waiting for something >> to happen. >> In non-overlapped I/O a thread does not block. I chose >> non-overlapped I/O to avoid thread blocking at the OS level - >> instead, the thread blocking is kept in Java. > Isn't "overlapped" (asynchronous) I/O meaning that you invoke some > ReadFile(...,&overlapped, ...) > INSTEAD of performing a synchronous (blocking) function call blocking > the thread? > > As far as I see, W32_Support.cpp uses CreateFile without > FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O > operations are serialized, even if the calls to the read and write > functions specify an OVERLAPPED structure." [1] and "A synchronous > handle behaves such that I/O function calls using that handle are > blocked until they complete" [2] > > Given that CCOMTIMEOUTS get: > "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values > for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier > members, specifies that the read operation is to return immediately with > the bytes that have already been received, even if no bytes have been > received." [3] > > It looks likes this implementation relies on polling, which probably > would waste much computing power. > > What did I miss? > > oki, > > Steffen > > [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx > [2] > http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro > nous_and_asynchronous_i_o_handles > [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at sandglass-software.com Tue Mar 1 09:55:29 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:55:29 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <1142-1298983027-957144@sneakemail.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> Message-ID: <4D6D2501.1020803@sandglass-software.com> That code duplicates what is in Dispatcher.cpp. A Unix port would only need to implement CommPortFactory::getInstance(portName, portType). -Adrian On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 15:07:46 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 2 Mar 2011 09:07:46 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6D2501.1020803@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> <4D6D2501.1020803@sandglass-software.com> Message-ID: <23749-1299017266-991798@sneakemail.com> What is this duplicating? A Unix port will need to call open() anyways (just so we're talking about the same thing here: open() is the Unix equivalent of CreateFile()) On Wed, Mar 2, 2011 at 3:55 AM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > That code duplicates what is in Dispatcher.cpp. A Unix port would only > need to implement CommPortFactory::getInstance(portName, portType). > > -Adrian > > > On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Tue Mar 1 22:53:07 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 00:53:07 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: Hi, I haven't seen any response to my question below. Is this not the right place to ask? If not, where would be a better place to ask? Any suggestions? Thanks, Ryan On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >> Hi, >> >> I have a receive thread that does nothing but call read() on the serial >> port input stream. It works fine for a while but after running for a long >> time it eventually returns -1 which means EOF. This is my first problem, as >> the device I'm talking to runs forever, I don't know why it would return -1. >> I am calling disableReceiveThreshold() and disableReceiveTimeout() at >> initialization which according to the documentation means read will return >> as soon as any data is available and it will block forever when data is not >> available, so -1 should never be returned from read, right? >> >> I have been unable to figure out why read returns -1 after a long while >> but I have found that if I kill my application and restart it everything >> works fine again. Therefore I tried to work around the problem by having my >> code close the port and reopen it when read returns -1. My second problem is >> that in this case when I call close() on the port it blocks forever. I did >> find this old bug >> >> http://bugzilla.qbang.org/show_bug.cgi?id=53 >> >> which describes close() hanging on OSX, but it says that bug was fixed >> with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have >> any idea why read might be returning -1 in the first place? If I can avoid >> that I don't care about close() hanging because I would never close the >> port. If not, does anyone know why close() might block forever and how I can >> prevent this? I'm using RXTX version 2.1-7. >> >> Thanks, >> -- >> Ryan >> >> > > > -- > Ryan Boder > 1 614 598-6339 > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Mar 2 01:34:48 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 2 Mar 2011 10:34:48 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/2/11 07:53, "Ryan Boder" wrote: Can you / have you made a simple test to ensure that rxtx is the issue? Can you write a simple C-program to see if this exhibits the same problem? I've never encountered this sort of problem with rxtx, it mostly just works. But I'm on Mac so can't say about Windows (7) br Kusti >Hi, > >I haven't seen any response to my question below. Is this not the right >place to ask? If not, where would be a better place to ask? Any >suggestions? > >Thanks, >Ryan > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > >I mis-spoke, I don't have my own thread calling read, I am calling >read in the event handler after receiving a >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be >accurate though. > >Ryan > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >Hi, > >I have a receive thread that does nothing but call read() on the serial >port input stream. It works fine for a while but after running for a long >time it eventually returns -1 which means EOF. This is my first problem, >as the device I'm talking to runs forever, I don't know why it would >return -1. I am calling disableReceiveThreshold() and >disableReceiveTimeout() at initialization which according to the >documentation means read will return as soon as any data is available and >it will block forever when data is not available, so -1 should never be >returned from read, right? > >I have been unable to figure out why read returns -1 after a long while >but I have found that if I kill my application and restart it everything >works fine again. Therefore I tried to work around the problem by having >my code close the port and reopen it when read returns -1. My second >problem is that in this case when I call close() on the port it blocks >forever. I did find this old bug > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > >which describes close() hanging on OSX, but it says that bug was fixed >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone >have any idea why read might be returning -1 in the first place? If I can >avoid that I don't care about close() hanging because I would never close >the port. If not, does anyone know why close() might block forever and >how I can prevent this? I'm using RXTX version 2.1-7. > >Thanks, >-- >Ryan > > > > > > > > > >-- >Ryan Boder >1 614 598-6339 > > > > > > >-- >Ryan Boder >1 614 598-6339 > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From Steffen.DETTMER at ingenico.com Wed Mar 2 03:08:57 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:08:57 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <32684-1298981297-704398@sneakemail.com> References: <4D6CD4DE.7040501@sandglass-software.com> <32684-1298981297-704398@sneakemail.com> Message-ID: <20110302100857.GB8030@elberon.bln.de.ingenico.com> * iqzw2r602 at sneakemail.com wrote on Tue, Mar 01, 2011 at 23:08 +1100: > This reminds me of a nasty problem I had with overlapped I/O on windows Yeah, those thousands of complex, difficult to use and exception-containing WinAPI is really hard to use... About strange effects on overlapped&multithreading, MSDN has: `the calling thread uses the GetOverlappedResult function or one of the wait functions' [1] also also mentiones I/O Completion Ports [2], and later continues: `If an application reuses OVERLAPPED structures on multiple threads and calls GetOverlappedResult with the bWait parameter set to TRUE, the application must ensure that the associated event is set before the application reuses the structure. This can be accomplished by using the WaitForSingleObject function after calling GetOverlappedResult to force the thread to wait until the operation completes. Note that the event object must be a manual-reset event object. If an autoreset event object is used, calling GetOverlappedResult with the bWait parameter set to TRUE causes the function to be blocked indefinitely.' also [1] oki, Steffen [1] http://msdn.microsoft.com/en-us/library/ms686358%28v=vs.85%29.aspx [2] http://msdn.microsoft.com/en-us/library/aa365198%28v=vs.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:15:11 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:15:11 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6D1D93.6090306@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> <4D6D1D93.6090306@sandglass-software.com> Message-ID: <20110302101511.GC8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 08:23 -0800: > Unfortunately, the javax.comm API specification includes a lot of > implementation details. That is one of the weaknesses of the > specification in my opinion. The bottom line is, anyone wanting to use > RxTx as a javax.comm implementation is going to expect it to do the > things the specification says it does. Yeah ok, but even then the implementation could check for the TooManyListenersException situations (if it really is required to support applications relying on that exception) but internally use just a single I/O thread waiting for events on any open file descriptors. Of course an implementation supporting all sort of concurrency could become quite complex (especially if open-read-close should work fast, I think would be difficult to implement, because a new file descriptors had to be added to the waitFor/select list, and who knows how systems behave here in detail...). oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:25:15 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:25:15 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6CDB22.9070401@sandglass-software.com> References: <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> <4D6CDB22.9070401@sandglass-software.com> Message-ID: <20110302102515.GD8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 03:40 -0800: > * from some older mail: > > My question would be: Why would you do that? The rewrite does > > most of the work for you - all you have to do is implement > > two C++ virtual classes and two C++ functions. > > > > In Windows that took me a few hours. > > Every journey begins with a single step. Yes, of course, but then it shouldn't be used as base for new effort estimations like `In Windows that took a few hours' ;-) (BTW, calling a single step `the rewrite' may sound a bit ambitious ;)) But of course a prototype demonstrating something can be really helpful, sure. I just wanted to tell that interfaces should be easy to use and powerful at the same time and may non-trivial initial considerations before starting to implement them. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From ryan.boder at gmail.com Wed Mar 2 18:44:35 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:44:35 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: While running the tests you requested I may have stumbled on the problem, I just don't know how to fix it. According to the documentation, if both the receive timeout and receive threshold are disabled then read() should block forever until data is available. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#getInputStream%28%29 On my system using RXTX read() is returning -1 when no data is available even though I have disabled both thresholds. The reason my program was running fine for a while without this problem showing up is that I was using the DATA_AVAILABLE event to be notified when data is available and only calling read() to read an entire frame whenever the DATA_AVAILABLE event occurred, until eventually my device (I'm guessing) probably took longer than normal to send the entire data frame and therefore I called read when no data was available and it returned -1. The following Java program demonstrates my problem, it returns -1 as soon as no data is available, even though I think it should block until data is available. import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; public class Main implements SerialPortEventListener { public static void main(String[] args) throws Exception { new Main().run(); } private void run() throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier("COM4"); SerialPort port = (SerialPort) portIdentifier.open(Main.class.getName(), 2000); port.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); port.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); port.disableReceiveThreshold(); port.disableReceiveTimeout(); BufferedInputStream in = new BufferedInputStream(port.getInputStream()); BufferedOutputStream out = new BufferedOutputStream(port.getOutputStream()); port.addEventListener(this); Thread.sleep(1000); out.write(new byte[] {0x02, 0x60}); out.flush(); while (true) { int x = in.read(); if (x == -1) { System.out.println("EOF"); Thread.sleep(1000000000); } String s = Integer.toHexString(x & 0xFF); if (s.length() == 1) s = "0" + s; System.out.print(s + " "); System.out.flush(); } } public void serialEvent(SerialPortEvent arg0) { System.out.println("Serial port event"); } } However, the follow C# program ran all day today without ever read ever returning -1, as I would expect. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.IO.Ports; using System.Threading; namespace RXTXReadTest1 { class Program { static void Main(string[] args) { new Program().run(); } private void run() { SerialPort port = new SerialPort("COM4", 19200, Parity.None, 8, StopBits.One); port.Open(); port.Write(new byte[] { 0x02, 0x60 }, 0, 2); while (true) { int x = port.ReadByte(); if (x == -1) { Console.WriteLine("EOF"); Thread.Sleep(1000000000); } String s = x.ToString("X"); if (s.Length == 1 ) s = "0" + s; Console.Out.Write(s + " "); Console.Out.Flush(); } } } } Now I am experimenting with what happens if I set the receive timeout to it's maximum value (apparently 1600ms) and only call read() when I am expecting data. Hopefully it will never be more than 1600ms late. This is still only a work around, not solving the problem. Am I doing something wrong in my code above or is RXTX retuning -1 when it should be blocking? Thanks, Ryan On Wed, Mar 2, 2011 at 3:34 AM, Kustaa Nyholm wrote: > On 3/2/11 07:53, "Ryan Boder" wrote: > Can you / have you made a simple test to ensure that rxtx is the issue? > > Can you write a simple C-program to see if this exhibits the same problem? > > I've never encountered this sort of problem with rxtx, it mostly just > works. > > But I'm on Mac so can't say about Windows (7) > > br Kusti > > > > > >Hi, > > > >I haven't seen any response to my question below. Is this not the right > >place to ask? If not, where would be a better place to ask? Any > >suggestions? > > > >Thanks, > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder > wrote: > > > >I mis-spoke, I don't have my own thread calling read, I am calling > >read in the event handler after receiving a > >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be > >accurate though. > > > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder > wrote: > > > >Hi, > > > >I have a receive thread that does nothing but call read() on the serial > >port input stream. It works fine for a while but after running for a long > >time it eventually returns -1 which means EOF. This is my first problem, > >as the device I'm talking to runs forever, I don't know why it would > >return -1. I am calling disableReceiveThreshold() and > >disableReceiveTimeout() at initialization which according to the > >documentation means read will return as soon as any data is available and > >it will block forever when data is not available, so -1 should never be > >returned from read, right? > > > >I have been unable to figure out why read returns -1 after a long while > >but I have found that if I kill my application and restart it everything > >works fine again. Therefore I tried to work around the problem by having > >my code close the port and reopen it when read returns -1. My second > >problem is that in this case when I call close() on the port it blocks > >forever. I did find this old bug > > > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > > > >which describes close() hanging on OSX, but it says that bug was fixed > >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone > >have any idea why read might be returning -1 in the first place? If I can > >avoid that I don't care about close() hanging because I would never close > >the port. If not, does anyone know why close() might block forever and > >how I can prevent this? I'm using RXTX version 2.1-7. > > > >Thanks, > >-- > >Ryan > > > > > > > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Wed Mar 2 18:46:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:46:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: <-1051064942000733580@unknownmsgid> References: <-1051064942000733580@unknownmsgid> Message-ID: It is USB and seems very reliable with the C# test program in my previous email. On Wed, Mar 2, 2011 at 6:58 PM, Bruce Griffith wrote: > How reliable is your serial port ? is it USB or Bluetooth? > > > > Bruce Griffith > > 303-532-4778 > > > > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On Behalf > Of *Ryan Boder > *Sent:* Tuesday, 01 March 2011 10:53 PM > *To:* rxtx at qbang.org > *Subject:* Re: [Rxtx] RXTX serial port read() returns -1 unexpectedly and > then blocks forever on close() > > > > Hi, > > I haven't seen any response to my question below. Is this not the right > place to ask? If not, where would be a better place to ask? Any suggestions? > > Thanks, > Ryan > > On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > > Hi, > > I have a receive thread that does nothing but call read() on the serial > port input stream. It works fine for a while but after running for a long > time it eventually returns -1 which means EOF. This is my first problem, as > the device I'm talking to runs forever, I don't know why it would return -1. > I am calling disableReceiveThreshold() and disableReceiveTimeout() at > initialization which according to the documentation means read will return > as soon as any data is available and it will block forever when data is not > available, so -1 should never be returned from read, right? > > I have been unable to figure out why read returns -1 after a long while but > I have found that if I kill my application and restart it everything works > fine again. Therefore I tried to work around the problem by having my code > close the port and reopen it when read returns -1. My second problem is that > in this case when I call close() on the port it blocks forever. I did find > this old bug > > http://bugzilla.qbang.org/show_bug.cgi?id=53 > > which describes close() hanging on OSX, but it says that bug was fixed with > a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have any > idea why read might be returning -1 in the first place? If I can avoid that > I don't care about close() hanging because I would never close the port. If > not, does anyone know why close() might block forever and how I can prevent > this? I'm using RXTX version 2.1-7. > > Thanks, > -- > Ryan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Mar 3 02:50:20 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 3 Mar 2011 09:50:20 +0000 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: So if -1 is unexpectedly returned from read, and we have demonstrated that your USB-serial adapter can actually causes this to happen in RXTX, why not just ignore the -1 value? What happens when you try this? As for a hang on close, are your closing your port from within your serial event handler? I know that this can cause some serious problems. Regards, Michael Erskine. From Kustaa.Nyholm at planmeca.com Thu Mar 3 03:39:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 12:39:34 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 03:44, "Ryan Boder" wrote: >While running the tests you requested I may have stumbled on the problem, >I just don't know how to fix it. According to the documentation, if both >the receive timeout and receive threshold are disabled then read() should >block forever until data is available. > >http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/re >ference/api/javax/comm/CommPort.html#getInputStream%28%29 > >On my system using RXTX read() is returning -1 when no data is available >even though I have disabled both thresholds. The reason my program was >running fine for a while without this problem showing up is that I was >using the DATA_AVAILABLE event to be notified when data is available and >only calling read() to read an entire frame whenever the DATA_AVAILABLE >event occurred, until eventually my device (I'm guessing) probably took >longer than normal to send the entire data frame and therefore I called >read when no data was available and it returned -1. As a workaround have you tried to perform another read() if it returns -1? The javadoc says (see getInputStream): "Note, however, that framing errors may cause the Timeout and Threshold values to complete prematurely without raising an exception." I read this as a hint that read might return even if no data is available. Because of the above and that read() can only return -1 or the byte received it would be somewhat logical to return -1 in case of framing error ? I'm not claiming that my interpretation of the specification, such as it is, is correct, just speculating that the behavior could be something like that. It might give you some more insight if you used the read(bytes[],int,int) method, because this can and will return 0 in case of timeout (and presumably might do so in case of framing error, maybe some other error condition too). That might allow you to handle or work around the problem in this case. You have not shown your complete code (no need) but your comments and the example makes me wonder if the code is otherwise as it should be, meaning are you assuming that when you get the DATA_AVAILABLE event all of your frame has arrived and that you can just blindly read it away from the input stream? That is not guaranteed of course. Also using read(), instead of read(bytes[],int,int), is not very efficient and might be masking other problems as mused above. BTE you can print a byte in hex with leading zeros more easily with: System.out.printf("%02X",x); br Kusti From ryan.boder at gmail.com Thu Mar 3 07:56:16 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:56:16 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 5:39 AM, Kustaa Nyholm wrote: > > As a workaround have you tried to perform another read() if it returns -1? > I tried that and it did work sometimes but not all the time. > > The javadoc says (see getInputStream): > > "Note, however, that framing errors may cause the Timeout and Threshold > values to complete prematurely without raising an exception." > > I read this as a hint that read might return even if no data is available. > > Because of the above and that read() can only return -1 or the byte > received > it would be somewhat logical to return -1 in case of framing error ? > > I'm not claiming that my interpretation of the specification, such as it > is, > is correct, just speculating that the behavior could be something like > that. > Receive framing is not enabled by default. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#enableReceiveFraming%28int%29 My choice of word might be misleading, when I said frame I just meant a contiguous message from the device. I am not enabling receive framing. Can you have a framing error when receive framing is disabled? > > It might give you some more insight if you used the read(bytes[],int,int) > method, because > this can and will return 0 in case of timeout (and presumably might do so > in case of framing > error, maybe some other error condition too). > > That might allow you to handle or work around the problem in this case. > > You have not shown your complete code (no need) but your comments and the > example > makes me wonder if the code is otherwise as it should be, meaning are you > assuming > that when you get the DATA_AVAILABLE event all of your frame has arrived > and that > you can just blindly read it away from the input stream? That is not > guaranteed of course. > I'm not assuming the entire message has arrived, I'm just assuming it either has arrived or will arrive soon which is why I'm using a (supposedly) blocking read(). > > Also using read(), instead of read(bytes[],int,int), is not very efficient > and > might be masking other problems as mused above. > True, I'm reading one byte at a time because I don't know how long the message will be until I read and parse some of it. I suppose I can use read(bytes[],int,int) once I figure out how long the message will be. > > BTE you can print a byte in hex with leading zeros more easily with: > > > System.out.printf("%02X",x); > I did it the dumb way in that test program so I could copy and paste the code from C# to Java without having to figure out how to do the same in C# which I'm not as familiar with. Thanks and BR, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 07:58:24 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:58:24 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: Yes I was doing the close in the serial event handler, I didn't realize that caused a problem. Thanks, I'll fix it. On Thu, Mar 3, 2011 at 4:50 AM, Michael Erskine wrote: > So if -1 is unexpectedly returned from read, and we have demonstrated > that your USB-serial adapter can actually causes this to happen in > RXTX, why not just ignore the -1 value? What happens when you try > this? As for a hang on close, are your closing your port from within > your serial event handler? I know that this can cause some serious > problems. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 11:48:20 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 13:48:20 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm wrote: > On 3/3/11 16:56, "Ryan Boder" wrote: > > > >I'm not assuming the entire message has arrived, I'm just assuming it > >either has arrived or will arrive soon which is why I'm using a > >(supposedly) blocking read(). > > > I've been giving this some further thought. > > It does not feel healthy to block without timeout, especially > from within a thread that is essentially internal to the rxtx. > > I've never done that, I always use a time out, read(byte[],int,int) > for the expected number of bytes, check how much I got and issue > more reads until I get everything. > > You have not described how your communication works so I'm only > speculating. > > If your device needs some response to send more bytes (from your > code it looks like this is not the case) then a missing byte > would block your read and prevent you from responding and > getting more data. But as said, looks like that is not the case. > > Anyway, if this was my problem, I would enable the timeout > and use read(byte[],int,int) and loop until I get what I need. > You are right, I should and will use a timeout. In fact, my program has been running flawlessly for 12 hours and the only change I made was to enable a timeout, no change in the logic at all. Without the timeout read() was returning -1 usually after it ran for an hour or two. I will change the code to make use of the timeout and handle it appropriately. It still seems to me that RXTX's behavior doesn't match the documentation when rx timeout and rx threshold are disabled read() should block until data is available instead of immediately returning -1. I don't believe that a framing error is occurring immediately every time data is not available causing read() to return -1. Especially since the C# test program above runs all day with no error and the Java program above runs all day with no error when a timeout is enabled. To me it seems like enabling the timeout is what is causing read() to block until data is available, even if only for 1600ms, and without the timeout read() is returning -1 immediately when it should be blocking. Thanks for all the help and best regards, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Thu Mar 3 13:02:30 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 22:02:30 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 20:48, "Ryan Boder" wrote: >On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm > wrote: > >On 3/3/11 16:56, "Ryan Boder" wrote: >> > >>I'm not assuming the entire message has arrived, I'm just assuming it >>either has arrived or will arrive soon which is why I'm using a >>(supposedly) blocking read(). > > > >I've been giving this some further thought. > >It does not feel healthy to block without timeout, especially >from within a thread that is essentially internal to the rxtx. > >I've never done that, I always use a time out, read(byte[],int,int) >for the expected number of bytes, check how much I got and issue >more reads until I get everything. > >You have not described how your communication works so I'm only >speculating. > >If your device needs some response to send more bytes (from your >code it looks like this is not the case) then a missing byte >would block your read and prevent you from responding and >getting more data. But as said, looks like that is not the case. > >Anyway, if this was my problem, I would enable the timeout >and use read(byte[],int,int) and loop until I get what I need. > > > > >You are right, I should and will use a timeout. In fact, my program has >been running flawlessly for 12 hours and the only change I made was to >enable a timeout, no change in the logic at all. Without the timeout >read() was returning -1 usually after it ran for an hour or two. I will >change the code to make use of the timeout and handle it appropriately. That's nice! > >It still seems to me that RXTX's behavior doesn't match the documentation >when rx timeout and rx threshold are disabled read() should block until >data is available instead of immediately returning -1. Yeah, it does look like bug. However this might be related to some Windows specific serial port issue. Years ago I had issues with JavaComm (not RxTx) where I did a blocking read and I had huge issues with my program consuming all resources. I curser the Sun and JavaComm and re-code my own SerialPort using JNI to access the Win32 API directly. And I run into the same problems as with the Sun's implementation! So I ditched my code, changed my code to use timeouts and problems disappeared. > I don't believe that a framing error is occurring immediately every time >data is not available causing read() to return -1. Especially since the >C# test program above runs all day with no error and the Java program >above runs all day with no error when a timeout is enabled. I think so too, all things considered I don't really believe in framing errors in this case. > To me it seems like enabling the timeout is what is causing read() to >block until data is available, even if only for 1600ms, and without the >timeout read() is returning -1 immediately when it should be blocking. Yeah, I had a peek at the innards of RxTx Windows serial port a week or so ago and also read MSDN documentation about serial ports and the way overlapped and non-overlapped (non blocking and blocking) IO is handled is a way different. So yeah, it can well be that there is an issue lurking there somewhere inside RxTx in Windows. > > >Thanks for all the help and best regards, >-- >Ryan Boder I'm happy if I was of any assistance. br Kusti From tjarvi at qbang.org Thu Mar 3 18:52:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Mar 2011 18:52:50 -0700 (MST) Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: >> Without the timeout >> read() was returning -1 usually after it ran for an hour or two. There is a big hammer in rxtx causing that behavior. >> It still seems to me that RXTX's behavior doesn't match the documentation >> when rx timeout and rx threshold are disabled read() should block until >> data is available instead of immediately returning -1. > > Yeah, it does look like bug. However this might be related to some > Windows specific serial port issue. Years ago I had issues with > JavaComm (not RxTx) where I did a blocking read and I had huge > issues with my program consuming all resources. I curser the Sun > and JavaComm and re-code my own SerialPort using JNI to access > the Win32 API directly. And I run into the same problems as > with the Sun's implementation! So I ditched my code, changed > my code to use timeouts and problems disappeared. > > >> To me it seems like enabling the timeout is what is causing read() to >> block until data is available, even if only for 1600ms, and without the >> timeout read() is returning -1 immediately when it should be blocking. > > Yeah, I had a peek at the innards of RxTx Windows serial port a week > or so ago and also read MSDN documentation about serial ports and > the way overlapped and non-overlapped (non blocking and blocking) > IO is handled is a way different. So yeah, it can well be that > there is an issue lurking there somewhere inside RxTx in Windows. > > Yes. RXTX was patched to behave the way it does. I don't fully understand the issue behind the patch. Marc noticed the odd behavior as well and offered a fix which was greeted with resistance. The windows implementation was done without real documentatino of the windows API. I think I had an example from the late 80's early 90's on Microsoft's site and some API documentation that was obviously not microsofts in Europe. Wayne Roberts had a real need for windows support and fixed some major issues it had. My interest at the time was mingw32. I then cleaned it up for some specific uses I had later. The read returning -1 when it should block didn't impact anybody and appeared to help some people. It isnt the documented behavior though. There could be all sorts of latent bugs in that code but in the real world, it gets by in almost all use cases. Its a hack but it worked for 100's of thousands of people over a 14 year period. Maybe its time to revisit the code but there is more risk than gain for most people. How do you move forward and avoid the risk? Some have expressed interests in coding C++ or other efforts. I'm all for such efforts but feel some unit tests that work with a null modem cables are the only thing that will move rxtx (and perhaps CommAPI) forward. If we have a test suite in place as a qualification for implementations, progress can be made in the right direction regardless of the implementation details. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Fri Mar 4 02:57:16 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 4 Mar 2011 11:57:16 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/4/11 03:52, "Trent Jarvi" wrote: >Yes. RXTX was patched to behave the way it does. I don't fully >understand the issue behind the patch. Marc noticed the odd behavior as >well and offered a fix which was greeted with resistance. > >The windows implementation was done without real documentatino of the >windows API. I think I had an example from the late 80's early 90's on >Microsoft's site and some API documentation that was obviously not >microsofts in Europe. Wayne Roberts had a real need for windows support >and fixed some major issues it had. My interest at the time was mingw32. >I then cleaned it up for some specific uses I had later. The read >returning -1 when it should block didn't impact anybody and appeared to >help some people. It isnt the documented behavior though. > >There could be all sorts of latent bugs in that code but in the real >world, it gets by in almost all use cases. I think so too, never had any problems with it. > Its a hack but it worked for 100's of thousands of people over a 14 year >period. Yeah! Thanks for everyone who has contributed over the years, job well done! >Maybe its time to >revisit the code but there is more risk than gain for most people. How >do >you move forward and avoid the risk? My view is that it is quite risky and rather pointless to move forward, other than fixing bugs that really affect people. At the moment the major issue IMO is just that it seems (not been following this too carefully, so maybe I'm wrong, so in case this FUD, my apologies) that 'official' binaries are not available. I think the rewrite, tempting as it is in some respects is not the way forward. Just gentle maintenance to iron out real issues and then get the binaries out. br Kusti From ryan.boder at gmail.com Fri Mar 4 07:24:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Fri, 4 Mar 2011 09:24:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 8:52 PM, Trent Jarvi wrote: > > The windows implementation was done without real documentatino of the > windows API. I think I had an example from the late 80's early 90's on > Microsoft's site and some API documentation that was obviously not > microsofts in Europe. Wayne Roberts had a real need for windows support and > fixed some major issues it had. My interest at the time was mingw32. I then > cleaned it up for some specific uses I had later. The read returning -1 > when it should block didn't impact anybody and appeared to help some people. > It isnt the documented behavior though. > > There could be all sorts of latent bugs in that code but in the real world, > it gets by in almost all use cases. Its a hack but it worked for 100's of > thousands of people over a 14 year period. Maybe its time to revisit the > code but there is more risk than gain for most people. How do you move > forward and avoid the risk? > The safest and easiest solution would be to add a javadoc comment to disableReceiveTimeout explaining the difference between the RXTX behavior and Sunacle's documented behavior so that when someone uses the method in an IDE like Eclipse a little box would pop up informing them. Generating javadoc HTML and hosting it on the RXTX website would go a long way too, when something behaves differently than I expect the first thing I do is look for the javadoc online. -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From kharrington at neuronrobotics.com Mon Mar 7 10:47:26 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 12:47:26 -0500 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! Message-ID: Hey all, this is just a heads up that i have made a fork of rxtxSerial. Some of the features we have added: * Self deployment of native libraries ( all native code is stored inside the jar and deployed at runtime). No more manual install of native code. * Arm Cortex support (Gumstix) * Android Support (requires a rooted phone for now) * Google Code (SVN) repository for easy code and jar access * Single makefile compile (simplifies the compilation of project binaries) * Ant build script for jar creation * Removal of partialy implemented code to streamline the lib for just serial port access * Full Eclipse integration, for testing application code against sources. And a bunch of bug fixes: * Fixed the memory access error that causes OSX to crash the JVM when serial.close() is cvalled * Fixed the windows serial port zombie bind that prevents re-accessing serial ports when exiting on an exception * Fixed erronious printouts of native library mis-match To check it out, take a look at our page here: http://code.google.com/p/nrjavaserial/ From Kustaa.Nyholm at planmeca.com Mon Mar 7 11:46:26 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Mar 2011 20:46:26 +0200 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: Message-ID: On 3/7/11 19:47, "Kevin Harrington NR" wrote: >Hey all, this is just a heads up that i have made a fork of >rxtxSerial. Some of the features we have added great! If also does what it says on the tin: brilliant! Congrats and thanks. br Kusti From jmsachs at gmail.com Mon Mar 7 12:50:33 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 14:50:33 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: > From: Kevin Harrington NR > To: rxtx at qbang.org > Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > Hey all, this is just a heads up that i have made a fork of > rxtxSerial. Some of the features we have added: > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with a ten-foot pole. From Kustaa.Nyholm at planmeca.com Mon Mar 7 13:10:43 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Mar 2011 22:10:43 +0200 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: Message-ID: On 3/7/11 21:50, "Jason Sachs" wrote: > >Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >a ten-foot pole. >_______________________________________________ Oh crap, makes it useless for me and many others. Also I see no provision in RxTx license to change it so how could anyone change it to GPLv3? br Kusti From showard314 at gmail.com Mon Mar 7 13:24:08 2011 From: showard314 at gmail.com (Scott Howard) Date: Mon, 7 Mar 2011 15:24:08 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 3:10 PM, Kustaa Nyholm wrote: > Also I see no provision in RxTx license to change > it so how could anyone change it to GPLv3? I think this is allowed: 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. From jmsachs at gmail.com Mon Mar 7 13:24:47 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 15:24:47 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 2:50 PM, Jason Sachs wrote: >> From: Kevin Harrington NR >> To: rxtx at qbang.org >> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> > > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with > a ten-foot pole. > Let me back up a second (perhaps to make up for my lack of diplomacy) and state that I think any progress w/ rxtx is good. If an rxtx fork were LGPL (or some other non-spreading open source license) and leading in a good direction, I'd gladly return the favor by posting any improvements or bugfixes I found to the community. --Jason From jmsachs at gmail.com Mon Mar 7 13:36:13 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 15:36:13 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: Kevin: could you clarify the license? http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java has the RXTX 2.1 license (LGPL v 2.1 + Linking Over Controlled Interface.) but http://code.google.com/p/nrjavaserial/ says GPLv3. --Jason From kharrington at neuronrobotics.com Mon Mar 7 14:00:02 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 16:00:02 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: The one downside to google code is that it does not allow custom licensing. You have to pick from a drop-down list. Treat the licences on the files themselves as the licence to be concerned with, and ignore the "project licence". Sorry for the confusion. On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: > Kevin: could you clarify the license? > > http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java > has the RXTX 2.1 license > (LGPL v 2.1 + Linking Over Controlled Interface.) > > but http://code.google.com/p/nrjavaserial/ says GPLv3. > > --Jason > From iqzw2r602 at sneakemail.com Mon Mar 7 14:08:18 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 8 Mar 2011 08:08:18 +1100 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: References: Message-ID: <11253-1299532098-811882@sneakemail.com> Nice! Out of curiosity, did you use the patch that I sent Trent about two years ago to do the native library loading, or did you implement your own solution? Cheers, Uwe On Tue, Mar 8, 2011 at 5:46 AM, Kustaa Nyholm Kustaa.Nyholm-at-planmeca.com| rxtx.org mailing list/Example Allow| wrote: > On 3/7/11 19:47, "Kevin Harrington NR" > wrote: > > >Hey all, this is just a heads up that i have made a fork of > >rxtxSerial. Some of the features we have added > > > > great! If also does what it says on the tin: brilliant! > > Congrats and thanks. > > br Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aawolfe at gmail.com Mon Mar 7 15:31:47 2011 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 7 Mar 2011 17:31:47 -0500 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR wrote: > Hey all, this is just a heads up that i have made a fork of > rxtxSerial. Some of the features we have added: > > * Self deployment of native libraries ( all native code is stored > inside the jar and deployed at runtime). No more manual install of > native code. > * Arm Cortex support (Gumstix) > * Android Support (requires a rooted phone for now) > * Google Code (SVN) repository for easy code and jar access > * Single makefile compile (simplifies the compilation of project binaries) > * Ant build script for jar creation > * Removal of partialy implemented code to streamline the lib for just > serial port access > * Full Eclipse integration, for testing application code against sources. > > And a bunch of bug fixes: > > * Fixed the memory access error that causes OSX to crash the JVM when > serial.close() is cvalled > * Fixed the windows serial port zombie bind that prevents re-accessing > serial ports when exiting on an exception > * Fixed erronious printouts of native library mis-match > > To check it out, take a look at our page here: > > http://code.google.com/p/nrjavaserial/ This is interesting, getting the native libs set up has been an issue for some of my users. Will have to check it out. Out of curiosity, what Android devices provide a serial port? Or are there some that allow USB host mode and then a usb-serial adapter? I have only an Android cell phone, don't think it can do anything serial but would love to be wrong about that. From jfh at greenhousepc.com Mon Mar 7 15:54:39 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 15:54:39 -0700 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! Message-ID: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Mon Mar 7 16:53:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Mar 2011 16:53:50 -0700 (MST) Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: Hi Kevin, Until Google fixes the options as developers have requested, I'd suggest the least misleading dropdown option is "Other Open Source" with a clarification about LGPL 2.1 on the project page. If you are not supporting the CommAPI SPI interface that was available prior to the current JSR so that applications work in the javax.comm namespace, there is no need for the linking over controlled interfaces exception. RXTX 2.0 is used in that fashion but RXTX 2.1 is not. The exception explicitly states it can be removed if the source has been modified. The license is then explicitly OSI reviewed and approved as Google requests but is not in their drop down box as it should be and is for the GPL v2. http://opensource.org/licenses/alphabetical http://opensource.org/licenses/lgpl-2.1 The drawback would be that the library effectively could never be used in that SPI/controlled interface fashion again. On Mon, 7 Mar 2011, Kevin Harrington NR wrote: > The one downside to google code is that it does not allow custom > licensing. You have to pick from a drop-down list. Treat the licences > on the files themselves as the licence to be concerned with, and > ignore the "project licence". Sorry for the confusion. > > On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >> Kevin: could you clarify the license? >> >> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >> has the RXTX 2.1 license >> (LGPL v 2.1 + Linking Over Controlled Interface.) >> >> but http://code.google.com/p/nrjavaserial/ says GPLv3. >> >> --Jason >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From hakcenter at gmail.com Mon Mar 7 18:55:57 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 17:55:57 -0800 Subject: [Rxtx] Latency Woes Message-ID: <4D758CAD.2010602@gmail.com> I have finally deduced my slow data logging to a latency issue. I write software for dsms, and the protocol is request / receive, you cannot do more than 1 sensor at a time. So when you log multiple sensors, +20ms per item, sampling rate drops like a rock. I was wondering if there is any ideas besides going completely native with my application to reduce latency. With or without events I don't care at this point I need to kill as much of the latency as possible. Realistically I need no more than 1ms. From adrian.crum at sandglass-software.com Mon Mar 7 19:08:21 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Mon, 07 Mar 2011 18:08:21 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D758CAD.2010602@gmail.com> References: <4D758CAD.2010602@gmail.com> Message-ID: <4D758F95.90800@sandglass-software.com> Drop the requests into a queue, and then have a separate thread service the queue. -Adrian On 3/7/2011 5:55 PM, Curtis Hacker wrote: > I have finally deduced my slow data logging to a latency issue. > > I write software for dsms, and the protocol is request / receive, you > cannot do more than 1 sensor at a time. So when you log multiple > sensors, +20ms per item, sampling rate drops like a rock. > > I was wondering if there is any ideas besides going completely native > with my application to reduce latency. With or without events I don't > care at this point I need to kill as much of the latency as possible. > Realistically I need no more than 1ms. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From hakcenter at gmail.com Mon Mar 7 19:24:16 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 18:24:16 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D758F95.90800@sandglass-software.com> References: <4D758CAD.2010602@gmail.com> <4D758F95.90800@sandglass-software.com> Message-ID: <4D759350.8060402@gmail.com> Sample code ? I don't necessarily want to read the byte I just wrote, but wait till the que depth is 2. Setup a thread without a sleep timer: if (in.available() > 1) { do_stuff(); } ?? On 03/07/11 18:08, Adrian Crum wrote: > Drop the requests into a queue, and then have a separate thread > service the queue. > > -Adrian > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: >> I have finally deduced my slow data logging to a latency issue. >> >> I write software for dsms, and the protocol is request / receive, you >> cannot do more than 1 sensor at a time. So when you log multiple >> sensors, +20ms per item, sampling rate drops like a rock. >> >> I was wondering if there is any ideas besides going completely native >> with my application to reduce latency. With or without events I don't >> care at this point I need to kill as much of the latency as possible. >> Realistically I need no more than 1ms. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adrian.crum at sandglass-software.com Mon Mar 7 19:46:02 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Mon, 07 Mar 2011 18:46:02 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D759350.8060402@gmail.com> References: <4D758CAD.2010602@gmail.com> <4D758F95.90800@sandglass-software.com> <4D759350.8060402@gmail.com> Message-ID: <4D75986A.6020003@sandglass-software.com> http://download.oracle.com/javase/tutorial/essential/concurrency/executors.html -Adrian On 3/7/2011 6:24 PM, Curtis Hacker wrote: > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: >> Drop the requests into a queue, and then have a separate thread >> service the queue. >> >> -Adrian >> >> On 3/7/2011 5:55 PM, Curtis Hacker wrote: >>> I have finally deduced my slow data logging to a latency issue. >>> >>> I write software for dsms, and the protocol is request / receive, >>> you cannot do more than 1 sensor at a time. So when you log multiple >>> sensors, +20ms per item, sampling rate drops like a rock. >>> >>> I was wondering if there is any ideas besides going completely >>> native with my application to reduce latency. With or without events >>> I don't care at this point I need to kill as much of the latency as >>> possible. Realistically I need no more than 1ms. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Mon Mar 7 19:50:45 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 19:50:45 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Mon Mar 7 20:04:01 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 19:04:01 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> Message-ID: <4D759CA1.8010903@gmail.com> I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. in.read(data, 0, 2); ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? On 03/07/11 18:50, jfh at greenhousepc.com wrote: > Curtis, > > No, I assume he means a real queue, not just "don't read all the bytes > at once." However, if you know you can process some number of > requests in some amount of time, allowing data to pile up (receiver > FIFO space permitting) can be a valid strategy. Inserting gobs of > Thread.yield() and notify() can help pep things up as well. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Mon, March 07, 2011 8:24 pm > To: rxtx at qbang.org > > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: > > Drop the requests into a queue, and then have a separate thread > > service the queue. > > > > -Adrian > > > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: > >> I have finally deduced my slow data logging to a latency issue. > >> > >> I write software for dsms, and the protocol is request / > receive, you > >> cannot do more than 1 sensor at a time. So when you log multiple > >> sensors, +20ms per item, sampling rate drops like a rock. > >> > >> I was wondering if there is any ideas besides going completely > native > >> with my application to reduce latency. With or without events I > don't > >> care at this point I need to kill as much of the latency as > possible. > >> Realistically I need no more than 1ms. > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From bartley at cmu.edu Mon Mar 7 20:08:05 2011 From: bartley at cmu.edu (Chris Bartley) Date: Mon, 7 Mar 2011 22:08:05 -0500 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> Message-ID: <9B1804F9-DBD0-476D-9345-806D00065A97@cmu.edu> We use a queue for all our request/response serial communications, and have found it really easy to work with. Code is here: http://code.google.com/p/create-lab-commons/source/browse/trunk/java/code/serial/src/edu/cmu/ri/createlab/serial/SerialPortCommandExecutionQueue.java It's assuming a command & response scheme that's specific to the protocol we use to talk to our robots, but it should be easy to modify for your needs. Hope this helps. Let me know if you have questions. Chris On Mar 7, 2011, at 9:50 PM, wrote: > Curtis, > > No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > Date: Mon, March 07, 2011 8:24 pm > To: rxtx at qbang.org > > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: > > Drop the requests into a queue, and then have a separate thread > > service the queue. > > > > -Adrian > > > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: > >> I have finally deduced my slow data logging to a latency issue. > >> > >> I write software for dsms, and the protocol is request / receive, you > >> cannot do more than 1 sensor at a time. So when you log multiple > >> sensors, +20ms per item, sampling rate drops like a rock. > >> > >> I was wondering if there is any ideas besides going completely native > >> with my application to reduce latency. With or without events I don't > >> care at this point I need to kill as much of the latency as possible. > >> Realistically I need no more than 1ms. > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Mon Mar 7 20:51:17 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 20:51:17 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110307205116.8ef0e5b4a80cef441275a6330ffad77d.9b325137d1.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From kharrington at neuronrobotics.com Mon Mar 7 20:55:23 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 22:55:23 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 7 In-Reply-To: References: Message-ID: To answer a few of you, I have changed the license to "Other open source license" as suggested. My company is modifying and maintaining this fork to support our robotics development library (http://code.google.com/p/nr-sdk/ http://dev.neuronrobotics.com). We will be implementing the standard serial port interface only, as it is the only one we need or care about. As for where the implementation came from, i would have to refer to my other developer to answer that. I wrote the build scripts and make files, as well as streamlining the C build process. I have remover the configure script, as it ends up being more confusing then compiling 3 C files needs to be. if you guys want to bring any of this into the main line, that's cool, but up to you to port over. Our fork will be focusing on polishing up the serial interface,and hopefully making it faster. I hope some of you will find our improvements useful! On Mon, Mar 7, 2011 at 6:53 PM, wrote: > Send Rxtx mailing list submissions to > ? ? ? ?rxtx at qbang.org > > To subscribe or unsubscribe via the World Wide Web, visit > ? ? ? ?http://mailman.qbang.org/mailman/listinfo/rxtx > or, via email, send a message with subject or body 'help' to > ? ? ? ?rxtx-request at qbang.org > > You can reach the person managing the list at > ? ? ? ?rxtx-owner at qbang.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Rxtx digest..." > > > Today's Topics: > > ? 1. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 2. Re: Rxtx Digest, Vol 43, Issue 6 (Kustaa Nyholm) > ? 3. Re: Rxtx Digest, Vol 43, Issue 6 (Scott Howard) > ? 4. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 5. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 6. Re: Rxtx Digest, Vol 43, Issue 6 (Kevin Harrington NR) > ? 7. Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! > ? ? ?(iqzw2r602 at sneakemail.com) > ? 8. Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! > ? ? ?(Aaron Wolfe) > ? 9. Re: [SPAM] Re: ?NRJavaSerial, a fork of rxtx that fixes the > ? ? ?papercuts! (jfh at greenhousepc.com) > ?10. Re: Rxtx Digest, Vol 43, Issue 6 (Trent Jarvi) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 7 Mar 2011 14:50:33 -0500 > From: Jason Sachs > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > >> From: Kevin Harrington NR >> To: rxtx at qbang.org >> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> > > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with > a ten-foot pole. > > > ------------------------------ > > Message: 2 > Date: Mon, 7 Mar 2011 22:10:43 +0200 > From: Kustaa Nyholm > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > On 3/7/11 21:50, "Jason Sachs" wrote: >> >>Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >>a ten-foot pole. >>_______________________________________________ > > Oh crap, makes it useless for me and many others. > > Also I see no provision in RxTx license to change > it so how could anyone change it to GPLv3? > > br Kusti > > > > ------------------------------ > > Message: 3 > Date: Mon, 7 Mar 2011 15:24:08 -0500 > From: Scott Howard > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 3:10 PM, Kustaa Nyholm > wrote: >> Also I see no provision in RxTx license to change >> it so how could anyone change it to GPLv3? > > I think this is allowed: > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. ?To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. ?(If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) ?Do not make any other change in > these notices. > > ? Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > ? This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > > ------------------------------ > > Message: 4 > Date: Mon, 7 Mar 2011 15:24:47 -0500 > From: Jason Sachs > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 2:50 PM, Jason Sachs wrote: >>> From: Kevin Harrington NR >>> To: rxtx at qbang.org >>> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >>> Message-ID: >>> ? ? ? ? >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> Hey all, this is just a heads up that i have made a fork of >>> rxtxSerial. Some of the features we have added: >>> >> >> Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >> a ten-foot pole. >> > > Let me back up a second (perhaps to make up for my lack of diplomacy) > and state that I think any progress w/ rxtx is good. > > If an rxtx fork were LGPL (or some other non-spreading open source > license) and leading in a good direction, I'd gladly return the favor > by posting any improvements or bugfixes I found to the community. > > --Jason > > > ------------------------------ > > Message: 5 > Date: Mon, 7 Mar 2011 15:36:13 -0500 > From: Jason Sachs > To: rxtx at qbang.org, kharrington at neuronrobotics.com > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > Kevin: could you clarify the license? > > http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java > has the RXTX 2.1 license > (LGPL v 2.1 + Linking Over Controlled Interface.) > > but http://code.google.com/p/nrjavaserial/ says GPLv3. > > --Jason > > > ------------------------------ > > Message: 6 > Date: Mon, 7 Mar 2011 16:00:02 -0500 > From: Kevin Harrington NR > To: Jason Sachs > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > The one downside to google code is that it does not allow custom > licensing. You have to pick from a drop-down list. Treat the licences > on the files themselves as the licence to be concerned with, and > ignore the "project licence". Sorry for the confusion. > > On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >> Kevin: could you clarify the license? >> >> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >> has the RXTX 2.1 license >> (LGPL v 2.1 + Linking Over Controlled Interface.) >> >> but http://code.google.com/p/nrjavaserial/ says GPLv3. >> >> --Jason >> > > > ------------------------------ > > Message: 7 > Date: Tue, 8 Mar 2011 08:08:18 +1100 > From: iqzw2r602 at sneakemail.com > To: Rxtx at qbang.org > Subject: Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > ? ? ? ?papercuts! > Message-ID: <11253-1299532098-811882 at sneakemail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Nice! > > Out of curiosity, did you use the patch that I sent Trent about two years > ago to do the native library loading, or did you implement your own > solution? > > Cheers, > > Uwe > > On Tue, Mar 8, 2011 at 5:46 AM, Kustaa Nyholm Kustaa.Nyholm-at-planmeca.com| > rxtx.org mailing list/Example Allow| wrote: > >> On 3/7/11 19:47, "Kevin Harrington NR" >> wrote: >> >> >Hey all, this is just a heads up that i have made a fork of >> >rxtxSerial. Some of the features we have added >> >> >> >> great! If also does what it says on the tin: brilliant! >> >> Congrats and thanks. >> >> br Kusti >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 8 > Date: Mon, 7 Mar 2011 17:31:47 -0500 > From: Aaron Wolfe > To: rxtx at qbang.org > Subject: Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > ? ? ? ?papercuts! > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR > wrote: >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> >> * Self deployment of native libraries ( all native code is stored >> inside the jar and deployed at runtime). No more manual install of >> native code. >> * Arm Cortex support (Gumstix) >> * Android Support (requires a rooted phone for now) >> * Google Code (SVN) repository for easy code and jar access >> * Single makefile compile (simplifies the compilation of project binaries) >> * Ant build script for jar creation >> * Removal of partialy implemented code to streamline the lib for just >> serial port access >> * Full Eclipse integration, for testing application code against sources. >> >> And a bunch of bug fixes: >> >> * Fixed the memory access error that causes OSX to crash the JVM when >> serial.close() is cvalled >> * Fixed the windows serial port zombie bind that prevents re-accessing >> serial ports when exiting on an exception >> * Fixed erronious printouts of native library mis-match >> >> To check it out, take a look at our page here: >> >> http://code.google.com/p/nrjavaserial/ > > This is interesting, getting the native libs set up has been an issue > for some of my users. ?Will have to check it out. > > Out of curiosity, what Android devices provide a serial port? ?Or are > there some that allow USB host mode and then a usb-serial adapter? ?I > have only an Android cell phone, don't think it can do anything serial > but would love to be wrong about that. > > > ------------------------------ > > Message: 9 > Date: Mon, 07 Mar 2011 15:54:39 -0700 > From: > To: aaron at aaronwolfe.com, rxtx at qbang.org > Subject: Re: [Rxtx] [SPAM] Re: ?NRJavaSerial, a fork of rxtx that > ? ? ? ?fixes the papercuts! > Message-ID: > ? ? ? ?<20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe at email13.secureserver.net> > > Content-Type: text/plain; charset="us-ascii" > > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 10 > Date: Mon, 7 Mar 2011 16:53:50 -0700 (MST) > From: Trent Jarvi > To: rxtx at qbang.org > Cc: Jason Sachs > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > Hi Kevin, > > Until Google fixes the options as developers have requested, I'd suggest > the least misleading dropdown option is "Other Open Source" with a > clarification about LGPL 2.1 on the project page. > > If you are not supporting the CommAPI SPI interface that was available > prior to the current JSR so that applications work in the javax.comm > namespace, there is no need for the linking over controlled interfaces > exception. ?RXTX 2.0 is used in that fashion but RXTX 2.1 is not. ?The > exception explicitly states it can be removed if the source has been > modified. ?The license is then explicitly OSI reviewed and approved as > Google requests but is not in their drop down box as it should be and is > for the GPL v2. > > ? ? ? ?http://opensource.org/licenses/alphabetical > ? ? ? ?http://opensource.org/licenses/lgpl-2.1 > > The drawback would be that the library effectively could never be used in > that SPI/controlled interface fashion again. > > On Mon, 7 Mar 2011, Kevin Harrington NR wrote: > >> The one downside to google code is that it does not allow custom >> licensing. You have to pick from a drop-down list. Treat the licences >> on the files themselves as the licence to be concerned with, and >> ignore the "project licence". Sorry for the confusion. >> >> On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >>> Kevin: could you clarify the license? >>> >>> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >>> has the RXTX 2.1 license >>> (LGPL v 2.1 + Linking Over Controlled Interface.) >>> >>> but http://code.google.com/p/nrjavaserial/ says GPLv3. >>> >>> --Jason >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > ------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > End of Rxtx Digest, Vol 43, Issue 7 > *********************************** > From Kustaa.Nyholm at planmeca.com Mon Mar 7 21:43:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 8 Mar 2011 06:43:57 +0200 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307205116.8ef0e5b4a80cef441275a6330ffad77d.9b325137d1.wbe@email13.secureserver.net> Message-ID: On 3/8/11 05:51, "jfh at greenhousepc.com" wrote: >Curtis, > > >None of that is relevant, as long as the UART is reasonable and the code >implements a proper half duplex protocol. > >If I understand correctly, you send a byte, the sensor sends back two >bytes. So long as you don't send the next byte until the two bytes are >in the UART receiver FIFO, you're fine. You don't have to actually >=read= them, just know they are available. To the OP, are you using a serial USB port, like FTDI? This has a built in latency of 10ms ie nothing is actually sent out of the device if you send less than 64 bytes until 10 msec timeout. This has nothing to do with RxTx. If you search the list archives you'll find more about this issue and IIRC someone reported that there is some diver parameter you can tweak to get rid of that latency. I'm sure the FTDI people had a good reason for this but it really brings down the communication speed if your protocol uses short messages and need to wait for a response. Sorry if this has already been mentioned or if this is not relevant, I've not been paying attention to this thread. br Kusti From bob_jacobsen at lbl.gov Tue Mar 8 00:02:28 2011 From: bob_jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 8 Mar 2011 00:02:28 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D759CA1.8010903@gmail.com> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> Message-ID: If you're transferring three bytes total at 1953 baud, it's going to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to wait 20msec to get the data back instead of 15.4 msec doesn't seem to be as big a problem as you're making it sound. Bob On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. > > To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. > > So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. > > in.read(data, 0, 2); > ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? > > On 03/07/11 18:50, jfh at greenhousepc.com wrote: >> Curtis, >> >> No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker >> Date: Mon, March 07, 2011 8:24 pm >> To: rxtx at qbang.org >> >> Sample code ? >> >> I don't necessarily want to read the byte I just wrote, but wait till >> the que depth is 2. >> >> Setup a thread without a sleep timer: >> if (in.available() > 1) { >> do_stuff(); >> } >> >> ?? >> >> On 03/07/11 18:08, Adrian Crum wrote: >> > Drop the requests into a queue, and then have a separate thread >> > service the queue. >> > >> > -Adrian >> > >> > On 3/7/2011 5:55 PM, Curtis Hacker wrote: >> >> I have finally deduced my slow data logging to a latency issue. >> >> >> >> I write software for dsms, and the protocol is request / receive, you >> >> cannot do more than 1 sensor at a time. So when you log multiple >> >> sensors, +20ms per item, sampling rate drops like a rock. >> >> >> >> I was wondering if there is any ideas besides going completely native >> >> with my application to reduce latency. With or without events I don't >> >> care at this point I need to kill as much of the latency as possible. >> >> Realistically I need no more than 1ms. >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From hakcenter at gmail.com Tue Mar 8 01:33:24 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 00:33:24 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> Message-ID: <4D75E9D4.5090307@gmail.com> I am going to try a couple things today and hopefully figure something out. Bob I don't want to pop your bubble, but a native application named 'TunerPro' can sample the same data, over 30 sensors, in less than 25ms. I've exchanged some emails with the author and it is a native C, polling, no events just timeouts. Kusta thanks for the FTDI notice, I believe that is tunable, however I have a particular user using a Keyspan converter and verified sampling rate with 'TunerPro' and its just off the charts. Chris thank you, I'll look into the queing. On 03/07/11 23:02, Bob Jacobsen wrote: > If you're transferring three bytes total at 1953 baud, it's going to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to wait 20msec to get the data back instead of 15.4 msec doesn't seem to be as big a problem as you're making it sound. > > Bob > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > >> I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. >> >> To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. >> >> So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. >> >> in.read(data, 0, 2); >> ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? >> >> On 03/07/11 18:50, jfh at greenhousepc.com wrote: >>> Curtis, >>> >>> No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. >>> -- >>> Julie Haugh >>> Senior Design Engineer >>> greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype From msemtd at googlemail.com Tue Mar 8 01:50:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 8 Mar 2011 08:50:15 +0000 Subject: [Rxtx] Latency Woes In-Reply-To: <4D75E9D4.5090307@gmail.com> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> <4D75E9D4.5090307@gmail.com> Message-ID: On 8 March 2011 08:33, Curtis Hacker wrote: > I am going to try a couple things today and hopefully figure something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than 25ms. > I've exchanged some emails with the author and it is a native C, polling, no > events just timeouts. Perhaps the author of TunerPro will let you use his native code - sounds just what you need. Regards, Michael Erskine. From jfh at greenhousepc.com Tue Mar 8 04:00:18 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 04:00:18 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 12:33:35 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 11:33:35 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> Message-ID: <4D76848F.5080809@gmail.com> Cable schematic: http://i1106.photobucket.com/albums/h377/vigilart/jackal%20logging%20set%20up/RS232SCHEMATIC.jpg 0.00268554 TunerPro.exe IOCTL_SERIAL_SET_BAUD_RATE VCP0 SUCCESS Rate: 1952 0.00305178 TunerPro.exe IOCTL_SERIAL_SET_RTS VCP0 SUCCESS 0.00297524 TunerPro.exe IOCTL_SERIAL_SET_DTR VCP0 SUCCESS 0.00297384 TunerPro.exe IOCTL_SERIAL_SET_LINE_CONTROL VCP0 SUCCESS StopBits: 1 Parity: NONE WordLength: 8 0.00000335 TunerPro.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 0.00202540 TunerPro.exe IOCTL_SERIAL_SET_HANDFLOW VCP0 SUCCESS Shake:1 Replace:40 XonLimit:2048 XoffLimit:512 0.00000335 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:300 RM:0 RC:2000 WM:0 WC:110 0.00000279 TunerPro.exe IOCTL_SERIAL_SET_QUEUE_SIZE VCP0 SUCCESS InSize: 1024 OutSize: 512 0.00000307 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000279 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:300 RM:0 RC:2000 WM:0 WC:110 0.00000307 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:75 RM:0 RC:400 WM:0 WC:300 0.00000559 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: RXCLEAR 0.00000335 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: TXCLEAR 0.00064980 TunerPro.exe IRP_MJ_WRITE VCP0 SUCCESS Length 1: . 0.01498738 TunerPro.exe IRP_MJ_READ VCP0 SUCCESS Length 1: . 0.00000363 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:200 RM:0 RC:20 WM:0 WC:300 0.02042774 TunerPro.exe IRP_MJ_READ VCP0 TIMEOUT Length 0: That is time on the left side. Now I'm with you on timing, it doesn't make a lot of sense, but that is how the logs come out. You can view the logs yourself. Tunerpro log : http://www.ds-map.net/tunerpro_log.csv My apps log : http://www.ds-map.net/my_log.csv 2nd app log : http://www.ds-map.net/my_log2.csv All these logs, were done from the same car, same cable. I have some older logs with some palm software, that was 13 sensors, and had a total 45-55ms between each set of 13. More info about the car / ecu at http://mmcdlogger.sourceforge.net Disassembly on the ecu: [SS1:SS0] is baud rate divider, 00(16) 01(128) 10(1024) 11(4096), assuming basic clock of 2MHZ, we get 125000baud, 15625baud, 1953baud, 488baud In any event, I attempted a no sleep thread, that waited till in.available > 1, and it wasn't any faster than running the events. Then I tried a read write thread, that slept from 1ms to 30ms after it wrote (so it wouldn't read what it just wrote). And couldn't get it doing much. I wish I had more of an understanding of all of this, which is why I'm asking for help. On 03/08/11 03:00, jfh at greenhousepc.com wrote: > Curtis, > > At the risk of being told "No, they really say it can be done", 30 > sensors is 30 * 3 character times (are you sure it's not a single byte > response?). At 1953 baud, a single character time is 10 bits * (1 / > 1953) seconds, or 15.4ms as Bob pointed out. 30 * 15.4ms is 460ms, > and that assumes everything works perfectly, no turnaround times, etc. > > If you can come up with some other way to make the math work, I'd love > to hear it. > > Short and sweet -- just because TunerPro can talk to an ECM/ECU that > is running faster than 1953 baud doesn't mean your Mitsubishi (or > whatever car you've got that runs at 1953 baud) runs at that faster > baud rate. > > Also, are you sure your data cable is correct? What cable are you > using? What's the schematic? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 2:33 am > To: rxtx at qbang.org > > I am going to try a couple things today and hopefully figure > something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than > 25ms. > I've exchanged some emails with the author and it is a native C, > polling, no events just timeouts. > > Kusta thanks for the FTDI notice, I believe that is tunable, > however I > have a particular user using a Keyspan converter and verified > sampling > rate with 'TunerPro' and its just off the charts. > > Chris thank you, I'll look into the queing. > > On 03/07/11 23:02, Bob Jacobsen wrote: > > If you're transferring three bytes total at 1953 baud, it's going > to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to > wait 20msec to get the data back instead of 15.4 msec doesn't seem > to be as big a problem as you're making it sound. > > > > Bob > > > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > > > >> I guess I'm gunna need some serious help with this then, because > of the scenario I'm stuck with. > >> > >> To communicate there is only 1 data line, rx/tx tied together > with a diode protecting the tx. No RTS/CTS handshaking nothing.. > >> > >> So the ecu can't process the next byte of info, without you > pulling the 2 bytes back. I wish this was standard, but even the > baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard > spot with this.. > >> > >> in.read(data , 0, 2); > >> ^ would the above wait till the timeout to read 2 bytes ? or > read 1 byte wait for the 2nd ? or just read the 1 ?? > >> > >> On 03/07/11 18:50, jfh at greenhousepc.com > wrote: > >>> Curtis, > >>> > >>> No, I assume he means a real queue, not just "don't read all > the bytes at once." However, if you know you can process some > number of requests in some amount of time, allowing data to pile > up (receiver FIFO space permitting) can be a valid strategy. > Inserting gobs of Thread.yield() and notify() can help pep things > up as well. > >>> -- > >>> Julie Haugh > >>> Senior Design Engineer > >>> greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 13:12:03 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 12:12:03 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> Message-ID: <4D768D93.1030504@gmail.com> So I looked over the Tunerpro log again today.. is it me or does it appear to be reusing values ? On 03/08/11 03:00, jfh at greenhousepc.com wrote: > Curtis, > > At the risk of being told "No, they really say it can be done", 30 > sensors is 30 * 3 character times (are you sure it's not a single byte > response?). At 1953 baud, a single character time is 10 bits * (1 / > 1953) seconds, or 15.4ms as Bob pointed out. 30 * 15.4ms is 460ms, > and that assumes everything works perfectly, no turnaround times, etc. > > If you can come up with some other way to make the math work, I'd love > to hear it. > > Short and sweet -- just because TunerPro can talk to an ECM/ECU that > is running faster than 1953 baud doesn't mean your Mitsubishi (or > whatever car you've got that runs at 1953 baud) runs at that faster > baud rate. > > Also, are you sure your data cable is correct? What cable are you > using? What's the schematic? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 2:33 am > To: rxtx at qbang.org > > I am going to try a couple things today and hopefully figure > something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than > 25ms. > I've exchanged some emails with the author and it is a native C, > polling, no events just timeouts. > > Kusta thanks for the FTDI notice, I believe that is tunable, > however I > have a particular user using a Keyspan converter and verified > sampling > rate with 'TunerPro' and its just off the charts. > > Chris thank you, I'll look into the queing. > > On 03/07/11 23:02, Bob Jacobsen wrote: > > If you're transferring three bytes total at 1953 baud, it's going > to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to > wait 20msec to get the data back instead of 15.4 msec doesn't seem > to be as big a problem as you're making it sound. > > > > Bob > > > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > > > >> I guess I'm gunna need some serious help with this then, because > of the scenario I'm stuck with. > >> > >> To communicate there is only 1 data line, rx/tx tied together > with a diode protecting the tx. No RTS/CTS handshaking nothing.. > >> > >> So the ecu can't process the next byte of info, without you > pulling the 2 bytes back. I wish this was standard, but even the > baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard > spot with this.. > >> > >> in.read(data , 0, 2); > >> ^ would the above wait till the timeout to read 2 bytes ? or > read 1 byte wait for the 2nd ? or just read the 1 ?? > >> > >> On 03/07/11 18:50, jfh at greenhousepc.com > wrote: > >>> Curtis, > >>> > >>> No, I assume he means a real queue, not just "don't read all > the bytes at once." However, if you know you can process some > number of requests in some amount of time, allowing data to pile > up (receiver FIFO space permitting) can be a valid strategy. > Inserting gobs of Thread.yield() and notify() can help pep things > up as well. > >>> -- > >>> Julie Haugh > >>> Senior Design Engineer > >>> greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 13:51:13 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 13:51:13 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308135113.8ef0e5b4a80cef441275a6330ffad77d.a5fff5bbc7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From bob_jacobsen at lbl.gov Tue Mar 8 14:14:57 2011 From: bob_jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 8 Mar 2011 14:14:57 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D76848F.5080809@gmail.com> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> Message-ID: <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > Tunerpro log : http://www.ds-map.net/tunerpro_log.csv It's only reading one sensor per line. Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT changed in lines 16 and 40; every 24 lines but at a different phase. GramsRev in lines 23 and 47; every 24 lines, at yet another phase. Looks like (69-1) readings in 1.30 seconds = 19msec per reading. Arithmetic still works! Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From hakcenter at gmail.com Tue Mar 8 14:27:12 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 13:27:12 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> Message-ID: <4D769F30.9050807@gmail.com> Thank you guys, cause I was really worried there. I guess another win for math today hahaha. So what is the imposed latency that rxtx has ? maybe 5-10ms ? On 03/08/11 13:14, Bob Jacobsen wrote: > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > It's only reading one sensor per line. > > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT changed in lines 16 and 40; every 24 lines but at a different phase. GramsRev in lines 23 and 47; every 24 lines, at yet another phase. > > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. Arithmetic still works! > > Bob > -- > Bob Jacobsen, LBNL > Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue Mar 8 14:07:24 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Mar 2011 14:07:24 -0700 (MST) Subject: [Rxtx] Latency Woes In-Reply-To: <4D769F30.9050807@gmail.com> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> <4D769F30.9050807@gmail.com> Message-ID: Hi Curtis While not your exact question, a simple test I performed can give you a ballpark idea. Writing a byte to a loopback at 9600 baud and displaying elapsed time on the data available event takes ~10 ms round trip in a large application. There are occasional 20 ms latencies. I used a typical linux desktop to try it just now without any special considerations. Windows NT was a little faster - maybe 8 ms - when I tried several years ago. On Tue, 8 Mar 2011, Curtis Hacker wrote: > Thank you guys, cause I was really worried there. I guess another win for > math today hahaha. So what is the imposed latency that rxtx has ? maybe > 5-10ms ? > > On 03/08/11 13:14, Bob Jacobsen wrote: >> On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >>> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> It's only reading one sensor per line. >> >> Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT >> changed in lines 16 and 40; every 24 lines but at a different phase. >> GramsRev in lines 23 and 47; every 24 lines, at yet another phase. >> >> Looks like (69-1) readings in 1.30 seconds = 19msec per reading. >> Arithmetic still works! >> >> Bob >> -- >> Bob Jacobsen, LBNL >> Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >> JacobsenRG >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Wei.Shen at Honeywell.com Tue Mar 8 15:15:32 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Tue, 8 Mar 2011 17:15:32 -0500 Subject: [Rxtx] [rxtx] disconnect event Message-ID: <83B3B1411349194D9D05821CEF48E78C02284B17@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 16:05:12 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 16:05:12 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 16:26:15 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 15:26:15 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> References: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> Message-ID: <4D76BB17.2090305@gmail.com> So if I could get the baud up 15625, theoretical maximum latency is 1.92ms ? Basically 500 samples/sec ? 125000, theoretical maximum latency is 0.24ms ? Basically 4167 samples/sec ? Keeping the protocol the same. On 03/08/11 15:05, jfh at greenhousepc.com wrote: > Curtis, > > It's nowhere near that bad. I'd measured it once before, and I > believe it's sub-millisecond. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 3:27 pm > To: rxtx at qbang.org > > Thank you guys, cause I was really worried there. I guess another win > for math today hahaha. So what is the imposed latency that rxtx has ? > maybe 5-10ms ? > > On 03/08/11 13:14, Bob Jacobsen wrote: > > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > > It's only reading one sensor per line. > > > > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 > lines. IAT changed in lines 16 and 40; every 24 lines but at a > different phase. GramsRev in lines 23 and 47; every 24 lines, at > yet another phase. > > > > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. > Arithmetic still works! > > > > Bob > > -- > > Bob Jacobsen, LBNL > > Bob_Jacobsen at lbl.gov > +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Tue Mar 8 17:40:36 2011 From: jredman at ergotech.com (Jim Redman) Date: Tue, 08 Mar 2011 17:40:36 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D76BB17.2090305@gmail.com> References: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> <4D76BB17.2090305@gmail.com> Message-ID: <4D76CC84.9040307@ergotech.com> How long does it take the device to generate a response? Increasing the baud rate may not help you much if the device takes a significant amount of time to process the request. On 03/08/2011 04:26 PM, Curtis Hacker wrote: > So if I could get the baud up > 15625, theoretical maximum latency is 1.92ms ? Basically 500 samples/sec ? > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 samples/sec ? > > Keeping the protocol the same. > > On 03/08/11 15:05, jfh at greenhousepc.com wrote: >> Curtis, >> >> It's nowhere near that bad. I'd measured it once before, and I >> believe it's sub-millisecond. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker > >> Date: Tue, March 08, 2011 3:27 pm >> To: rxtx at qbang.org >> >> Thank you guys, cause I was really worried there. I guess another win >> for math today hahaha. So what is the imposed latency that rxtx has ? >> maybe 5-10ms ? >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> > It's only reading one sensor per line. >> > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 >> lines. IAT changed in lines 16 and 40; every 24 lines but at a >> different phase. GramsRev in lines 23 and 47; every 24 lines, at >> yet another phase. >> > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. >> Arithmetic still works! >> > >> > Bob >> > -- >> > Bob Jacobsen, LBNL >> > Bob_Jacobsen at lbl.gov >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 jfh at greenhousepc.com Tue Mar 8 17:58:24 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 17:58:24 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 18:06:04 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 18:06:04 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 18:14:14 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 17:14:14 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> References: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> Message-ID: <4D76D466.7060303@gmail.com> I can edit the ECU eeprom to change the baud rate divisor to bump it up from 1953, to 15625 or 125000. But as Jim asked how fast the device can respond.. not very fast in its stock form. I can recode a lot of the eeprom for the ecu to alter the ecus baud rate, and put the response code into its own interrupt. I just wanted to make sure that in order to lower latency and increase sampling rate. I have to increase the baud rate of the ecu and the user right ? Or change the protocol.. to respond with more sensors per request. On 03/08/11 16:58, jfh at greenhousepc.com wrote: > Unless the ECU can auto-detect the baud rate, it won't even work. > > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Jim Redman > > Date: Tue, March 08, 2011 6:40 pm > To: rxtx at qbang.org > > How long does it take the device to generate a response? > > Increasing the baud rate may not help you much if the device takes a > significant amount of time to process the request. > > > On 03/08/2011 04:26 PM, Curtis Hacker wrote: > > So if I could get the baud up > > 15625, theoretical maximum latency is 1.92ms ? Basically 500 > samples/sec ? > > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 > samples/sec ? > > > > Keeping the protocol the same. > > > > On 03/08/11 15:05, jfh at greenhousepc.com > wrote: > >> Curtis, > >> > >> It's nowhere near that bad. I'd measured it once before, and I > >> believe it's sub-millisecond. > >> -- > >> Julie Haugh > >> Senior Design Engineer > >> greenHouse Computers, LLC // jfh at greenhousepc.com > > >> ; // > greenHousePC on Skype > >> > >> > >> -------- Original Message -------- > >> Subject: Re: [Rxtx] Latency Woes > >> From: Curtis Hacker > > >> Date: Tue, March 08, 2011 3:27 pm > >> To: rxtx at qbang.org > >> > >> Thank you guys, cause I was really worried there. I guess > another win > >> for math today hahaha. So what is the imposed latency that rxtx > has ? > >> maybe 5-10ms ? > >> > >> On 03/08/11 13:14, Bob Jacobsen wrote: > >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > >> > It's only reading one sensor per line. > >> > > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 > >> lines. IAT changed in lines 16 and 40; every 24 lines but at a > >> different phase. GramsRev in lines 23 and 47; every 24 lines, at > >> yet another phase. > >> > > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. > >> Arithmetic still works! > >> > > >> > Bob > >> > -- > >> > Bob Jacobsen, LBNL > >> > Bob_Jacobsen at lbl.gov > > >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > >> > > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Tue Mar 8 18:19:14 2011 From: jredman at ergotech.com (Jim Redman) Date: Tue, 08 Mar 2011 18:19:14 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> References: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> Message-ID: <4D76D592.9000802@ergotech.com> I'm no expert on this, but isn't the underlying ODB-II CAN bus or something similar. They always seem to require a dongle that converts to something. I know you can get serial, bluetooth, USB, etc. converters. I've seen serial dongles that claim multiple baud rates, so I suspect that whatever's providing the conversion may significantly affect the performance. A big second on the required timing comment. I suspect some intelligent consideration of what values change quickly (RPM, Speed, maybe things like fuel pressure) and read values like fuel levels, coolant temps, etc. much less frequently. On 03/08/2011 06:06 PM, jfh at greenhousepc.com wrote: > Curtis, > > You can't just increase the baud rate and have the device adapt to that > rate. Embedded systems tend to have their communications parameters > either hard coded in a memory location or else they are using a hardware > timebase. You're welcome to try increasing the baud rate, but there is > no guarantee it will even work. > > Whoever designed the ECU probably selected the baud rate for a good > reason. My suggestion would be to look at how the sensor values are all > laid out and go from there. Also, look at what the sensor represent and > consider the physical properties of what is being measured. It's > extremely unlikely that, for example, the coolant temperature is going > to rise more than 1* per second. If that much. Some values might change > more often, but do they really matter on a sub-second measurement basis? > > Part of software =engineering= is understanding the problem. Anyone can > sling code in the hope it works. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 5:26 pm > To: rxtx at qbang.org > > So if I could get the baud up > 15625, theoretical maximum latency is 1.92ms ? Basically 500 > samples/sec ? > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 > samples/sec ? > > Keeping the protocol the same. > > On 03/08/11 15:05, jfh at greenhousepc.com wrote: >> Curtis, >> >> It's nowhere near that bad. I'd measured it once before, and I >> believe it's sub-millisecond. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker > > >> Date: Tue, March 08, 2011 3:27 pm >> To: rxtx at qbang.org >> >> Thank you guys, cause I was really worried there. I guess >> another win >> for math today hahaha. So what is the imposed latency that >> rxtx has ? >> maybe 5-10ms ? >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> > It's only reading one sensor per line. >> > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every >> 24 lines. IAT changed in lines 16 and 40; every 24 lines but >> at a different phase. GramsRev in lines 23 and 47; every 24 >> lines, at yet another phase. >> > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per >> reading. Arithmetic still works! >> > >> > Bob >> > -- >> > Bob Jacobsen, LBNL >> > Bob_Jacobsen at lbl.gov >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > ------------------------------------------------------------------------ > _______________________________________________ > Rxtx mailing list > Rxtx 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 jfh at greenhousepc.com Tue Mar 8 18:32:28 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 18:32:28 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 19:45:00 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 18:45:00 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> References: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> Message-ID: <4D76E9AC.8050909@gmail.com> Julie, I really am not looking at the practicality of it. I was just wondering if that is how it works. I don't know a whole lot about rs232, which is the main reason I've been on this mailing list for a couple years. I have full control over the ecu eeprom code, I can change its baud rate, I can re-write the logging interface, I could update the ADC's on the ecu in the interface so that when you request said sensor it updates the ADC then replies it. But I wanted to know if the underlying issue with a 2mhz/8mhz processor is the baud rate keeping sampling down ? On 03/08/11 17:32, jfh at greenhousepc.com wrote: > Curtis, > > You also have to look at the response time of the sensor itself. > > Seriously -- look at what the sensors are reporting and determine if > the underlying physical property can actually change that rapidly. > And even if it can, do you really need to know that. > > I built drag bikes in the 70's and I drive sports cars in my old age. > You don't really need millisecond sampling rates for every single last > sensor coming out of the engine. Boost pressure, fuel pressure, > manifold pressure and RPMs are probably high frequency sensors if you > want to tweak the motor for turbo lag or something, but other than > that, are you really going to be able to make sense of all that data? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 7:14 pm > To: rxtx at qbang.org > > I can edit the ECU eeprom to change the baud rate divisor to bump > it up from 1953, to 15625 or 125000. But as Jim asked how fast the > device can respond.. not very fast in its stock form. > > I can recode a lot of the eeprom for the ecu to alter the ecus > baud rate, and put the response code into its own interrupt. > > I just wanted to make sure that in order to lower latency and > increase sampling rate. I have to increase the baud rate of the > ecu and the user right ? Or change the protocol.. to respond with > more sensors per request. > > On 03/08/11 16:58, jfh at greenhousepc.com wrote: >> Unless the ECU can auto-detect the baud rate, it won't even work. >> >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Jim Redman > > >> Date: Tue, March 08, 2011 6:40 pm >> To: rxtx at qbang.org >> >> How long does it take the device to generate a response? >> >> Increasing the baud rate may not help you much if the device >> takes a >> significant amount of time to process the request. >> >> >> On 03/08/2011 04:26 PM, Curtis Hacker wrote: >> > So if I could get the baud up >> > 15625, theoretical maximum latency is 1.92ms ? Basically 500 >> samples/sec ? >> > 125000, theoretical maximum latency is 0.24ms ? Basically >> 4167 samples/sec ? >> > >> > Keeping the protocol the same. >> > >> > On 03/08/11 15:05, jfh at greenhousepc.com >> wrote: >> >> Curtis, >> >> >> >> It's nowhere near that bad. I'd measured it once before, and I >> >> believe it's sub-millisecond. >> >> -- >> >> Julie Haugh >> >> Senior Design Engineer >> >> greenHouse Computers, LLC // jfh at greenhousepc.com >> >> >> ; // >> greenHousePC on Skype >> >> >> >> >> >> -------- Original Message -------- >> >> Subject: Re: [Rxtx] Latency Woes >> >> From: Curtis Hacker > > >> >> Date: Tue, March 08, 2011 3:27 pm >> >> To: rxtx at qbang.org >> >> >> >> >> Thank you guys, cause I was really worried there. I guess >> another win >> >> for math today hahaha. So what is the imposed latency that >> rxtx has ? >> >> maybe 5-10ms ? >> >> >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> >> > It's only reading one sensor per line. >> >> > >> >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; >> every 24 >> >> lines. IAT changed in lines 16 and 40; every 24 lines but at a >> >> different phase. GramsRev in lines 23 and 47; every 24 >> lines, at >> >> yet another phase. >> >> > >> >> > Looks like (69-1) readings in 1.30 seconds = 19msec per >> reading. >> >> Arithmetic still works! >> >> > >> >> > Bob >> >> > -- >> >> > Bob Jacobsen, LBNL >> >> > Bob_Jacobsen at lbl.gov >> >> >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Rxtx mailing list >> >> > Rxtx at qbang.org >> >> >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > ------------------------------------------------------------------------ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 20:43:11 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 20:43:11 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308204311.8ef0e5b4a80cef441275a6330ffad77d.e9b135168c.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From andrea.antonello at gmail.com Wed Mar 9 06:50:07 2011 From: andrea.antonello at gmail.com (andrea antonello) Date: Wed, 9 Mar 2011 14:50:07 +0100 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> References: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> Message-ID: Has anyone tried the lib? I am not sure if it is appropriate to write to the list about this, if not, I apologize. I wanted to try your fork out for our application which is an eclipse rcp plugin based one. It has been easy to substitute the 6 plugins with your library (that is one of the things I like). But then when I run it, it tries to load it from: ---- Loading: /tmp/libNRJavaSerial_moovida_0/libNRJavaSerial.so Trying to load: NRJavaSerial Trying to load: libNRJavaSerial Trying to load: rxtxSerial ---- So it is extracting the native lib to a tmp folder. But that one is not in the library path, so it fails. Is there any docs to try the lib out? Thanks, Andrea On Mon, Mar 7, 2011 at 11:54 PM, wrote: > Aaron, > > It should be possible for an Android to do BlueTooth serial.? If I were > looking for a serial solution, that's how I'd go. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on > Skype > > -------- Original Message -------- > Subject: [SPAM] Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > papercuts! > From: Aaron Wolfe > Date: Mon, March 07, 2011 4:31 pm > To: rxtx at qbang.org > > On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR > wrote: >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> >> * Self deployment of native libraries ( all native code is stored >> inside the jar and deployed at runtime). No more manual install of >> native code. >> * Arm Cortex support (Gumstix) >> * Android Support (requires a rooted phone for now) >> * Google Code (SVN) repository for easy code and jar access >> * Single makefile compile (simplifies the compilation of project binaries) >> * Ant build script for jar creation >> * Removal of partialy implemented code to streamline the lib for just >> serial port access >> * Full Eclipse integration, for testing application code against sources. >> >> And a bunch of bug fixes: >> >> * Fixed the memory access error that causes OSX to crash the JVM when >> serial.close() is cvalled >> * Fixed the windows serial port zombie bind that prevents re-accessing >> serial ports when exiting on an exception >> * Fixed erronious printouts of native library mis-match >> >> To check it out, take a look at our page here: >> >> http://code.google.com/p/nrjavaserial/ > > This is interesting, getting the native libs set up has been an issue > for some of my users. Will have to check it out. > > Out of curiosity, what Android devices provide a serial port? Or are > there some that allow USB host mode and then a usb-serial adapter? I > have only an Android cell phone, don't think it can do anything serial > but would love to be wrong 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 Kustaa.Nyholm at planmeca.com Tue Mar 1 00:54:17 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 09:54:17 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> Message-ID: Adrian, had a look at your code/rewrite and it looks rather clean/nice. I was looking at the code to gain insight (not related to the rewrite) into what is involved in serial port programming in Windows. Or rather, to refresh my memory and see how others have done, because I've been there done that. So my questions are just to satisfy my curiosity, not to criticize or suggest improvements. 1) It looks like a new thread (EventMonitor) is created for each Serial port, is that correct? Many people seem to try to avoid using many threads in this sort of situation, and like to use something like unix select(). I personally find using threads more natural and better impedance match to the problem being solved here. I guess 'many people' above refers to those implementing thousands of connections and who cannot live with the overhead and limited number of threads available. 2) The EventMonitor basically polls for events at 50 msec interval? 3) There is a comment in the source code near the sleep(50) : // Sufficient up to 19200 baud I'm sure you thought about this carefully, so again not criticizing, but seeking to understand how or why, because at 50 msec would seem to limit through in some cases. Like if you send one byte and need to wait for one to return, then this limits speed to 200 chars/sec? 4) I've done something similar to a few years back from Java using JNI to access Win32 API serial port, and I seem to recall that I had threading issues ie when I submitted a read (ReadFile) and there was no data coming in, the thread would not only block but also consume a lot of CPU cycles ie it was not sleeping properly inside the ReadFile call when the serial port blocked. Im a bit fuzzy about the details after five years, so my question is have you checked if there an issue here? 5) AFAIK the select() on Windows does not work serial ports but there is some other mechanism (events?) to implement the same functionality, did you consider that? Probably, so you decided against it, why? br Kusti From adrian.crum at sandglass-software.com Tue Mar 1 04:13:34 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:13:34 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: References: Message-ID: <4D6CD4DE.7040501@sandglass-software.com> The javax.comm API specification requires one event monitor thread per port. I don't like the idea of having a thread per port either, but one of the rewrite's design goals is strict conformance to the specification. The 50 mS polling interval is just a placeholder. The final design of that is yet to be decided. In Windows, you have two choices for I/O: overlapped and non-overlapped. In overlapped I/O a thread is blocked, waiting for something to happen. In non-overlapped I/O a thread does not block. I chose non-overlapped I/O to avoid thread blocking at the OS level - instead, the thread blocking is kept in Java. -Adrian On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > Adrian, > > had a look at your code/rewrite and it looks rather clean/nice. > > I was looking at the code to gain insight (not related to the > rewrite) into what is involved in serial port programming > in Windows. Or rather, to refresh my memory and see how others have > done, because I've been there done that. > > So my questions are just to satisfy my curiosity, not to criticize > or suggest improvements. > > 1) It looks like a new thread (EventMonitor) is created for > each Serial port, is that correct? > > Many people seem to try to avoid using many threads in this sort > of situation, and like to use something like unix select(). > I personally find using threads more natural and better impedance > match to the problem being solved here. I guess 'many people' above > > refers to those implementing thousands of connections and > who cannot live with the overhead and limited number of threads > available. > > 2) The EventMonitor basically polls for events at 50 msec interval? > > 3) There is a comment in the source code near the sleep(50) : > > // Sufficient up to 19200 baud > > > I'm sure you thought about this carefully, so again not > criticizing, but seeking to understand how or why, because > at 50 msec would seem to limit through in some cases. Like > if you send one byte and need to wait for one to return, > then this limits speed to 200 chars/sec? > > 4) I've done something similar to a few years back from > Java using JNI to access Win32 API serial port, and > I seem to recall that I had threading issues ie when > I submitted a read (ReadFile) and there was no data coming > in, the thread would not only block but also consume a > lot of CPU cycles ie it was not sleeping properly inside > the ReadFile call when the serial port blocked. > > Im a bit fuzzy about the details after five years, so my question is > have you checked if there an issue here? > > > 5) AFAIK the select() on Windows does not work serial ports > but there is some other mechanism (events?) to implement the > same functionality, did you consider that? Probably, so you > decided against it, why? > > > br Kusti > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Tue Mar 1 04:25:23 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:25:23 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C2E90.9010601@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > My question would be: Why would you do that? The rewrite does > most of the work for you - all you have to do is implement > two C++ virtual classes and two C++ functions. You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? I just took a short look, maybe it could be discussed further, but I don't think I like it much. BTW, the main interface defined there is called gnu.io.Dispatcher? I thought the package names should be used in a way to avoid clashes, e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name space authority :)). > In Windows that took me a few hours. where is the implementation? I found commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp with things like const bool SerialPortImpl::isDataAvailable() const { // Needs implementation return true; } and timeouts.ReadIntervalTimeout = MAXDWORD;* timeouts.ReadTotalTimeoutMultiplier = 0; timeouts.ReadTotalTimeoutConstant = 0; timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 0; if (!SetCommTimeouts(hComm, &timeouts)) throw IOException(); which seems to be oversimplified or some prototype only? I think (and I wrote about this already in the past years) that correct timeout handling is one of the challenges, so I think this should be prototyped first - for each system flavor - before cementation of the (JNI-) interfaces. Personally, I would vote to form it in a way allowing to be implemented on embedded devices, for example. Another big challenge is to prove a rewrite fully working (and probably compatible to the old implementation) on "all" the supported OSes. Not a big problem for linux and windows, just use some thousand lines test code, test drivers and serial loopbacks etc, but for the exotic platforms, probably a high number of, this probably won't be too easy... (there are more challenges, such as being comfortable and threadsafe [are read and write permitted at the same time?], detailed and helpful exceptions on user API level [not necessarily on JNI/JNA layer], how to have a configurable threadsafe logging/tracing [maybe also from native code to assist porting / testing on exotic OSes, such as OSes where the developers have no direct access too, which can be quite hard to usually leads to good log messages], just to name a few.). So even it might seem easy for one platform and I agree with Micheal that > > * yay! let's start a rewrite is unlikely to succeede soon... However, when considering this, before IMHO a powerful Java API has to be defined, because according to my experiences for implementing non-trivial protocols InputStream/OutputStream might not be comfortable/powerfull enough (eventually I consider both wrong) and have some InputStream derivation available as wrapper (so applications can use InputStream and whatever high-level-API they want). The JNI interface shall make such a powerful implementation possible, thus the interface of it is driving the JNI interface design and thus I think it had to be done first. All this surely requires much work: agreements on the APIs, safeness for the users, design, documentation, all the implementations and the testing. As long as such bug amount of work cannot be spent, for example if some employee would get half a year time paid for it or so :-), probably it is unlikely to progress on this. Otherwise, I'm afraid, patches, improvements, new design ideas and even rewrites wouldn't become complete and thus won't form a new rxtx version (3.0); thus either collect dust in some forgotten CVS branch or could generate a split... > I can't imagine other ports taking > much longer than that - especially since POSIX-based code can > be shared between ports. Things are more complex than they seem to be... I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select on serial ports isn't supported; maybe it is non-trivial to "map" (like mapping select() to WaitForMultipleObjects() which might have different semantics etc.) or maybe some different approach has to be used. A system may have POSIX like termios interfaces but not support timeouts or have any other interoperability bug... You never run out of things that can go wrong. And if something can go wrong, it will... :-) Or, as Michael wrote: > > I seriously don't believe anyone will come up with anything better anytime soon. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue Mar 1 04:39:37 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:39:37 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com><13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED6B@COSNPREXC3.usr.ingenico.loc> > 3. Write all of the native (or non-native) code to implement > the native interface. > > Is that correct? If yes, how is that easier than the simple > implementation the current rewrite design uses? To have it complete, reliable, traceable, maintainable and well tested, it is much more work, I'm afraid. A prototype can be done within a few days (maybe on one day), but getting it right (including a passed review) IMHO is a completely different story. In the end you may end up with an average of ten lines per day, when assuming four major native packs (common, win, mac, termios/select) with let's say just 5000 lines each (with logging messages and detailed exceptions this is not much) we would have to estimate a total effort of nine man-years (20000/10/220)... oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 04:40:18 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:40:18 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6CDB22.9070401@sandglass-software.com> Every journey begins with a single step. -Adrian On 3/1/2011 3:25 AM, Steffen DETTMER wrote: > * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> My question would be: Why would you do that? The rewrite does >> most of the work for you - all you have to do is implement >> two C++ virtual classes and two C++ functions. > You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? > I just took a short look, maybe it could be discussed further, > but I don't think I like it much. > BTW, the main interface defined there is called gnu.io.Dispatcher? > I thought the package names should be used in a way to avoid clashes, > e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name > space authority :)). > >> In Windows that took me a few hours. > where is the implementation? > I found > commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp > with things like > > const bool SerialPortImpl::isDataAvailable() const > { > // Needs implementation > return true; > } > > and > > timeouts.ReadIntervalTimeout = MAXDWORD;* > timeouts.ReadTotalTimeoutMultiplier = 0; > timeouts.ReadTotalTimeoutConstant = 0; > timeouts.WriteTotalTimeoutMultiplier = 0; > timeouts.WriteTotalTimeoutConstant = 0; > if (!SetCommTimeouts(hComm,&timeouts)) > throw IOException(); > > which seems to be oversimplified or some prototype only? > > I think (and I wrote about this already in the past years) that correct > timeout handling is one of the challenges, so I think this should be > prototyped first - for each system flavor - before cementation of the > (JNI-) interfaces. Personally, I would vote to form it in a way allowing > to be implemented on embedded devices, for example. > > Another big challenge is to prove a rewrite fully working (and probably > compatible to the old implementation) on "all" the supported OSes. Not a > big problem for linux and windows, just use some thousand lines test > code, test drivers and serial loopbacks etc, but for the exotic > platforms, probably a high number of, this probably won't be too easy... > (there are more challenges, such as being comfortable and threadsafe > [are read and write permitted at the same time?], detailed and helpful > exceptions on user API level [not necessarily on JNI/JNA layer], how to > have a configurable threadsafe logging/tracing [maybe also from native > code to assist porting / testing on exotic OSes, such as OSes where the > developers have no direct access too, which can be quite hard to usually > leads to good log messages], just to name a few.). > > So even it might seem easy for one platform and I agree with Micheal > that > >>> * yay! let's start a rewrite > is unlikely to succeede soon... > > However, when considering this, before IMHO a powerful Java API has to > be defined, because according to my experiences for implementing > non-trivial protocols InputStream/OutputStream might not be > comfortable/powerfull enough (eventually I consider both wrong) and have > some InputStream derivation available as wrapper (so applications can > use InputStream and whatever high-level-API they want). > The JNI interface shall make such a powerful implementation possible, > thus the interface of it is driving the JNI interface design and thus I > think it had to be done first. > > All this surely requires much work: agreements on the APIs, safeness for > the users, design, documentation, all the implementations and the > testing. As long as such bug amount of work cannot be spent, for example > if some employee would get half a year time paid for it or so :-), > probably it is unlikely to progress on this. > > Otherwise, I'm afraid, patches, improvements, new design ideas and even > rewrites wouldn't become complete and thus won't form a new rxtx version > (3.0); thus either collect dust in some forgotten CVS branch or could > generate a split... > >> I can't imagine other ports taking >> much longer than that - especially since POSIX-based code can >> be shared between ports. > Things are more complex than they seem to be... > > I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select > on serial ports isn't supported; maybe it is non-trivial to "map" (like > mapping select() to WaitForMultipleObjects() which might have different > semantics etc.) or maybe some different approach has to be used. A > system may have POSIX like termios interfaces but not support timeouts > or have any other interoperability bug... > You never run out of things that can go wrong. And if something can go > wrong, it will... :-) > > Or, as Michael wrote: > >>> I seriously don't believe anyone will come up with anything better > anytime soon. > > oki, > > Steffen > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Kustaa.Nyholm at planmeca.com Tue Mar 1 04:57:02 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 13:57:02 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: On 3/1/11 13:13, "Adrian Crum" wrote: >The javax.comm API specification requires one event monitor thread per >port. I don't like the idea of having a thread per port either, but one >of the rewrite's design goals is strict conformance to the specification. Ah, had not spotted that requirement. > >The 50 mS polling interval is just a placeholder. The final design of >that is yet to be decided. > >In Windows, you have two choices for I/O: overlapped and non-overlapped. >In overlapped I/O a thread is blocked, waiting for something to happen. >In non-overlapped I/O a thread does not block. I chose non-overlapped >I/O to avoid thread blocking at the OS level - instead, the thread >blocking is kept in Java. > >-Adrian thanks for the explanation. br Kusti From iqzw2r602 at sneakemail.com Tue Mar 1 05:08:17 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:08:17 +1100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <32684-1298981297-704398@sneakemail.com> This reminds me of a nasty problem I had with overlapped I/O on windows with jpathwatch. You can't start an I/O request in one thread and then do the check if that request completed in another thread. Very strange things happen when you attempt that; made me change the design of the Windows implementation quite drastically (one thread on a command queue that executes requests from other threads instead of letting them wildly call into GetOverlappedResult()). Out of curiosity: Did you come across that too? Or are all requests handled in the same thread they're issued? Cheers, Uwe On Tue, Mar 1, 2011 at 10:13 PM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > The javax.comm API specification requires one event monitor thread per > port. I don't like the idea of having a thread per port either, but one of > the rewrite's design goals is strict conformance to the specification. > > The 50 mS polling interval is just a placeholder. The final design of that > is yet to be decided. > > In Windows, you have two choices for I/O: overlapped and non-overlapped. In > overlapped I/O a thread is blocked, waiting for something to happen. In > non-overlapped I/O a thread does not block. I chose non-overlapped I/O to > avoid thread blocking at the OS level - instead, the thread blocking is kept > in Java. > > -Adrian > > > On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > >> Adrian, >> >> had a look at your code/rewrite and it looks rather clean/nice. >> >> I was looking at the code to gain insight (not related to the >> rewrite) into what is involved in serial port programming >> in Windows. Or rather, to refresh my memory and see how others have >> done, because I've been there done that. >> >> So my questions are just to satisfy my curiosity, not to criticize >> or suggest improvements. >> >> 1) It looks like a new thread (EventMonitor) is created for >> each Serial port, is that correct? >> >> Many people seem to try to avoid using many threads in this sort >> of situation, and like to use something like unix select(). >> I personally find using threads more natural and better impedance >> match to the problem being solved here. I guess 'many people' above >> >> refers to those implementing thousands of connections and >> who cannot live with the overhead and limited number of threads >> available. >> >> 2) The EventMonitor basically polls for events at 50 msec interval? >> >> 3) There is a comment in the source code near the sleep(50) : >> >> // Sufficient up to 19200 baud >> >> >> I'm sure you thought about this carefully, so again not >> criticizing, but seeking to understand how or why, because >> at 50 msec would seem to limit through in some cases. Like >> if you send one byte and need to wait for one to return, >> then this limits speed to 200 chars/sec? >> >> 4) I've done something similar to a few years back from >> Java using JNI to access Win32 API serial port, and >> I seem to recall that I had threading issues ie when >> I submitted a read (ReadFile) and there was no data coming >> in, the thread would not only block but also consume a >> lot of CPU cycles ie it was not sleeping properly inside >> the ReadFile call when the serial port blocked. >> >> Im a bit fuzzy about the details after five years, so my question is >> have you checked if there an issue here? >> >> >> 5) AFAIK the select() on Windows does not work serial ports >> but there is some other mechanism (events?) to implement the >> same functionality, did you consider that? Probably, so you >> decided against it, why? >> >> >> br Kusti >> >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 05:37:07 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:37:07 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <1142-1298983027-957144@sneakemail.com> On Tue, Mar 1, 2011 at 1:32 PM, Adrian Crum wrote: > Just to make sure I'm understanding you correctly, anyone porting RxTx to > a new platform would have to do the following: > > 1. Write their own Java implementation of an abstract Dispatcher class. > yep. I'd probably put all my calls to native OS wrappers in there two, looks the most straight-forward to me. > 2. Write a native (JNI or JNA) interface for the abstract class > implementation. > yes. For POSIX you'd probably only write one piece of code that provides implementations for open(), close(), and friends. You can compile that on all posix platforms (yeah, the devil is in the detail, but it's very little code, still). So this does open() (when using ***, but you can also use +++) // Unix.java class Unix{ public static native int open(String filename, int flags, int mode); .... } // Unix.cpp JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) { const char* pathname = env->GetStringUTFChars(jpathname, 0); if(pathname == 0) return -1; // java throws an out of memory error in this case int result = open(pathname, flags, mode); Unix_cacheErrno(); // handle interference between JVM and errno; env->ReleaseStringUTFChars(jpathname, pathname); return result; } .... 3. Write all of the native (or non-native) code to implement the native > interface. > Not sure what you mean by that. I've done the OS wrappers in step 2. step 1. implements that Dispatcher. What else do I need? > Is that correct? If yes, how is that easier than the simple implementation > the current rewrite design uses? > Yes, except for 3 (see above). How it is easier: I can debug the Java code directly. I can step from the read() call of an input stream directly into the guts of the RXTX implementation on my platform and see e.g. why it's hanging, because I see all the way up the call stack right where it calls Unix.read(). You can't easily do that with a fat native library, especially if you have no second set of devtools installed (the ones for native development). And I bet anyone knowing both languages can write it faster in Java, with less bugs. > On a side note: there is no requirement to write native code using C++. If > C++ is a real obstacle to adoption, then regular C could be used instead. In > that case, there would be a Dispatcher.c file that contains function > protoypes that need to be implemented. Dispatcher.c would still maintain the > same role as Dispatcher.cpp - which is to shield native code developers from > the details of JNI. Just build out the missing functions using C data types > and you're ready to go. > As I said, whatever works for you. Java works for me better than C++ in this case... Cheers, Uwe -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Mar 1 08:26:41 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 16:26:41 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> > The javax.comm API specification requires one event monitor > thread per port. Where does it require this? Do you mean "All the events received by this listener are generated by one dedicated thread that belongs to the SerialPort object. "? I think this is an implementation detail, isn't it? At least it is mentioned after "The current implementation only allows one listener per SerialPort". A bit bad that javadoc does not distinguish between API spec and implementation documentation. Also I don't think that TooManyListenersException MUST be thrown (I think it CAN be thrown). > I don't like the idea of having a thread per > port either, but one of the rewrite's design goals is strict > conformance to the specification. (but not necessarily on JNI layer) > The 50 mS polling interval is just a placeholder. The final > design of that is yet to be decided. I though no polling would be wanted; what could be the placeholder stand for? Do you mean a different interval duration or do you mean something completely different? > In Windows, you have two choices for I/O: overlapped and > non-overlapped. > In overlapped I/O a thread is blocked, waiting for something > to happen. > In non-overlapped I/O a thread does not block. I chose > non-overlapped I/O to avoid thread blocking at the OS level - > instead, the thread blocking is kept in Java. Isn't "overlapped" (asynchronous) I/O meaning that you invoke some ReadFile(..., &overlapped, ...) INSTEAD of performing a synchronous (blocking) function call blocking the thread? As far as I see, W32_Support.cpp uses CreateFile without FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O operations are serialized, even if the calls to the read and write functions specify an OVERLAPPED structure." [1] and "A synchronous handle behaves such that I/O function calls using that handle are blocked until they complete" [2] Given that CCOMTIMEOUTS get: "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the bytes that have already been received, even if no bytes have been received." [3] It looks likes this implementation relies on polling, which probably would waste much computing power. What did I miss? oki, Steffen [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro nous_and_asynchronous_i_o_handles [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 09:23:47 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:23:47 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6D1D93.6090306@sandglass-software.com> Unfortunately, the javax.comm API specification includes a lot of implementation details. That is one of the weaknesses of the specification in my opinion. The bottom line is, anyone wanting to use RxTx as a javax.comm implementation is going to expect it to do the things the specification says it does. -Adrian On 3/1/2011 7:26 AM, Steffen DETTMER wrote: >> The javax.comm API specification requires one event monitor >> thread per port. > Where does it require this? > > Do you mean "All the events received by this listener are generated > by one dedicated thread that belongs to the SerialPort object. "? > > I think this is an implementation detail, isn't it? At least it is > mentioned after "The current implementation only allows one listener per > SerialPort". A bit bad that javadoc does not distinguish between API > spec and implementation documentation. Also I don't think that > TooManyListenersException MUST be thrown (I think it CAN be thrown). > >> I don't like the idea of having a thread per >> port either, but one of the rewrite's design goals is strict >> conformance to the specification. > (but not necessarily on JNI layer) > >> The 50 mS polling interval is just a placeholder. The final >> design of that is yet to be decided. > I though no polling would be wanted; what could be the placeholder stand > for? Do you mean a different interval duration or do you mean something > completely different? > >> In Windows, you have two choices for I/O: overlapped and >> non-overlapped. >> In overlapped I/O a thread is blocked, waiting for something >> to happen. >> In non-overlapped I/O a thread does not block. I chose >> non-overlapped I/O to avoid thread blocking at the OS level - >> instead, the thread blocking is kept in Java. > Isn't "overlapped" (asynchronous) I/O meaning that you invoke some > ReadFile(...,&overlapped, ...) > INSTEAD of performing a synchronous (blocking) function call blocking > the thread? > > As far as I see, W32_Support.cpp uses CreateFile without > FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O > operations are serialized, even if the calls to the read and write > functions specify an OVERLAPPED structure." [1] and "A synchronous > handle behaves such that I/O function calls using that handle are > blocked until they complete" [2] > > Given that CCOMTIMEOUTS get: > "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values > for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier > members, specifies that the read operation is to return immediately with > the bytes that have already been received, even if no bytes have been > received." [3] > > It looks likes this implementation relies on polling, which probably > would waste much computing power. > > What did I miss? > > oki, > > Steffen > > [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx > [2] > http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro > nous_and_asynchronous_i_o_handles > [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at sandglass-software.com Tue Mar 1 09:55:29 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:55:29 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <1142-1298983027-957144@sneakemail.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> Message-ID: <4D6D2501.1020803@sandglass-software.com> That code duplicates what is in Dispatcher.cpp. A Unix port would only need to implement CommPortFactory::getInstance(portName, portType). -Adrian On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 15:07:46 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 2 Mar 2011 09:07:46 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6D2501.1020803@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> <4D6D2501.1020803@sandglass-software.com> Message-ID: <23749-1299017266-991798@sneakemail.com> What is this duplicating? A Unix port will need to call open() anyways (just so we're talking about the same thing here: open() is the Unix equivalent of CreateFile()) On Wed, Mar 2, 2011 at 3:55 AM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > That code duplicates what is in Dispatcher.cpp. A Unix port would only > need to implement CommPortFactory::getInstance(portName, portType). > > -Adrian > > > On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Tue Mar 1 22:53:07 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 00:53:07 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: Hi, I haven't seen any response to my question below. Is this not the right place to ask? If not, where would be a better place to ask? Any suggestions? Thanks, Ryan On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >> Hi, >> >> I have a receive thread that does nothing but call read() on the serial >> port input stream. It works fine for a while but after running for a long >> time it eventually returns -1 which means EOF. This is my first problem, as >> the device I'm talking to runs forever, I don't know why it would return -1. >> I am calling disableReceiveThreshold() and disableReceiveTimeout() at >> initialization which according to the documentation means read will return >> as soon as any data is available and it will block forever when data is not >> available, so -1 should never be returned from read, right? >> >> I have been unable to figure out why read returns -1 after a long while >> but I have found that if I kill my application and restart it everything >> works fine again. Therefore I tried to work around the problem by having my >> code close the port and reopen it when read returns -1. My second problem is >> that in this case when I call close() on the port it blocks forever. I did >> find this old bug >> >> http://bugzilla.qbang.org/show_bug.cgi?id=53 >> >> which describes close() hanging on OSX, but it says that bug was fixed >> with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have >> any idea why read might be returning -1 in the first place? If I can avoid >> that I don't care about close() hanging because I would never close the >> port. If not, does anyone know why close() might block forever and how I can >> prevent this? I'm using RXTX version 2.1-7. >> >> Thanks, >> -- >> Ryan >> >> > > > -- > Ryan Boder > 1 614 598-6339 > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Mar 2 01:34:48 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 2 Mar 2011 10:34:48 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/2/11 07:53, "Ryan Boder" wrote: Can you / have you made a simple test to ensure that rxtx is the issue? Can you write a simple C-program to see if this exhibits the same problem? I've never encountered this sort of problem with rxtx, it mostly just works. But I'm on Mac so can't say about Windows (7) br Kusti >Hi, > >I haven't seen any response to my question below. Is this not the right >place to ask? If not, where would be a better place to ask? Any >suggestions? > >Thanks, >Ryan > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > >I mis-spoke, I don't have my own thread calling read, I am calling >read in the event handler after receiving a >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be >accurate though. > >Ryan > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >Hi, > >I have a receive thread that does nothing but call read() on the serial >port input stream. It works fine for a while but after running for a long >time it eventually returns -1 which means EOF. This is my first problem, >as the device I'm talking to runs forever, I don't know why it would >return -1. I am calling disableReceiveThreshold() and >disableReceiveTimeout() at initialization which according to the >documentation means read will return as soon as any data is available and >it will block forever when data is not available, so -1 should never be >returned from read, right? > >I have been unable to figure out why read returns -1 after a long while >but I have found that if I kill my application and restart it everything >works fine again. Therefore I tried to work around the problem by having >my code close the port and reopen it when read returns -1. My second >problem is that in this case when I call close() on the port it blocks >forever. I did find this old bug > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > >which describes close() hanging on OSX, but it says that bug was fixed >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone >have any idea why read might be returning -1 in the first place? If I can >avoid that I don't care about close() hanging because I would never close >the port. If not, does anyone know why close() might block forever and >how I can prevent this? I'm using RXTX version 2.1-7. > >Thanks, >-- >Ryan > > > > > > > > > >-- >Ryan Boder >1 614 598-6339 > > > > > > >-- >Ryan Boder >1 614 598-6339 > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From Steffen.DETTMER at ingenico.com Wed Mar 2 03:08:57 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:08:57 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <32684-1298981297-704398@sneakemail.com> References: <4D6CD4DE.7040501@sandglass-software.com> <32684-1298981297-704398@sneakemail.com> Message-ID: <20110302100857.GB8030@elberon.bln.de.ingenico.com> * iqzw2r602 at sneakemail.com wrote on Tue, Mar 01, 2011 at 23:08 +1100: > This reminds me of a nasty problem I had with overlapped I/O on windows Yeah, those thousands of complex, difficult to use and exception-containing WinAPI is really hard to use... About strange effects on overlapped&multithreading, MSDN has: `the calling thread uses the GetOverlappedResult function or one of the wait functions' [1] also also mentiones I/O Completion Ports [2], and later continues: `If an application reuses OVERLAPPED structures on multiple threads and calls GetOverlappedResult with the bWait parameter set to TRUE, the application must ensure that the associated event is set before the application reuses the structure. This can be accomplished by using the WaitForSingleObject function after calling GetOverlappedResult to force the thread to wait until the operation completes. Note that the event object must be a manual-reset event object. If an autoreset event object is used, calling GetOverlappedResult with the bWait parameter set to TRUE causes the function to be blocked indefinitely.' also [1] oki, Steffen [1] http://msdn.microsoft.com/en-us/library/ms686358%28v=vs.85%29.aspx [2] http://msdn.microsoft.com/en-us/library/aa365198%28v=vs.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:15:11 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:15:11 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6D1D93.6090306@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> <4D6D1D93.6090306@sandglass-software.com> Message-ID: <20110302101511.GC8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 08:23 -0800: > Unfortunately, the javax.comm API specification includes a lot of > implementation details. That is one of the weaknesses of the > specification in my opinion. The bottom line is, anyone wanting to use > RxTx as a javax.comm implementation is going to expect it to do the > things the specification says it does. Yeah ok, but even then the implementation could check for the TooManyListenersException situations (if it really is required to support applications relying on that exception) but internally use just a single I/O thread waiting for events on any open file descriptors. Of course an implementation supporting all sort of concurrency could become quite complex (especially if open-read-close should work fast, I think would be difficult to implement, because a new file descriptors had to be added to the waitFor/select list, and who knows how systems behave here in detail...). oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:25:15 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:25:15 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6CDB22.9070401@sandglass-software.com> References: <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> <4D6CDB22.9070401@sandglass-software.com> Message-ID: <20110302102515.GD8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 03:40 -0800: > * from some older mail: > > My question would be: Why would you do that? The rewrite does > > most of the work for you - all you have to do is implement > > two C++ virtual classes and two C++ functions. > > > > In Windows that took me a few hours. > > Every journey begins with a single step. Yes, of course, but then it shouldn't be used as base for new effort estimations like `In Windows that took a few hours' ;-) (BTW, calling a single step `the rewrite' may sound a bit ambitious ;)) But of course a prototype demonstrating something can be really helpful, sure. I just wanted to tell that interfaces should be easy to use and powerful at the same time and may non-trivial initial considerations before starting to implement them. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From ryan.boder at gmail.com Wed Mar 2 18:44:35 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:44:35 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: While running the tests you requested I may have stumbled on the problem, I just don't know how to fix it. According to the documentation, if both the receive timeout and receive threshold are disabled then read() should block forever until data is available. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#getInputStream%28%29 On my system using RXTX read() is returning -1 when no data is available even though I have disabled both thresholds. The reason my program was running fine for a while without this problem showing up is that I was using the DATA_AVAILABLE event to be notified when data is available and only calling read() to read an entire frame whenever the DATA_AVAILABLE event occurred, until eventually my device (I'm guessing) probably took longer than normal to send the entire data frame and therefore I called read when no data was available and it returned -1. The following Java program demonstrates my problem, it returns -1 as soon as no data is available, even though I think it should block until data is available. import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; public class Main implements SerialPortEventListener { public static void main(String[] args) throws Exception { new Main().run(); } private void run() throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier("COM4"); SerialPort port = (SerialPort) portIdentifier.open(Main.class.getName(), 2000); port.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); port.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); port.disableReceiveThreshold(); port.disableReceiveTimeout(); BufferedInputStream in = new BufferedInputStream(port.getInputStream()); BufferedOutputStream out = new BufferedOutputStream(port.getOutputStream()); port.addEventListener(this); Thread.sleep(1000); out.write(new byte[] {0x02, 0x60}); out.flush(); while (true) { int x = in.read(); if (x == -1) { System.out.println("EOF"); Thread.sleep(1000000000); } String s = Integer.toHexString(x & 0xFF); if (s.length() == 1) s = "0" + s; System.out.print(s + " "); System.out.flush(); } } public void serialEvent(SerialPortEvent arg0) { System.out.println("Serial port event"); } } However, the follow C# program ran all day today without ever read ever returning -1, as I would expect. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.IO.Ports; using System.Threading; namespace RXTXReadTest1 { class Program { static void Main(string[] args) { new Program().run(); } private void run() { SerialPort port = new SerialPort("COM4", 19200, Parity.None, 8, StopBits.One); port.Open(); port.Write(new byte[] { 0x02, 0x60 }, 0, 2); while (true) { int x = port.ReadByte(); if (x == -1) { Console.WriteLine("EOF"); Thread.Sleep(1000000000); } String s = x.ToString("X"); if (s.Length == 1 ) s = "0" + s; Console.Out.Write(s + " "); Console.Out.Flush(); } } } } Now I am experimenting with what happens if I set the receive timeout to it's maximum value (apparently 1600ms) and only call read() when I am expecting data. Hopefully it will never be more than 1600ms late. This is still only a work around, not solving the problem. Am I doing something wrong in my code above or is RXTX retuning -1 when it should be blocking? Thanks, Ryan On Wed, Mar 2, 2011 at 3:34 AM, Kustaa Nyholm wrote: > On 3/2/11 07:53, "Ryan Boder" wrote: > Can you / have you made a simple test to ensure that rxtx is the issue? > > Can you write a simple C-program to see if this exhibits the same problem? > > I've never encountered this sort of problem with rxtx, it mostly just > works. > > But I'm on Mac so can't say about Windows (7) > > br Kusti > > > > > >Hi, > > > >I haven't seen any response to my question below. Is this not the right > >place to ask? If not, where would be a better place to ask? Any > >suggestions? > > > >Thanks, > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder > wrote: > > > >I mis-spoke, I don't have my own thread calling read, I am calling > >read in the event handler after receiving a > >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be > >accurate though. > > > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder > wrote: > > > >Hi, > > > >I have a receive thread that does nothing but call read() on the serial > >port input stream. It works fine for a while but after running for a long > >time it eventually returns -1 which means EOF. This is my first problem, > >as the device I'm talking to runs forever, I don't know why it would > >return -1. I am calling disableReceiveThreshold() and > >disableReceiveTimeout() at initialization which according to the > >documentation means read will return as soon as any data is available and > >it will block forever when data is not available, so -1 should never be > >returned from read, right? > > > >I have been unable to figure out why read returns -1 after a long while > >but I have found that if I kill my application and restart it everything > >works fine again. Therefore I tried to work around the problem by having > >my code close the port and reopen it when read returns -1. My second > >problem is that in this case when I call close() on the port it blocks > >forever. I did find this old bug > > > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > > > >which describes close() hanging on OSX, but it says that bug was fixed > >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone > >have any idea why read might be returning -1 in the first place? If I can > >avoid that I don't care about close() hanging because I would never close > >the port. If not, does anyone know why close() might block forever and > >how I can prevent this? I'm using RXTX version 2.1-7. > > > >Thanks, > >-- > >Ryan > > > > > > > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Wed Mar 2 18:46:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:46:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: <-1051064942000733580@unknownmsgid> References: <-1051064942000733580@unknownmsgid> Message-ID: It is USB and seems very reliable with the C# test program in my previous email. On Wed, Mar 2, 2011 at 6:58 PM, Bruce Griffith wrote: > How reliable is your serial port ? is it USB or Bluetooth? > > > > Bruce Griffith > > 303-532-4778 > > > > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On Behalf > Of *Ryan Boder > *Sent:* Tuesday, 01 March 2011 10:53 PM > *To:* rxtx at qbang.org > *Subject:* Re: [Rxtx] RXTX serial port read() returns -1 unexpectedly and > then blocks forever on close() > > > > Hi, > > I haven't seen any response to my question below. Is this not the right > place to ask? If not, where would be a better place to ask? Any suggestions? > > Thanks, > Ryan > > On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > > Hi, > > I have a receive thread that does nothing but call read() on the serial > port input stream. It works fine for a while but after running for a long > time it eventually returns -1 which means EOF. This is my first problem, as > the device I'm talking to runs forever, I don't know why it would return -1. > I am calling disableReceiveThreshold() and disableReceiveTimeout() at > initialization which according to the documentation means read will return > as soon as any data is available and it will block forever when data is not > available, so -1 should never be returned from read, right? > > I have been unable to figure out why read returns -1 after a long while but > I have found that if I kill my application and restart it everything works > fine again. Therefore I tried to work around the problem by having my code > close the port and reopen it when read returns -1. My second problem is that > in this case when I call close() on the port it blocks forever. I did find > this old bug > > http://bugzilla.qbang.org/show_bug.cgi?id=53 > > which describes close() hanging on OSX, but it says that bug was fixed with > a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have any > idea why read might be returning -1 in the first place? If I can avoid that > I don't care about close() hanging because I would never close the port. If > not, does anyone know why close() might block forever and how I can prevent > this? I'm using RXTX version 2.1-7. > > Thanks, > -- > Ryan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Mar 3 02:50:20 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 3 Mar 2011 09:50:20 +0000 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: So if -1 is unexpectedly returned from read, and we have demonstrated that your USB-serial adapter can actually causes this to happen in RXTX, why not just ignore the -1 value? What happens when you try this? As for a hang on close, are your closing your port from within your serial event handler? I know that this can cause some serious problems. Regards, Michael Erskine. From Kustaa.Nyholm at planmeca.com Thu Mar 3 03:39:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 12:39:34 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 03:44, "Ryan Boder" wrote: >While running the tests you requested I may have stumbled on the problem, >I just don't know how to fix it. According to the documentation, if both >the receive timeout and receive threshold are disabled then read() should >block forever until data is available. > >http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/re >ference/api/javax/comm/CommPort.html#getInputStream%28%29 > >On my system using RXTX read() is returning -1 when no data is available >even though I have disabled both thresholds. The reason my program was >running fine for a while without this problem showing up is that I was >using the DATA_AVAILABLE event to be notified when data is available and >only calling read() to read an entire frame whenever the DATA_AVAILABLE >event occurred, until eventually my device (I'm guessing) probably took >longer than normal to send the entire data frame and therefore I called >read when no data was available and it returned -1. As a workaround have you tried to perform another read() if it returns -1? The javadoc says (see getInputStream): "Note, however, that framing errors may cause the Timeout and Threshold values to complete prematurely without raising an exception." I read this as a hint that read might return even if no data is available. Because of the above and that read() can only return -1 or the byte received it would be somewhat logical to return -1 in case of framing error ? I'm not claiming that my interpretation of the specification, such as it is, is correct, just speculating that the behavior could be something like that. It might give you some more insight if you used the read(bytes[],int,int) method, because this can and will return 0 in case of timeout (and presumably might do so in case of framing error, maybe some other error condition too). That might allow you to handle or work around the problem in this case. You have not shown your complete code (no need) but your comments and the example makes me wonder if the code is otherwise as it should be, meaning are you assuming that when you get the DATA_AVAILABLE event all of your frame has arrived and that you can just blindly read it away from the input stream? That is not guaranteed of course. Also using read(), instead of read(bytes[],int,int), is not very efficient and might be masking other problems as mused above. BTE you can print a byte in hex with leading zeros more easily with: System.out.printf("%02X",x); br Kusti From ryan.boder at gmail.com Thu Mar 3 07:56:16 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:56:16 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 5:39 AM, Kustaa Nyholm wrote: > > As a workaround have you tried to perform another read() if it returns -1? > I tried that and it did work sometimes but not all the time. > > The javadoc says (see getInputStream): > > "Note, however, that framing errors may cause the Timeout and Threshold > values to complete prematurely without raising an exception." > > I read this as a hint that read might return even if no data is available. > > Because of the above and that read() can only return -1 or the byte > received > it would be somewhat logical to return -1 in case of framing error ? > > I'm not claiming that my interpretation of the specification, such as it > is, > is correct, just speculating that the behavior could be something like > that. > Receive framing is not enabled by default. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#enableReceiveFraming%28int%29 My choice of word might be misleading, when I said frame I just meant a contiguous message from the device. I am not enabling receive framing. Can you have a framing error when receive framing is disabled? > > It might give you some more insight if you used the read(bytes[],int,int) > method, because > this can and will return 0 in case of timeout (and presumably might do so > in case of framing > error, maybe some other error condition too). > > That might allow you to handle or work around the problem in this case. > > You have not shown your complete code (no need) but your comments and the > example > makes me wonder if the code is otherwise as it should be, meaning are you > assuming > that when you get the DATA_AVAILABLE event all of your frame has arrived > and that > you can just blindly read it away from the input stream? That is not > guaranteed of course. > I'm not assuming the entire message has arrived, I'm just assuming it either has arrived or will arrive soon which is why I'm using a (supposedly) blocking read(). > > Also using read(), instead of read(bytes[],int,int), is not very efficient > and > might be masking other problems as mused above. > True, I'm reading one byte at a time because I don't know how long the message will be until I read and parse some of it. I suppose I can use read(bytes[],int,int) once I figure out how long the message will be. > > BTE you can print a byte in hex with leading zeros more easily with: > > > System.out.printf("%02X",x); > I did it the dumb way in that test program so I could copy and paste the code from C# to Java without having to figure out how to do the same in C# which I'm not as familiar with. Thanks and BR, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 07:58:24 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:58:24 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: Yes I was doing the close in the serial event handler, I didn't realize that caused a problem. Thanks, I'll fix it. On Thu, Mar 3, 2011 at 4:50 AM, Michael Erskine wrote: > So if -1 is unexpectedly returned from read, and we have demonstrated > that your USB-serial adapter can actually causes this to happen in > RXTX, why not just ignore the -1 value? What happens when you try > this? As for a hang on close, are your closing your port from within > your serial event handler? I know that this can cause some serious > problems. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 11:48:20 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 13:48:20 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm wrote: > On 3/3/11 16:56, "Ryan Boder" wrote: > > > >I'm not assuming the entire message has arrived, I'm just assuming it > >either has arrived or will arrive soon which is why I'm using a > >(supposedly) blocking read(). > > > I've been giving this some further thought. > > It does not feel healthy to block without timeout, especially > from within a thread that is essentially internal to the rxtx. > > I've never done that, I always use a time out, read(byte[],int,int) > for the expected number of bytes, check how much I got and issue > more reads until I get everything. > > You have not described how your communication works so I'm only > speculating. > > If your device needs some response to send more bytes (from your > code it looks like this is not the case) then a missing byte > would block your read and prevent you from responding and > getting more data. But as said, looks like that is not the case. > > Anyway, if this was my problem, I would enable the timeout > and use read(byte[],int,int) and loop until I get what I need. > You are right, I should and will use a timeout. In fact, my program has been running flawlessly for 12 hours and the only change I made was to enable a timeout, no change in the logic at all. Without the timeout read() was returning -1 usually after it ran for an hour or two. I will change the code to make use of the timeout and handle it appropriately. It still seems to me that RXTX's behavior doesn't match the documentation when rx timeout and rx threshold are disabled read() should block until data is available instead of immediately returning -1. I don't believe that a framing error is occurring immediately every time data is not available causing read() to return -1. Especially since the C# test program above runs all day with no error and the Java program above runs all day with no error when a timeout is enabled. To me it seems like enabling the timeout is what is causing read() to block until data is available, even if only for 1600ms, and without the timeout read() is returning -1 immediately when it should be blocking. Thanks for all the help and best regards, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Thu Mar 3 13:02:30 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 22:02:30 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 20:48, "Ryan Boder" wrote: >On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm > wrote: > >On 3/3/11 16:56, "Ryan Boder" wrote: >> > >>I'm not assuming the entire message has arrived, I'm just assuming it >>either has arrived or will arrive soon which is why I'm using a >>(supposedly) blocking read(). > > > >I've been giving this some further thought. > >It does not feel healthy to block without timeout, especially >from within a thread that is essentially internal to the rxtx. > >I've never done that, I always use a time out, read(byte[],int,int) >for the expected number of bytes, check how much I got and issue >more reads until I get everything. > >You have not described how your communication works so I'm only >speculating. > >If your device needs some response to send more bytes (from your >code it looks like this is not the case) then a missing byte >would block your read and prevent you from responding and >getting more data. But as said, looks like that is not the case. > >Anyway, if this was my problem, I would enable the timeout >and use read(byte[],int,int) and loop until I get what I need. > > > > >You are right, I should and will use a timeout. In fact, my program has >been running flawlessly for 12 hours and the only change I made was to >enable a timeout, no change in the logic at all. Without the timeout >read() was returning -1 usually after it ran for an hour or two. I will >change the code to make use of the timeout and handle it appropriately. That's nice! > >It still seems to me that RXTX's behavior doesn't match the documentation >when rx timeout and rx threshold are disabled read() should block until >data is available instead of immediately returning -1. Yeah, it does look like bug. However this might be related to some Windows specific serial port issue. Years ago I had issues with JavaComm (not RxTx) where I did a blocking read and I had huge issues with my program consuming all resources. I curser the Sun and JavaComm and re-code my own SerialPort using JNI to access the Win32 API directly. And I run into the same problems as with the Sun's implementation! So I ditched my code, changed my code to use timeouts and problems disappeared. > I don't believe that a framing error is occurring immediately every time >data is not available causing read() to return -1. Especially since the >C# test program above runs all day with no error and the Java program >above runs all day with no error when a timeout is enabled. I think so too, all things considered I don't really believe in framing errors in this case. > To me it seems like enabling the timeout is what is causing read() to >block until data is available, even if only for 1600ms, and without the >timeout read() is returning -1 immediately when it should be blocking. Yeah, I had a peek at the innards of RxTx Windows serial port a week or so ago and also read MSDN documentation about serial ports and the way overlapped and non-overlapped (non blocking and blocking) IO is handled is a way different. So yeah, it can well be that there is an issue lurking there somewhere inside RxTx in Windows. > > >Thanks for all the help and best regards, >-- >Ryan Boder I'm happy if I was of any assistance. br Kusti From tjarvi at qbang.org Thu Mar 3 18:52:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Mar 2011 18:52:50 -0700 (MST) Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: >> Without the timeout >> read() was returning -1 usually after it ran for an hour or two. There is a big hammer in rxtx causing that behavior. >> It still seems to me that RXTX's behavior doesn't match the documentation >> when rx timeout and rx threshold are disabled read() should block until >> data is available instead of immediately returning -1. > > Yeah, it does look like bug. However this might be related to some > Windows specific serial port issue. Years ago I had issues with > JavaComm (not RxTx) where I did a blocking read and I had huge > issues with my program consuming all resources. I curser the Sun > and JavaComm and re-code my own SerialPort using JNI to access > the Win32 API directly. And I run into the same problems as > with the Sun's implementation! So I ditched my code, changed > my code to use timeouts and problems disappeared. > > >> To me it seems like enabling the timeout is what is causing read() to >> block until data is available, even if only for 1600ms, and without the >> timeout read() is returning -1 immediately when it should be blocking. > > Yeah, I had a peek at the innards of RxTx Windows serial port a week > or so ago and also read MSDN documentation about serial ports and > the way overlapped and non-overlapped (non blocking and blocking) > IO is handled is a way different. So yeah, it can well be that > there is an issue lurking there somewhere inside RxTx in Windows. > > Yes. RXTX was patched to behave the way it does. I don't fully understand the issue behind the patch. Marc noticed the odd behavior as well and offered a fix which was greeted with resistance. The windows implementation was done without real documentatino of the windows API. I think I had an example from the late 80's early 90's on Microsoft's site and some API documentation that was obviously not microsofts in Europe. Wayne Roberts had a real need for windows support and fixed some major issues it had. My interest at the time was mingw32. I then cleaned it up for some specific uses I had later. The read returning -1 when it should block didn't impact anybody and appeared to help some people. It isnt the documented behavior though. There could be all sorts of latent bugs in that code but in the real world, it gets by in almost all use cases. Its a hack but it worked for 100's of thousands of people over a 14 year period. Maybe its time to revisit the code but there is more risk than gain for most people. How do you move forward and avoid the risk? Some have expressed interests in coding C++ or other efforts. I'm all for such efforts but feel some unit tests that work with a null modem cables are the only thing that will move rxtx (and perhaps CommAPI) forward. If we have a test suite in place as a qualification for implementations, progress can be made in the right direction regardless of the implementation details. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Fri Mar 4 02:57:16 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 4 Mar 2011 11:57:16 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/4/11 03:52, "Trent Jarvi" wrote: >Yes. RXTX was patched to behave the way it does. I don't fully >understand the issue behind the patch. Marc noticed the odd behavior as >well and offered a fix which was greeted with resistance. > >The windows implementation was done without real documentatino of the >windows API. I think I had an example from the late 80's early 90's on >Microsoft's site and some API documentation that was obviously not >microsofts in Europe. Wayne Roberts had a real need for windows support >and fixed some major issues it had. My interest at the time was mingw32. >I then cleaned it up for some specific uses I had later. The read >returning -1 when it should block didn't impact anybody and appeared to >help some people. It isnt the documented behavior though. > >There could be all sorts of latent bugs in that code but in the real >world, it gets by in almost all use cases. I think so too, never had any problems with it. > Its a hack but it worked for 100's of thousands of people over a 14 year >period. Yeah! Thanks for everyone who has contributed over the years, job well done! >Maybe its time to >revisit the code but there is more risk than gain for most people. How >do >you move forward and avoid the risk? My view is that it is quite risky and rather pointless to move forward, other than fixing bugs that really affect people. At the moment the major issue IMO is just that it seems (not been following this too carefully, so maybe I'm wrong, so in case this FUD, my apologies) that 'official' binaries are not available. I think the rewrite, tempting as it is in some respects is not the way forward. Just gentle maintenance to iron out real issues and then get the binaries out. br Kusti From ryan.boder at gmail.com Fri Mar 4 07:24:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Fri, 4 Mar 2011 09:24:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 8:52 PM, Trent Jarvi wrote: > > The windows implementation was done without real documentatino of the > windows API. I think I had an example from the late 80's early 90's on > Microsoft's site and some API documentation that was obviously not > microsofts in Europe. Wayne Roberts had a real need for windows support and > fixed some major issues it had. My interest at the time was mingw32. I then > cleaned it up for some specific uses I had later. The read returning -1 > when it should block didn't impact anybody and appeared to help some people. > It isnt the documented behavior though. > > There could be all sorts of latent bugs in that code but in the real world, > it gets by in almost all use cases. Its a hack but it worked for 100's of > thousands of people over a 14 year period. Maybe its time to revisit the > code but there is more risk than gain for most people. How do you move > forward and avoid the risk? > The safest and easiest solution would be to add a javadoc comment to disableReceiveTimeout explaining the difference between the RXTX behavior and Sunacle's documented behavior so that when someone uses the method in an IDE like Eclipse a little box would pop up informing them. Generating javadoc HTML and hosting it on the RXTX website would go a long way too, when something behaves differently than I expect the first thing I do is look for the javadoc online. -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From kharrington at neuronrobotics.com Mon Mar 7 10:47:26 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 12:47:26 -0500 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! Message-ID: Hey all, this is just a heads up that i have made a fork of rxtxSerial. Some of the features we have added: * Self deployment of native libraries ( all native code is stored inside the jar and deployed at runtime). No more manual install of native code. * Arm Cortex support (Gumstix) * Android Support (requires a rooted phone for now) * Google Code (SVN) repository for easy code and jar access * Single makefile compile (simplifies the compilation of project binaries) * Ant build script for jar creation * Removal of partialy implemented code to streamline the lib for just serial port access * Full Eclipse integration, for testing application code against sources. And a bunch of bug fixes: * Fixed the memory access error that causes OSX to crash the JVM when serial.close() is cvalled * Fixed the windows serial port zombie bind that prevents re-accessing serial ports when exiting on an exception * Fixed erronious printouts of native library mis-match To check it out, take a look at our page here: http://code.google.com/p/nrjavaserial/ From Kustaa.Nyholm at planmeca.com Mon Mar 7 11:46:26 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Mar 2011 20:46:26 +0200 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: Message-ID: On 3/7/11 19:47, "Kevin Harrington NR" wrote: >Hey all, this is just a heads up that i have made a fork of >rxtxSerial. Some of the features we have added great! If also does what it says on the tin: brilliant! Congrats and thanks. br Kusti From jmsachs at gmail.com Mon Mar 7 12:50:33 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 14:50:33 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: > From: Kevin Harrington NR > To: rxtx at qbang.org > Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > Hey all, this is just a heads up that i have made a fork of > rxtxSerial. Some of the features we have added: > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with a ten-foot pole. From Kustaa.Nyholm at planmeca.com Mon Mar 7 13:10:43 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Mar 2011 22:10:43 +0200 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: Message-ID: On 3/7/11 21:50, "Jason Sachs" wrote: > >Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >a ten-foot pole. >_______________________________________________ Oh crap, makes it useless for me and many others. Also I see no provision in RxTx license to change it so how could anyone change it to GPLv3? br Kusti From showard314 at gmail.com Mon Mar 7 13:24:08 2011 From: showard314 at gmail.com (Scott Howard) Date: Mon, 7 Mar 2011 15:24:08 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 3:10 PM, Kustaa Nyholm wrote: > Also I see no provision in RxTx license to change > it so how could anyone change it to GPLv3? I think this is allowed: 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. From jmsachs at gmail.com Mon Mar 7 13:24:47 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 15:24:47 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 2:50 PM, Jason Sachs wrote: >> From: Kevin Harrington NR >> To: rxtx at qbang.org >> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> > > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with > a ten-foot pole. > Let me back up a second (perhaps to make up for my lack of diplomacy) and state that I think any progress w/ rxtx is good. If an rxtx fork were LGPL (or some other non-spreading open source license) and leading in a good direction, I'd gladly return the favor by posting any improvements or bugfixes I found to the community. --Jason From jmsachs at gmail.com Mon Mar 7 13:36:13 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 15:36:13 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: Kevin: could you clarify the license? http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java has the RXTX 2.1 license (LGPL v 2.1 + Linking Over Controlled Interface.) but http://code.google.com/p/nrjavaserial/ says GPLv3. --Jason From kharrington at neuronrobotics.com Mon Mar 7 14:00:02 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 16:00:02 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: The one downside to google code is that it does not allow custom licensing. You have to pick from a drop-down list. Treat the licences on the files themselves as the licence to be concerned with, and ignore the "project licence". Sorry for the confusion. On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: > Kevin: could you clarify the license? > > http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java > has the RXTX 2.1 license > (LGPL v 2.1 + Linking Over Controlled Interface.) > > but http://code.google.com/p/nrjavaserial/ says GPLv3. > > --Jason > From iqzw2r602 at sneakemail.com Mon Mar 7 14:08:18 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 8 Mar 2011 08:08:18 +1100 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: References: Message-ID: <11253-1299532098-811882@sneakemail.com> Nice! Out of curiosity, did you use the patch that I sent Trent about two years ago to do the native library loading, or did you implement your own solution? Cheers, Uwe On Tue, Mar 8, 2011 at 5:46 AM, Kustaa Nyholm Kustaa.Nyholm-at-planmeca.com| rxtx.org mailing list/Example Allow| wrote: > On 3/7/11 19:47, "Kevin Harrington NR" > wrote: > > >Hey all, this is just a heads up that i have made a fork of > >rxtxSerial. Some of the features we have added > > > > great! If also does what it says on the tin: brilliant! > > Congrats and thanks. > > br Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aawolfe at gmail.com Mon Mar 7 15:31:47 2011 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 7 Mar 2011 17:31:47 -0500 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR wrote: > Hey all, this is just a heads up that i have made a fork of > rxtxSerial. Some of the features we have added: > > * Self deployment of native libraries ( all native code is stored > inside the jar and deployed at runtime). No more manual install of > native code. > * Arm Cortex support (Gumstix) > * Android Support (requires a rooted phone for now) > * Google Code (SVN) repository for easy code and jar access > * Single makefile compile (simplifies the compilation of project binaries) > * Ant build script for jar creation > * Removal of partialy implemented code to streamline the lib for just > serial port access > * Full Eclipse integration, for testing application code against sources. > > And a bunch of bug fixes: > > * Fixed the memory access error that causes OSX to crash the JVM when > serial.close() is cvalled > * Fixed the windows serial port zombie bind that prevents re-accessing > serial ports when exiting on an exception > * Fixed erronious printouts of native library mis-match > > To check it out, take a look at our page here: > > http://code.google.com/p/nrjavaserial/ This is interesting, getting the native libs set up has been an issue for some of my users. Will have to check it out. Out of curiosity, what Android devices provide a serial port? Or are there some that allow USB host mode and then a usb-serial adapter? I have only an Android cell phone, don't think it can do anything serial but would love to be wrong about that. From jfh at greenhousepc.com Mon Mar 7 15:54:39 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 15:54:39 -0700 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! Message-ID: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Mon Mar 7 16:53:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Mar 2011 16:53:50 -0700 (MST) Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: Hi Kevin, Until Google fixes the options as developers have requested, I'd suggest the least misleading dropdown option is "Other Open Source" with a clarification about LGPL 2.1 on the project page. If you are not supporting the CommAPI SPI interface that was available prior to the current JSR so that applications work in the javax.comm namespace, there is no need for the linking over controlled interfaces exception. RXTX 2.0 is used in that fashion but RXTX 2.1 is not. The exception explicitly states it can be removed if the source has been modified. The license is then explicitly OSI reviewed and approved as Google requests but is not in their drop down box as it should be and is for the GPL v2. http://opensource.org/licenses/alphabetical http://opensource.org/licenses/lgpl-2.1 The drawback would be that the library effectively could never be used in that SPI/controlled interface fashion again. On Mon, 7 Mar 2011, Kevin Harrington NR wrote: > The one downside to google code is that it does not allow custom > licensing. You have to pick from a drop-down list. Treat the licences > on the files themselves as the licence to be concerned with, and > ignore the "project licence". Sorry for the confusion. > > On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >> Kevin: could you clarify the license? >> >> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >> has the RXTX 2.1 license >> (LGPL v 2.1 + Linking Over Controlled Interface.) >> >> but http://code.google.com/p/nrjavaserial/ says GPLv3. >> >> --Jason >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From hakcenter at gmail.com Mon Mar 7 18:55:57 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 17:55:57 -0800 Subject: [Rxtx] Latency Woes Message-ID: <4D758CAD.2010602@gmail.com> I have finally deduced my slow data logging to a latency issue. I write software for dsms, and the protocol is request / receive, you cannot do more than 1 sensor at a time. So when you log multiple sensors, +20ms per item, sampling rate drops like a rock. I was wondering if there is any ideas besides going completely native with my application to reduce latency. With or without events I don't care at this point I need to kill as much of the latency as possible. Realistically I need no more than 1ms. From adrian.crum at sandglass-software.com Mon Mar 7 19:08:21 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Mon, 07 Mar 2011 18:08:21 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D758CAD.2010602@gmail.com> References: <4D758CAD.2010602@gmail.com> Message-ID: <4D758F95.90800@sandglass-software.com> Drop the requests into a queue, and then have a separate thread service the queue. -Adrian On 3/7/2011 5:55 PM, Curtis Hacker wrote: > I have finally deduced my slow data logging to a latency issue. > > I write software for dsms, and the protocol is request / receive, you > cannot do more than 1 sensor at a time. So when you log multiple > sensors, +20ms per item, sampling rate drops like a rock. > > I was wondering if there is any ideas besides going completely native > with my application to reduce latency. With or without events I don't > care at this point I need to kill as much of the latency as possible. > Realistically I need no more than 1ms. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From hakcenter at gmail.com Mon Mar 7 19:24:16 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 18:24:16 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D758F95.90800@sandglass-software.com> References: <4D758CAD.2010602@gmail.com> <4D758F95.90800@sandglass-software.com> Message-ID: <4D759350.8060402@gmail.com> Sample code ? I don't necessarily want to read the byte I just wrote, but wait till the que depth is 2. Setup a thread without a sleep timer: if (in.available() > 1) { do_stuff(); } ?? On 03/07/11 18:08, Adrian Crum wrote: > Drop the requests into a queue, and then have a separate thread > service the queue. > > -Adrian > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: >> I have finally deduced my slow data logging to a latency issue. >> >> I write software for dsms, and the protocol is request / receive, you >> cannot do more than 1 sensor at a time. So when you log multiple >> sensors, +20ms per item, sampling rate drops like a rock. >> >> I was wondering if there is any ideas besides going completely native >> with my application to reduce latency. With or without events I don't >> care at this point I need to kill as much of the latency as possible. >> Realistically I need no more than 1ms. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adrian.crum at sandglass-software.com Mon Mar 7 19:46:02 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Mon, 07 Mar 2011 18:46:02 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D759350.8060402@gmail.com> References: <4D758CAD.2010602@gmail.com> <4D758F95.90800@sandglass-software.com> <4D759350.8060402@gmail.com> Message-ID: <4D75986A.6020003@sandglass-software.com> http://download.oracle.com/javase/tutorial/essential/concurrency/executors.html -Adrian On 3/7/2011 6:24 PM, Curtis Hacker wrote: > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: >> Drop the requests into a queue, and then have a separate thread >> service the queue. >> >> -Adrian >> >> On 3/7/2011 5:55 PM, Curtis Hacker wrote: >>> I have finally deduced my slow data logging to a latency issue. >>> >>> I write software for dsms, and the protocol is request / receive, >>> you cannot do more than 1 sensor at a time. So when you log multiple >>> sensors, +20ms per item, sampling rate drops like a rock. >>> >>> I was wondering if there is any ideas besides going completely >>> native with my application to reduce latency. With or without events >>> I don't care at this point I need to kill as much of the latency as >>> possible. Realistically I need no more than 1ms. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Mon Mar 7 19:50:45 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 19:50:45 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Mon Mar 7 20:04:01 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 19:04:01 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> Message-ID: <4D759CA1.8010903@gmail.com> I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. in.read(data, 0, 2); ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? On 03/07/11 18:50, jfh at greenhousepc.com wrote: > Curtis, > > No, I assume he means a real queue, not just "don't read all the bytes > at once." However, if you know you can process some number of > requests in some amount of time, allowing data to pile up (receiver > FIFO space permitting) can be a valid strategy. Inserting gobs of > Thread.yield() and notify() can help pep things up as well. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Mon, March 07, 2011 8:24 pm > To: rxtx at qbang.org > > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: > > Drop the requests into a queue, and then have a separate thread > > service the queue. > > > > -Adrian > > > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: > >> I have finally deduced my slow data logging to a latency issue. > >> > >> I write software for dsms, and the protocol is request / > receive, you > >> cannot do more than 1 sensor at a time. So when you log multiple > >> sensors, +20ms per item, sampling rate drops like a rock. > >> > >> I was wondering if there is any ideas besides going completely > native > >> with my application to reduce latency. With or without events I > don't > >> care at this point I need to kill as much of the latency as > possible. > >> Realistically I need no more than 1ms. > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From bartley at cmu.edu Mon Mar 7 20:08:05 2011 From: bartley at cmu.edu (Chris Bartley) Date: Mon, 7 Mar 2011 22:08:05 -0500 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> Message-ID: <9B1804F9-DBD0-476D-9345-806D00065A97@cmu.edu> We use a queue for all our request/response serial communications, and have found it really easy to work with. Code is here: http://code.google.com/p/create-lab-commons/source/browse/trunk/java/code/serial/src/edu/cmu/ri/createlab/serial/SerialPortCommandExecutionQueue.java It's assuming a command & response scheme that's specific to the protocol we use to talk to our robots, but it should be easy to modify for your needs. Hope this helps. Let me know if you have questions. Chris On Mar 7, 2011, at 9:50 PM, wrote: > Curtis, > > No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > Date: Mon, March 07, 2011 8:24 pm > To: rxtx at qbang.org > > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: > > Drop the requests into a queue, and then have a separate thread > > service the queue. > > > > -Adrian > > > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: > >> I have finally deduced my slow data logging to a latency issue. > >> > >> I write software for dsms, and the protocol is request / receive, you > >> cannot do more than 1 sensor at a time. So when you log multiple > >> sensors, +20ms per item, sampling rate drops like a rock. > >> > >> I was wondering if there is any ideas besides going completely native > >> with my application to reduce latency. With or without events I don't > >> care at this point I need to kill as much of the latency as possible. > >> Realistically I need no more than 1ms. > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Mon Mar 7 20:51:17 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 20:51:17 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110307205116.8ef0e5b4a80cef441275a6330ffad77d.9b325137d1.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From kharrington at neuronrobotics.com Mon Mar 7 20:55:23 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 22:55:23 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 7 In-Reply-To: References: Message-ID: To answer a few of you, I have changed the license to "Other open source license" as suggested. My company is modifying and maintaining this fork to support our robotics development library (http://code.google.com/p/nr-sdk/ http://dev.neuronrobotics.com). We will be implementing the standard serial port interface only, as it is the only one we need or care about. As for where the implementation came from, i would have to refer to my other developer to answer that. I wrote the build scripts and make files, as well as streamlining the C build process. I have remover the configure script, as it ends up being more confusing then compiling 3 C files needs to be. if you guys want to bring any of this into the main line, that's cool, but up to you to port over. Our fork will be focusing on polishing up the serial interface,and hopefully making it faster. I hope some of you will find our improvements useful! On Mon, Mar 7, 2011 at 6:53 PM, wrote: > Send Rxtx mailing list submissions to > ? ? ? ?rxtx at qbang.org > > To subscribe or unsubscribe via the World Wide Web, visit > ? ? ? ?http://mailman.qbang.org/mailman/listinfo/rxtx > or, via email, send a message with subject or body 'help' to > ? ? ? ?rxtx-request at qbang.org > > You can reach the person managing the list at > ? ? ? ?rxtx-owner at qbang.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Rxtx digest..." > > > Today's Topics: > > ? 1. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 2. Re: Rxtx Digest, Vol 43, Issue 6 (Kustaa Nyholm) > ? 3. Re: Rxtx Digest, Vol 43, Issue 6 (Scott Howard) > ? 4. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 5. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 6. Re: Rxtx Digest, Vol 43, Issue 6 (Kevin Harrington NR) > ? 7. Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! > ? ? ?(iqzw2r602 at sneakemail.com) > ? 8. Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! > ? ? ?(Aaron Wolfe) > ? 9. Re: [SPAM] Re: ?NRJavaSerial, a fork of rxtx that fixes the > ? ? ?papercuts! (jfh at greenhousepc.com) > ?10. Re: Rxtx Digest, Vol 43, Issue 6 (Trent Jarvi) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 7 Mar 2011 14:50:33 -0500 > From: Jason Sachs > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > >> From: Kevin Harrington NR >> To: rxtx at qbang.org >> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> > > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with > a ten-foot pole. > > > ------------------------------ > > Message: 2 > Date: Mon, 7 Mar 2011 22:10:43 +0200 > From: Kustaa Nyholm > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > On 3/7/11 21:50, "Jason Sachs" wrote: >> >>Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >>a ten-foot pole. >>_______________________________________________ > > Oh crap, makes it useless for me and many others. > > Also I see no provision in RxTx license to change > it so how could anyone change it to GPLv3? > > br Kusti > > > > ------------------------------ > > Message: 3 > Date: Mon, 7 Mar 2011 15:24:08 -0500 > From: Scott Howard > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 3:10 PM, Kustaa Nyholm > wrote: >> Also I see no provision in RxTx license to change >> it so how could anyone change it to GPLv3? > > I think this is allowed: > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. ?To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. ?(If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) ?Do not make any other change in > these notices. > > ? Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > ? This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > > ------------------------------ > > Message: 4 > Date: Mon, 7 Mar 2011 15:24:47 -0500 > From: Jason Sachs > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 2:50 PM, Jason Sachs wrote: >>> From: Kevin Harrington NR >>> To: rxtx at qbang.org >>> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >>> Message-ID: >>> ? ? ? ? >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> Hey all, this is just a heads up that i have made a fork of >>> rxtxSerial. Some of the features we have added: >>> >> >> Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >> a ten-foot pole. >> > > Let me back up a second (perhaps to make up for my lack of diplomacy) > and state that I think any progress w/ rxtx is good. > > If an rxtx fork were LGPL (or some other non-spreading open source > license) and leading in a good direction, I'd gladly return the favor > by posting any improvements or bugfixes I found to the community. > > --Jason > > > ------------------------------ > > Message: 5 > Date: Mon, 7 Mar 2011 15:36:13 -0500 > From: Jason Sachs > To: rxtx at qbang.org, kharrington at neuronrobotics.com > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > Kevin: could you clarify the license? > > http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java > has the RXTX 2.1 license > (LGPL v 2.1 + Linking Over Controlled Interface.) > > but http://code.google.com/p/nrjavaserial/ says GPLv3. > > --Jason > > > ------------------------------ > > Message: 6 > Date: Mon, 7 Mar 2011 16:00:02 -0500 > From: Kevin Harrington NR > To: Jason Sachs > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > The one downside to google code is that it does not allow custom > licensing. You have to pick from a drop-down list. Treat the licences > on the files themselves as the licence to be concerned with, and > ignore the "project licence". Sorry for the confusion. > > On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >> Kevin: could you clarify the license? >> >> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >> has the RXTX 2.1 license >> (LGPL v 2.1 + Linking Over Controlled Interface.) >> >> but http://code.google.com/p/nrjavaserial/ says GPLv3. >> >> --Jason >> > > > ------------------------------ > > Message: 7 > Date: Tue, 8 Mar 2011 08:08:18 +1100 > From: iqzw2r602 at sneakemail.com > To: Rxtx at qbang.org > Subject: Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > ? ? ? ?papercuts! > Message-ID: <11253-1299532098-811882 at sneakemail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Nice! > > Out of curiosity, did you use the patch that I sent Trent about two years > ago to do the native library loading, or did you implement your own > solution? > > Cheers, > > Uwe > > On Tue, Mar 8, 2011 at 5:46 AM, Kustaa Nyholm Kustaa.Nyholm-at-planmeca.com| > rxtx.org mailing list/Example Allow| wrote: > >> On 3/7/11 19:47, "Kevin Harrington NR" >> wrote: >> >> >Hey all, this is just a heads up that i have made a fork of >> >rxtxSerial. Some of the features we have added >> >> >> >> great! If also does what it says on the tin: brilliant! >> >> Congrats and thanks. >> >> br Kusti >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 8 > Date: Mon, 7 Mar 2011 17:31:47 -0500 > From: Aaron Wolfe > To: rxtx at qbang.org > Subject: Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > ? ? ? ?papercuts! > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR > wrote: >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> >> * Self deployment of native libraries ( all native code is stored >> inside the jar and deployed at runtime). No more manual install of >> native code. >> * Arm Cortex support (Gumstix) >> * Android Support (requires a rooted phone for now) >> * Google Code (SVN) repository for easy code and jar access >> * Single makefile compile (simplifies the compilation of project binaries) >> * Ant build script for jar creation >> * Removal of partialy implemented code to streamline the lib for just >> serial port access >> * Full Eclipse integration, for testing application code against sources. >> >> And a bunch of bug fixes: >> >> * Fixed the memory access error that causes OSX to crash the JVM when >> serial.close() is cvalled >> * Fixed the windows serial port zombie bind that prevents re-accessing >> serial ports when exiting on an exception >> * Fixed erronious printouts of native library mis-match >> >> To check it out, take a look at our page here: >> >> http://code.google.com/p/nrjavaserial/ > > This is interesting, getting the native libs set up has been an issue > for some of my users. ?Will have to check it out. > > Out of curiosity, what Android devices provide a serial port? ?Or are > there some that allow USB host mode and then a usb-serial adapter? ?I > have only an Android cell phone, don't think it can do anything serial > but would love to be wrong about that. > > > ------------------------------ > > Message: 9 > Date: Mon, 07 Mar 2011 15:54:39 -0700 > From: > To: aaron at aaronwolfe.com, rxtx at qbang.org > Subject: Re: [Rxtx] [SPAM] Re: ?NRJavaSerial, a fork of rxtx that > ? ? ? ?fixes the papercuts! > Message-ID: > ? ? ? ?<20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe at email13.secureserver.net> > > Content-Type: text/plain; charset="us-ascii" > > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 10 > Date: Mon, 7 Mar 2011 16:53:50 -0700 (MST) > From: Trent Jarvi > To: rxtx at qbang.org > Cc: Jason Sachs > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > Hi Kevin, > > Until Google fixes the options as developers have requested, I'd suggest > the least misleading dropdown option is "Other Open Source" with a > clarification about LGPL 2.1 on the project page. > > If you are not supporting the CommAPI SPI interface that was available > prior to the current JSR so that applications work in the javax.comm > namespace, there is no need for the linking over controlled interfaces > exception. ?RXTX 2.0 is used in that fashion but RXTX 2.1 is not. ?The > exception explicitly states it can be removed if the source has been > modified. ?The license is then explicitly OSI reviewed and approved as > Google requests but is not in their drop down box as it should be and is > for the GPL v2. > > ? ? ? ?http://opensource.org/licenses/alphabetical > ? ? ? ?http://opensource.org/licenses/lgpl-2.1 > > The drawback would be that the library effectively could never be used in > that SPI/controlled interface fashion again. > > On Mon, 7 Mar 2011, Kevin Harrington NR wrote: > >> The one downside to google code is that it does not allow custom >> licensing. You have to pick from a drop-down list. Treat the licences >> on the files themselves as the licence to be concerned with, and >> ignore the "project licence". Sorry for the confusion. >> >> On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >>> Kevin: could you clarify the license? >>> >>> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >>> has the RXTX 2.1 license >>> (LGPL v 2.1 + Linking Over Controlled Interface.) >>> >>> but http://code.google.com/p/nrjavaserial/ says GPLv3. >>> >>> --Jason >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > ------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > End of Rxtx Digest, Vol 43, Issue 7 > *********************************** > From Kustaa.Nyholm at planmeca.com Mon Mar 7 21:43:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 8 Mar 2011 06:43:57 +0200 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307205116.8ef0e5b4a80cef441275a6330ffad77d.9b325137d1.wbe@email13.secureserver.net> Message-ID: On 3/8/11 05:51, "jfh at greenhousepc.com" wrote: >Curtis, > > >None of that is relevant, as long as the UART is reasonable and the code >implements a proper half duplex protocol. > >If I understand correctly, you send a byte, the sensor sends back two >bytes. So long as you don't send the next byte until the two bytes are >in the UART receiver FIFO, you're fine. You don't have to actually >=read= them, just know they are available. To the OP, are you using a serial USB port, like FTDI? This has a built in latency of 10ms ie nothing is actually sent out of the device if you send less than 64 bytes until 10 msec timeout. This has nothing to do with RxTx. If you search the list archives you'll find more about this issue and IIRC someone reported that there is some diver parameter you can tweak to get rid of that latency. I'm sure the FTDI people had a good reason for this but it really brings down the communication speed if your protocol uses short messages and need to wait for a response. Sorry if this has already been mentioned or if this is not relevant, I've not been paying attention to this thread. br Kusti From bob_jacobsen at lbl.gov Tue Mar 8 00:02:28 2011 From: bob_jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 8 Mar 2011 00:02:28 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D759CA1.8010903@gmail.com> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> Message-ID: If you're transferring three bytes total at 1953 baud, it's going to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to wait 20msec to get the data back instead of 15.4 msec doesn't seem to be as big a problem as you're making it sound. Bob On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. > > To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. > > So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. > > in.read(data, 0, 2); > ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? > > On 03/07/11 18:50, jfh at greenhousepc.com wrote: >> Curtis, >> >> No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker >> Date: Mon, March 07, 2011 8:24 pm >> To: rxtx at qbang.org >> >> Sample code ? >> >> I don't necessarily want to read the byte I just wrote, but wait till >> the que depth is 2. >> >> Setup a thread without a sleep timer: >> if (in.available() > 1) { >> do_stuff(); >> } >> >> ?? >> >> On 03/07/11 18:08, Adrian Crum wrote: >> > Drop the requests into a queue, and then have a separate thread >> > service the queue. >> > >> > -Adrian >> > >> > On 3/7/2011 5:55 PM, Curtis Hacker wrote: >> >> I have finally deduced my slow data logging to a latency issue. >> >> >> >> I write software for dsms, and the protocol is request / receive, you >> >> cannot do more than 1 sensor at a time. So when you log multiple >> >> sensors, +20ms per item, sampling rate drops like a rock. >> >> >> >> I was wondering if there is any ideas besides going completely native >> >> with my application to reduce latency. With or without events I don't >> >> care at this point I need to kill as much of the latency as possible. >> >> Realistically I need no more than 1ms. >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From hakcenter at gmail.com Tue Mar 8 01:33:24 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 00:33:24 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> Message-ID: <4D75E9D4.5090307@gmail.com> I am going to try a couple things today and hopefully figure something out. Bob I don't want to pop your bubble, but a native application named 'TunerPro' can sample the same data, over 30 sensors, in less than 25ms. I've exchanged some emails with the author and it is a native C, polling, no events just timeouts. Kusta thanks for the FTDI notice, I believe that is tunable, however I have a particular user using a Keyspan converter and verified sampling rate with 'TunerPro' and its just off the charts. Chris thank you, I'll look into the queing. On 03/07/11 23:02, Bob Jacobsen wrote: > If you're transferring three bytes total at 1953 baud, it's going to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to wait 20msec to get the data back instead of 15.4 msec doesn't seem to be as big a problem as you're making it sound. > > Bob > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > >> I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. >> >> To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. >> >> So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. >> >> in.read(data, 0, 2); >> ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? >> >> On 03/07/11 18:50, jfh at greenhousepc.com wrote: >>> Curtis, >>> >>> No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. >>> -- >>> Julie Haugh >>> Senior Design Engineer >>> greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype From msemtd at googlemail.com Tue Mar 8 01:50:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 8 Mar 2011 08:50:15 +0000 Subject: [Rxtx] Latency Woes In-Reply-To: <4D75E9D4.5090307@gmail.com> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> <4D75E9D4.5090307@gmail.com> Message-ID: On 8 March 2011 08:33, Curtis Hacker wrote: > I am going to try a couple things today and hopefully figure something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than 25ms. > I've exchanged some emails with the author and it is a native C, polling, no > events just timeouts. Perhaps the author of TunerPro will let you use his native code - sounds just what you need. Regards, Michael Erskine. From jfh at greenhousepc.com Tue Mar 8 04:00:18 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 04:00:18 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 12:33:35 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 11:33:35 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> Message-ID: <4D76848F.5080809@gmail.com> Cable schematic: http://i1106.photobucket.com/albums/h377/vigilart/jackal%20logging%20set%20up/RS232SCHEMATIC.jpg 0.00268554 TunerPro.exe IOCTL_SERIAL_SET_BAUD_RATE VCP0 SUCCESS Rate: 1952 0.00305178 TunerPro.exe IOCTL_SERIAL_SET_RTS VCP0 SUCCESS 0.00297524 TunerPro.exe IOCTL_SERIAL_SET_DTR VCP0 SUCCESS 0.00297384 TunerPro.exe IOCTL_SERIAL_SET_LINE_CONTROL VCP0 SUCCESS StopBits: 1 Parity: NONE WordLength: 8 0.00000335 TunerPro.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 0.00202540 TunerPro.exe IOCTL_SERIAL_SET_HANDFLOW VCP0 SUCCESS Shake:1 Replace:40 XonLimit:2048 XoffLimit:512 0.00000335 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:300 RM:0 RC:2000 WM:0 WC:110 0.00000279 TunerPro.exe IOCTL_SERIAL_SET_QUEUE_SIZE VCP0 SUCCESS InSize: 1024 OutSize: 512 0.00000307 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000279 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:300 RM:0 RC:2000 WM:0 WC:110 0.00000307 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:75 RM:0 RC:400 WM:0 WC:300 0.00000559 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: RXCLEAR 0.00000335 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: TXCLEAR 0.00064980 TunerPro.exe IRP_MJ_WRITE VCP0 SUCCESS Length 1: . 0.01498738 TunerPro.exe IRP_MJ_READ VCP0 SUCCESS Length 1: . 0.00000363 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:200 RM:0 RC:20 WM:0 WC:300 0.02042774 TunerPro.exe IRP_MJ_READ VCP0 TIMEOUT Length 0: That is time on the left side. Now I'm with you on timing, it doesn't make a lot of sense, but that is how the logs come out. You can view the logs yourself. Tunerpro log : http://www.ds-map.net/tunerpro_log.csv My apps log : http://www.ds-map.net/my_log.csv 2nd app log : http://www.ds-map.net/my_log2.csv All these logs, were done from the same car, same cable. I have some older logs with some palm software, that was 13 sensors, and had a total 45-55ms between each set of 13. More info about the car / ecu at http://mmcdlogger.sourceforge.net Disassembly on the ecu: [SS1:SS0] is baud rate divider, 00(16) 01(128) 10(1024) 11(4096), assuming basic clock of 2MHZ, we get 125000baud, 15625baud, 1953baud, 488baud In any event, I attempted a no sleep thread, that waited till in.available > 1, and it wasn't any faster than running the events. Then I tried a read write thread, that slept from 1ms to 30ms after it wrote (so it wouldn't read what it just wrote). And couldn't get it doing much. I wish I had more of an understanding of all of this, which is why I'm asking for help. On 03/08/11 03:00, jfh at greenhousepc.com wrote: > Curtis, > > At the risk of being told "No, they really say it can be done", 30 > sensors is 30 * 3 character times (are you sure it's not a single byte > response?). At 1953 baud, a single character time is 10 bits * (1 / > 1953) seconds, or 15.4ms as Bob pointed out. 30 * 15.4ms is 460ms, > and that assumes everything works perfectly, no turnaround times, etc. > > If you can come up with some other way to make the math work, I'd love > to hear it. > > Short and sweet -- just because TunerPro can talk to an ECM/ECU that > is running faster than 1953 baud doesn't mean your Mitsubishi (or > whatever car you've got that runs at 1953 baud) runs at that faster > baud rate. > > Also, are you sure your data cable is correct? What cable are you > using? What's the schematic? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 2:33 am > To: rxtx at qbang.org > > I am going to try a couple things today and hopefully figure > something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than > 25ms. > I've exchanged some emails with the author and it is a native C, > polling, no events just timeouts. > > Kusta thanks for the FTDI notice, I believe that is tunable, > however I > have a particular user using a Keyspan converter and verified > sampling > rate with 'TunerPro' and its just off the charts. > > Chris thank you, I'll look into the queing. > > On 03/07/11 23:02, Bob Jacobsen wrote: > > If you're transferring three bytes total at 1953 baud, it's going > to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to > wait 20msec to get the data back instead of 15.4 msec doesn't seem > to be as big a problem as you're making it sound. > > > > Bob > > > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > > > >> I guess I'm gunna need some serious help with this then, because > of the scenario I'm stuck with. > >> > >> To communicate there is only 1 data line, rx/tx tied together > with a diode protecting the tx. No RTS/CTS handshaking nothing.. > >> > >> So the ecu can't process the next byte of info, without you > pulling the 2 bytes back. I wish this was standard, but even the > baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard > spot with this.. > >> > >> in.read(data , 0, 2); > >> ^ would the above wait till the timeout to read 2 bytes ? or > read 1 byte wait for the 2nd ? or just read the 1 ?? > >> > >> On 03/07/11 18:50, jfh at greenhousepc.com > wrote: > >>> Curtis, > >>> > >>> No, I assume he means a real queue, not just "don't read all > the bytes at once." However, if you know you can process some > number of requests in some amount of time, allowing data to pile > up (receiver FIFO space permitting) can be a valid strategy. > Inserting gobs of Thread.yield() and notify() can help pep things > up as well. > >>> -- > >>> Julie Haugh > >>> Senior Design Engineer > >>> greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 13:12:03 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 12:12:03 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> Message-ID: <4D768D93.1030504@gmail.com> So I looked over the Tunerpro log again today.. is it me or does it appear to be reusing values ? On 03/08/11 03:00, jfh at greenhousepc.com wrote: > Curtis, > > At the risk of being told "No, they really say it can be done", 30 > sensors is 30 * 3 character times (are you sure it's not a single byte > response?). At 1953 baud, a single character time is 10 bits * (1 / > 1953) seconds, or 15.4ms as Bob pointed out. 30 * 15.4ms is 460ms, > and that assumes everything works perfectly, no turnaround times, etc. > > If you can come up with some other way to make the math work, I'd love > to hear it. > > Short and sweet -- just because TunerPro can talk to an ECM/ECU that > is running faster than 1953 baud doesn't mean your Mitsubishi (or > whatever car you've got that runs at 1953 baud) runs at that faster > baud rate. > > Also, are you sure your data cable is correct? What cable are you > using? What's the schematic? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 2:33 am > To: rxtx at qbang.org > > I am going to try a couple things today and hopefully figure > something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than > 25ms. > I've exchanged some emails with the author and it is a native C, > polling, no events just timeouts. > > Kusta thanks for the FTDI notice, I believe that is tunable, > however I > have a particular user using a Keyspan converter and verified > sampling > rate with 'TunerPro' and its just off the charts. > > Chris thank you, I'll look into the queing. > > On 03/07/11 23:02, Bob Jacobsen wrote: > > If you're transferring three bytes total at 1953 baud, it's going > to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to > wait 20msec to get the data back instead of 15.4 msec doesn't seem > to be as big a problem as you're making it sound. > > > > Bob > > > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > > > >> I guess I'm gunna need some serious help with this then, because > of the scenario I'm stuck with. > >> > >> To communicate there is only 1 data line, rx/tx tied together > with a diode protecting the tx. No RTS/CTS handshaking nothing.. > >> > >> So the ecu can't process the next byte of info, without you > pulling the 2 bytes back. I wish this was standard, but even the > baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard > spot with this.. > >> > >> in.read(data , 0, 2); > >> ^ would the above wait till the timeout to read 2 bytes ? or > read 1 byte wait for the 2nd ? or just read the 1 ?? > >> > >> On 03/07/11 18:50, jfh at greenhousepc.com > wrote: > >>> Curtis, > >>> > >>> No, I assume he means a real queue, not just "don't read all > the bytes at once." However, if you know you can process some > number of requests in some amount of time, allowing data to pile > up (receiver FIFO space permitting) can be a valid strategy. > Inserting gobs of Thread.yield() and notify() can help pep things > up as well. > >>> -- > >>> Julie Haugh > >>> Senior Design Engineer > >>> greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 13:51:13 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 13:51:13 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308135113.8ef0e5b4a80cef441275a6330ffad77d.a5fff5bbc7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From bob_jacobsen at lbl.gov Tue Mar 8 14:14:57 2011 From: bob_jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 8 Mar 2011 14:14:57 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D76848F.5080809@gmail.com> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> Message-ID: <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > Tunerpro log : http://www.ds-map.net/tunerpro_log.csv It's only reading one sensor per line. Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT changed in lines 16 and 40; every 24 lines but at a different phase. GramsRev in lines 23 and 47; every 24 lines, at yet another phase. Looks like (69-1) readings in 1.30 seconds = 19msec per reading. Arithmetic still works! Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From hakcenter at gmail.com Tue Mar 8 14:27:12 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 13:27:12 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> Message-ID: <4D769F30.9050807@gmail.com> Thank you guys, cause I was really worried there. I guess another win for math today hahaha. So what is the imposed latency that rxtx has ? maybe 5-10ms ? On 03/08/11 13:14, Bob Jacobsen wrote: > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > It's only reading one sensor per line. > > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT changed in lines 16 and 40; every 24 lines but at a different phase. GramsRev in lines 23 and 47; every 24 lines, at yet another phase. > > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. Arithmetic still works! > > Bob > -- > Bob Jacobsen, LBNL > Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue Mar 8 14:07:24 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Mar 2011 14:07:24 -0700 (MST) Subject: [Rxtx] Latency Woes In-Reply-To: <4D769F30.9050807@gmail.com> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> <4D769F30.9050807@gmail.com> Message-ID: Hi Curtis While not your exact question, a simple test I performed can give you a ballpark idea. Writing a byte to a loopback at 9600 baud and displaying elapsed time on the data available event takes ~10 ms round trip in a large application. There are occasional 20 ms latencies. I used a typical linux desktop to try it just now without any special considerations. Windows NT was a little faster - maybe 8 ms - when I tried several years ago. On Tue, 8 Mar 2011, Curtis Hacker wrote: > Thank you guys, cause I was really worried there. I guess another win for > math today hahaha. So what is the imposed latency that rxtx has ? maybe > 5-10ms ? > > On 03/08/11 13:14, Bob Jacobsen wrote: >> On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >>> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> It's only reading one sensor per line. >> >> Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT >> changed in lines 16 and 40; every 24 lines but at a different phase. >> GramsRev in lines 23 and 47; every 24 lines, at yet another phase. >> >> Looks like (69-1) readings in 1.30 seconds = 19msec per reading. >> Arithmetic still works! >> >> Bob >> -- >> Bob Jacobsen, LBNL >> Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >> JacobsenRG >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Wei.Shen at Honeywell.com Tue Mar 8 15:15:32 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Tue, 8 Mar 2011 17:15:32 -0500 Subject: [Rxtx] [rxtx] disconnect event Message-ID: <83B3B1411349194D9D05821CEF48E78C02284B17@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 16:05:12 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 16:05:12 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 16:26:15 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 15:26:15 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> References: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> Message-ID: <4D76BB17.2090305@gmail.com> So if I could get the baud up 15625, theoretical maximum latency is 1.92ms ? Basically 500 samples/sec ? 125000, theoretical maximum latency is 0.24ms ? Basically 4167 samples/sec ? Keeping the protocol the same. On 03/08/11 15:05, jfh at greenhousepc.com wrote: > Curtis, > > It's nowhere near that bad. I'd measured it once before, and I > believe it's sub-millisecond. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 3:27 pm > To: rxtx at qbang.org > > Thank you guys, cause I was really worried there. I guess another win > for math today hahaha. So what is the imposed latency that rxtx has ? > maybe 5-10ms ? > > On 03/08/11 13:14, Bob Jacobsen wrote: > > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > > It's only reading one sensor per line. > > > > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 > lines. IAT changed in lines 16 and 40; every 24 lines but at a > different phase. GramsRev in lines 23 and 47; every 24 lines, at > yet another phase. > > > > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. > Arithmetic still works! > > > > Bob > > -- > > Bob Jacobsen, LBNL > > Bob_Jacobsen at lbl.gov > +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Tue Mar 8 17:40:36 2011 From: jredman at ergotech.com (Jim Redman) Date: Tue, 08 Mar 2011 17:40:36 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D76BB17.2090305@gmail.com> References: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> <4D76BB17.2090305@gmail.com> Message-ID: <4D76CC84.9040307@ergotech.com> How long does it take the device to generate a response? Increasing the baud rate may not help you much if the device takes a significant amount of time to process the request. On 03/08/2011 04:26 PM, Curtis Hacker wrote: > So if I could get the baud up > 15625, theoretical maximum latency is 1.92ms ? Basically 500 samples/sec ? > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 samples/sec ? > > Keeping the protocol the same. > > On 03/08/11 15:05, jfh at greenhousepc.com wrote: >> Curtis, >> >> It's nowhere near that bad. I'd measured it once before, and I >> believe it's sub-millisecond. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker > >> Date: Tue, March 08, 2011 3:27 pm >> To: rxtx at qbang.org >> >> Thank you guys, cause I was really worried there. I guess another win >> for math today hahaha. So what is the imposed latency that rxtx has ? >> maybe 5-10ms ? >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> > It's only reading one sensor per line. >> > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 >> lines. IAT changed in lines 16 and 40; every 24 lines but at a >> different phase. GramsRev in lines 23 and 47; every 24 lines, at >> yet another phase. >> > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. >> Arithmetic still works! >> > >> > Bob >> > -- >> > Bob Jacobsen, LBNL >> > Bob_Jacobsen at lbl.gov >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 jfh at greenhousepc.com Tue Mar 8 17:58:24 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 17:58:24 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 18:06:04 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 18:06:04 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 18:14:14 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 17:14:14 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> References: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> Message-ID: <4D76D466.7060303@gmail.com> I can edit the ECU eeprom to change the baud rate divisor to bump it up from 1953, to 15625 or 125000. But as Jim asked how fast the device can respond.. not very fast in its stock form. I can recode a lot of the eeprom for the ecu to alter the ecus baud rate, and put the response code into its own interrupt. I just wanted to make sure that in order to lower latency and increase sampling rate. I have to increase the baud rate of the ecu and the user right ? Or change the protocol.. to respond with more sensors per request. On 03/08/11 16:58, jfh at greenhousepc.com wrote: > Unless the ECU can auto-detect the baud rate, it won't even work. > > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Jim Redman > > Date: Tue, March 08, 2011 6:40 pm > To: rxtx at qbang.org > > How long does it take the device to generate a response? > > Increasing the baud rate may not help you much if the device takes a > significant amount of time to process the request. > > > On 03/08/2011 04:26 PM, Curtis Hacker wrote: > > So if I could get the baud up > > 15625, theoretical maximum latency is 1.92ms ? Basically 500 > samples/sec ? > > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 > samples/sec ? > > > > Keeping the protocol the same. > > > > On 03/08/11 15:05, jfh at greenhousepc.com > wrote: > >> Curtis, > >> > >> It's nowhere near that bad. I'd measured it once before, and I > >> believe it's sub-millisecond. > >> -- > >> Julie Haugh > >> Senior Design Engineer > >> greenHouse Computers, LLC // jfh at greenhousepc.com > > >> ; // > greenHousePC on Skype > >> > >> > >> -------- Original Message -------- > >> Subject: Re: [Rxtx] Latency Woes > >> From: Curtis Hacker > > >> Date: Tue, March 08, 2011 3:27 pm > >> To: rxtx at qbang.org > >> > >> Thank you guys, cause I was really worried there. I guess > another win > >> for math today hahaha. So what is the imposed latency that rxtx > has ? > >> maybe 5-10ms ? > >> > >> On 03/08/11 13:14, Bob Jacobsen wrote: > >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > >> > It's only reading one sensor per line. > >> > > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 > >> lines. IAT changed in lines 16 and 40; every 24 lines but at a > >> different phase. GramsRev in lines 23 and 47; every 24 lines, at > >> yet another phase. > >> > > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. > >> Arithmetic still works! > >> > > >> > Bob > >> > -- > >> > Bob Jacobsen, LBNL > >> > Bob_Jacobsen at lbl.gov > > >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > >> > > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Tue Mar 8 18:19:14 2011 From: jredman at ergotech.com (Jim Redman) Date: Tue, 08 Mar 2011 18:19:14 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> References: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> Message-ID: <4D76D592.9000802@ergotech.com> I'm no expert on this, but isn't the underlying ODB-II CAN bus or something similar. They always seem to require a dongle that converts to something. I know you can get serial, bluetooth, USB, etc. converters. I've seen serial dongles that claim multiple baud rates, so I suspect that whatever's providing the conversion may significantly affect the performance. A big second on the required timing comment. I suspect some intelligent consideration of what values change quickly (RPM, Speed, maybe things like fuel pressure) and read values like fuel levels, coolant temps, etc. much less frequently. On 03/08/2011 06:06 PM, jfh at greenhousepc.com wrote: > Curtis, > > You can't just increase the baud rate and have the device adapt to that > rate. Embedded systems tend to have their communications parameters > either hard coded in a memory location or else they are using a hardware > timebase. You're welcome to try increasing the baud rate, but there is > no guarantee it will even work. > > Whoever designed the ECU probably selected the baud rate for a good > reason. My suggestion would be to look at how the sensor values are all > laid out and go from there. Also, look at what the sensor represent and > consider the physical properties of what is being measured. It's > extremely unlikely that, for example, the coolant temperature is going > to rise more than 1* per second. If that much. Some values might change > more often, but do they really matter on a sub-second measurement basis? > > Part of software =engineering= is understanding the problem. Anyone can > sling code in the hope it works. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 5:26 pm > To: rxtx at qbang.org > > So if I could get the baud up > 15625, theoretical maximum latency is 1.92ms ? Basically 500 > samples/sec ? > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 > samples/sec ? > > Keeping the protocol the same. > > On 03/08/11 15:05, jfh at greenhousepc.com wrote: >> Curtis, >> >> It's nowhere near that bad. I'd measured it once before, and I >> believe it's sub-millisecond. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker > > >> Date: Tue, March 08, 2011 3:27 pm >> To: rxtx at qbang.org >> >> Thank you guys, cause I was really worried there. I guess >> another win >> for math today hahaha. So what is the imposed latency that >> rxtx has ? >> maybe 5-10ms ? >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> > It's only reading one sensor per line. >> > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every >> 24 lines. IAT changed in lines 16 and 40; every 24 lines but >> at a different phase. GramsRev in lines 23 and 47; every 24 >> lines, at yet another phase. >> > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per >> reading. Arithmetic still works! >> > >> > Bob >> > -- >> > Bob Jacobsen, LBNL >> > Bob_Jacobsen at lbl.gov >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > ------------------------------------------------------------------------ > _______________________________________________ > Rxtx mailing list > Rxtx 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 jfh at greenhousepc.com Tue Mar 8 18:32:28 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 18:32:28 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 19:45:00 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 18:45:00 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> References: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> Message-ID: <4D76E9AC.8050909@gmail.com> Julie, I really am not looking at the practicality of it. I was just wondering if that is how it works. I don't know a whole lot about rs232, which is the main reason I've been on this mailing list for a couple years. I have full control over the ecu eeprom code, I can change its baud rate, I can re-write the logging interface, I could update the ADC's on the ecu in the interface so that when you request said sensor it updates the ADC then replies it. But I wanted to know if the underlying issue with a 2mhz/8mhz processor is the baud rate keeping sampling down ? On 03/08/11 17:32, jfh at greenhousepc.com wrote: > Curtis, > > You also have to look at the response time of the sensor itself. > > Seriously -- look at what the sensors are reporting and determine if > the underlying physical property can actually change that rapidly. > And even if it can, do you really need to know that. > > I built drag bikes in the 70's and I drive sports cars in my old age. > You don't really need millisecond sampling rates for every single last > sensor coming out of the engine. Boost pressure, fuel pressure, > manifold pressure and RPMs are probably high frequency sensors if you > want to tweak the motor for turbo lag or something, but other than > that, are you really going to be able to make sense of all that data? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 7:14 pm > To: rxtx at qbang.org > > I can edit the ECU eeprom to change the baud rate divisor to bump > it up from 1953, to 15625 or 125000. But as Jim asked how fast the > device can respond.. not very fast in its stock form. > > I can recode a lot of the eeprom for the ecu to alter the ecus > baud rate, and put the response code into its own interrupt. > > I just wanted to make sure that in order to lower latency and > increase sampling rate. I have to increase the baud rate of the > ecu and the user right ? Or change the protocol.. to respond with > more sensors per request. > > On 03/08/11 16:58, jfh at greenhousepc.com wrote: >> Unless the ECU can auto-detect the baud rate, it won't even work. >> >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Jim Redman > > >> Date: Tue, March 08, 2011 6:40 pm >> To: rxtx at qbang.org >> >> How long does it take the device to generate a response? >> >> Increasing the baud rate may not help you much if the device >> takes a >> significant amount of time to process the request. >> >> >> On 03/08/2011 04:26 PM, Curtis Hacker wrote: >> > So if I could get the baud up >> > 15625, theoretical maximum latency is 1.92ms ? Basically 500 >> samples/sec ? >> > 125000, theoretical maximum latency is 0.24ms ? Basically >> 4167 samples/sec ? >> > >> > Keeping the protocol the same. >> > >> > On 03/08/11 15:05, jfh at greenhousepc.com >> wrote: >> >> Curtis, >> >> >> >> It's nowhere near that bad. I'd measured it once before, and I >> >> believe it's sub-millisecond. >> >> -- >> >> Julie Haugh >> >> Senior Design Engineer >> >> greenHouse Computers, LLC // jfh at greenhousepc.com >> >> >> ; // >> greenHousePC on Skype >> >> >> >> >> >> -------- Original Message -------- >> >> Subject: Re: [Rxtx] Latency Woes >> >> From: Curtis Hacker > > >> >> Date: Tue, March 08, 2011 3:27 pm >> >> To: rxtx at qbang.org >> >> >> >> >> Thank you guys, cause I was really worried there. I guess >> another win >> >> for math today hahaha. So what is the imposed latency that >> rxtx has ? >> >> maybe 5-10ms ? >> >> >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> >> > It's only reading one sensor per line. >> >> > >> >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; >> every 24 >> >> lines. IAT changed in lines 16 and 40; every 24 lines but at a >> >> different phase. GramsRev in lines 23 and 47; every 24 >> lines, at >> >> yet another phase. >> >> > >> >> > Looks like (69-1) readings in 1.30 seconds = 19msec per >> reading. >> >> Arithmetic still works! >> >> > >> >> > Bob >> >> > -- >> >> > Bob Jacobsen, LBNL >> >> > Bob_Jacobsen at lbl.gov >> >> >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Rxtx mailing list >> >> > Rxtx at qbang.org >> >> >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > ------------------------------------------------------------------------ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 20:43:11 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 20:43:11 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308204311.8ef0e5b4a80cef441275a6330ffad77d.e9b135168c.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From andrea.antonello at gmail.com Wed Mar 9 06:50:07 2011 From: andrea.antonello at gmail.com (andrea antonello) Date: Wed, 9 Mar 2011 14:50:07 +0100 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> References: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> Message-ID: Has anyone tried the lib? I am not sure if it is appropriate to write to the list about this, if not, I apologize. I wanted to try your fork out for our application which is an eclipse rcp plugin based one. It has been easy to substitute the 6 plugins with your library (that is one of the things I like). But then when I run it, it tries to load it from: ---- Loading: /tmp/libNRJavaSerial_moovida_0/libNRJavaSerial.so Trying to load: NRJavaSerial Trying to load: libNRJavaSerial Trying to load: rxtxSerial ---- So it is extracting the native lib to a tmp folder. But that one is not in the library path, so it fails. Is there any docs to try the lib out? Thanks, Andrea On Mon, Mar 7, 2011 at 11:54 PM, wrote: > Aaron, > > It should be possible for an Android to do BlueTooth serial.? If I were > looking for a serial solution, that's how I'd go. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on > Skype > > -------- Original Message -------- > Subject: [SPAM] Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > papercuts! > From: Aaron Wolfe > Date: Mon, March 07, 2011 4:31 pm > To: rxtx at qbang.org > > On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR > wrote: >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> >> * Self deployment of native libraries ( all native code is stored >> inside the jar and deployed at runtime). No more manual install of >> native code. >> * Arm Cortex support (Gumstix) >> * Android Support (requires a rooted phone for now) >> * Google Code (SVN) repository for easy code and jar access >> * Single makefile compile (simplifies the compilation of project binaries) >> * Ant build script for jar creation >> * Removal of partialy implemented code to streamline the lib for just >> serial port access >> * Full Eclipse integration, for testing application code against sources. >> >> And a bunch of bug fixes: >> >> * Fixed the memory access error that causes OSX to crash the JVM when >> serial.close() is cvalled >> * Fixed the windows serial port zombie bind that prevents re-accessing >> serial ports when exiting on an exception >> * Fixed erronious printouts of native library mis-match >> >> To check it out, take a look at our page here: >> >> http://code.google.com/p/nrjavaserial/ > > This is interesting, getting the native libs set up has been an issue > for some of my users. Will have to check it out. > > Out of curiosity, what Android devices provide a serial port? Or are > there some that allow USB host mode and then a usb-serial adapter? I > have only an Android cell phone, don't think it can do anything serial > but would love to be wrong 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 Cougar at CasaDelGato.Com Wed Mar 9 10:02:24 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 09 Mar 2011 09:02:24 -0800 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> References: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> Message-ID: <4D77B2A0.8020004@CasaDelGato.Com> On 3/7/2011 2:54 PM, jfh at greenhousepc.com wrote: > Aaron, > > It should be possible for an Android to do BlueTooth serial. If I > were looking for a serial solution, that's how I'd go. Actually, I can't figure out WHY you would need RxTx on an Android device. The built in bluetooth support works just fine with a serial-bluetooth converter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Mar 1 00:54:17 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 09:54:17 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> Message-ID: Adrian, had a look at your code/rewrite and it looks rather clean/nice. I was looking at the code to gain insight (not related to the rewrite) into what is involved in serial port programming in Windows. Or rather, to refresh my memory and see how others have done, because I've been there done that. So my questions are just to satisfy my curiosity, not to criticize or suggest improvements. 1) It looks like a new thread (EventMonitor) is created for each Serial port, is that correct? Many people seem to try to avoid using many threads in this sort of situation, and like to use something like unix select(). I personally find using threads more natural and better impedance match to the problem being solved here. I guess 'many people' above refers to those implementing thousands of connections and who cannot live with the overhead and limited number of threads available. 2) The EventMonitor basically polls for events at 50 msec interval? 3) There is a comment in the source code near the sleep(50) : // Sufficient up to 19200 baud I'm sure you thought about this carefully, so again not criticizing, but seeking to understand how or why, because at 50 msec would seem to limit through in some cases. Like if you send one byte and need to wait for one to return, then this limits speed to 200 chars/sec? 4) I've done something similar to a few years back from Java using JNI to access Win32 API serial port, and I seem to recall that I had threading issues ie when I submitted a read (ReadFile) and there was no data coming in, the thread would not only block but also consume a lot of CPU cycles ie it was not sleeping properly inside the ReadFile call when the serial port blocked. Im a bit fuzzy about the details after five years, so my question is have you checked if there an issue here? 5) AFAIK the select() on Windows does not work serial ports but there is some other mechanism (events?) to implement the same functionality, did you consider that? Probably, so you decided against it, why? br Kusti From adrian.crum at sandglass-software.com Tue Mar 1 04:13:34 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:13:34 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: References: Message-ID: <4D6CD4DE.7040501@sandglass-software.com> The javax.comm API specification requires one event monitor thread per port. I don't like the idea of having a thread per port either, but one of the rewrite's design goals is strict conformance to the specification. The 50 mS polling interval is just a placeholder. The final design of that is yet to be decided. In Windows, you have two choices for I/O: overlapped and non-overlapped. In overlapped I/O a thread is blocked, waiting for something to happen. In non-overlapped I/O a thread does not block. I chose non-overlapped I/O to avoid thread blocking at the OS level - instead, the thread blocking is kept in Java. -Adrian On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > Adrian, > > had a look at your code/rewrite and it looks rather clean/nice. > > I was looking at the code to gain insight (not related to the > rewrite) into what is involved in serial port programming > in Windows. Or rather, to refresh my memory and see how others have > done, because I've been there done that. > > So my questions are just to satisfy my curiosity, not to criticize > or suggest improvements. > > 1) It looks like a new thread (EventMonitor) is created for > each Serial port, is that correct? > > Many people seem to try to avoid using many threads in this sort > of situation, and like to use something like unix select(). > I personally find using threads more natural and better impedance > match to the problem being solved here. I guess 'many people' above > > refers to those implementing thousands of connections and > who cannot live with the overhead and limited number of threads > available. > > 2) The EventMonitor basically polls for events at 50 msec interval? > > 3) There is a comment in the source code near the sleep(50) : > > // Sufficient up to 19200 baud > > > I'm sure you thought about this carefully, so again not > criticizing, but seeking to understand how or why, because > at 50 msec would seem to limit through in some cases. Like > if you send one byte and need to wait for one to return, > then this limits speed to 200 chars/sec? > > 4) I've done something similar to a few years back from > Java using JNI to access Win32 API serial port, and > I seem to recall that I had threading issues ie when > I submitted a read (ReadFile) and there was no data coming > in, the thread would not only block but also consume a > lot of CPU cycles ie it was not sleeping properly inside > the ReadFile call when the serial port blocked. > > Im a bit fuzzy about the details after five years, so my question is > have you checked if there an issue here? > > > 5) AFAIK the select() on Windows does not work serial ports > but there is some other mechanism (events?) to implement the > same functionality, did you consider that? Probably, so you > decided against it, why? > > > br Kusti > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Tue Mar 1 04:25:23 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:25:23 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C2E90.9010601@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > My question would be: Why would you do that? The rewrite does > most of the work for you - all you have to do is implement > two C++ virtual classes and two C++ functions. You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? I just took a short look, maybe it could be discussed further, but I don't think I like it much. BTW, the main interface defined there is called gnu.io.Dispatcher? I thought the package names should be used in a way to avoid clashes, e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name space authority :)). > In Windows that took me a few hours. where is the implementation? I found commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp with things like const bool SerialPortImpl::isDataAvailable() const { // Needs implementation return true; } and timeouts.ReadIntervalTimeout = MAXDWORD;* timeouts.ReadTotalTimeoutMultiplier = 0; timeouts.ReadTotalTimeoutConstant = 0; timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 0; if (!SetCommTimeouts(hComm, &timeouts)) throw IOException(); which seems to be oversimplified or some prototype only? I think (and I wrote about this already in the past years) that correct timeout handling is one of the challenges, so I think this should be prototyped first - for each system flavor - before cementation of the (JNI-) interfaces. Personally, I would vote to form it in a way allowing to be implemented on embedded devices, for example. Another big challenge is to prove a rewrite fully working (and probably compatible to the old implementation) on "all" the supported OSes. Not a big problem for linux and windows, just use some thousand lines test code, test drivers and serial loopbacks etc, but for the exotic platforms, probably a high number of, this probably won't be too easy... (there are more challenges, such as being comfortable and threadsafe [are read and write permitted at the same time?], detailed and helpful exceptions on user API level [not necessarily on JNI/JNA layer], how to have a configurable threadsafe logging/tracing [maybe also from native code to assist porting / testing on exotic OSes, such as OSes where the developers have no direct access too, which can be quite hard to usually leads to good log messages], just to name a few.). So even it might seem easy for one platform and I agree with Micheal that > > * yay! let's start a rewrite is unlikely to succeede soon... However, when considering this, before IMHO a powerful Java API has to be defined, because according to my experiences for implementing non-trivial protocols InputStream/OutputStream might not be comfortable/powerfull enough (eventually I consider both wrong) and have some InputStream derivation available as wrapper (so applications can use InputStream and whatever high-level-API they want). The JNI interface shall make such a powerful implementation possible, thus the interface of it is driving the JNI interface design and thus I think it had to be done first. All this surely requires much work: agreements on the APIs, safeness for the users, design, documentation, all the implementations and the testing. As long as such bug amount of work cannot be spent, for example if some employee would get half a year time paid for it or so :-), probably it is unlikely to progress on this. Otherwise, I'm afraid, patches, improvements, new design ideas and even rewrites wouldn't become complete and thus won't form a new rxtx version (3.0); thus either collect dust in some forgotten CVS branch or could generate a split... > I can't imagine other ports taking > much longer than that - especially since POSIX-based code can > be shared between ports. Things are more complex than they seem to be... I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select on serial ports isn't supported; maybe it is non-trivial to "map" (like mapping select() to WaitForMultipleObjects() which might have different semantics etc.) or maybe some different approach has to be used. A system may have POSIX like termios interfaces but not support timeouts or have any other interoperability bug... You never run out of things that can go wrong. And if something can go wrong, it will... :-) Or, as Michael wrote: > > I seriously don't believe anyone will come up with anything better anytime soon. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue Mar 1 04:39:37 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:39:37 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com><13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED6B@COSNPREXC3.usr.ingenico.loc> > 3. Write all of the native (or non-native) code to implement > the native interface. > > Is that correct? If yes, how is that easier than the simple > implementation the current rewrite design uses? To have it complete, reliable, traceable, maintainable and well tested, it is much more work, I'm afraid. A prototype can be done within a few days (maybe on one day), but getting it right (including a passed review) IMHO is a completely different story. In the end you may end up with an average of ten lines per day, when assuming four major native packs (common, win, mac, termios/select) with let's say just 5000 lines each (with logging messages and detailed exceptions this is not much) we would have to estimate a total effort of nine man-years (20000/10/220)... oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 04:40:18 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:40:18 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6CDB22.9070401@sandglass-software.com> Every journey begins with a single step. -Adrian On 3/1/2011 3:25 AM, Steffen DETTMER wrote: > * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> My question would be: Why would you do that? The rewrite does >> most of the work for you - all you have to do is implement >> two C++ virtual classes and two C++ functions. > You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? > I just took a short look, maybe it could be discussed further, > but I don't think I like it much. > BTW, the main interface defined there is called gnu.io.Dispatcher? > I thought the package names should be used in a way to avoid clashes, > e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name > space authority :)). > >> In Windows that took me a few hours. > where is the implementation? > I found > commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp > with things like > > const bool SerialPortImpl::isDataAvailable() const > { > // Needs implementation > return true; > } > > and > > timeouts.ReadIntervalTimeout = MAXDWORD;* > timeouts.ReadTotalTimeoutMultiplier = 0; > timeouts.ReadTotalTimeoutConstant = 0; > timeouts.WriteTotalTimeoutMultiplier = 0; > timeouts.WriteTotalTimeoutConstant = 0; > if (!SetCommTimeouts(hComm,&timeouts)) > throw IOException(); > > which seems to be oversimplified or some prototype only? > > I think (and I wrote about this already in the past years) that correct > timeout handling is one of the challenges, so I think this should be > prototyped first - for each system flavor - before cementation of the > (JNI-) interfaces. Personally, I would vote to form it in a way allowing > to be implemented on embedded devices, for example. > > Another big challenge is to prove a rewrite fully working (and probably > compatible to the old implementation) on "all" the supported OSes. Not a > big problem for linux and windows, just use some thousand lines test > code, test drivers and serial loopbacks etc, but for the exotic > platforms, probably a high number of, this probably won't be too easy... > (there are more challenges, such as being comfortable and threadsafe > [are read and write permitted at the same time?], detailed and helpful > exceptions on user API level [not necessarily on JNI/JNA layer], how to > have a configurable threadsafe logging/tracing [maybe also from native > code to assist porting / testing on exotic OSes, such as OSes where the > developers have no direct access too, which can be quite hard to usually > leads to good log messages], just to name a few.). > > So even it might seem easy for one platform and I agree with Micheal > that > >>> * yay! let's start a rewrite > is unlikely to succeede soon... > > However, when considering this, before IMHO a powerful Java API has to > be defined, because according to my experiences for implementing > non-trivial protocols InputStream/OutputStream might not be > comfortable/powerfull enough (eventually I consider both wrong) and have > some InputStream derivation available as wrapper (so applications can > use InputStream and whatever high-level-API they want). > The JNI interface shall make such a powerful implementation possible, > thus the interface of it is driving the JNI interface design and thus I > think it had to be done first. > > All this surely requires much work: agreements on the APIs, safeness for > the users, design, documentation, all the implementations and the > testing. As long as such bug amount of work cannot be spent, for example > if some employee would get half a year time paid for it or so :-), > probably it is unlikely to progress on this. > > Otherwise, I'm afraid, patches, improvements, new design ideas and even > rewrites wouldn't become complete and thus won't form a new rxtx version > (3.0); thus either collect dust in some forgotten CVS branch or could > generate a split... > >> I can't imagine other ports taking >> much longer than that - especially since POSIX-based code can >> be shared between ports. > Things are more complex than they seem to be... > > I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select > on serial ports isn't supported; maybe it is non-trivial to "map" (like > mapping select() to WaitForMultipleObjects() which might have different > semantics etc.) or maybe some different approach has to be used. A > system may have POSIX like termios interfaces but not support timeouts > or have any other interoperability bug... > You never run out of things that can go wrong. And if something can go > wrong, it will... :-) > > Or, as Michael wrote: > >>> I seriously don't believe anyone will come up with anything better > anytime soon. > > oki, > > Steffen > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Kustaa.Nyholm at planmeca.com Tue Mar 1 04:57:02 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 13:57:02 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: On 3/1/11 13:13, "Adrian Crum" wrote: >The javax.comm API specification requires one event monitor thread per >port. I don't like the idea of having a thread per port either, but one >of the rewrite's design goals is strict conformance to the specification. Ah, had not spotted that requirement. > >The 50 mS polling interval is just a placeholder. The final design of >that is yet to be decided. > >In Windows, you have two choices for I/O: overlapped and non-overlapped. >In overlapped I/O a thread is blocked, waiting for something to happen. >In non-overlapped I/O a thread does not block. I chose non-overlapped >I/O to avoid thread blocking at the OS level - instead, the thread >blocking is kept in Java. > >-Adrian thanks for the explanation. br Kusti From iqzw2r602 at sneakemail.com Tue Mar 1 05:08:17 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:08:17 +1100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <32684-1298981297-704398@sneakemail.com> This reminds me of a nasty problem I had with overlapped I/O on windows with jpathwatch. You can't start an I/O request in one thread and then do the check if that request completed in another thread. Very strange things happen when you attempt that; made me change the design of the Windows implementation quite drastically (one thread on a command queue that executes requests from other threads instead of letting them wildly call into GetOverlappedResult()). Out of curiosity: Did you come across that too? Or are all requests handled in the same thread they're issued? Cheers, Uwe On Tue, Mar 1, 2011 at 10:13 PM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > The javax.comm API specification requires one event monitor thread per > port. I don't like the idea of having a thread per port either, but one of > the rewrite's design goals is strict conformance to the specification. > > The 50 mS polling interval is just a placeholder. The final design of that > is yet to be decided. > > In Windows, you have two choices for I/O: overlapped and non-overlapped. In > overlapped I/O a thread is blocked, waiting for something to happen. In > non-overlapped I/O a thread does not block. I chose non-overlapped I/O to > avoid thread blocking at the OS level - instead, the thread blocking is kept > in Java. > > -Adrian > > > On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > >> Adrian, >> >> had a look at your code/rewrite and it looks rather clean/nice. >> >> I was looking at the code to gain insight (not related to the >> rewrite) into what is involved in serial port programming >> in Windows. Or rather, to refresh my memory and see how others have >> done, because I've been there done that. >> >> So my questions are just to satisfy my curiosity, not to criticize >> or suggest improvements. >> >> 1) It looks like a new thread (EventMonitor) is created for >> each Serial port, is that correct? >> >> Many people seem to try to avoid using many threads in this sort >> of situation, and like to use something like unix select(). >> I personally find using threads more natural and better impedance >> match to the problem being solved here. I guess 'many people' above >> >> refers to those implementing thousands of connections and >> who cannot live with the overhead and limited number of threads >> available. >> >> 2) The EventMonitor basically polls for events at 50 msec interval? >> >> 3) There is a comment in the source code near the sleep(50) : >> >> // Sufficient up to 19200 baud >> >> >> I'm sure you thought about this carefully, so again not >> criticizing, but seeking to understand how or why, because >> at 50 msec would seem to limit through in some cases. Like >> if you send one byte and need to wait for one to return, >> then this limits speed to 200 chars/sec? >> >> 4) I've done something similar to a few years back from >> Java using JNI to access Win32 API serial port, and >> I seem to recall that I had threading issues ie when >> I submitted a read (ReadFile) and there was no data coming >> in, the thread would not only block but also consume a >> lot of CPU cycles ie it was not sleeping properly inside >> the ReadFile call when the serial port blocked. >> >> Im a bit fuzzy about the details after five years, so my question is >> have you checked if there an issue here? >> >> >> 5) AFAIK the select() on Windows does not work serial ports >> but there is some other mechanism (events?) to implement the >> same functionality, did you consider that? Probably, so you >> decided against it, why? >> >> >> br Kusti >> >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 05:37:07 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:37:07 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <1142-1298983027-957144@sneakemail.com> On Tue, Mar 1, 2011 at 1:32 PM, Adrian Crum wrote: > Just to make sure I'm understanding you correctly, anyone porting RxTx to > a new platform would have to do the following: > > 1. Write their own Java implementation of an abstract Dispatcher class. > yep. I'd probably put all my calls to native OS wrappers in there two, looks the most straight-forward to me. > 2. Write a native (JNI or JNA) interface for the abstract class > implementation. > yes. For POSIX you'd probably only write one piece of code that provides implementations for open(), close(), and friends. You can compile that on all posix platforms (yeah, the devil is in the detail, but it's very little code, still). So this does open() (when using ***, but you can also use +++) // Unix.java class Unix{ public static native int open(String filename, int flags, int mode); .... } // Unix.cpp JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) { const char* pathname = env->GetStringUTFChars(jpathname, 0); if(pathname == 0) return -1; // java throws an out of memory error in this case int result = open(pathname, flags, mode); Unix_cacheErrno(); // handle interference between JVM and errno; env->ReleaseStringUTFChars(jpathname, pathname); return result; } .... 3. Write all of the native (or non-native) code to implement the native > interface. > Not sure what you mean by that. I've done the OS wrappers in step 2. step 1. implements that Dispatcher. What else do I need? > Is that correct? If yes, how is that easier than the simple implementation > the current rewrite design uses? > Yes, except for 3 (see above). How it is easier: I can debug the Java code directly. I can step from the read() call of an input stream directly into the guts of the RXTX implementation on my platform and see e.g. why it's hanging, because I see all the way up the call stack right where it calls Unix.read(). You can't easily do that with a fat native library, especially if you have no second set of devtools installed (the ones for native development). And I bet anyone knowing both languages can write it faster in Java, with less bugs. > On a side note: there is no requirement to write native code using C++. If > C++ is a real obstacle to adoption, then regular C could be used instead. In > that case, there would be a Dispatcher.c file that contains function > protoypes that need to be implemented. Dispatcher.c would still maintain the > same role as Dispatcher.cpp - which is to shield native code developers from > the details of JNI. Just build out the missing functions using C data types > and you're ready to go. > As I said, whatever works for you. Java works for me better than C++ in this case... Cheers, Uwe -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Mar 1 08:26:41 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 16:26:41 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> > The javax.comm API specification requires one event monitor > thread per port. Where does it require this? Do you mean "All the events received by this listener are generated by one dedicated thread that belongs to the SerialPort object. "? I think this is an implementation detail, isn't it? At least it is mentioned after "The current implementation only allows one listener per SerialPort". A bit bad that javadoc does not distinguish between API spec and implementation documentation. Also I don't think that TooManyListenersException MUST be thrown (I think it CAN be thrown). > I don't like the idea of having a thread per > port either, but one of the rewrite's design goals is strict > conformance to the specification. (but not necessarily on JNI layer) > The 50 mS polling interval is just a placeholder. The final > design of that is yet to be decided. I though no polling would be wanted; what could be the placeholder stand for? Do you mean a different interval duration or do you mean something completely different? > In Windows, you have two choices for I/O: overlapped and > non-overlapped. > In overlapped I/O a thread is blocked, waiting for something > to happen. > In non-overlapped I/O a thread does not block. I chose > non-overlapped I/O to avoid thread blocking at the OS level - > instead, the thread blocking is kept in Java. Isn't "overlapped" (asynchronous) I/O meaning that you invoke some ReadFile(..., &overlapped, ...) INSTEAD of performing a synchronous (blocking) function call blocking the thread? As far as I see, W32_Support.cpp uses CreateFile without FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O operations are serialized, even if the calls to the read and write functions specify an OVERLAPPED structure." [1] and "A synchronous handle behaves such that I/O function calls using that handle are blocked until they complete" [2] Given that CCOMTIMEOUTS get: "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the bytes that have already been received, even if no bytes have been received." [3] It looks likes this implementation relies on polling, which probably would waste much computing power. What did I miss? oki, Steffen [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro nous_and_asynchronous_i_o_handles [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 09:23:47 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:23:47 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6D1D93.6090306@sandglass-software.com> Unfortunately, the javax.comm API specification includes a lot of implementation details. That is one of the weaknesses of the specification in my opinion. The bottom line is, anyone wanting to use RxTx as a javax.comm implementation is going to expect it to do the things the specification says it does. -Adrian On 3/1/2011 7:26 AM, Steffen DETTMER wrote: >> The javax.comm API specification requires one event monitor >> thread per port. > Where does it require this? > > Do you mean "All the events received by this listener are generated > by one dedicated thread that belongs to the SerialPort object. "? > > I think this is an implementation detail, isn't it? At least it is > mentioned after "The current implementation only allows one listener per > SerialPort". A bit bad that javadoc does not distinguish between API > spec and implementation documentation. Also I don't think that > TooManyListenersException MUST be thrown (I think it CAN be thrown). > >> I don't like the idea of having a thread per >> port either, but one of the rewrite's design goals is strict >> conformance to the specification. > (but not necessarily on JNI layer) > >> The 50 mS polling interval is just a placeholder. The final >> design of that is yet to be decided. > I though no polling would be wanted; what could be the placeholder stand > for? Do you mean a different interval duration or do you mean something > completely different? > >> In Windows, you have two choices for I/O: overlapped and >> non-overlapped. >> In overlapped I/O a thread is blocked, waiting for something >> to happen. >> In non-overlapped I/O a thread does not block. I chose >> non-overlapped I/O to avoid thread blocking at the OS level - >> instead, the thread blocking is kept in Java. > Isn't "overlapped" (asynchronous) I/O meaning that you invoke some > ReadFile(...,&overlapped, ...) > INSTEAD of performing a synchronous (blocking) function call blocking > the thread? > > As far as I see, W32_Support.cpp uses CreateFile without > FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O > operations are serialized, even if the calls to the read and write > functions specify an OVERLAPPED structure." [1] and "A synchronous > handle behaves such that I/O function calls using that handle are > blocked until they complete" [2] > > Given that CCOMTIMEOUTS get: > "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values > for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier > members, specifies that the read operation is to return immediately with > the bytes that have already been received, even if no bytes have been > received." [3] > > It looks likes this implementation relies on polling, which probably > would waste much computing power. > > What did I miss? > > oki, > > Steffen > > [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx > [2] > http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro > nous_and_asynchronous_i_o_handles > [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at sandglass-software.com Tue Mar 1 09:55:29 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:55:29 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <1142-1298983027-957144@sneakemail.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> Message-ID: <4D6D2501.1020803@sandglass-software.com> That code duplicates what is in Dispatcher.cpp. A Unix port would only need to implement CommPortFactory::getInstance(portName, portType). -Adrian On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 15:07:46 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 2 Mar 2011 09:07:46 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6D2501.1020803@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> <4D6D2501.1020803@sandglass-software.com> Message-ID: <23749-1299017266-991798@sneakemail.com> What is this duplicating? A Unix port will need to call open() anyways (just so we're talking about the same thing here: open() is the Unix equivalent of CreateFile()) On Wed, Mar 2, 2011 at 3:55 AM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > That code duplicates what is in Dispatcher.cpp. A Unix port would only > need to implement CommPortFactory::getInstance(portName, portType). > > -Adrian > > > On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Tue Mar 1 22:53:07 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 00:53:07 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: Hi, I haven't seen any response to my question below. Is this not the right place to ask? If not, where would be a better place to ask? Any suggestions? Thanks, Ryan On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >> Hi, >> >> I have a receive thread that does nothing but call read() on the serial >> port input stream. It works fine for a while but after running for a long >> time it eventually returns -1 which means EOF. This is my first problem, as >> the device I'm talking to runs forever, I don't know why it would return -1. >> I am calling disableReceiveThreshold() and disableReceiveTimeout() at >> initialization which according to the documentation means read will return >> as soon as any data is available and it will block forever when data is not >> available, so -1 should never be returned from read, right? >> >> I have been unable to figure out why read returns -1 after a long while >> but I have found that if I kill my application and restart it everything >> works fine again. Therefore I tried to work around the problem by having my >> code close the port and reopen it when read returns -1. My second problem is >> that in this case when I call close() on the port it blocks forever. I did >> find this old bug >> >> http://bugzilla.qbang.org/show_bug.cgi?id=53 >> >> which describes close() hanging on OSX, but it says that bug was fixed >> with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have >> any idea why read might be returning -1 in the first place? If I can avoid >> that I don't care about close() hanging because I would never close the >> port. If not, does anyone know why close() might block forever and how I can >> prevent this? I'm using RXTX version 2.1-7. >> >> Thanks, >> -- >> Ryan >> >> > > > -- > Ryan Boder > 1 614 598-6339 > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Mar 2 01:34:48 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 2 Mar 2011 10:34:48 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/2/11 07:53, "Ryan Boder" wrote: Can you / have you made a simple test to ensure that rxtx is the issue? Can you write a simple C-program to see if this exhibits the same problem? I've never encountered this sort of problem with rxtx, it mostly just works. But I'm on Mac so can't say about Windows (7) br Kusti >Hi, > >I haven't seen any response to my question below. Is this not the right >place to ask? If not, where would be a better place to ask? Any >suggestions? > >Thanks, >Ryan > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > >I mis-spoke, I don't have my own thread calling read, I am calling >read in the event handler after receiving a >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be >accurate though. > >Ryan > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >Hi, > >I have a receive thread that does nothing but call read() on the serial >port input stream. It works fine for a while but after running for a long >time it eventually returns -1 which means EOF. This is my first problem, >as the device I'm talking to runs forever, I don't know why it would >return -1. I am calling disableReceiveThreshold() and >disableReceiveTimeout() at initialization which according to the >documentation means read will return as soon as any data is available and >it will block forever when data is not available, so -1 should never be >returned from read, right? > >I have been unable to figure out why read returns -1 after a long while >but I have found that if I kill my application and restart it everything >works fine again. Therefore I tried to work around the problem by having >my code close the port and reopen it when read returns -1. My second >problem is that in this case when I call close() on the port it blocks >forever. I did find this old bug > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > >which describes close() hanging on OSX, but it says that bug was fixed >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone >have any idea why read might be returning -1 in the first place? If I can >avoid that I don't care about close() hanging because I would never close >the port. If not, does anyone know why close() might block forever and >how I can prevent this? I'm using RXTX version 2.1-7. > >Thanks, >-- >Ryan > > > > > > > > > >-- >Ryan Boder >1 614 598-6339 > > > > > > >-- >Ryan Boder >1 614 598-6339 > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From Steffen.DETTMER at ingenico.com Wed Mar 2 03:08:57 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:08:57 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <32684-1298981297-704398@sneakemail.com> References: <4D6CD4DE.7040501@sandglass-software.com> <32684-1298981297-704398@sneakemail.com> Message-ID: <20110302100857.GB8030@elberon.bln.de.ingenico.com> * iqzw2r602 at sneakemail.com wrote on Tue, Mar 01, 2011 at 23:08 +1100: > This reminds me of a nasty problem I had with overlapped I/O on windows Yeah, those thousands of complex, difficult to use and exception-containing WinAPI is really hard to use... About strange effects on overlapped&multithreading, MSDN has: `the calling thread uses the GetOverlappedResult function or one of the wait functions' [1] also also mentiones I/O Completion Ports [2], and later continues: `If an application reuses OVERLAPPED structures on multiple threads and calls GetOverlappedResult with the bWait parameter set to TRUE, the application must ensure that the associated event is set before the application reuses the structure. This can be accomplished by using the WaitForSingleObject function after calling GetOverlappedResult to force the thread to wait until the operation completes. Note that the event object must be a manual-reset event object. If an autoreset event object is used, calling GetOverlappedResult with the bWait parameter set to TRUE causes the function to be blocked indefinitely.' also [1] oki, Steffen [1] http://msdn.microsoft.com/en-us/library/ms686358%28v=vs.85%29.aspx [2] http://msdn.microsoft.com/en-us/library/aa365198%28v=vs.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:15:11 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:15:11 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6D1D93.6090306@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> <4D6D1D93.6090306@sandglass-software.com> Message-ID: <20110302101511.GC8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 08:23 -0800: > Unfortunately, the javax.comm API specification includes a lot of > implementation details. That is one of the weaknesses of the > specification in my opinion. The bottom line is, anyone wanting to use > RxTx as a javax.comm implementation is going to expect it to do the > things the specification says it does. Yeah ok, but even then the implementation could check for the TooManyListenersException situations (if it really is required to support applications relying on that exception) but internally use just a single I/O thread waiting for events on any open file descriptors. Of course an implementation supporting all sort of concurrency could become quite complex (especially if open-read-close should work fast, I think would be difficult to implement, because a new file descriptors had to be added to the waitFor/select list, and who knows how systems behave here in detail...). oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:25:15 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:25:15 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6CDB22.9070401@sandglass-software.com> References: <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> <4D6CDB22.9070401@sandglass-software.com> Message-ID: <20110302102515.GD8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 03:40 -0800: > * from some older mail: > > My question would be: Why would you do that? The rewrite does > > most of the work for you - all you have to do is implement > > two C++ virtual classes and two C++ functions. > > > > In Windows that took me a few hours. > > Every journey begins with a single step. Yes, of course, but then it shouldn't be used as base for new effort estimations like `In Windows that took a few hours' ;-) (BTW, calling a single step `the rewrite' may sound a bit ambitious ;)) But of course a prototype demonstrating something can be really helpful, sure. I just wanted to tell that interfaces should be easy to use and powerful at the same time and may non-trivial initial considerations before starting to implement them. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From ryan.boder at gmail.com Wed Mar 2 18:44:35 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:44:35 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: While running the tests you requested I may have stumbled on the problem, I just don't know how to fix it. According to the documentation, if both the receive timeout and receive threshold are disabled then read() should block forever until data is available. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#getInputStream%28%29 On my system using RXTX read() is returning -1 when no data is available even though I have disabled both thresholds. The reason my program was running fine for a while without this problem showing up is that I was using the DATA_AVAILABLE event to be notified when data is available and only calling read() to read an entire frame whenever the DATA_AVAILABLE event occurred, until eventually my device (I'm guessing) probably took longer than normal to send the entire data frame and therefore I called read when no data was available and it returned -1. The following Java program demonstrates my problem, it returns -1 as soon as no data is available, even though I think it should block until data is available. import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; public class Main implements SerialPortEventListener { public static void main(String[] args) throws Exception { new Main().run(); } private void run() throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier("COM4"); SerialPort port = (SerialPort) portIdentifier.open(Main.class.getName(), 2000); port.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); port.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); port.disableReceiveThreshold(); port.disableReceiveTimeout(); BufferedInputStream in = new BufferedInputStream(port.getInputStream()); BufferedOutputStream out = new BufferedOutputStream(port.getOutputStream()); port.addEventListener(this); Thread.sleep(1000); out.write(new byte[] {0x02, 0x60}); out.flush(); while (true) { int x = in.read(); if (x == -1) { System.out.println("EOF"); Thread.sleep(1000000000); } String s = Integer.toHexString(x & 0xFF); if (s.length() == 1) s = "0" + s; System.out.print(s + " "); System.out.flush(); } } public void serialEvent(SerialPortEvent arg0) { System.out.println("Serial port event"); } } However, the follow C# program ran all day today without ever read ever returning -1, as I would expect. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.IO.Ports; using System.Threading; namespace RXTXReadTest1 { class Program { static void Main(string[] args) { new Program().run(); } private void run() { SerialPort port = new SerialPort("COM4", 19200, Parity.None, 8, StopBits.One); port.Open(); port.Write(new byte[] { 0x02, 0x60 }, 0, 2); while (true) { int x = port.ReadByte(); if (x == -1) { Console.WriteLine("EOF"); Thread.Sleep(1000000000); } String s = x.ToString("X"); if (s.Length == 1 ) s = "0" + s; Console.Out.Write(s + " "); Console.Out.Flush(); } } } } Now I am experimenting with what happens if I set the receive timeout to it's maximum value (apparently 1600ms) and only call read() when I am expecting data. Hopefully it will never be more than 1600ms late. This is still only a work around, not solving the problem. Am I doing something wrong in my code above or is RXTX retuning -1 when it should be blocking? Thanks, Ryan On Wed, Mar 2, 2011 at 3:34 AM, Kustaa Nyholm wrote: > On 3/2/11 07:53, "Ryan Boder" wrote: > Can you / have you made a simple test to ensure that rxtx is the issue? > > Can you write a simple C-program to see if this exhibits the same problem? > > I've never encountered this sort of problem with rxtx, it mostly just > works. > > But I'm on Mac so can't say about Windows (7) > > br Kusti > > > > > >Hi, > > > >I haven't seen any response to my question below. Is this not the right > >place to ask? If not, where would be a better place to ask? Any > >suggestions? > > > >Thanks, > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder > wrote: > > > >I mis-spoke, I don't have my own thread calling read, I am calling > >read in the event handler after receiving a > >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be > >accurate though. > > > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder > wrote: > > > >Hi, > > > >I have a receive thread that does nothing but call read() on the serial > >port input stream. It works fine for a while but after running for a long > >time it eventually returns -1 which means EOF. This is my first problem, > >as the device I'm talking to runs forever, I don't know why it would > >return -1. I am calling disableReceiveThreshold() and > >disableReceiveTimeout() at initialization which according to the > >documentation means read will return as soon as any data is available and > >it will block forever when data is not available, so -1 should never be > >returned from read, right? > > > >I have been unable to figure out why read returns -1 after a long while > >but I have found that if I kill my application and restart it everything > >works fine again. Therefore I tried to work around the problem by having > >my code close the port and reopen it when read returns -1. My second > >problem is that in this case when I call close() on the port it blocks > >forever. I did find this old bug > > > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > > > >which describes close() hanging on OSX, but it says that bug was fixed > >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone > >have any idea why read might be returning -1 in the first place? If I can > >avoid that I don't care about close() hanging because I would never close > >the port. If not, does anyone know why close() might block forever and > >how I can prevent this? I'm using RXTX version 2.1-7. > > > >Thanks, > >-- > >Ryan > > > > > > > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Wed Mar 2 18:46:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:46:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: <-1051064942000733580@unknownmsgid> References: <-1051064942000733580@unknownmsgid> Message-ID: It is USB and seems very reliable with the C# test program in my previous email. On Wed, Mar 2, 2011 at 6:58 PM, Bruce Griffith wrote: > How reliable is your serial port ? is it USB or Bluetooth? > > > > Bruce Griffith > > 303-532-4778 > > > > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On Behalf > Of *Ryan Boder > *Sent:* Tuesday, 01 March 2011 10:53 PM > *To:* rxtx at qbang.org > *Subject:* Re: [Rxtx] RXTX serial port read() returns -1 unexpectedly and > then blocks forever on close() > > > > Hi, > > I haven't seen any response to my question below. Is this not the right > place to ask? If not, where would be a better place to ask? Any suggestions? > > Thanks, > Ryan > > On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > > Hi, > > I have a receive thread that does nothing but call read() on the serial > port input stream. It works fine for a while but after running for a long > time it eventually returns -1 which means EOF. This is my first problem, as > the device I'm talking to runs forever, I don't know why it would return -1. > I am calling disableReceiveThreshold() and disableReceiveTimeout() at > initialization which according to the documentation means read will return > as soon as any data is available and it will block forever when data is not > available, so -1 should never be returned from read, right? > > I have been unable to figure out why read returns -1 after a long while but > I have found that if I kill my application and restart it everything works > fine again. Therefore I tried to work around the problem by having my code > close the port and reopen it when read returns -1. My second problem is that > in this case when I call close() on the port it blocks forever. I did find > this old bug > > http://bugzilla.qbang.org/show_bug.cgi?id=53 > > which describes close() hanging on OSX, but it says that bug was fixed with > a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have any > idea why read might be returning -1 in the first place? If I can avoid that > I don't care about close() hanging because I would never close the port. If > not, does anyone know why close() might block forever and how I can prevent > this? I'm using RXTX version 2.1-7. > > Thanks, > -- > Ryan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Mar 3 02:50:20 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 3 Mar 2011 09:50:20 +0000 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: So if -1 is unexpectedly returned from read, and we have demonstrated that your USB-serial adapter can actually causes this to happen in RXTX, why not just ignore the -1 value? What happens when you try this? As for a hang on close, are your closing your port from within your serial event handler? I know that this can cause some serious problems. Regards, Michael Erskine. From Kustaa.Nyholm at planmeca.com Thu Mar 3 03:39:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 12:39:34 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 03:44, "Ryan Boder" wrote: >While running the tests you requested I may have stumbled on the problem, >I just don't know how to fix it. According to the documentation, if both >the receive timeout and receive threshold are disabled then read() should >block forever until data is available. > >http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/re >ference/api/javax/comm/CommPort.html#getInputStream%28%29 > >On my system using RXTX read() is returning -1 when no data is available >even though I have disabled both thresholds. The reason my program was >running fine for a while without this problem showing up is that I was >using the DATA_AVAILABLE event to be notified when data is available and >only calling read() to read an entire frame whenever the DATA_AVAILABLE >event occurred, until eventually my device (I'm guessing) probably took >longer than normal to send the entire data frame and therefore I called >read when no data was available and it returned -1. As a workaround have you tried to perform another read() if it returns -1? The javadoc says (see getInputStream): "Note, however, that framing errors may cause the Timeout and Threshold values to complete prematurely without raising an exception." I read this as a hint that read might return even if no data is available. Because of the above and that read() can only return -1 or the byte received it would be somewhat logical to return -1 in case of framing error ? I'm not claiming that my interpretation of the specification, such as it is, is correct, just speculating that the behavior could be something like that. It might give you some more insight if you used the read(bytes[],int,int) method, because this can and will return 0 in case of timeout (and presumably might do so in case of framing error, maybe some other error condition too). That might allow you to handle or work around the problem in this case. You have not shown your complete code (no need) but your comments and the example makes me wonder if the code is otherwise as it should be, meaning are you assuming that when you get the DATA_AVAILABLE event all of your frame has arrived and that you can just blindly read it away from the input stream? That is not guaranteed of course. Also using read(), instead of read(bytes[],int,int), is not very efficient and might be masking other problems as mused above. BTE you can print a byte in hex with leading zeros more easily with: System.out.printf("%02X",x); br Kusti From ryan.boder at gmail.com Thu Mar 3 07:56:16 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:56:16 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 5:39 AM, Kustaa Nyholm wrote: > > As a workaround have you tried to perform another read() if it returns -1? > I tried that and it did work sometimes but not all the time. > > The javadoc says (see getInputStream): > > "Note, however, that framing errors may cause the Timeout and Threshold > values to complete prematurely without raising an exception." > > I read this as a hint that read might return even if no data is available. > > Because of the above and that read() can only return -1 or the byte > received > it would be somewhat logical to return -1 in case of framing error ? > > I'm not claiming that my interpretation of the specification, such as it > is, > is correct, just speculating that the behavior could be something like > that. > Receive framing is not enabled by default. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#enableReceiveFraming%28int%29 My choice of word might be misleading, when I said frame I just meant a contiguous message from the device. I am not enabling receive framing. Can you have a framing error when receive framing is disabled? > > It might give you some more insight if you used the read(bytes[],int,int) > method, because > this can and will return 0 in case of timeout (and presumably might do so > in case of framing > error, maybe some other error condition too). > > That might allow you to handle or work around the problem in this case. > > You have not shown your complete code (no need) but your comments and the > example > makes me wonder if the code is otherwise as it should be, meaning are you > assuming > that when you get the DATA_AVAILABLE event all of your frame has arrived > and that > you can just blindly read it away from the input stream? That is not > guaranteed of course. > I'm not assuming the entire message has arrived, I'm just assuming it either has arrived or will arrive soon which is why I'm using a (supposedly) blocking read(). > > Also using read(), instead of read(bytes[],int,int), is not very efficient > and > might be masking other problems as mused above. > True, I'm reading one byte at a time because I don't know how long the message will be until I read and parse some of it. I suppose I can use read(bytes[],int,int) once I figure out how long the message will be. > > BTE you can print a byte in hex with leading zeros more easily with: > > > System.out.printf("%02X",x); > I did it the dumb way in that test program so I could copy and paste the code from C# to Java without having to figure out how to do the same in C# which I'm not as familiar with. Thanks and BR, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 07:58:24 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:58:24 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: Yes I was doing the close in the serial event handler, I didn't realize that caused a problem. Thanks, I'll fix it. On Thu, Mar 3, 2011 at 4:50 AM, Michael Erskine wrote: > So if -1 is unexpectedly returned from read, and we have demonstrated > that your USB-serial adapter can actually causes this to happen in > RXTX, why not just ignore the -1 value? What happens when you try > this? As for a hang on close, are your closing your port from within > your serial event handler? I know that this can cause some serious > problems. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 11:48:20 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 13:48:20 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm wrote: > On 3/3/11 16:56, "Ryan Boder" wrote: > > > >I'm not assuming the entire message has arrived, I'm just assuming it > >either has arrived or will arrive soon which is why I'm using a > >(supposedly) blocking read(). > > > I've been giving this some further thought. > > It does not feel healthy to block without timeout, especially > from within a thread that is essentially internal to the rxtx. > > I've never done that, I always use a time out, read(byte[],int,int) > for the expected number of bytes, check how much I got and issue > more reads until I get everything. > > You have not described how your communication works so I'm only > speculating. > > If your device needs some response to send more bytes (from your > code it looks like this is not the case) then a missing byte > would block your read and prevent you from responding and > getting more data. But as said, looks like that is not the case. > > Anyway, if this was my problem, I would enable the timeout > and use read(byte[],int,int) and loop until I get what I need. > You are right, I should and will use a timeout. In fact, my program has been running flawlessly for 12 hours and the only change I made was to enable a timeout, no change in the logic at all. Without the timeout read() was returning -1 usually after it ran for an hour or two. I will change the code to make use of the timeout and handle it appropriately. It still seems to me that RXTX's behavior doesn't match the documentation when rx timeout and rx threshold are disabled read() should block until data is available instead of immediately returning -1. I don't believe that a framing error is occurring immediately every time data is not available causing read() to return -1. Especially since the C# test program above runs all day with no error and the Java program above runs all day with no error when a timeout is enabled. To me it seems like enabling the timeout is what is causing read() to block until data is available, even if only for 1600ms, and without the timeout read() is returning -1 immediately when it should be blocking. Thanks for all the help and best regards, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Thu Mar 3 13:02:30 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 22:02:30 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 20:48, "Ryan Boder" wrote: >On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm > wrote: > >On 3/3/11 16:56, "Ryan Boder" wrote: >> > >>I'm not assuming the entire message has arrived, I'm just assuming it >>either has arrived or will arrive soon which is why I'm using a >>(supposedly) blocking read(). > > > >I've been giving this some further thought. > >It does not feel healthy to block without timeout, especially >from within a thread that is essentially internal to the rxtx. > >I've never done that, I always use a time out, read(byte[],int,int) >for the expected number of bytes, check how much I got and issue >more reads until I get everything. > >You have not described how your communication works so I'm only >speculating. > >If your device needs some response to send more bytes (from your >code it looks like this is not the case) then a missing byte >would block your read and prevent you from responding and >getting more data. But as said, looks like that is not the case. > >Anyway, if this was my problem, I would enable the timeout >and use read(byte[],int,int) and loop until I get what I need. > > > > >You are right, I should and will use a timeout. In fact, my program has >been running flawlessly for 12 hours and the only change I made was to >enable a timeout, no change in the logic at all. Without the timeout >read() was returning -1 usually after it ran for an hour or two. I will >change the code to make use of the timeout and handle it appropriately. That's nice! > >It still seems to me that RXTX's behavior doesn't match the documentation >when rx timeout and rx threshold are disabled read() should block until >data is available instead of immediately returning -1. Yeah, it does look like bug. However this might be related to some Windows specific serial port issue. Years ago I had issues with JavaComm (not RxTx) where I did a blocking read and I had huge issues with my program consuming all resources. I curser the Sun and JavaComm and re-code my own SerialPort using JNI to access the Win32 API directly. And I run into the same problems as with the Sun's implementation! So I ditched my code, changed my code to use timeouts and problems disappeared. > I don't believe that a framing error is occurring immediately every time >data is not available causing read() to return -1. Especially since the >C# test program above runs all day with no error and the Java program >above runs all day with no error when a timeout is enabled. I think so too, all things considered I don't really believe in framing errors in this case. > To me it seems like enabling the timeout is what is causing read() to >block until data is available, even if only for 1600ms, and without the >timeout read() is returning -1 immediately when it should be blocking. Yeah, I had a peek at the innards of RxTx Windows serial port a week or so ago and also read MSDN documentation about serial ports and the way overlapped and non-overlapped (non blocking and blocking) IO is handled is a way different. So yeah, it can well be that there is an issue lurking there somewhere inside RxTx in Windows. > > >Thanks for all the help and best regards, >-- >Ryan Boder I'm happy if I was of any assistance. br Kusti From tjarvi at qbang.org Thu Mar 3 18:52:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Mar 2011 18:52:50 -0700 (MST) Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: >> Without the timeout >> read() was returning -1 usually after it ran for an hour or two. There is a big hammer in rxtx causing that behavior. >> It still seems to me that RXTX's behavior doesn't match the documentation >> when rx timeout and rx threshold are disabled read() should block until >> data is available instead of immediately returning -1. > > Yeah, it does look like bug. However this might be related to some > Windows specific serial port issue. Years ago I had issues with > JavaComm (not RxTx) where I did a blocking read and I had huge > issues with my program consuming all resources. I curser the Sun > and JavaComm and re-code my own SerialPort using JNI to access > the Win32 API directly. And I run into the same problems as > with the Sun's implementation! So I ditched my code, changed > my code to use timeouts and problems disappeared. > > >> To me it seems like enabling the timeout is what is causing read() to >> block until data is available, even if only for 1600ms, and without the >> timeout read() is returning -1 immediately when it should be blocking. > > Yeah, I had a peek at the innards of RxTx Windows serial port a week > or so ago and also read MSDN documentation about serial ports and > the way overlapped and non-overlapped (non blocking and blocking) > IO is handled is a way different. So yeah, it can well be that > there is an issue lurking there somewhere inside RxTx in Windows. > > Yes. RXTX was patched to behave the way it does. I don't fully understand the issue behind the patch. Marc noticed the odd behavior as well and offered a fix which was greeted with resistance. The windows implementation was done without real documentatino of the windows API. I think I had an example from the late 80's early 90's on Microsoft's site and some API documentation that was obviously not microsofts in Europe. Wayne Roberts had a real need for windows support and fixed some major issues it had. My interest at the time was mingw32. I then cleaned it up for some specific uses I had later. The read returning -1 when it should block didn't impact anybody and appeared to help some people. It isnt the documented behavior though. There could be all sorts of latent bugs in that code but in the real world, it gets by in almost all use cases. Its a hack but it worked for 100's of thousands of people over a 14 year period. Maybe its time to revisit the code but there is more risk than gain for most people. How do you move forward and avoid the risk? Some have expressed interests in coding C++ or other efforts. I'm all for such efforts but feel some unit tests that work with a null modem cables are the only thing that will move rxtx (and perhaps CommAPI) forward. If we have a test suite in place as a qualification for implementations, progress can be made in the right direction regardless of the implementation details. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Fri Mar 4 02:57:16 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 4 Mar 2011 11:57:16 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/4/11 03:52, "Trent Jarvi" wrote: >Yes. RXTX was patched to behave the way it does. I don't fully >understand the issue behind the patch. Marc noticed the odd behavior as >well and offered a fix which was greeted with resistance. > >The windows implementation was done without real documentatino of the >windows API. I think I had an example from the late 80's early 90's on >Microsoft's site and some API documentation that was obviously not >microsofts in Europe. Wayne Roberts had a real need for windows support >and fixed some major issues it had. My interest at the time was mingw32. >I then cleaned it up for some specific uses I had later. The read >returning -1 when it should block didn't impact anybody and appeared to >help some people. It isnt the documented behavior though. > >There could be all sorts of latent bugs in that code but in the real >world, it gets by in almost all use cases. I think so too, never had any problems with it. > Its a hack but it worked for 100's of thousands of people over a 14 year >period. Yeah! Thanks for everyone who has contributed over the years, job well done! >Maybe its time to >revisit the code but there is more risk than gain for most people. How >do >you move forward and avoid the risk? My view is that it is quite risky and rather pointless to move forward, other than fixing bugs that really affect people. At the moment the major issue IMO is just that it seems (not been following this too carefully, so maybe I'm wrong, so in case this FUD, my apologies) that 'official' binaries are not available. I think the rewrite, tempting as it is in some respects is not the way forward. Just gentle maintenance to iron out real issues and then get the binaries out. br Kusti From ryan.boder at gmail.com Fri Mar 4 07:24:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Fri, 4 Mar 2011 09:24:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 8:52 PM, Trent Jarvi wrote: > > The windows implementation was done without real documentatino of the > windows API. I think I had an example from the late 80's early 90's on > Microsoft's site and some API documentation that was obviously not > microsofts in Europe. Wayne Roberts had a real need for windows support and > fixed some major issues it had. My interest at the time was mingw32. I then > cleaned it up for some specific uses I had later. The read returning -1 > when it should block didn't impact anybody and appeared to help some people. > It isnt the documented behavior though. > > There could be all sorts of latent bugs in that code but in the real world, > it gets by in almost all use cases. Its a hack but it worked for 100's of > thousands of people over a 14 year period. Maybe its time to revisit the > code but there is more risk than gain for most people. How do you move > forward and avoid the risk? > The safest and easiest solution would be to add a javadoc comment to disableReceiveTimeout explaining the difference between the RXTX behavior and Sunacle's documented behavior so that when someone uses the method in an IDE like Eclipse a little box would pop up informing them. Generating javadoc HTML and hosting it on the RXTX website would go a long way too, when something behaves differently than I expect the first thing I do is look for the javadoc online. -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From kharrington at neuronrobotics.com Mon Mar 7 10:47:26 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 12:47:26 -0500 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! Message-ID: Hey all, this is just a heads up that i have made a fork of rxtxSerial. Some of the features we have added: * Self deployment of native libraries ( all native code is stored inside the jar and deployed at runtime). No more manual install of native code. * Arm Cortex support (Gumstix) * Android Support (requires a rooted phone for now) * Google Code (SVN) repository for easy code and jar access * Single makefile compile (simplifies the compilation of project binaries) * Ant build script for jar creation * Removal of partialy implemented code to streamline the lib for just serial port access * Full Eclipse integration, for testing application code against sources. And a bunch of bug fixes: * Fixed the memory access error that causes OSX to crash the JVM when serial.close() is cvalled * Fixed the windows serial port zombie bind that prevents re-accessing serial ports when exiting on an exception * Fixed erronious printouts of native library mis-match To check it out, take a look at our page here: http://code.google.com/p/nrjavaserial/ From Kustaa.Nyholm at planmeca.com Mon Mar 7 11:46:26 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Mar 2011 20:46:26 +0200 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: Message-ID: On 3/7/11 19:47, "Kevin Harrington NR" wrote: >Hey all, this is just a heads up that i have made a fork of >rxtxSerial. Some of the features we have added great! If also does what it says on the tin: brilliant! Congrats and thanks. br Kusti From jmsachs at gmail.com Mon Mar 7 12:50:33 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 14:50:33 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: > From: Kevin Harrington NR > To: rxtx at qbang.org > Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > Hey all, this is just a heads up that i have made a fork of > rxtxSerial. Some of the features we have added: > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with a ten-foot pole. From Kustaa.Nyholm at planmeca.com Mon Mar 7 13:10:43 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Mar 2011 22:10:43 +0200 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: Message-ID: On 3/7/11 21:50, "Jason Sachs" wrote: > >Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >a ten-foot pole. >_______________________________________________ Oh crap, makes it useless for me and many others. Also I see no provision in RxTx license to change it so how could anyone change it to GPLv3? br Kusti From showard314 at gmail.com Mon Mar 7 13:24:08 2011 From: showard314 at gmail.com (Scott Howard) Date: Mon, 7 Mar 2011 15:24:08 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 3:10 PM, Kustaa Nyholm wrote: > Also I see no provision in RxTx license to change > it so how could anyone change it to GPLv3? I think this is allowed: 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. From jmsachs at gmail.com Mon Mar 7 13:24:47 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 15:24:47 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 2:50 PM, Jason Sachs wrote: >> From: Kevin Harrington NR >> To: rxtx at qbang.org >> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> > > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with > a ten-foot pole. > Let me back up a second (perhaps to make up for my lack of diplomacy) and state that I think any progress w/ rxtx is good. If an rxtx fork were LGPL (or some other non-spreading open source license) and leading in a good direction, I'd gladly return the favor by posting any improvements or bugfixes I found to the community. --Jason From jmsachs at gmail.com Mon Mar 7 13:36:13 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 15:36:13 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: Kevin: could you clarify the license? http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java has the RXTX 2.1 license (LGPL v 2.1 + Linking Over Controlled Interface.) but http://code.google.com/p/nrjavaserial/ says GPLv3. --Jason From kharrington at neuronrobotics.com Mon Mar 7 14:00:02 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 16:00:02 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: The one downside to google code is that it does not allow custom licensing. You have to pick from a drop-down list. Treat the licences on the files themselves as the licence to be concerned with, and ignore the "project licence". Sorry for the confusion. On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: > Kevin: could you clarify the license? > > http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java > has the RXTX 2.1 license > (LGPL v 2.1 + Linking Over Controlled Interface.) > > but http://code.google.com/p/nrjavaserial/ says GPLv3. > > --Jason > From iqzw2r602 at sneakemail.com Mon Mar 7 14:08:18 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 8 Mar 2011 08:08:18 +1100 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: References: Message-ID: <11253-1299532098-811882@sneakemail.com> Nice! Out of curiosity, did you use the patch that I sent Trent about two years ago to do the native library loading, or did you implement your own solution? Cheers, Uwe On Tue, Mar 8, 2011 at 5:46 AM, Kustaa Nyholm Kustaa.Nyholm-at-planmeca.com| rxtx.org mailing list/Example Allow| wrote: > On 3/7/11 19:47, "Kevin Harrington NR" > wrote: > > >Hey all, this is just a heads up that i have made a fork of > >rxtxSerial. Some of the features we have added > > > > great! If also does what it says on the tin: brilliant! > > Congrats and thanks. > > br Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aawolfe at gmail.com Mon Mar 7 15:31:47 2011 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 7 Mar 2011 17:31:47 -0500 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR wrote: > Hey all, this is just a heads up that i have made a fork of > rxtxSerial. Some of the features we have added: > > * Self deployment of native libraries ( all native code is stored > inside the jar and deployed at runtime). No more manual install of > native code. > * Arm Cortex support (Gumstix) > * Android Support (requires a rooted phone for now) > * Google Code (SVN) repository for easy code and jar access > * Single makefile compile (simplifies the compilation of project binaries) > * Ant build script for jar creation > * Removal of partialy implemented code to streamline the lib for just > serial port access > * Full Eclipse integration, for testing application code against sources. > > And a bunch of bug fixes: > > * Fixed the memory access error that causes OSX to crash the JVM when > serial.close() is cvalled > * Fixed the windows serial port zombie bind that prevents re-accessing > serial ports when exiting on an exception > * Fixed erronious printouts of native library mis-match > > To check it out, take a look at our page here: > > http://code.google.com/p/nrjavaserial/ This is interesting, getting the native libs set up has been an issue for some of my users. Will have to check it out. Out of curiosity, what Android devices provide a serial port? Or are there some that allow USB host mode and then a usb-serial adapter? I have only an Android cell phone, don't think it can do anything serial but would love to be wrong about that. From jfh at greenhousepc.com Mon Mar 7 15:54:39 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 15:54:39 -0700 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! Message-ID: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Mon Mar 7 16:53:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Mar 2011 16:53:50 -0700 (MST) Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: Hi Kevin, Until Google fixes the options as developers have requested, I'd suggest the least misleading dropdown option is "Other Open Source" with a clarification about LGPL 2.1 on the project page. If you are not supporting the CommAPI SPI interface that was available prior to the current JSR so that applications work in the javax.comm namespace, there is no need for the linking over controlled interfaces exception. RXTX 2.0 is used in that fashion but RXTX 2.1 is not. The exception explicitly states it can be removed if the source has been modified. The license is then explicitly OSI reviewed and approved as Google requests but is not in their drop down box as it should be and is for the GPL v2. http://opensource.org/licenses/alphabetical http://opensource.org/licenses/lgpl-2.1 The drawback would be that the library effectively could never be used in that SPI/controlled interface fashion again. On Mon, 7 Mar 2011, Kevin Harrington NR wrote: > The one downside to google code is that it does not allow custom > licensing. You have to pick from a drop-down list. Treat the licences > on the files themselves as the licence to be concerned with, and > ignore the "project licence". Sorry for the confusion. > > On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >> Kevin: could you clarify the license? >> >> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >> has the RXTX 2.1 license >> (LGPL v 2.1 + Linking Over Controlled Interface.) >> >> but http://code.google.com/p/nrjavaserial/ says GPLv3. >> >> --Jason >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From hakcenter at gmail.com Mon Mar 7 18:55:57 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 17:55:57 -0800 Subject: [Rxtx] Latency Woes Message-ID: <4D758CAD.2010602@gmail.com> I have finally deduced my slow data logging to a latency issue. I write software for dsms, and the protocol is request / receive, you cannot do more than 1 sensor at a time. So when you log multiple sensors, +20ms per item, sampling rate drops like a rock. I was wondering if there is any ideas besides going completely native with my application to reduce latency. With or without events I don't care at this point I need to kill as much of the latency as possible. Realistically I need no more than 1ms. From adrian.crum at sandglass-software.com Mon Mar 7 19:08:21 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Mon, 07 Mar 2011 18:08:21 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D758CAD.2010602@gmail.com> References: <4D758CAD.2010602@gmail.com> Message-ID: <4D758F95.90800@sandglass-software.com> Drop the requests into a queue, and then have a separate thread service the queue. -Adrian On 3/7/2011 5:55 PM, Curtis Hacker wrote: > I have finally deduced my slow data logging to a latency issue. > > I write software for dsms, and the protocol is request / receive, you > cannot do more than 1 sensor at a time. So when you log multiple > sensors, +20ms per item, sampling rate drops like a rock. > > I was wondering if there is any ideas besides going completely native > with my application to reduce latency. With or without events I don't > care at this point I need to kill as much of the latency as possible. > Realistically I need no more than 1ms. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From hakcenter at gmail.com Mon Mar 7 19:24:16 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 18:24:16 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D758F95.90800@sandglass-software.com> References: <4D758CAD.2010602@gmail.com> <4D758F95.90800@sandglass-software.com> Message-ID: <4D759350.8060402@gmail.com> Sample code ? I don't necessarily want to read the byte I just wrote, but wait till the que depth is 2. Setup a thread without a sleep timer: if (in.available() > 1) { do_stuff(); } ?? On 03/07/11 18:08, Adrian Crum wrote: > Drop the requests into a queue, and then have a separate thread > service the queue. > > -Adrian > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: >> I have finally deduced my slow data logging to a latency issue. >> >> I write software for dsms, and the protocol is request / receive, you >> cannot do more than 1 sensor at a time. So when you log multiple >> sensors, +20ms per item, sampling rate drops like a rock. >> >> I was wondering if there is any ideas besides going completely native >> with my application to reduce latency. With or without events I don't >> care at this point I need to kill as much of the latency as possible. >> Realistically I need no more than 1ms. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adrian.crum at sandglass-software.com Mon Mar 7 19:46:02 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Mon, 07 Mar 2011 18:46:02 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D759350.8060402@gmail.com> References: <4D758CAD.2010602@gmail.com> <4D758F95.90800@sandglass-software.com> <4D759350.8060402@gmail.com> Message-ID: <4D75986A.6020003@sandglass-software.com> http://download.oracle.com/javase/tutorial/essential/concurrency/executors.html -Adrian On 3/7/2011 6:24 PM, Curtis Hacker wrote: > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: >> Drop the requests into a queue, and then have a separate thread >> service the queue. >> >> -Adrian >> >> On 3/7/2011 5:55 PM, Curtis Hacker wrote: >>> I have finally deduced my slow data logging to a latency issue. >>> >>> I write software for dsms, and the protocol is request / receive, >>> you cannot do more than 1 sensor at a time. So when you log multiple >>> sensors, +20ms per item, sampling rate drops like a rock. >>> >>> I was wondering if there is any ideas besides going completely >>> native with my application to reduce latency. With or without events >>> I don't care at this point I need to kill as much of the latency as >>> possible. Realistically I need no more than 1ms. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Mon Mar 7 19:50:45 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 19:50:45 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Mon Mar 7 20:04:01 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 19:04:01 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> Message-ID: <4D759CA1.8010903@gmail.com> I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. in.read(data, 0, 2); ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? On 03/07/11 18:50, jfh at greenhousepc.com wrote: > Curtis, > > No, I assume he means a real queue, not just "don't read all the bytes > at once." However, if you know you can process some number of > requests in some amount of time, allowing data to pile up (receiver > FIFO space permitting) can be a valid strategy. Inserting gobs of > Thread.yield() and notify() can help pep things up as well. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Mon, March 07, 2011 8:24 pm > To: rxtx at qbang.org > > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: > > Drop the requests into a queue, and then have a separate thread > > service the queue. > > > > -Adrian > > > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: > >> I have finally deduced my slow data logging to a latency issue. > >> > >> I write software for dsms, and the protocol is request / > receive, you > >> cannot do more than 1 sensor at a time. So when you log multiple > >> sensors, +20ms per item, sampling rate drops like a rock. > >> > >> I was wondering if there is any ideas besides going completely > native > >> with my application to reduce latency. With or without events I > don't > >> care at this point I need to kill as much of the latency as > possible. > >> Realistically I need no more than 1ms. > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From bartley at cmu.edu Mon Mar 7 20:08:05 2011 From: bartley at cmu.edu (Chris Bartley) Date: Mon, 7 Mar 2011 22:08:05 -0500 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> Message-ID: <9B1804F9-DBD0-476D-9345-806D00065A97@cmu.edu> We use a queue for all our request/response serial communications, and have found it really easy to work with. Code is here: http://code.google.com/p/create-lab-commons/source/browse/trunk/java/code/serial/src/edu/cmu/ri/createlab/serial/SerialPortCommandExecutionQueue.java It's assuming a command & response scheme that's specific to the protocol we use to talk to our robots, but it should be easy to modify for your needs. Hope this helps. Let me know if you have questions. Chris On Mar 7, 2011, at 9:50 PM, wrote: > Curtis, > > No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > Date: Mon, March 07, 2011 8:24 pm > To: rxtx at qbang.org > > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: > > Drop the requests into a queue, and then have a separate thread > > service the queue. > > > > -Adrian > > > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: > >> I have finally deduced my slow data logging to a latency issue. > >> > >> I write software for dsms, and the protocol is request / receive, you > >> cannot do more than 1 sensor at a time. So when you log multiple > >> sensors, +20ms per item, sampling rate drops like a rock. > >> > >> I was wondering if there is any ideas besides going completely native > >> with my application to reduce latency. With or without events I don't > >> care at this point I need to kill as much of the latency as possible. > >> Realistically I need no more than 1ms. > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Mon Mar 7 20:51:17 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 20:51:17 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110307205116.8ef0e5b4a80cef441275a6330ffad77d.9b325137d1.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From kharrington at neuronrobotics.com Mon Mar 7 20:55:23 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 22:55:23 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 7 In-Reply-To: References: Message-ID: To answer a few of you, I have changed the license to "Other open source license" as suggested. My company is modifying and maintaining this fork to support our robotics development library (http://code.google.com/p/nr-sdk/ http://dev.neuronrobotics.com). We will be implementing the standard serial port interface only, as it is the only one we need or care about. As for where the implementation came from, i would have to refer to my other developer to answer that. I wrote the build scripts and make files, as well as streamlining the C build process. I have remover the configure script, as it ends up being more confusing then compiling 3 C files needs to be. if you guys want to bring any of this into the main line, that's cool, but up to you to port over. Our fork will be focusing on polishing up the serial interface,and hopefully making it faster. I hope some of you will find our improvements useful! On Mon, Mar 7, 2011 at 6:53 PM, wrote: > Send Rxtx mailing list submissions to > ? ? ? ?rxtx at qbang.org > > To subscribe or unsubscribe via the World Wide Web, visit > ? ? ? ?http://mailman.qbang.org/mailman/listinfo/rxtx > or, via email, send a message with subject or body 'help' to > ? ? ? ?rxtx-request at qbang.org > > You can reach the person managing the list at > ? ? ? ?rxtx-owner at qbang.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Rxtx digest..." > > > Today's Topics: > > ? 1. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 2. Re: Rxtx Digest, Vol 43, Issue 6 (Kustaa Nyholm) > ? 3. Re: Rxtx Digest, Vol 43, Issue 6 (Scott Howard) > ? 4. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 5. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 6. Re: Rxtx Digest, Vol 43, Issue 6 (Kevin Harrington NR) > ? 7. Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! > ? ? ?(iqzw2r602 at sneakemail.com) > ? 8. Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! > ? ? ?(Aaron Wolfe) > ? 9. Re: [SPAM] Re: ?NRJavaSerial, a fork of rxtx that fixes the > ? ? ?papercuts! (jfh at greenhousepc.com) > ?10. Re: Rxtx Digest, Vol 43, Issue 6 (Trent Jarvi) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 7 Mar 2011 14:50:33 -0500 > From: Jason Sachs > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > >> From: Kevin Harrington NR >> To: rxtx at qbang.org >> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> > > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with > a ten-foot pole. > > > ------------------------------ > > Message: 2 > Date: Mon, 7 Mar 2011 22:10:43 +0200 > From: Kustaa Nyholm > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > On 3/7/11 21:50, "Jason Sachs" wrote: >> >>Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >>a ten-foot pole. >>_______________________________________________ > > Oh crap, makes it useless for me and many others. > > Also I see no provision in RxTx license to change > it so how could anyone change it to GPLv3? > > br Kusti > > > > ------------------------------ > > Message: 3 > Date: Mon, 7 Mar 2011 15:24:08 -0500 > From: Scott Howard > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 3:10 PM, Kustaa Nyholm > wrote: >> Also I see no provision in RxTx license to change >> it so how could anyone change it to GPLv3? > > I think this is allowed: > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. ?To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. ?(If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) ?Do not make any other change in > these notices. > > ? Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > ? This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > > ------------------------------ > > Message: 4 > Date: Mon, 7 Mar 2011 15:24:47 -0500 > From: Jason Sachs > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 2:50 PM, Jason Sachs wrote: >>> From: Kevin Harrington NR >>> To: rxtx at qbang.org >>> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >>> Message-ID: >>> ? ? ? ? >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> Hey all, this is just a heads up that i have made a fork of >>> rxtxSerial. Some of the features we have added: >>> >> >> Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >> a ten-foot pole. >> > > Let me back up a second (perhaps to make up for my lack of diplomacy) > and state that I think any progress w/ rxtx is good. > > If an rxtx fork were LGPL (or some other non-spreading open source > license) and leading in a good direction, I'd gladly return the favor > by posting any improvements or bugfixes I found to the community. > > --Jason > > > ------------------------------ > > Message: 5 > Date: Mon, 7 Mar 2011 15:36:13 -0500 > From: Jason Sachs > To: rxtx at qbang.org, kharrington at neuronrobotics.com > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > Kevin: could you clarify the license? > > http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java > has the RXTX 2.1 license > (LGPL v 2.1 + Linking Over Controlled Interface.) > > but http://code.google.com/p/nrjavaserial/ says GPLv3. > > --Jason > > > ------------------------------ > > Message: 6 > Date: Mon, 7 Mar 2011 16:00:02 -0500 > From: Kevin Harrington NR > To: Jason Sachs > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > The one downside to google code is that it does not allow custom > licensing. You have to pick from a drop-down list. Treat the licences > on the files themselves as the licence to be concerned with, and > ignore the "project licence". Sorry for the confusion. > > On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >> Kevin: could you clarify the license? >> >> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >> has the RXTX 2.1 license >> (LGPL v 2.1 + Linking Over Controlled Interface.) >> >> but http://code.google.com/p/nrjavaserial/ says GPLv3. >> >> --Jason >> > > > ------------------------------ > > Message: 7 > Date: Tue, 8 Mar 2011 08:08:18 +1100 > From: iqzw2r602 at sneakemail.com > To: Rxtx at qbang.org > Subject: Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > ? ? ? ?papercuts! > Message-ID: <11253-1299532098-811882 at sneakemail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Nice! > > Out of curiosity, did you use the patch that I sent Trent about two years > ago to do the native library loading, or did you implement your own > solution? > > Cheers, > > Uwe > > On Tue, Mar 8, 2011 at 5:46 AM, Kustaa Nyholm Kustaa.Nyholm-at-planmeca.com| > rxtx.org mailing list/Example Allow| wrote: > >> On 3/7/11 19:47, "Kevin Harrington NR" >> wrote: >> >> >Hey all, this is just a heads up that i have made a fork of >> >rxtxSerial. Some of the features we have added >> >> >> >> great! If also does what it says on the tin: brilliant! >> >> Congrats and thanks. >> >> br Kusti >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 8 > Date: Mon, 7 Mar 2011 17:31:47 -0500 > From: Aaron Wolfe > To: rxtx at qbang.org > Subject: Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > ? ? ? ?papercuts! > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR > wrote: >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> >> * Self deployment of native libraries ( all native code is stored >> inside the jar and deployed at runtime). No more manual install of >> native code. >> * Arm Cortex support (Gumstix) >> * Android Support (requires a rooted phone for now) >> * Google Code (SVN) repository for easy code and jar access >> * Single makefile compile (simplifies the compilation of project binaries) >> * Ant build script for jar creation >> * Removal of partialy implemented code to streamline the lib for just >> serial port access >> * Full Eclipse integration, for testing application code against sources. >> >> And a bunch of bug fixes: >> >> * Fixed the memory access error that causes OSX to crash the JVM when >> serial.close() is cvalled >> * Fixed the windows serial port zombie bind that prevents re-accessing >> serial ports when exiting on an exception >> * Fixed erronious printouts of native library mis-match >> >> To check it out, take a look at our page here: >> >> http://code.google.com/p/nrjavaserial/ > > This is interesting, getting the native libs set up has been an issue > for some of my users. ?Will have to check it out. > > Out of curiosity, what Android devices provide a serial port? ?Or are > there some that allow USB host mode and then a usb-serial adapter? ?I > have only an Android cell phone, don't think it can do anything serial > but would love to be wrong about that. > > > ------------------------------ > > Message: 9 > Date: Mon, 07 Mar 2011 15:54:39 -0700 > From: > To: aaron at aaronwolfe.com, rxtx at qbang.org > Subject: Re: [Rxtx] [SPAM] Re: ?NRJavaSerial, a fork of rxtx that > ? ? ? ?fixes the papercuts! > Message-ID: > ? ? ? ?<20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe at email13.secureserver.net> > > Content-Type: text/plain; charset="us-ascii" > > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 10 > Date: Mon, 7 Mar 2011 16:53:50 -0700 (MST) > From: Trent Jarvi > To: rxtx at qbang.org > Cc: Jason Sachs > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > Hi Kevin, > > Until Google fixes the options as developers have requested, I'd suggest > the least misleading dropdown option is "Other Open Source" with a > clarification about LGPL 2.1 on the project page. > > If you are not supporting the CommAPI SPI interface that was available > prior to the current JSR so that applications work in the javax.comm > namespace, there is no need for the linking over controlled interfaces > exception. ?RXTX 2.0 is used in that fashion but RXTX 2.1 is not. ?The > exception explicitly states it can be removed if the source has been > modified. ?The license is then explicitly OSI reviewed and approved as > Google requests but is not in their drop down box as it should be and is > for the GPL v2. > > ? ? ? ?http://opensource.org/licenses/alphabetical > ? ? ? ?http://opensource.org/licenses/lgpl-2.1 > > The drawback would be that the library effectively could never be used in > that SPI/controlled interface fashion again. > > On Mon, 7 Mar 2011, Kevin Harrington NR wrote: > >> The one downside to google code is that it does not allow custom >> licensing. You have to pick from a drop-down list. Treat the licences >> on the files themselves as the licence to be concerned with, and >> ignore the "project licence". Sorry for the confusion. >> >> On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >>> Kevin: could you clarify the license? >>> >>> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >>> has the RXTX 2.1 license >>> (LGPL v 2.1 + Linking Over Controlled Interface.) >>> >>> but http://code.google.com/p/nrjavaserial/ says GPLv3. >>> >>> --Jason >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > ------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > End of Rxtx Digest, Vol 43, Issue 7 > *********************************** > From Kustaa.Nyholm at planmeca.com Mon Mar 7 21:43:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 8 Mar 2011 06:43:57 +0200 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307205116.8ef0e5b4a80cef441275a6330ffad77d.9b325137d1.wbe@email13.secureserver.net> Message-ID: On 3/8/11 05:51, "jfh at greenhousepc.com" wrote: >Curtis, > > >None of that is relevant, as long as the UART is reasonable and the code >implements a proper half duplex protocol. > >If I understand correctly, you send a byte, the sensor sends back two >bytes. So long as you don't send the next byte until the two bytes are >in the UART receiver FIFO, you're fine. You don't have to actually >=read= them, just know they are available. To the OP, are you using a serial USB port, like FTDI? This has a built in latency of 10ms ie nothing is actually sent out of the device if you send less than 64 bytes until 10 msec timeout. This has nothing to do with RxTx. If you search the list archives you'll find more about this issue and IIRC someone reported that there is some diver parameter you can tweak to get rid of that latency. I'm sure the FTDI people had a good reason for this but it really brings down the communication speed if your protocol uses short messages and need to wait for a response. Sorry if this has already been mentioned or if this is not relevant, I've not been paying attention to this thread. br Kusti From bob_jacobsen at lbl.gov Tue Mar 8 00:02:28 2011 From: bob_jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 8 Mar 2011 00:02:28 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D759CA1.8010903@gmail.com> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> Message-ID: If you're transferring three bytes total at 1953 baud, it's going to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to wait 20msec to get the data back instead of 15.4 msec doesn't seem to be as big a problem as you're making it sound. Bob On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. > > To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. > > So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. > > in.read(data, 0, 2); > ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? > > On 03/07/11 18:50, jfh at greenhousepc.com wrote: >> Curtis, >> >> No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker >> Date: Mon, March 07, 2011 8:24 pm >> To: rxtx at qbang.org >> >> Sample code ? >> >> I don't necessarily want to read the byte I just wrote, but wait till >> the que depth is 2. >> >> Setup a thread without a sleep timer: >> if (in.available() > 1) { >> do_stuff(); >> } >> >> ?? >> >> On 03/07/11 18:08, Adrian Crum wrote: >> > Drop the requests into a queue, and then have a separate thread >> > service the queue. >> > >> > -Adrian >> > >> > On 3/7/2011 5:55 PM, Curtis Hacker wrote: >> >> I have finally deduced my slow data logging to a latency issue. >> >> >> >> I write software for dsms, and the protocol is request / receive, you >> >> cannot do more than 1 sensor at a time. So when you log multiple >> >> sensors, +20ms per item, sampling rate drops like a rock. >> >> >> >> I was wondering if there is any ideas besides going completely native >> >> with my application to reduce latency. With or without events I don't >> >> care at this point I need to kill as much of the latency as possible. >> >> Realistically I need no more than 1ms. >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From hakcenter at gmail.com Tue Mar 8 01:33:24 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 00:33:24 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> Message-ID: <4D75E9D4.5090307@gmail.com> I am going to try a couple things today and hopefully figure something out. Bob I don't want to pop your bubble, but a native application named 'TunerPro' can sample the same data, over 30 sensors, in less than 25ms. I've exchanged some emails with the author and it is a native C, polling, no events just timeouts. Kusta thanks for the FTDI notice, I believe that is tunable, however I have a particular user using a Keyspan converter and verified sampling rate with 'TunerPro' and its just off the charts. Chris thank you, I'll look into the queing. On 03/07/11 23:02, Bob Jacobsen wrote: > If you're transferring three bytes total at 1953 baud, it's going to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to wait 20msec to get the data back instead of 15.4 msec doesn't seem to be as big a problem as you're making it sound. > > Bob > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > >> I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. >> >> To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. >> >> So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. >> >> in.read(data, 0, 2); >> ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? >> >> On 03/07/11 18:50, jfh at greenhousepc.com wrote: >>> Curtis, >>> >>> No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. >>> -- >>> Julie Haugh >>> Senior Design Engineer >>> greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype From msemtd at googlemail.com Tue Mar 8 01:50:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 8 Mar 2011 08:50:15 +0000 Subject: [Rxtx] Latency Woes In-Reply-To: <4D75E9D4.5090307@gmail.com> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> <4D75E9D4.5090307@gmail.com> Message-ID: On 8 March 2011 08:33, Curtis Hacker wrote: > I am going to try a couple things today and hopefully figure something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than 25ms. > I've exchanged some emails with the author and it is a native C, polling, no > events just timeouts. Perhaps the author of TunerPro will let you use his native code - sounds just what you need. Regards, Michael Erskine. From jfh at greenhousepc.com Tue Mar 8 04:00:18 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 04:00:18 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 12:33:35 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 11:33:35 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> Message-ID: <4D76848F.5080809@gmail.com> Cable schematic: http://i1106.photobucket.com/albums/h377/vigilart/jackal%20logging%20set%20up/RS232SCHEMATIC.jpg 0.00268554 TunerPro.exe IOCTL_SERIAL_SET_BAUD_RATE VCP0 SUCCESS Rate: 1952 0.00305178 TunerPro.exe IOCTL_SERIAL_SET_RTS VCP0 SUCCESS 0.00297524 TunerPro.exe IOCTL_SERIAL_SET_DTR VCP0 SUCCESS 0.00297384 TunerPro.exe IOCTL_SERIAL_SET_LINE_CONTROL VCP0 SUCCESS StopBits: 1 Parity: NONE WordLength: 8 0.00000335 TunerPro.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 0.00202540 TunerPro.exe IOCTL_SERIAL_SET_HANDFLOW VCP0 SUCCESS Shake:1 Replace:40 XonLimit:2048 XoffLimit:512 0.00000335 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:300 RM:0 RC:2000 WM:0 WC:110 0.00000279 TunerPro.exe IOCTL_SERIAL_SET_QUEUE_SIZE VCP0 SUCCESS InSize: 1024 OutSize: 512 0.00000307 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000279 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:300 RM:0 RC:2000 WM:0 WC:110 0.00000307 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:75 RM:0 RC:400 WM:0 WC:300 0.00000559 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: RXCLEAR 0.00000335 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: TXCLEAR 0.00064980 TunerPro.exe IRP_MJ_WRITE VCP0 SUCCESS Length 1: . 0.01498738 TunerPro.exe IRP_MJ_READ VCP0 SUCCESS Length 1: . 0.00000363 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:200 RM:0 RC:20 WM:0 WC:300 0.02042774 TunerPro.exe IRP_MJ_READ VCP0 TIMEOUT Length 0: That is time on the left side. Now I'm with you on timing, it doesn't make a lot of sense, but that is how the logs come out. You can view the logs yourself. Tunerpro log : http://www.ds-map.net/tunerpro_log.csv My apps log : http://www.ds-map.net/my_log.csv 2nd app log : http://www.ds-map.net/my_log2.csv All these logs, were done from the same car, same cable. I have some older logs with some palm software, that was 13 sensors, and had a total 45-55ms between each set of 13. More info about the car / ecu at http://mmcdlogger.sourceforge.net Disassembly on the ecu: [SS1:SS0] is baud rate divider, 00(16) 01(128) 10(1024) 11(4096), assuming basic clock of 2MHZ, we get 125000baud, 15625baud, 1953baud, 488baud In any event, I attempted a no sleep thread, that waited till in.available > 1, and it wasn't any faster than running the events. Then I tried a read write thread, that slept from 1ms to 30ms after it wrote (so it wouldn't read what it just wrote). And couldn't get it doing much. I wish I had more of an understanding of all of this, which is why I'm asking for help. On 03/08/11 03:00, jfh at greenhousepc.com wrote: > Curtis, > > At the risk of being told "No, they really say it can be done", 30 > sensors is 30 * 3 character times (are you sure it's not a single byte > response?). At 1953 baud, a single character time is 10 bits * (1 / > 1953) seconds, or 15.4ms as Bob pointed out. 30 * 15.4ms is 460ms, > and that assumes everything works perfectly, no turnaround times, etc. > > If you can come up with some other way to make the math work, I'd love > to hear it. > > Short and sweet -- just because TunerPro can talk to an ECM/ECU that > is running faster than 1953 baud doesn't mean your Mitsubishi (or > whatever car you've got that runs at 1953 baud) runs at that faster > baud rate. > > Also, are you sure your data cable is correct? What cable are you > using? What's the schematic? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 2:33 am > To: rxtx at qbang.org > > I am going to try a couple things today and hopefully figure > something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than > 25ms. > I've exchanged some emails with the author and it is a native C, > polling, no events just timeouts. > > Kusta thanks for the FTDI notice, I believe that is tunable, > however I > have a particular user using a Keyspan converter and verified > sampling > rate with 'TunerPro' and its just off the charts. > > Chris thank you, I'll look into the queing. > > On 03/07/11 23:02, Bob Jacobsen wrote: > > If you're transferring three bytes total at 1953 baud, it's going > to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to > wait 20msec to get the data back instead of 15.4 msec doesn't seem > to be as big a problem as you're making it sound. > > > > Bob > > > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > > > >> I guess I'm gunna need some serious help with this then, because > of the scenario I'm stuck with. > >> > >> To communicate there is only 1 data line, rx/tx tied together > with a diode protecting the tx. No RTS/CTS handshaking nothing.. > >> > >> So the ecu can't process the next byte of info, without you > pulling the 2 bytes back. I wish this was standard, but even the > baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard > spot with this.. > >> > >> in.read(data , 0, 2); > >> ^ would the above wait till the timeout to read 2 bytes ? or > read 1 byte wait for the 2nd ? or just read the 1 ?? > >> > >> On 03/07/11 18:50, jfh at greenhousepc.com > wrote: > >>> Curtis, > >>> > >>> No, I assume he means a real queue, not just "don't read all > the bytes at once." However, if you know you can process some > number of requests in some amount of time, allowing data to pile > up (receiver FIFO space permitting) can be a valid strategy. > Inserting gobs of Thread.yield() and notify() can help pep things > up as well. > >>> -- > >>> Julie Haugh > >>> Senior Design Engineer > >>> greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 13:12:03 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 12:12:03 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> Message-ID: <4D768D93.1030504@gmail.com> So I looked over the Tunerpro log again today.. is it me or does it appear to be reusing values ? On 03/08/11 03:00, jfh at greenhousepc.com wrote: > Curtis, > > At the risk of being told "No, they really say it can be done", 30 > sensors is 30 * 3 character times (are you sure it's not a single byte > response?). At 1953 baud, a single character time is 10 bits * (1 / > 1953) seconds, or 15.4ms as Bob pointed out. 30 * 15.4ms is 460ms, > and that assumes everything works perfectly, no turnaround times, etc. > > If you can come up with some other way to make the math work, I'd love > to hear it. > > Short and sweet -- just because TunerPro can talk to an ECM/ECU that > is running faster than 1953 baud doesn't mean your Mitsubishi (or > whatever car you've got that runs at 1953 baud) runs at that faster > baud rate. > > Also, are you sure your data cable is correct? What cable are you > using? What's the schematic? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 2:33 am > To: rxtx at qbang.org > > I am going to try a couple things today and hopefully figure > something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than > 25ms. > I've exchanged some emails with the author and it is a native C, > polling, no events just timeouts. > > Kusta thanks for the FTDI notice, I believe that is tunable, > however I > have a particular user using a Keyspan converter and verified > sampling > rate with 'TunerPro' and its just off the charts. > > Chris thank you, I'll look into the queing. > > On 03/07/11 23:02, Bob Jacobsen wrote: > > If you're transferring three bytes total at 1953 baud, it's going > to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to > wait 20msec to get the data back instead of 15.4 msec doesn't seem > to be as big a problem as you're making it sound. > > > > Bob > > > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > > > >> I guess I'm gunna need some serious help with this then, because > of the scenario I'm stuck with. > >> > >> To communicate there is only 1 data line, rx/tx tied together > with a diode protecting the tx. No RTS/CTS handshaking nothing.. > >> > >> So the ecu can't process the next byte of info, without you > pulling the 2 bytes back. I wish this was standard, but even the > baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard > spot with this.. > >> > >> in.read(data , 0, 2); > >> ^ would the above wait till the timeout to read 2 bytes ? or > read 1 byte wait for the 2nd ? or just read the 1 ?? > >> > >> On 03/07/11 18:50, jfh at greenhousepc.com > wrote: > >>> Curtis, > >>> > >>> No, I assume he means a real queue, not just "don't read all > the bytes at once." However, if you know you can process some > number of requests in some amount of time, allowing data to pile > up (receiver FIFO space permitting) can be a valid strategy. > Inserting gobs of Thread.yield() and notify() can help pep things > up as well. > >>> -- > >>> Julie Haugh > >>> Senior Design Engineer > >>> greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 13:51:13 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 13:51:13 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308135113.8ef0e5b4a80cef441275a6330ffad77d.a5fff5bbc7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From bob_jacobsen at lbl.gov Tue Mar 8 14:14:57 2011 From: bob_jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 8 Mar 2011 14:14:57 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D76848F.5080809@gmail.com> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> Message-ID: <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > Tunerpro log : http://www.ds-map.net/tunerpro_log.csv It's only reading one sensor per line. Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT changed in lines 16 and 40; every 24 lines but at a different phase. GramsRev in lines 23 and 47; every 24 lines, at yet another phase. Looks like (69-1) readings in 1.30 seconds = 19msec per reading. Arithmetic still works! Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From hakcenter at gmail.com Tue Mar 8 14:27:12 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 13:27:12 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> Message-ID: <4D769F30.9050807@gmail.com> Thank you guys, cause I was really worried there. I guess another win for math today hahaha. So what is the imposed latency that rxtx has ? maybe 5-10ms ? On 03/08/11 13:14, Bob Jacobsen wrote: > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > It's only reading one sensor per line. > > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT changed in lines 16 and 40; every 24 lines but at a different phase. GramsRev in lines 23 and 47; every 24 lines, at yet another phase. > > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. Arithmetic still works! > > Bob > -- > Bob Jacobsen, LBNL > Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue Mar 8 14:07:24 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Mar 2011 14:07:24 -0700 (MST) Subject: [Rxtx] Latency Woes In-Reply-To: <4D769F30.9050807@gmail.com> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> <4D769F30.9050807@gmail.com> Message-ID: Hi Curtis While not your exact question, a simple test I performed can give you a ballpark idea. Writing a byte to a loopback at 9600 baud and displaying elapsed time on the data available event takes ~10 ms round trip in a large application. There are occasional 20 ms latencies. I used a typical linux desktop to try it just now without any special considerations. Windows NT was a little faster - maybe 8 ms - when I tried several years ago. On Tue, 8 Mar 2011, Curtis Hacker wrote: > Thank you guys, cause I was really worried there. I guess another win for > math today hahaha. So what is the imposed latency that rxtx has ? maybe > 5-10ms ? > > On 03/08/11 13:14, Bob Jacobsen wrote: >> On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >>> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> It's only reading one sensor per line. >> >> Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT >> changed in lines 16 and 40; every 24 lines but at a different phase. >> GramsRev in lines 23 and 47; every 24 lines, at yet another phase. >> >> Looks like (69-1) readings in 1.30 seconds = 19msec per reading. >> Arithmetic still works! >> >> Bob >> -- >> Bob Jacobsen, LBNL >> Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >> JacobsenRG >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Wei.Shen at Honeywell.com Tue Mar 8 15:15:32 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Tue, 8 Mar 2011 17:15:32 -0500 Subject: [Rxtx] [rxtx] disconnect event Message-ID: <83B3B1411349194D9D05821CEF48E78C02284B17@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 16:05:12 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 16:05:12 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 16:26:15 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 15:26:15 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> References: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> Message-ID: <4D76BB17.2090305@gmail.com> So if I could get the baud up 15625, theoretical maximum latency is 1.92ms ? Basically 500 samples/sec ? 125000, theoretical maximum latency is 0.24ms ? Basically 4167 samples/sec ? Keeping the protocol the same. On 03/08/11 15:05, jfh at greenhousepc.com wrote: > Curtis, > > It's nowhere near that bad. I'd measured it once before, and I > believe it's sub-millisecond. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 3:27 pm > To: rxtx at qbang.org > > Thank you guys, cause I was really worried there. I guess another win > for math today hahaha. So what is the imposed latency that rxtx has ? > maybe 5-10ms ? > > On 03/08/11 13:14, Bob Jacobsen wrote: > > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > > It's only reading one sensor per line. > > > > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 > lines. IAT changed in lines 16 and 40; every 24 lines but at a > different phase. GramsRev in lines 23 and 47; every 24 lines, at > yet another phase. > > > > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. > Arithmetic still works! > > > > Bob > > -- > > Bob Jacobsen, LBNL > > Bob_Jacobsen at lbl.gov > +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Tue Mar 8 17:40:36 2011 From: jredman at ergotech.com (Jim Redman) Date: Tue, 08 Mar 2011 17:40:36 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D76BB17.2090305@gmail.com> References: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> <4D76BB17.2090305@gmail.com> Message-ID: <4D76CC84.9040307@ergotech.com> How long does it take the device to generate a response? Increasing the baud rate may not help you much if the device takes a significant amount of time to process the request. On 03/08/2011 04:26 PM, Curtis Hacker wrote: > So if I could get the baud up > 15625, theoretical maximum latency is 1.92ms ? Basically 500 samples/sec ? > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 samples/sec ? > > Keeping the protocol the same. > > On 03/08/11 15:05, jfh at greenhousepc.com wrote: >> Curtis, >> >> It's nowhere near that bad. I'd measured it once before, and I >> believe it's sub-millisecond. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker > >> Date: Tue, March 08, 2011 3:27 pm >> To: rxtx at qbang.org >> >> Thank you guys, cause I was really worried there. I guess another win >> for math today hahaha. So what is the imposed latency that rxtx has ? >> maybe 5-10ms ? >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> > It's only reading one sensor per line. >> > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 >> lines. IAT changed in lines 16 and 40; every 24 lines but at a >> different phase. GramsRev in lines 23 and 47; every 24 lines, at >> yet another phase. >> > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. >> Arithmetic still works! >> > >> > Bob >> > -- >> > Bob Jacobsen, LBNL >> > Bob_Jacobsen at lbl.gov >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 jfh at greenhousepc.com Tue Mar 8 17:58:24 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 17:58:24 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 18:06:04 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 18:06:04 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 18:14:14 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 17:14:14 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> References: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> Message-ID: <4D76D466.7060303@gmail.com> I can edit the ECU eeprom to change the baud rate divisor to bump it up from 1953, to 15625 or 125000. But as Jim asked how fast the device can respond.. not very fast in its stock form. I can recode a lot of the eeprom for the ecu to alter the ecus baud rate, and put the response code into its own interrupt. I just wanted to make sure that in order to lower latency and increase sampling rate. I have to increase the baud rate of the ecu and the user right ? Or change the protocol.. to respond with more sensors per request. On 03/08/11 16:58, jfh at greenhousepc.com wrote: > Unless the ECU can auto-detect the baud rate, it won't even work. > > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Jim Redman > > Date: Tue, March 08, 2011 6:40 pm > To: rxtx at qbang.org > > How long does it take the device to generate a response? > > Increasing the baud rate may not help you much if the device takes a > significant amount of time to process the request. > > > On 03/08/2011 04:26 PM, Curtis Hacker wrote: > > So if I could get the baud up > > 15625, theoretical maximum latency is 1.92ms ? Basically 500 > samples/sec ? > > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 > samples/sec ? > > > > Keeping the protocol the same. > > > > On 03/08/11 15:05, jfh at greenhousepc.com > wrote: > >> Curtis, > >> > >> It's nowhere near that bad. I'd measured it once before, and I > >> believe it's sub-millisecond. > >> -- > >> Julie Haugh > >> Senior Design Engineer > >> greenHouse Computers, LLC // jfh at greenhousepc.com > > >> ; // > greenHousePC on Skype > >> > >> > >> -------- Original Message -------- > >> Subject: Re: [Rxtx] Latency Woes > >> From: Curtis Hacker > > >> Date: Tue, March 08, 2011 3:27 pm > >> To: rxtx at qbang.org > >> > >> Thank you guys, cause I was really worried there. I guess > another win > >> for math today hahaha. So what is the imposed latency that rxtx > has ? > >> maybe 5-10ms ? > >> > >> On 03/08/11 13:14, Bob Jacobsen wrote: > >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > >> > It's only reading one sensor per line. > >> > > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 > >> lines. IAT changed in lines 16 and 40; every 24 lines but at a > >> different phase. GramsRev in lines 23 and 47; every 24 lines, at > >> yet another phase. > >> > > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. > >> Arithmetic still works! > >> > > >> > Bob > >> > -- > >> > Bob Jacobsen, LBNL > >> > Bob_Jacobsen at lbl.gov > > >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > >> > > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Tue Mar 8 18:19:14 2011 From: jredman at ergotech.com (Jim Redman) Date: Tue, 08 Mar 2011 18:19:14 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> References: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> Message-ID: <4D76D592.9000802@ergotech.com> I'm no expert on this, but isn't the underlying ODB-II CAN bus or something similar. They always seem to require a dongle that converts to something. I know you can get serial, bluetooth, USB, etc. converters. I've seen serial dongles that claim multiple baud rates, so I suspect that whatever's providing the conversion may significantly affect the performance. A big second on the required timing comment. I suspect some intelligent consideration of what values change quickly (RPM, Speed, maybe things like fuel pressure) and read values like fuel levels, coolant temps, etc. much less frequently. On 03/08/2011 06:06 PM, jfh at greenhousepc.com wrote: > Curtis, > > You can't just increase the baud rate and have the device adapt to that > rate. Embedded systems tend to have their communications parameters > either hard coded in a memory location or else they are using a hardware > timebase. You're welcome to try increasing the baud rate, but there is > no guarantee it will even work. > > Whoever designed the ECU probably selected the baud rate for a good > reason. My suggestion would be to look at how the sensor values are all > laid out and go from there. Also, look at what the sensor represent and > consider the physical properties of what is being measured. It's > extremely unlikely that, for example, the coolant temperature is going > to rise more than 1* per second. If that much. Some values might change > more often, but do they really matter on a sub-second measurement basis? > > Part of software =engineering= is understanding the problem. Anyone can > sling code in the hope it works. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 5:26 pm > To: rxtx at qbang.org > > So if I could get the baud up > 15625, theoretical maximum latency is 1.92ms ? Basically 500 > samples/sec ? > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 > samples/sec ? > > Keeping the protocol the same. > > On 03/08/11 15:05, jfh at greenhousepc.com wrote: >> Curtis, >> >> It's nowhere near that bad. I'd measured it once before, and I >> believe it's sub-millisecond. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker > > >> Date: Tue, March 08, 2011 3:27 pm >> To: rxtx at qbang.org >> >> Thank you guys, cause I was really worried there. I guess >> another win >> for math today hahaha. So what is the imposed latency that >> rxtx has ? >> maybe 5-10ms ? >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> > It's only reading one sensor per line. >> > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every >> 24 lines. IAT changed in lines 16 and 40; every 24 lines but >> at a different phase. GramsRev in lines 23 and 47; every 24 >> lines, at yet another phase. >> > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per >> reading. Arithmetic still works! >> > >> > Bob >> > -- >> > Bob Jacobsen, LBNL >> > Bob_Jacobsen at lbl.gov >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > ------------------------------------------------------------------------ > _______________________________________________ > Rxtx mailing list > Rxtx 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 jfh at greenhousepc.com Tue Mar 8 18:32:28 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 18:32:28 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 19:45:00 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 18:45:00 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> References: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> Message-ID: <4D76E9AC.8050909@gmail.com> Julie, I really am not looking at the practicality of it. I was just wondering if that is how it works. I don't know a whole lot about rs232, which is the main reason I've been on this mailing list for a couple years. I have full control over the ecu eeprom code, I can change its baud rate, I can re-write the logging interface, I could update the ADC's on the ecu in the interface so that when you request said sensor it updates the ADC then replies it. But I wanted to know if the underlying issue with a 2mhz/8mhz processor is the baud rate keeping sampling down ? On 03/08/11 17:32, jfh at greenhousepc.com wrote: > Curtis, > > You also have to look at the response time of the sensor itself. > > Seriously -- look at what the sensors are reporting and determine if > the underlying physical property can actually change that rapidly. > And even if it can, do you really need to know that. > > I built drag bikes in the 70's and I drive sports cars in my old age. > You don't really need millisecond sampling rates for every single last > sensor coming out of the engine. Boost pressure, fuel pressure, > manifold pressure and RPMs are probably high frequency sensors if you > want to tweak the motor for turbo lag or something, but other than > that, are you really going to be able to make sense of all that data? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 7:14 pm > To: rxtx at qbang.org > > I can edit the ECU eeprom to change the baud rate divisor to bump > it up from 1953, to 15625 or 125000. But as Jim asked how fast the > device can respond.. not very fast in its stock form. > > I can recode a lot of the eeprom for the ecu to alter the ecus > baud rate, and put the response code into its own interrupt. > > I just wanted to make sure that in order to lower latency and > increase sampling rate. I have to increase the baud rate of the > ecu and the user right ? Or change the protocol.. to respond with > more sensors per request. > > On 03/08/11 16:58, jfh at greenhousepc.com wrote: >> Unless the ECU can auto-detect the baud rate, it won't even work. >> >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Jim Redman > > >> Date: Tue, March 08, 2011 6:40 pm >> To: rxtx at qbang.org >> >> How long does it take the device to generate a response? >> >> Increasing the baud rate may not help you much if the device >> takes a >> significant amount of time to process the request. >> >> >> On 03/08/2011 04:26 PM, Curtis Hacker wrote: >> > So if I could get the baud up >> > 15625, theoretical maximum latency is 1.92ms ? Basically 500 >> samples/sec ? >> > 125000, theoretical maximum latency is 0.24ms ? Basically >> 4167 samples/sec ? >> > >> > Keeping the protocol the same. >> > >> > On 03/08/11 15:05, jfh at greenhousepc.com >> wrote: >> >> Curtis, >> >> >> >> It's nowhere near that bad. I'd measured it once before, and I >> >> believe it's sub-millisecond. >> >> -- >> >> Julie Haugh >> >> Senior Design Engineer >> >> greenHouse Computers, LLC // jfh at greenhousepc.com >> >> >> ; // >> greenHousePC on Skype >> >> >> >> >> >> -------- Original Message -------- >> >> Subject: Re: [Rxtx] Latency Woes >> >> From: Curtis Hacker > > >> >> Date: Tue, March 08, 2011 3:27 pm >> >> To: rxtx at qbang.org >> >> >> >> >> Thank you guys, cause I was really worried there. I guess >> another win >> >> for math today hahaha. So what is the imposed latency that >> rxtx has ? >> >> maybe 5-10ms ? >> >> >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> >> > It's only reading one sensor per line. >> >> > >> >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; >> every 24 >> >> lines. IAT changed in lines 16 and 40; every 24 lines but at a >> >> different phase. GramsRev in lines 23 and 47; every 24 >> lines, at >> >> yet another phase. >> >> > >> >> > Looks like (69-1) readings in 1.30 seconds = 19msec per >> reading. >> >> Arithmetic still works! >> >> > >> >> > Bob >> >> > -- >> >> > Bob Jacobsen, LBNL >> >> > Bob_Jacobsen at lbl.gov >> >> >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Rxtx mailing list >> >> > Rxtx at qbang.org >> >> >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > ------------------------------------------------------------------------ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 20:43:11 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 20:43:11 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308204311.8ef0e5b4a80cef441275a6330ffad77d.e9b135168c.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From andrea.antonello at gmail.com Wed Mar 9 06:50:07 2011 From: andrea.antonello at gmail.com (andrea antonello) Date: Wed, 9 Mar 2011 14:50:07 +0100 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> References: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> Message-ID: Has anyone tried the lib? I am not sure if it is appropriate to write to the list about this, if not, I apologize. I wanted to try your fork out for our application which is an eclipse rcp plugin based one. It has been easy to substitute the 6 plugins with your library (that is one of the things I like). But then when I run it, it tries to load it from: ---- Loading: /tmp/libNRJavaSerial_moovida_0/libNRJavaSerial.so Trying to load: NRJavaSerial Trying to load: libNRJavaSerial Trying to load: rxtxSerial ---- So it is extracting the native lib to a tmp folder. But that one is not in the library path, so it fails. Is there any docs to try the lib out? Thanks, Andrea On Mon, Mar 7, 2011 at 11:54 PM, wrote: > Aaron, > > It should be possible for an Android to do BlueTooth serial.? If I were > looking for a serial solution, that's how I'd go. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on > Skype > > -------- Original Message -------- > Subject: [SPAM] Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > papercuts! > From: Aaron Wolfe > Date: Mon, March 07, 2011 4:31 pm > To: rxtx at qbang.org > > On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR > wrote: >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> >> * Self deployment of native libraries ( all native code is stored >> inside the jar and deployed at runtime). No more manual install of >> native code. >> * Arm Cortex support (Gumstix) >> * Android Support (requires a rooted phone for now) >> * Google Code (SVN) repository for easy code and jar access >> * Single makefile compile (simplifies the compilation of project binaries) >> * Ant build script for jar creation >> * Removal of partialy implemented code to streamline the lib for just >> serial port access >> * Full Eclipse integration, for testing application code against sources. >> >> And a bunch of bug fixes: >> >> * Fixed the memory access error that causes OSX to crash the JVM when >> serial.close() is cvalled >> * Fixed the windows serial port zombie bind that prevents re-accessing >> serial ports when exiting on an exception >> * Fixed erronious printouts of native library mis-match >> >> To check it out, take a look at our page here: >> >> http://code.google.com/p/nrjavaserial/ > > This is interesting, getting the native libs set up has been an issue > for some of my users. Will have to check it out. > > Out of curiosity, what Android devices provide a serial port? Or are > there some that allow USB host mode and then a usb-serial adapter? I > have only an Android cell phone, don't think it can do anything serial > but would love to be wrong 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 Cougar at CasaDelGato.Com Wed Mar 9 10:02:24 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 09 Mar 2011 09:02:24 -0800 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> References: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> Message-ID: <4D77B2A0.8020004@CasaDelGato.Com> On 3/7/2011 2:54 PM, jfh at greenhousepc.com wrote: > Aaron, > > It should be possible for an Android to do BlueTooth serial. If I > were looking for a serial solution, that's how I'd go. Actually, I can't figure out WHY you would need RxTx on an Android device. The built in bluetooth support works just fine with a serial-bluetooth converter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Mar 1 00:54:17 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 09:54:17 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> Message-ID: Adrian, had a look at your code/rewrite and it looks rather clean/nice. I was looking at the code to gain insight (not related to the rewrite) into what is involved in serial port programming in Windows. Or rather, to refresh my memory and see how others have done, because I've been there done that. So my questions are just to satisfy my curiosity, not to criticize or suggest improvements. 1) It looks like a new thread (EventMonitor) is created for each Serial port, is that correct? Many people seem to try to avoid using many threads in this sort of situation, and like to use something like unix select(). I personally find using threads more natural and better impedance match to the problem being solved here. I guess 'many people' above refers to those implementing thousands of connections and who cannot live with the overhead and limited number of threads available. 2) The EventMonitor basically polls for events at 50 msec interval? 3) There is a comment in the source code near the sleep(50) : // Sufficient up to 19200 baud I'm sure you thought about this carefully, so again not criticizing, but seeking to understand how or why, because at 50 msec would seem to limit through in some cases. Like if you send one byte and need to wait for one to return, then this limits speed to 200 chars/sec? 4) I've done something similar to a few years back from Java using JNI to access Win32 API serial port, and I seem to recall that I had threading issues ie when I submitted a read (ReadFile) and there was no data coming in, the thread would not only block but also consume a lot of CPU cycles ie it was not sleeping properly inside the ReadFile call when the serial port blocked. Im a bit fuzzy about the details after five years, so my question is have you checked if there an issue here? 5) AFAIK the select() on Windows does not work serial ports but there is some other mechanism (events?) to implement the same functionality, did you consider that? Probably, so you decided against it, why? br Kusti From adrian.crum at sandglass-software.com Tue Mar 1 04:13:34 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:13:34 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: References: Message-ID: <4D6CD4DE.7040501@sandglass-software.com> The javax.comm API specification requires one event monitor thread per port. I don't like the idea of having a thread per port either, but one of the rewrite's design goals is strict conformance to the specification. The 50 mS polling interval is just a placeholder. The final design of that is yet to be decided. In Windows, you have two choices for I/O: overlapped and non-overlapped. In overlapped I/O a thread is blocked, waiting for something to happen. In non-overlapped I/O a thread does not block. I chose non-overlapped I/O to avoid thread blocking at the OS level - instead, the thread blocking is kept in Java. -Adrian On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > Adrian, > > had a look at your code/rewrite and it looks rather clean/nice. > > I was looking at the code to gain insight (not related to the > rewrite) into what is involved in serial port programming > in Windows. Or rather, to refresh my memory and see how others have > done, because I've been there done that. > > So my questions are just to satisfy my curiosity, not to criticize > or suggest improvements. > > 1) It looks like a new thread (EventMonitor) is created for > each Serial port, is that correct? > > Many people seem to try to avoid using many threads in this sort > of situation, and like to use something like unix select(). > I personally find using threads more natural and better impedance > match to the problem being solved here. I guess 'many people' above > > refers to those implementing thousands of connections and > who cannot live with the overhead and limited number of threads > available. > > 2) The EventMonitor basically polls for events at 50 msec interval? > > 3) There is a comment in the source code near the sleep(50) : > > // Sufficient up to 19200 baud > > > I'm sure you thought about this carefully, so again not > criticizing, but seeking to understand how or why, because > at 50 msec would seem to limit through in some cases. Like > if you send one byte and need to wait for one to return, > then this limits speed to 200 chars/sec? > > 4) I've done something similar to a few years back from > Java using JNI to access Win32 API serial port, and > I seem to recall that I had threading issues ie when > I submitted a read (ReadFile) and there was no data coming > in, the thread would not only block but also consume a > lot of CPU cycles ie it was not sleeping properly inside > the ReadFile call when the serial port blocked. > > Im a bit fuzzy about the details after five years, so my question is > have you checked if there an issue here? > > > 5) AFAIK the select() on Windows does not work serial ports > but there is some other mechanism (events?) to implement the > same functionality, did you consider that? Probably, so you > decided against it, why? > > > br Kusti > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Tue Mar 1 04:25:23 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:25:23 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C2E90.9010601@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > My question would be: Why would you do that? The rewrite does > most of the work for you - all you have to do is implement > two C++ virtual classes and two C++ functions. You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? I just took a short look, maybe it could be discussed further, but I don't think I like it much. BTW, the main interface defined there is called gnu.io.Dispatcher? I thought the package names should be used in a way to avoid clashes, e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name space authority :)). > In Windows that took me a few hours. where is the implementation? I found commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp with things like const bool SerialPortImpl::isDataAvailable() const { // Needs implementation return true; } and timeouts.ReadIntervalTimeout = MAXDWORD;* timeouts.ReadTotalTimeoutMultiplier = 0; timeouts.ReadTotalTimeoutConstant = 0; timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 0; if (!SetCommTimeouts(hComm, &timeouts)) throw IOException(); which seems to be oversimplified or some prototype only? I think (and I wrote about this already in the past years) that correct timeout handling is one of the challenges, so I think this should be prototyped first - for each system flavor - before cementation of the (JNI-) interfaces. Personally, I would vote to form it in a way allowing to be implemented on embedded devices, for example. Another big challenge is to prove a rewrite fully working (and probably compatible to the old implementation) on "all" the supported OSes. Not a big problem for linux and windows, just use some thousand lines test code, test drivers and serial loopbacks etc, but for the exotic platforms, probably a high number of, this probably won't be too easy... (there are more challenges, such as being comfortable and threadsafe [are read and write permitted at the same time?], detailed and helpful exceptions on user API level [not necessarily on JNI/JNA layer], how to have a configurable threadsafe logging/tracing [maybe also from native code to assist porting / testing on exotic OSes, such as OSes where the developers have no direct access too, which can be quite hard to usually leads to good log messages], just to name a few.). So even it might seem easy for one platform and I agree with Micheal that > > * yay! let's start a rewrite is unlikely to succeede soon... However, when considering this, before IMHO a powerful Java API has to be defined, because according to my experiences for implementing non-trivial protocols InputStream/OutputStream might not be comfortable/powerfull enough (eventually I consider both wrong) and have some InputStream derivation available as wrapper (so applications can use InputStream and whatever high-level-API they want). The JNI interface shall make such a powerful implementation possible, thus the interface of it is driving the JNI interface design and thus I think it had to be done first. All this surely requires much work: agreements on the APIs, safeness for the users, design, documentation, all the implementations and the testing. As long as such bug amount of work cannot be spent, for example if some employee would get half a year time paid for it or so :-), probably it is unlikely to progress on this. Otherwise, I'm afraid, patches, improvements, new design ideas and even rewrites wouldn't become complete and thus won't form a new rxtx version (3.0); thus either collect dust in some forgotten CVS branch or could generate a split... > I can't imagine other ports taking > much longer than that - especially since POSIX-based code can > be shared between ports. Things are more complex than they seem to be... I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select on serial ports isn't supported; maybe it is non-trivial to "map" (like mapping select() to WaitForMultipleObjects() which might have different semantics etc.) or maybe some different approach has to be used. A system may have POSIX like termios interfaces but not support timeouts or have any other interoperability bug... You never run out of things that can go wrong. And if something can go wrong, it will... :-) Or, as Michael wrote: > > I seriously don't believe anyone will come up with anything better anytime soon. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue Mar 1 04:39:37 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:39:37 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com><13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED6B@COSNPREXC3.usr.ingenico.loc> > 3. Write all of the native (or non-native) code to implement > the native interface. > > Is that correct? If yes, how is that easier than the simple > implementation the current rewrite design uses? To have it complete, reliable, traceable, maintainable and well tested, it is much more work, I'm afraid. A prototype can be done within a few days (maybe on one day), but getting it right (including a passed review) IMHO is a completely different story. In the end you may end up with an average of ten lines per day, when assuming four major native packs (common, win, mac, termios/select) with let's say just 5000 lines each (with logging messages and detailed exceptions this is not much) we would have to estimate a total effort of nine man-years (20000/10/220)... oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 04:40:18 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:40:18 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6CDB22.9070401@sandglass-software.com> Every journey begins with a single step. -Adrian On 3/1/2011 3:25 AM, Steffen DETTMER wrote: > * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> My question would be: Why would you do that? The rewrite does >> most of the work for you - all you have to do is implement >> two C++ virtual classes and two C++ functions. > You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? > I just took a short look, maybe it could be discussed further, > but I don't think I like it much. > BTW, the main interface defined there is called gnu.io.Dispatcher? > I thought the package names should be used in a way to avoid clashes, > e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name > space authority :)). > >> In Windows that took me a few hours. > where is the implementation? > I found > commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp > with things like > > const bool SerialPortImpl::isDataAvailable() const > { > // Needs implementation > return true; > } > > and > > timeouts.ReadIntervalTimeout = MAXDWORD;* > timeouts.ReadTotalTimeoutMultiplier = 0; > timeouts.ReadTotalTimeoutConstant = 0; > timeouts.WriteTotalTimeoutMultiplier = 0; > timeouts.WriteTotalTimeoutConstant = 0; > if (!SetCommTimeouts(hComm,&timeouts)) > throw IOException(); > > which seems to be oversimplified or some prototype only? > > I think (and I wrote about this already in the past years) that correct > timeout handling is one of the challenges, so I think this should be > prototyped first - for each system flavor - before cementation of the > (JNI-) interfaces. Personally, I would vote to form it in a way allowing > to be implemented on embedded devices, for example. > > Another big challenge is to prove a rewrite fully working (and probably > compatible to the old implementation) on "all" the supported OSes. Not a > big problem for linux and windows, just use some thousand lines test > code, test drivers and serial loopbacks etc, but for the exotic > platforms, probably a high number of, this probably won't be too easy... > (there are more challenges, such as being comfortable and threadsafe > [are read and write permitted at the same time?], detailed and helpful > exceptions on user API level [not necessarily on JNI/JNA layer], how to > have a configurable threadsafe logging/tracing [maybe also from native > code to assist porting / testing on exotic OSes, such as OSes where the > developers have no direct access too, which can be quite hard to usually > leads to good log messages], just to name a few.). > > So even it might seem easy for one platform and I agree with Micheal > that > >>> * yay! let's start a rewrite > is unlikely to succeede soon... > > However, when considering this, before IMHO a powerful Java API has to > be defined, because according to my experiences for implementing > non-trivial protocols InputStream/OutputStream might not be > comfortable/powerfull enough (eventually I consider both wrong) and have > some InputStream derivation available as wrapper (so applications can > use InputStream and whatever high-level-API they want). > The JNI interface shall make such a powerful implementation possible, > thus the interface of it is driving the JNI interface design and thus I > think it had to be done first. > > All this surely requires much work: agreements on the APIs, safeness for > the users, design, documentation, all the implementations and the > testing. As long as such bug amount of work cannot be spent, for example > if some employee would get half a year time paid for it or so :-), > probably it is unlikely to progress on this. > > Otherwise, I'm afraid, patches, improvements, new design ideas and even > rewrites wouldn't become complete and thus won't form a new rxtx version > (3.0); thus either collect dust in some forgotten CVS branch or could > generate a split... > >> I can't imagine other ports taking >> much longer than that - especially since POSIX-based code can >> be shared between ports. > Things are more complex than they seem to be... > > I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select > on serial ports isn't supported; maybe it is non-trivial to "map" (like > mapping select() to WaitForMultipleObjects() which might have different > semantics etc.) or maybe some different approach has to be used. A > system may have POSIX like termios interfaces but not support timeouts > or have any other interoperability bug... > You never run out of things that can go wrong. And if something can go > wrong, it will... :-) > > Or, as Michael wrote: > >>> I seriously don't believe anyone will come up with anything better > anytime soon. > > oki, > > Steffen > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Kustaa.Nyholm at planmeca.com Tue Mar 1 04:57:02 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 13:57:02 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: On 3/1/11 13:13, "Adrian Crum" wrote: >The javax.comm API specification requires one event monitor thread per >port. I don't like the idea of having a thread per port either, but one >of the rewrite's design goals is strict conformance to the specification. Ah, had not spotted that requirement. > >The 50 mS polling interval is just a placeholder. The final design of >that is yet to be decided. > >In Windows, you have two choices for I/O: overlapped and non-overlapped. >In overlapped I/O a thread is blocked, waiting for something to happen. >In non-overlapped I/O a thread does not block. I chose non-overlapped >I/O to avoid thread blocking at the OS level - instead, the thread >blocking is kept in Java. > >-Adrian thanks for the explanation. br Kusti From iqzw2r602 at sneakemail.com Tue Mar 1 05:08:17 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:08:17 +1100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <32684-1298981297-704398@sneakemail.com> This reminds me of a nasty problem I had with overlapped I/O on windows with jpathwatch. You can't start an I/O request in one thread and then do the check if that request completed in another thread. Very strange things happen when you attempt that; made me change the design of the Windows implementation quite drastically (one thread on a command queue that executes requests from other threads instead of letting them wildly call into GetOverlappedResult()). Out of curiosity: Did you come across that too? Or are all requests handled in the same thread they're issued? Cheers, Uwe On Tue, Mar 1, 2011 at 10:13 PM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > The javax.comm API specification requires one event monitor thread per > port. I don't like the idea of having a thread per port either, but one of > the rewrite's design goals is strict conformance to the specification. > > The 50 mS polling interval is just a placeholder. The final design of that > is yet to be decided. > > In Windows, you have two choices for I/O: overlapped and non-overlapped. In > overlapped I/O a thread is blocked, waiting for something to happen. In > non-overlapped I/O a thread does not block. I chose non-overlapped I/O to > avoid thread blocking at the OS level - instead, the thread blocking is kept > in Java. > > -Adrian > > > On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > >> Adrian, >> >> had a look at your code/rewrite and it looks rather clean/nice. >> >> I was looking at the code to gain insight (not related to the >> rewrite) into what is involved in serial port programming >> in Windows. Or rather, to refresh my memory and see how others have >> done, because I've been there done that. >> >> So my questions are just to satisfy my curiosity, not to criticize >> or suggest improvements. >> >> 1) It looks like a new thread (EventMonitor) is created for >> each Serial port, is that correct? >> >> Many people seem to try to avoid using many threads in this sort >> of situation, and like to use something like unix select(). >> I personally find using threads more natural and better impedance >> match to the problem being solved here. I guess 'many people' above >> >> refers to those implementing thousands of connections and >> who cannot live with the overhead and limited number of threads >> available. >> >> 2) The EventMonitor basically polls for events at 50 msec interval? >> >> 3) There is a comment in the source code near the sleep(50) : >> >> // Sufficient up to 19200 baud >> >> >> I'm sure you thought about this carefully, so again not >> criticizing, but seeking to understand how or why, because >> at 50 msec would seem to limit through in some cases. Like >> if you send one byte and need to wait for one to return, >> then this limits speed to 200 chars/sec? >> >> 4) I've done something similar to a few years back from >> Java using JNI to access Win32 API serial port, and >> I seem to recall that I had threading issues ie when >> I submitted a read (ReadFile) and there was no data coming >> in, the thread would not only block but also consume a >> lot of CPU cycles ie it was not sleeping properly inside >> the ReadFile call when the serial port blocked. >> >> Im a bit fuzzy about the details after five years, so my question is >> have you checked if there an issue here? >> >> >> 5) AFAIK the select() on Windows does not work serial ports >> but there is some other mechanism (events?) to implement the >> same functionality, did you consider that? Probably, so you >> decided against it, why? >> >> >> br Kusti >> >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 05:37:07 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:37:07 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <1142-1298983027-957144@sneakemail.com> On Tue, Mar 1, 2011 at 1:32 PM, Adrian Crum wrote: > Just to make sure I'm understanding you correctly, anyone porting RxTx to > a new platform would have to do the following: > > 1. Write their own Java implementation of an abstract Dispatcher class. > yep. I'd probably put all my calls to native OS wrappers in there two, looks the most straight-forward to me. > 2. Write a native (JNI or JNA) interface for the abstract class > implementation. > yes. For POSIX you'd probably only write one piece of code that provides implementations for open(), close(), and friends. You can compile that on all posix platforms (yeah, the devil is in the detail, but it's very little code, still). So this does open() (when using ***, but you can also use +++) // Unix.java class Unix{ public static native int open(String filename, int flags, int mode); .... } // Unix.cpp JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) { const char* pathname = env->GetStringUTFChars(jpathname, 0); if(pathname == 0) return -1; // java throws an out of memory error in this case int result = open(pathname, flags, mode); Unix_cacheErrno(); // handle interference between JVM and errno; env->ReleaseStringUTFChars(jpathname, pathname); return result; } .... 3. Write all of the native (or non-native) code to implement the native > interface. > Not sure what you mean by that. I've done the OS wrappers in step 2. step 1. implements that Dispatcher. What else do I need? > Is that correct? If yes, how is that easier than the simple implementation > the current rewrite design uses? > Yes, except for 3 (see above). How it is easier: I can debug the Java code directly. I can step from the read() call of an input stream directly into the guts of the RXTX implementation on my platform and see e.g. why it's hanging, because I see all the way up the call stack right where it calls Unix.read(). You can't easily do that with a fat native library, especially if you have no second set of devtools installed (the ones for native development). And I bet anyone knowing both languages can write it faster in Java, with less bugs. > On a side note: there is no requirement to write native code using C++. If > C++ is a real obstacle to adoption, then regular C could be used instead. In > that case, there would be a Dispatcher.c file that contains function > protoypes that need to be implemented. Dispatcher.c would still maintain the > same role as Dispatcher.cpp - which is to shield native code developers from > the details of JNI. Just build out the missing functions using C data types > and you're ready to go. > As I said, whatever works for you. Java works for me better than C++ in this case... Cheers, Uwe -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Mar 1 08:26:41 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 16:26:41 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> > The javax.comm API specification requires one event monitor > thread per port. Where does it require this? Do you mean "All the events received by this listener are generated by one dedicated thread that belongs to the SerialPort object. "? I think this is an implementation detail, isn't it? At least it is mentioned after "The current implementation only allows one listener per SerialPort". A bit bad that javadoc does not distinguish between API spec and implementation documentation. Also I don't think that TooManyListenersException MUST be thrown (I think it CAN be thrown). > I don't like the idea of having a thread per > port either, but one of the rewrite's design goals is strict > conformance to the specification. (but not necessarily on JNI layer) > The 50 mS polling interval is just a placeholder. The final > design of that is yet to be decided. I though no polling would be wanted; what could be the placeholder stand for? Do you mean a different interval duration or do you mean something completely different? > In Windows, you have two choices for I/O: overlapped and > non-overlapped. > In overlapped I/O a thread is blocked, waiting for something > to happen. > In non-overlapped I/O a thread does not block. I chose > non-overlapped I/O to avoid thread blocking at the OS level - > instead, the thread blocking is kept in Java. Isn't "overlapped" (asynchronous) I/O meaning that you invoke some ReadFile(..., &overlapped, ...) INSTEAD of performing a synchronous (blocking) function call blocking the thread? As far as I see, W32_Support.cpp uses CreateFile without FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O operations are serialized, even if the calls to the read and write functions specify an OVERLAPPED structure." [1] and "A synchronous handle behaves such that I/O function calls using that handle are blocked until they complete" [2] Given that CCOMTIMEOUTS get: "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the bytes that have already been received, even if no bytes have been received." [3] It looks likes this implementation relies on polling, which probably would waste much computing power. What did I miss? oki, Steffen [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro nous_and_asynchronous_i_o_handles [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 09:23:47 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:23:47 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6D1D93.6090306@sandglass-software.com> Unfortunately, the javax.comm API specification includes a lot of implementation details. That is one of the weaknesses of the specification in my opinion. The bottom line is, anyone wanting to use RxTx as a javax.comm implementation is going to expect it to do the things the specification says it does. -Adrian On 3/1/2011 7:26 AM, Steffen DETTMER wrote: >> The javax.comm API specification requires one event monitor >> thread per port. > Where does it require this? > > Do you mean "All the events received by this listener are generated > by one dedicated thread that belongs to the SerialPort object. "? > > I think this is an implementation detail, isn't it? At least it is > mentioned after "The current implementation only allows one listener per > SerialPort". A bit bad that javadoc does not distinguish between API > spec and implementation documentation. Also I don't think that > TooManyListenersException MUST be thrown (I think it CAN be thrown). > >> I don't like the idea of having a thread per >> port either, but one of the rewrite's design goals is strict >> conformance to the specification. > (but not necessarily on JNI layer) > >> The 50 mS polling interval is just a placeholder. The final >> design of that is yet to be decided. > I though no polling would be wanted; what could be the placeholder stand > for? Do you mean a different interval duration or do you mean something > completely different? > >> In Windows, you have two choices for I/O: overlapped and >> non-overlapped. >> In overlapped I/O a thread is blocked, waiting for something >> to happen. >> In non-overlapped I/O a thread does not block. I chose >> non-overlapped I/O to avoid thread blocking at the OS level - >> instead, the thread blocking is kept in Java. > Isn't "overlapped" (asynchronous) I/O meaning that you invoke some > ReadFile(...,&overlapped, ...) > INSTEAD of performing a synchronous (blocking) function call blocking > the thread? > > As far as I see, W32_Support.cpp uses CreateFile without > FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O > operations are serialized, even if the calls to the read and write > functions specify an OVERLAPPED structure." [1] and "A synchronous > handle behaves such that I/O function calls using that handle are > blocked until they complete" [2] > > Given that CCOMTIMEOUTS get: > "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values > for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier > members, specifies that the read operation is to return immediately with > the bytes that have already been received, even if no bytes have been > received." [3] > > It looks likes this implementation relies on polling, which probably > would waste much computing power. > > What did I miss? > > oki, > > Steffen > > [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx > [2] > http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro > nous_and_asynchronous_i_o_handles > [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at sandglass-software.com Tue Mar 1 09:55:29 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:55:29 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <1142-1298983027-957144@sneakemail.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> Message-ID: <4D6D2501.1020803@sandglass-software.com> That code duplicates what is in Dispatcher.cpp. A Unix port would only need to implement CommPortFactory::getInstance(portName, portType). -Adrian On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 15:07:46 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 2 Mar 2011 09:07:46 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6D2501.1020803@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> <4D6D2501.1020803@sandglass-software.com> Message-ID: <23749-1299017266-991798@sneakemail.com> What is this duplicating? A Unix port will need to call open() anyways (just so we're talking about the same thing here: open() is the Unix equivalent of CreateFile()) On Wed, Mar 2, 2011 at 3:55 AM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > That code duplicates what is in Dispatcher.cpp. A Unix port would only > need to implement CommPortFactory::getInstance(portName, portType). > > -Adrian > > > On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Tue Mar 1 22:53:07 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 00:53:07 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: Hi, I haven't seen any response to my question below. Is this not the right place to ask? If not, where would be a better place to ask? Any suggestions? Thanks, Ryan On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >> Hi, >> >> I have a receive thread that does nothing but call read() on the serial >> port input stream. It works fine for a while but after running for a long >> time it eventually returns -1 which means EOF. This is my first problem, as >> the device I'm talking to runs forever, I don't know why it would return -1. >> I am calling disableReceiveThreshold() and disableReceiveTimeout() at >> initialization which according to the documentation means read will return >> as soon as any data is available and it will block forever when data is not >> available, so -1 should never be returned from read, right? >> >> I have been unable to figure out why read returns -1 after a long while >> but I have found that if I kill my application and restart it everything >> works fine again. Therefore I tried to work around the problem by having my >> code close the port and reopen it when read returns -1. My second problem is >> that in this case when I call close() on the port it blocks forever. I did >> find this old bug >> >> http://bugzilla.qbang.org/show_bug.cgi?id=53 >> >> which describes close() hanging on OSX, but it says that bug was fixed >> with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have >> any idea why read might be returning -1 in the first place? If I can avoid >> that I don't care about close() hanging because I would never close the >> port. If not, does anyone know why close() might block forever and how I can >> prevent this? I'm using RXTX version 2.1-7. >> >> Thanks, >> -- >> Ryan >> >> > > > -- > Ryan Boder > 1 614 598-6339 > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Mar 2 01:34:48 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 2 Mar 2011 10:34:48 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/2/11 07:53, "Ryan Boder" wrote: Can you / have you made a simple test to ensure that rxtx is the issue? Can you write a simple C-program to see if this exhibits the same problem? I've never encountered this sort of problem with rxtx, it mostly just works. But I'm on Mac so can't say about Windows (7) br Kusti >Hi, > >I haven't seen any response to my question below. Is this not the right >place to ask? If not, where would be a better place to ask? Any >suggestions? > >Thanks, >Ryan > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > >I mis-spoke, I don't have my own thread calling read, I am calling >read in the event handler after receiving a >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be >accurate though. > >Ryan > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >Hi, > >I have a receive thread that does nothing but call read() on the serial >port input stream. It works fine for a while but after running for a long >time it eventually returns -1 which means EOF. This is my first problem, >as the device I'm talking to runs forever, I don't know why it would >return -1. I am calling disableReceiveThreshold() and >disableReceiveTimeout() at initialization which according to the >documentation means read will return as soon as any data is available and >it will block forever when data is not available, so -1 should never be >returned from read, right? > >I have been unable to figure out why read returns -1 after a long while >but I have found that if I kill my application and restart it everything >works fine again. Therefore I tried to work around the problem by having >my code close the port and reopen it when read returns -1. My second >problem is that in this case when I call close() on the port it blocks >forever. I did find this old bug > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > >which describes close() hanging on OSX, but it says that bug was fixed >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone >have any idea why read might be returning -1 in the first place? If I can >avoid that I don't care about close() hanging because I would never close >the port. If not, does anyone know why close() might block forever and >how I can prevent this? I'm using RXTX version 2.1-7. > >Thanks, >-- >Ryan > > > > > > > > > >-- >Ryan Boder >1 614 598-6339 > > > > > > >-- >Ryan Boder >1 614 598-6339 > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From Steffen.DETTMER at ingenico.com Wed Mar 2 03:08:57 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:08:57 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <32684-1298981297-704398@sneakemail.com> References: <4D6CD4DE.7040501@sandglass-software.com> <32684-1298981297-704398@sneakemail.com> Message-ID: <20110302100857.GB8030@elberon.bln.de.ingenico.com> * iqzw2r602 at sneakemail.com wrote on Tue, Mar 01, 2011 at 23:08 +1100: > This reminds me of a nasty problem I had with overlapped I/O on windows Yeah, those thousands of complex, difficult to use and exception-containing WinAPI is really hard to use... About strange effects on overlapped&multithreading, MSDN has: `the calling thread uses the GetOverlappedResult function or one of the wait functions' [1] also also mentiones I/O Completion Ports [2], and later continues: `If an application reuses OVERLAPPED structures on multiple threads and calls GetOverlappedResult with the bWait parameter set to TRUE, the application must ensure that the associated event is set before the application reuses the structure. This can be accomplished by using the WaitForSingleObject function after calling GetOverlappedResult to force the thread to wait until the operation completes. Note that the event object must be a manual-reset event object. If an autoreset event object is used, calling GetOverlappedResult with the bWait parameter set to TRUE causes the function to be blocked indefinitely.' also [1] oki, Steffen [1] http://msdn.microsoft.com/en-us/library/ms686358%28v=vs.85%29.aspx [2] http://msdn.microsoft.com/en-us/library/aa365198%28v=vs.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:15:11 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:15:11 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6D1D93.6090306@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> <4D6D1D93.6090306@sandglass-software.com> Message-ID: <20110302101511.GC8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 08:23 -0800: > Unfortunately, the javax.comm API specification includes a lot of > implementation details. That is one of the weaknesses of the > specification in my opinion. The bottom line is, anyone wanting to use > RxTx as a javax.comm implementation is going to expect it to do the > things the specification says it does. Yeah ok, but even then the implementation could check for the TooManyListenersException situations (if it really is required to support applications relying on that exception) but internally use just a single I/O thread waiting for events on any open file descriptors. Of course an implementation supporting all sort of concurrency could become quite complex (especially if open-read-close should work fast, I think would be difficult to implement, because a new file descriptors had to be added to the waitFor/select list, and who knows how systems behave here in detail...). oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:25:15 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:25:15 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6CDB22.9070401@sandglass-software.com> References: <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> <4D6CDB22.9070401@sandglass-software.com> Message-ID: <20110302102515.GD8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 03:40 -0800: > * from some older mail: > > My question would be: Why would you do that? The rewrite does > > most of the work for you - all you have to do is implement > > two C++ virtual classes and two C++ functions. > > > > In Windows that took me a few hours. > > Every journey begins with a single step. Yes, of course, but then it shouldn't be used as base for new effort estimations like `In Windows that took a few hours' ;-) (BTW, calling a single step `the rewrite' may sound a bit ambitious ;)) But of course a prototype demonstrating something can be really helpful, sure. I just wanted to tell that interfaces should be easy to use and powerful at the same time and may non-trivial initial considerations before starting to implement them. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From ryan.boder at gmail.com Wed Mar 2 18:44:35 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:44:35 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: While running the tests you requested I may have stumbled on the problem, I just don't know how to fix it. According to the documentation, if both the receive timeout and receive threshold are disabled then read() should block forever until data is available. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#getInputStream%28%29 On my system using RXTX read() is returning -1 when no data is available even though I have disabled both thresholds. The reason my program was running fine for a while without this problem showing up is that I was using the DATA_AVAILABLE event to be notified when data is available and only calling read() to read an entire frame whenever the DATA_AVAILABLE event occurred, until eventually my device (I'm guessing) probably took longer than normal to send the entire data frame and therefore I called read when no data was available and it returned -1. The following Java program demonstrates my problem, it returns -1 as soon as no data is available, even though I think it should block until data is available. import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; public class Main implements SerialPortEventListener { public static void main(String[] args) throws Exception { new Main().run(); } private void run() throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier("COM4"); SerialPort port = (SerialPort) portIdentifier.open(Main.class.getName(), 2000); port.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); port.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); port.disableReceiveThreshold(); port.disableReceiveTimeout(); BufferedInputStream in = new BufferedInputStream(port.getInputStream()); BufferedOutputStream out = new BufferedOutputStream(port.getOutputStream()); port.addEventListener(this); Thread.sleep(1000); out.write(new byte[] {0x02, 0x60}); out.flush(); while (true) { int x = in.read(); if (x == -1) { System.out.println("EOF"); Thread.sleep(1000000000); } String s = Integer.toHexString(x & 0xFF); if (s.length() == 1) s = "0" + s; System.out.print(s + " "); System.out.flush(); } } public void serialEvent(SerialPortEvent arg0) { System.out.println("Serial port event"); } } However, the follow C# program ran all day today without ever read ever returning -1, as I would expect. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.IO.Ports; using System.Threading; namespace RXTXReadTest1 { class Program { static void Main(string[] args) { new Program().run(); } private void run() { SerialPort port = new SerialPort("COM4", 19200, Parity.None, 8, StopBits.One); port.Open(); port.Write(new byte[] { 0x02, 0x60 }, 0, 2); while (true) { int x = port.ReadByte(); if (x == -1) { Console.WriteLine("EOF"); Thread.Sleep(1000000000); } String s = x.ToString("X"); if (s.Length == 1 ) s = "0" + s; Console.Out.Write(s + " "); Console.Out.Flush(); } } } } Now I am experimenting with what happens if I set the receive timeout to it's maximum value (apparently 1600ms) and only call read() when I am expecting data. Hopefully it will never be more than 1600ms late. This is still only a work around, not solving the problem. Am I doing something wrong in my code above or is RXTX retuning -1 when it should be blocking? Thanks, Ryan On Wed, Mar 2, 2011 at 3:34 AM, Kustaa Nyholm wrote: > On 3/2/11 07:53, "Ryan Boder" wrote: > Can you / have you made a simple test to ensure that rxtx is the issue? > > Can you write a simple C-program to see if this exhibits the same problem? > > I've never encountered this sort of problem with rxtx, it mostly just > works. > > But I'm on Mac so can't say about Windows (7) > > br Kusti > > > > > >Hi, > > > >I haven't seen any response to my question below. Is this not the right > >place to ask? If not, where would be a better place to ask? Any > >suggestions? > > > >Thanks, > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder > wrote: > > > >I mis-spoke, I don't have my own thread calling read, I am calling > >read in the event handler after receiving a > >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be > >accurate though. > > > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder > wrote: > > > >Hi, > > > >I have a receive thread that does nothing but call read() on the serial > >port input stream. It works fine for a while but after running for a long > >time it eventually returns -1 which means EOF. This is my first problem, > >as the device I'm talking to runs forever, I don't know why it would > >return -1. I am calling disableReceiveThreshold() and > >disableReceiveTimeout() at initialization which according to the > >documentation means read will return as soon as any data is available and > >it will block forever when data is not available, so -1 should never be > >returned from read, right? > > > >I have been unable to figure out why read returns -1 after a long while > >but I have found that if I kill my application and restart it everything > >works fine again. Therefore I tried to work around the problem by having > >my code close the port and reopen it when read returns -1. My second > >problem is that in this case when I call close() on the port it blocks > >forever. I did find this old bug > > > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > > > >which describes close() hanging on OSX, but it says that bug was fixed > >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone > >have any idea why read might be returning -1 in the first place? If I can > >avoid that I don't care about close() hanging because I would never close > >the port. If not, does anyone know why close() might block forever and > >how I can prevent this? I'm using RXTX version 2.1-7. > > > >Thanks, > >-- > >Ryan > > > > > > > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Wed Mar 2 18:46:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:46:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: <-1051064942000733580@unknownmsgid> References: <-1051064942000733580@unknownmsgid> Message-ID: It is USB and seems very reliable with the C# test program in my previous email. On Wed, Mar 2, 2011 at 6:58 PM, Bruce Griffith wrote: > How reliable is your serial port ? is it USB or Bluetooth? > > > > Bruce Griffith > > 303-532-4778 > > > > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On Behalf > Of *Ryan Boder > *Sent:* Tuesday, 01 March 2011 10:53 PM > *To:* rxtx at qbang.org > *Subject:* Re: [Rxtx] RXTX serial port read() returns -1 unexpectedly and > then blocks forever on close() > > > > Hi, > > I haven't seen any response to my question below. Is this not the right > place to ask? If not, where would be a better place to ask? Any suggestions? > > Thanks, > Ryan > > On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > > Hi, > > I have a receive thread that does nothing but call read() on the serial > port input stream. It works fine for a while but after running for a long > time it eventually returns -1 which means EOF. This is my first problem, as > the device I'm talking to runs forever, I don't know why it would return -1. > I am calling disableReceiveThreshold() and disableReceiveTimeout() at > initialization which according to the documentation means read will return > as soon as any data is available and it will block forever when data is not > available, so -1 should never be returned from read, right? > > I have been unable to figure out why read returns -1 after a long while but > I have found that if I kill my application and restart it everything works > fine again. Therefore I tried to work around the problem by having my code > close the port and reopen it when read returns -1. My second problem is that > in this case when I call close() on the port it blocks forever. I did find > this old bug > > http://bugzilla.qbang.org/show_bug.cgi?id=53 > > which describes close() hanging on OSX, but it says that bug was fixed with > a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have any > idea why read might be returning -1 in the first place? If I can avoid that > I don't care about close() hanging because I would never close the port. If > not, does anyone know why close() might block forever and how I can prevent > this? I'm using RXTX version 2.1-7. > > Thanks, > -- > Ryan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Mar 3 02:50:20 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 3 Mar 2011 09:50:20 +0000 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: So if -1 is unexpectedly returned from read, and we have demonstrated that your USB-serial adapter can actually causes this to happen in RXTX, why not just ignore the -1 value? What happens when you try this? As for a hang on close, are your closing your port from within your serial event handler? I know that this can cause some serious problems. Regards, Michael Erskine. From Kustaa.Nyholm at planmeca.com Thu Mar 3 03:39:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 12:39:34 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 03:44, "Ryan Boder" wrote: >While running the tests you requested I may have stumbled on the problem, >I just don't know how to fix it. According to the documentation, if both >the receive timeout and receive threshold are disabled then read() should >block forever until data is available. > >http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/re >ference/api/javax/comm/CommPort.html#getInputStream%28%29 > >On my system using RXTX read() is returning -1 when no data is available >even though I have disabled both thresholds. The reason my program was >running fine for a while without this problem showing up is that I was >using the DATA_AVAILABLE event to be notified when data is available and >only calling read() to read an entire frame whenever the DATA_AVAILABLE >event occurred, until eventually my device (I'm guessing) probably took >longer than normal to send the entire data frame and therefore I called >read when no data was available and it returned -1. As a workaround have you tried to perform another read() if it returns -1? The javadoc says (see getInputStream): "Note, however, that framing errors may cause the Timeout and Threshold values to complete prematurely without raising an exception." I read this as a hint that read might return even if no data is available. Because of the above and that read() can only return -1 or the byte received it would be somewhat logical to return -1 in case of framing error ? I'm not claiming that my interpretation of the specification, such as it is, is correct, just speculating that the behavior could be something like that. It might give you some more insight if you used the read(bytes[],int,int) method, because this can and will return 0 in case of timeout (and presumably might do so in case of framing error, maybe some other error condition too). That might allow you to handle or work around the problem in this case. You have not shown your complete code (no need) but your comments and the example makes me wonder if the code is otherwise as it should be, meaning are you assuming that when you get the DATA_AVAILABLE event all of your frame has arrived and that you can just blindly read it away from the input stream? That is not guaranteed of course. Also using read(), instead of read(bytes[],int,int), is not very efficient and might be masking other problems as mused above. BTE you can print a byte in hex with leading zeros more easily with: System.out.printf("%02X",x); br Kusti From ryan.boder at gmail.com Thu Mar 3 07:56:16 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:56:16 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 5:39 AM, Kustaa Nyholm wrote: > > As a workaround have you tried to perform another read() if it returns -1? > I tried that and it did work sometimes but not all the time. > > The javadoc says (see getInputStream): > > "Note, however, that framing errors may cause the Timeout and Threshold > values to complete prematurely without raising an exception." > > I read this as a hint that read might return even if no data is available. > > Because of the above and that read() can only return -1 or the byte > received > it would be somewhat logical to return -1 in case of framing error ? > > I'm not claiming that my interpretation of the specification, such as it > is, > is correct, just speculating that the behavior could be something like > that. > Receive framing is not enabled by default. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#enableReceiveFraming%28int%29 My choice of word might be misleading, when I said frame I just meant a contiguous message from the device. I am not enabling receive framing. Can you have a framing error when receive framing is disabled? > > It might give you some more insight if you used the read(bytes[],int,int) > method, because > this can and will return 0 in case of timeout (and presumably might do so > in case of framing > error, maybe some other error condition too). > > That might allow you to handle or work around the problem in this case. > > You have not shown your complete code (no need) but your comments and the > example > makes me wonder if the code is otherwise as it should be, meaning are you > assuming > that when you get the DATA_AVAILABLE event all of your frame has arrived > and that > you can just blindly read it away from the input stream? That is not > guaranteed of course. > I'm not assuming the entire message has arrived, I'm just assuming it either has arrived or will arrive soon which is why I'm using a (supposedly) blocking read(). > > Also using read(), instead of read(bytes[],int,int), is not very efficient > and > might be masking other problems as mused above. > True, I'm reading one byte at a time because I don't know how long the message will be until I read and parse some of it. I suppose I can use read(bytes[],int,int) once I figure out how long the message will be. > > BTE you can print a byte in hex with leading zeros more easily with: > > > System.out.printf("%02X",x); > I did it the dumb way in that test program so I could copy and paste the code from C# to Java without having to figure out how to do the same in C# which I'm not as familiar with. Thanks and BR, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 07:58:24 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:58:24 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: Yes I was doing the close in the serial event handler, I didn't realize that caused a problem. Thanks, I'll fix it. On Thu, Mar 3, 2011 at 4:50 AM, Michael Erskine wrote: > So if -1 is unexpectedly returned from read, and we have demonstrated > that your USB-serial adapter can actually causes this to happen in > RXTX, why not just ignore the -1 value? What happens when you try > this? As for a hang on close, are your closing your port from within > your serial event handler? I know that this can cause some serious > problems. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 11:48:20 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 13:48:20 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm wrote: > On 3/3/11 16:56, "Ryan Boder" wrote: > > > >I'm not assuming the entire message has arrived, I'm just assuming it > >either has arrived or will arrive soon which is why I'm using a > >(supposedly) blocking read(). > > > I've been giving this some further thought. > > It does not feel healthy to block without timeout, especially > from within a thread that is essentially internal to the rxtx. > > I've never done that, I always use a time out, read(byte[],int,int) > for the expected number of bytes, check how much I got and issue > more reads until I get everything. > > You have not described how your communication works so I'm only > speculating. > > If your device needs some response to send more bytes (from your > code it looks like this is not the case) then a missing byte > would block your read and prevent you from responding and > getting more data. But as said, looks like that is not the case. > > Anyway, if this was my problem, I would enable the timeout > and use read(byte[],int,int) and loop until I get what I need. > You are right, I should and will use a timeout. In fact, my program has been running flawlessly for 12 hours and the only change I made was to enable a timeout, no change in the logic at all. Without the timeout read() was returning -1 usually after it ran for an hour or two. I will change the code to make use of the timeout and handle it appropriately. It still seems to me that RXTX's behavior doesn't match the documentation when rx timeout and rx threshold are disabled read() should block until data is available instead of immediately returning -1. I don't believe that a framing error is occurring immediately every time data is not available causing read() to return -1. Especially since the C# test program above runs all day with no error and the Java program above runs all day with no error when a timeout is enabled. To me it seems like enabling the timeout is what is causing read() to block until data is available, even if only for 1600ms, and without the timeout read() is returning -1 immediately when it should be blocking. Thanks for all the help and best regards, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Thu Mar 3 13:02:30 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 22:02:30 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 20:48, "Ryan Boder" wrote: >On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm > wrote: > >On 3/3/11 16:56, "Ryan Boder" wrote: >> > >>I'm not assuming the entire message has arrived, I'm just assuming it >>either has arrived or will arrive soon which is why I'm using a >>(supposedly) blocking read(). > > > >I've been giving this some further thought. > >It does not feel healthy to block without timeout, especially >from within a thread that is essentially internal to the rxtx. > >I've never done that, I always use a time out, read(byte[],int,int) >for the expected number of bytes, check how much I got and issue >more reads until I get everything. > >You have not described how your communication works so I'm only >speculating. > >If your device needs some response to send more bytes (from your >code it looks like this is not the case) then a missing byte >would block your read and prevent you from responding and >getting more data. But as said, looks like that is not the case. > >Anyway, if this was my problem, I would enable the timeout >and use read(byte[],int,int) and loop until I get what I need. > > > > >You are right, I should and will use a timeout. In fact, my program has >been running flawlessly for 12 hours and the only change I made was to >enable a timeout, no change in the logic at all. Without the timeout >read() was returning -1 usually after it ran for an hour or two. I will >change the code to make use of the timeout and handle it appropriately. That's nice! > >It still seems to me that RXTX's behavior doesn't match the documentation >when rx timeout and rx threshold are disabled read() should block until >data is available instead of immediately returning -1. Yeah, it does look like bug. However this might be related to some Windows specific serial port issue. Years ago I had issues with JavaComm (not RxTx) where I did a blocking read and I had huge issues with my program consuming all resources. I curser the Sun and JavaComm and re-code my own SerialPort using JNI to access the Win32 API directly. And I run into the same problems as with the Sun's implementation! So I ditched my code, changed my code to use timeouts and problems disappeared. > I don't believe that a framing error is occurring immediately every time >data is not available causing read() to return -1. Especially since the >C# test program above runs all day with no error and the Java program >above runs all day with no error when a timeout is enabled. I think so too, all things considered I don't really believe in framing errors in this case. > To me it seems like enabling the timeout is what is causing read() to >block until data is available, even if only for 1600ms, and without the >timeout read() is returning -1 immediately when it should be blocking. Yeah, I had a peek at the innards of RxTx Windows serial port a week or so ago and also read MSDN documentation about serial ports and the way overlapped and non-overlapped (non blocking and blocking) IO is handled is a way different. So yeah, it can well be that there is an issue lurking there somewhere inside RxTx in Windows. > > >Thanks for all the help and best regards, >-- >Ryan Boder I'm happy if I was of any assistance. br Kusti From tjarvi at qbang.org Thu Mar 3 18:52:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Mar 2011 18:52:50 -0700 (MST) Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: >> Without the timeout >> read() was returning -1 usually after it ran for an hour or two. There is a big hammer in rxtx causing that behavior. >> It still seems to me that RXTX's behavior doesn't match the documentation >> when rx timeout and rx threshold are disabled read() should block until >> data is available instead of immediately returning -1. > > Yeah, it does look like bug. However this might be related to some > Windows specific serial port issue. Years ago I had issues with > JavaComm (not RxTx) where I did a blocking read and I had huge > issues with my program consuming all resources. I curser the Sun > and JavaComm and re-code my own SerialPort using JNI to access > the Win32 API directly. And I run into the same problems as > with the Sun's implementation! So I ditched my code, changed > my code to use timeouts and problems disappeared. > > >> To me it seems like enabling the timeout is what is causing read() to >> block until data is available, even if only for 1600ms, and without the >> timeout read() is returning -1 immediately when it should be blocking. > > Yeah, I had a peek at the innards of RxTx Windows serial port a week > or so ago and also read MSDN documentation about serial ports and > the way overlapped and non-overlapped (non blocking and blocking) > IO is handled is a way different. So yeah, it can well be that > there is an issue lurking there somewhere inside RxTx in Windows. > > Yes. RXTX was patched to behave the way it does. I don't fully understand the issue behind the patch. Marc noticed the odd behavior as well and offered a fix which was greeted with resistance. The windows implementation was done without real documentatino of the windows API. I think I had an example from the late 80's early 90's on Microsoft's site and some API documentation that was obviously not microsofts in Europe. Wayne Roberts had a real need for windows support and fixed some major issues it had. My interest at the time was mingw32. I then cleaned it up for some specific uses I had later. The read returning -1 when it should block didn't impact anybody and appeared to help some people. It isnt the documented behavior though. There could be all sorts of latent bugs in that code but in the real world, it gets by in almost all use cases. Its a hack but it worked for 100's of thousands of people over a 14 year period. Maybe its time to revisit the code but there is more risk than gain for most people. How do you move forward and avoid the risk? Some have expressed interests in coding C++ or other efforts. I'm all for such efforts but feel some unit tests that work with a null modem cables are the only thing that will move rxtx (and perhaps CommAPI) forward. If we have a test suite in place as a qualification for implementations, progress can be made in the right direction regardless of the implementation details. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Fri Mar 4 02:57:16 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 4 Mar 2011 11:57:16 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/4/11 03:52, "Trent Jarvi" wrote: >Yes. RXTX was patched to behave the way it does. I don't fully >understand the issue behind the patch. Marc noticed the odd behavior as >well and offered a fix which was greeted with resistance. > >The windows implementation was done without real documentatino of the >windows API. I think I had an example from the late 80's early 90's on >Microsoft's site and some API documentation that was obviously not >microsofts in Europe. Wayne Roberts had a real need for windows support >and fixed some major issues it had. My interest at the time was mingw32. >I then cleaned it up for some specific uses I had later. The read >returning -1 when it should block didn't impact anybody and appeared to >help some people. It isnt the documented behavior though. > >There could be all sorts of latent bugs in that code but in the real >world, it gets by in almost all use cases. I think so too, never had any problems with it. > Its a hack but it worked for 100's of thousands of people over a 14 year >period. Yeah! Thanks for everyone who has contributed over the years, job well done! >Maybe its time to >revisit the code but there is more risk than gain for most people. How >do >you move forward and avoid the risk? My view is that it is quite risky and rather pointless to move forward, other than fixing bugs that really affect people. At the moment the major issue IMO is just that it seems (not been following this too carefully, so maybe I'm wrong, so in case this FUD, my apologies) that 'official' binaries are not available. I think the rewrite, tempting as it is in some respects is not the way forward. Just gentle maintenance to iron out real issues and then get the binaries out. br Kusti From ryan.boder at gmail.com Fri Mar 4 07:24:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Fri, 4 Mar 2011 09:24:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 8:52 PM, Trent Jarvi wrote: > > The windows implementation was done without real documentatino of the > windows API. I think I had an example from the late 80's early 90's on > Microsoft's site and some API documentation that was obviously not > microsofts in Europe. Wayne Roberts had a real need for windows support and > fixed some major issues it had. My interest at the time was mingw32. I then > cleaned it up for some specific uses I had later. The read returning -1 > when it should block didn't impact anybody and appeared to help some people. > It isnt the documented behavior though. > > There could be all sorts of latent bugs in that code but in the real world, > it gets by in almost all use cases. Its a hack but it worked for 100's of > thousands of people over a 14 year period. Maybe its time to revisit the > code but there is more risk than gain for most people. How do you move > forward and avoid the risk? > The safest and easiest solution would be to add a javadoc comment to disableReceiveTimeout explaining the difference between the RXTX behavior and Sunacle's documented behavior so that when someone uses the method in an IDE like Eclipse a little box would pop up informing them. Generating javadoc HTML and hosting it on the RXTX website would go a long way too, when something behaves differently than I expect the first thing I do is look for the javadoc online. -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From kharrington at neuronrobotics.com Mon Mar 7 10:47:26 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 12:47:26 -0500 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! Message-ID: Hey all, this is just a heads up that i have made a fork of rxtxSerial. Some of the features we have added: * Self deployment of native libraries ( all native code is stored inside the jar and deployed at runtime). No more manual install of native code. * Arm Cortex support (Gumstix) * Android Support (requires a rooted phone for now) * Google Code (SVN) repository for easy code and jar access * Single makefile compile (simplifies the compilation of project binaries) * Ant build script for jar creation * Removal of partialy implemented code to streamline the lib for just serial port access * Full Eclipse integration, for testing application code against sources. And a bunch of bug fixes: * Fixed the memory access error that causes OSX to crash the JVM when serial.close() is cvalled * Fixed the windows serial port zombie bind that prevents re-accessing serial ports when exiting on an exception * Fixed erronious printouts of native library mis-match To check it out, take a look at our page here: http://code.google.com/p/nrjavaserial/ From Kustaa.Nyholm at planmeca.com Mon Mar 7 11:46:26 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Mar 2011 20:46:26 +0200 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: Message-ID: On 3/7/11 19:47, "Kevin Harrington NR" wrote: >Hey all, this is just a heads up that i have made a fork of >rxtxSerial. Some of the features we have added great! If also does what it says on the tin: brilliant! Congrats and thanks. br Kusti From jmsachs at gmail.com Mon Mar 7 12:50:33 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 14:50:33 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: > From: Kevin Harrington NR > To: rxtx at qbang.org > Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > Hey all, this is just a heads up that i have made a fork of > rxtxSerial. Some of the features we have added: > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with a ten-foot pole. From Kustaa.Nyholm at planmeca.com Mon Mar 7 13:10:43 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Mar 2011 22:10:43 +0200 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: Message-ID: On 3/7/11 21:50, "Jason Sachs" wrote: > >Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >a ten-foot pole. >_______________________________________________ Oh crap, makes it useless for me and many others. Also I see no provision in RxTx license to change it so how could anyone change it to GPLv3? br Kusti From showard314 at gmail.com Mon Mar 7 13:24:08 2011 From: showard314 at gmail.com (Scott Howard) Date: Mon, 7 Mar 2011 15:24:08 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 3:10 PM, Kustaa Nyholm wrote: > Also I see no provision in RxTx license to change > it so how could anyone change it to GPLv3? I think this is allowed: 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. From jmsachs at gmail.com Mon Mar 7 13:24:47 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 15:24:47 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 2:50 PM, Jason Sachs wrote: >> From: Kevin Harrington NR >> To: rxtx at qbang.org >> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> > > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with > a ten-foot pole. > Let me back up a second (perhaps to make up for my lack of diplomacy) and state that I think any progress w/ rxtx is good. If an rxtx fork were LGPL (or some other non-spreading open source license) and leading in a good direction, I'd gladly return the favor by posting any improvements or bugfixes I found to the community. --Jason From jmsachs at gmail.com Mon Mar 7 13:36:13 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 15:36:13 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: Kevin: could you clarify the license? http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java has the RXTX 2.1 license (LGPL v 2.1 + Linking Over Controlled Interface.) but http://code.google.com/p/nrjavaserial/ says GPLv3. --Jason From kharrington at neuronrobotics.com Mon Mar 7 14:00:02 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 16:00:02 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: The one downside to google code is that it does not allow custom licensing. You have to pick from a drop-down list. Treat the licences on the files themselves as the licence to be concerned with, and ignore the "project licence". Sorry for the confusion. On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: > Kevin: could you clarify the license? > > http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java > has the RXTX 2.1 license > (LGPL v 2.1 + Linking Over Controlled Interface.) > > but http://code.google.com/p/nrjavaserial/ says GPLv3. > > --Jason > From iqzw2r602 at sneakemail.com Mon Mar 7 14:08:18 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 8 Mar 2011 08:08:18 +1100 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: References: Message-ID: <11253-1299532098-811882@sneakemail.com> Nice! Out of curiosity, did you use the patch that I sent Trent about two years ago to do the native library loading, or did you implement your own solution? Cheers, Uwe On Tue, Mar 8, 2011 at 5:46 AM, Kustaa Nyholm Kustaa.Nyholm-at-planmeca.com| rxtx.org mailing list/Example Allow| wrote: > On 3/7/11 19:47, "Kevin Harrington NR" > wrote: > > >Hey all, this is just a heads up that i have made a fork of > >rxtxSerial. Some of the features we have added > > > > great! If also does what it says on the tin: brilliant! > > Congrats and thanks. > > br Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aawolfe at gmail.com Mon Mar 7 15:31:47 2011 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 7 Mar 2011 17:31:47 -0500 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR wrote: > Hey all, this is just a heads up that i have made a fork of > rxtxSerial. Some of the features we have added: > > * Self deployment of native libraries ( all native code is stored > inside the jar and deployed at runtime). No more manual install of > native code. > * Arm Cortex support (Gumstix) > * Android Support (requires a rooted phone for now) > * Google Code (SVN) repository for easy code and jar access > * Single makefile compile (simplifies the compilation of project binaries) > * Ant build script for jar creation > * Removal of partialy implemented code to streamline the lib for just > serial port access > * Full Eclipse integration, for testing application code against sources. > > And a bunch of bug fixes: > > * Fixed the memory access error that causes OSX to crash the JVM when > serial.close() is cvalled > * Fixed the windows serial port zombie bind that prevents re-accessing > serial ports when exiting on an exception > * Fixed erronious printouts of native library mis-match > > To check it out, take a look at our page here: > > http://code.google.com/p/nrjavaserial/ This is interesting, getting the native libs set up has been an issue for some of my users. Will have to check it out. Out of curiosity, what Android devices provide a serial port? Or are there some that allow USB host mode and then a usb-serial adapter? I have only an Android cell phone, don't think it can do anything serial but would love to be wrong about that. From jfh at greenhousepc.com Mon Mar 7 15:54:39 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 15:54:39 -0700 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! Message-ID: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Mon Mar 7 16:53:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Mar 2011 16:53:50 -0700 (MST) Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: Hi Kevin, Until Google fixes the options as developers have requested, I'd suggest the least misleading dropdown option is "Other Open Source" with a clarification about LGPL 2.1 on the project page. If you are not supporting the CommAPI SPI interface that was available prior to the current JSR so that applications work in the javax.comm namespace, there is no need for the linking over controlled interfaces exception. RXTX 2.0 is used in that fashion but RXTX 2.1 is not. The exception explicitly states it can be removed if the source has been modified. The license is then explicitly OSI reviewed and approved as Google requests but is not in their drop down box as it should be and is for the GPL v2. http://opensource.org/licenses/alphabetical http://opensource.org/licenses/lgpl-2.1 The drawback would be that the library effectively could never be used in that SPI/controlled interface fashion again. On Mon, 7 Mar 2011, Kevin Harrington NR wrote: > The one downside to google code is that it does not allow custom > licensing. You have to pick from a drop-down list. Treat the licences > on the files themselves as the licence to be concerned with, and > ignore the "project licence". Sorry for the confusion. > > On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >> Kevin: could you clarify the license? >> >> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >> has the RXTX 2.1 license >> (LGPL v 2.1 + Linking Over Controlled Interface.) >> >> but http://code.google.com/p/nrjavaserial/ says GPLv3. >> >> --Jason >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From hakcenter at gmail.com Mon Mar 7 18:55:57 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 17:55:57 -0800 Subject: [Rxtx] Latency Woes Message-ID: <4D758CAD.2010602@gmail.com> I have finally deduced my slow data logging to a latency issue. I write software for dsms, and the protocol is request / receive, you cannot do more than 1 sensor at a time. So when you log multiple sensors, +20ms per item, sampling rate drops like a rock. I was wondering if there is any ideas besides going completely native with my application to reduce latency. With or without events I don't care at this point I need to kill as much of the latency as possible. Realistically I need no more than 1ms. From adrian.crum at sandglass-software.com Mon Mar 7 19:08:21 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Mon, 07 Mar 2011 18:08:21 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D758CAD.2010602@gmail.com> References: <4D758CAD.2010602@gmail.com> Message-ID: <4D758F95.90800@sandglass-software.com> Drop the requests into a queue, and then have a separate thread service the queue. -Adrian On 3/7/2011 5:55 PM, Curtis Hacker wrote: > I have finally deduced my slow data logging to a latency issue. > > I write software for dsms, and the protocol is request / receive, you > cannot do more than 1 sensor at a time. So when you log multiple > sensors, +20ms per item, sampling rate drops like a rock. > > I was wondering if there is any ideas besides going completely native > with my application to reduce latency. With or without events I don't > care at this point I need to kill as much of the latency as possible. > Realistically I need no more than 1ms. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From hakcenter at gmail.com Mon Mar 7 19:24:16 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 18:24:16 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D758F95.90800@sandglass-software.com> References: <4D758CAD.2010602@gmail.com> <4D758F95.90800@sandglass-software.com> Message-ID: <4D759350.8060402@gmail.com> Sample code ? I don't necessarily want to read the byte I just wrote, but wait till the que depth is 2. Setup a thread without a sleep timer: if (in.available() > 1) { do_stuff(); } ?? On 03/07/11 18:08, Adrian Crum wrote: > Drop the requests into a queue, and then have a separate thread > service the queue. > > -Adrian > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: >> I have finally deduced my slow data logging to a latency issue. >> >> I write software for dsms, and the protocol is request / receive, you >> cannot do more than 1 sensor at a time. So when you log multiple >> sensors, +20ms per item, sampling rate drops like a rock. >> >> I was wondering if there is any ideas besides going completely native >> with my application to reduce latency. With or without events I don't >> care at this point I need to kill as much of the latency as possible. >> Realistically I need no more than 1ms. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adrian.crum at sandglass-software.com Mon Mar 7 19:46:02 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Mon, 07 Mar 2011 18:46:02 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D759350.8060402@gmail.com> References: <4D758CAD.2010602@gmail.com> <4D758F95.90800@sandglass-software.com> <4D759350.8060402@gmail.com> Message-ID: <4D75986A.6020003@sandglass-software.com> http://download.oracle.com/javase/tutorial/essential/concurrency/executors.html -Adrian On 3/7/2011 6:24 PM, Curtis Hacker wrote: > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: >> Drop the requests into a queue, and then have a separate thread >> service the queue. >> >> -Adrian >> >> On 3/7/2011 5:55 PM, Curtis Hacker wrote: >>> I have finally deduced my slow data logging to a latency issue. >>> >>> I write software for dsms, and the protocol is request / receive, >>> you cannot do more than 1 sensor at a time. So when you log multiple >>> sensors, +20ms per item, sampling rate drops like a rock. >>> >>> I was wondering if there is any ideas besides going completely >>> native with my application to reduce latency. With or without events >>> I don't care at this point I need to kill as much of the latency as >>> possible. Realistically I need no more than 1ms. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Mon Mar 7 19:50:45 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 19:50:45 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Mon Mar 7 20:04:01 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 19:04:01 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> Message-ID: <4D759CA1.8010903@gmail.com> I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. in.read(data, 0, 2); ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? On 03/07/11 18:50, jfh at greenhousepc.com wrote: > Curtis, > > No, I assume he means a real queue, not just "don't read all the bytes > at once." However, if you know you can process some number of > requests in some amount of time, allowing data to pile up (receiver > FIFO space permitting) can be a valid strategy. Inserting gobs of > Thread.yield() and notify() can help pep things up as well. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Mon, March 07, 2011 8:24 pm > To: rxtx at qbang.org > > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: > > Drop the requests into a queue, and then have a separate thread > > service the queue. > > > > -Adrian > > > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: > >> I have finally deduced my slow data logging to a latency issue. > >> > >> I write software for dsms, and the protocol is request / > receive, you > >> cannot do more than 1 sensor at a time. So when you log multiple > >> sensors, +20ms per item, sampling rate drops like a rock. > >> > >> I was wondering if there is any ideas besides going completely > native > >> with my application to reduce latency. With or without events I > don't > >> care at this point I need to kill as much of the latency as > possible. > >> Realistically I need no more than 1ms. > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From bartley at cmu.edu Mon Mar 7 20:08:05 2011 From: bartley at cmu.edu (Chris Bartley) Date: Mon, 7 Mar 2011 22:08:05 -0500 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> Message-ID: <9B1804F9-DBD0-476D-9345-806D00065A97@cmu.edu> We use a queue for all our request/response serial communications, and have found it really easy to work with. Code is here: http://code.google.com/p/create-lab-commons/source/browse/trunk/java/code/serial/src/edu/cmu/ri/createlab/serial/SerialPortCommandExecutionQueue.java It's assuming a command & response scheme that's specific to the protocol we use to talk to our robots, but it should be easy to modify for your needs. Hope this helps. Let me know if you have questions. Chris On Mar 7, 2011, at 9:50 PM, wrote: > Curtis, > > No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > Date: Mon, March 07, 2011 8:24 pm > To: rxtx at qbang.org > > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: > > Drop the requests into a queue, and then have a separate thread > > service the queue. > > > > -Adrian > > > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: > >> I have finally deduced my slow data logging to a latency issue. > >> > >> I write software for dsms, and the protocol is request / receive, you > >> cannot do more than 1 sensor at a time. So when you log multiple > >> sensors, +20ms per item, sampling rate drops like a rock. > >> > >> I was wondering if there is any ideas besides going completely native > >> with my application to reduce latency. With or without events I don't > >> care at this point I need to kill as much of the latency as possible. > >> Realistically I need no more than 1ms. > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Mon Mar 7 20:51:17 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 20:51:17 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110307205116.8ef0e5b4a80cef441275a6330ffad77d.9b325137d1.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From kharrington at neuronrobotics.com Mon Mar 7 20:55:23 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 22:55:23 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 7 In-Reply-To: References: Message-ID: To answer a few of you, I have changed the license to "Other open source license" as suggested. My company is modifying and maintaining this fork to support our robotics development library (http://code.google.com/p/nr-sdk/ http://dev.neuronrobotics.com). We will be implementing the standard serial port interface only, as it is the only one we need or care about. As for where the implementation came from, i would have to refer to my other developer to answer that. I wrote the build scripts and make files, as well as streamlining the C build process. I have remover the configure script, as it ends up being more confusing then compiling 3 C files needs to be. if you guys want to bring any of this into the main line, that's cool, but up to you to port over. Our fork will be focusing on polishing up the serial interface,and hopefully making it faster. I hope some of you will find our improvements useful! On Mon, Mar 7, 2011 at 6:53 PM, wrote: > Send Rxtx mailing list submissions to > ? ? ? ?rxtx at qbang.org > > To subscribe or unsubscribe via the World Wide Web, visit > ? ? ? ?http://mailman.qbang.org/mailman/listinfo/rxtx > or, via email, send a message with subject or body 'help' to > ? ? ? ?rxtx-request at qbang.org > > You can reach the person managing the list at > ? ? ? ?rxtx-owner at qbang.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Rxtx digest..." > > > Today's Topics: > > ? 1. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 2. Re: Rxtx Digest, Vol 43, Issue 6 (Kustaa Nyholm) > ? 3. Re: Rxtx Digest, Vol 43, Issue 6 (Scott Howard) > ? 4. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 5. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 6. Re: Rxtx Digest, Vol 43, Issue 6 (Kevin Harrington NR) > ? 7. Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! > ? ? ?(iqzw2r602 at sneakemail.com) > ? 8. Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! > ? ? ?(Aaron Wolfe) > ? 9. Re: [SPAM] Re: ?NRJavaSerial, a fork of rxtx that fixes the > ? ? ?papercuts! (jfh at greenhousepc.com) > ?10. Re: Rxtx Digest, Vol 43, Issue 6 (Trent Jarvi) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 7 Mar 2011 14:50:33 -0500 > From: Jason Sachs > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > >> From: Kevin Harrington NR >> To: rxtx at qbang.org >> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> > > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with > a ten-foot pole. > > > ------------------------------ > > Message: 2 > Date: Mon, 7 Mar 2011 22:10:43 +0200 > From: Kustaa Nyholm > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > On 3/7/11 21:50, "Jason Sachs" wrote: >> >>Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >>a ten-foot pole. >>_______________________________________________ > > Oh crap, makes it useless for me and many others. > > Also I see no provision in RxTx license to change > it so how could anyone change it to GPLv3? > > br Kusti > > > > ------------------------------ > > Message: 3 > Date: Mon, 7 Mar 2011 15:24:08 -0500 > From: Scott Howard > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 3:10 PM, Kustaa Nyholm > wrote: >> Also I see no provision in RxTx license to change >> it so how could anyone change it to GPLv3? > > I think this is allowed: > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. ?To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. ?(If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) ?Do not make any other change in > these notices. > > ? Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > ? This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > > ------------------------------ > > Message: 4 > Date: Mon, 7 Mar 2011 15:24:47 -0500 > From: Jason Sachs > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 2:50 PM, Jason Sachs wrote: >>> From: Kevin Harrington NR >>> To: rxtx at qbang.org >>> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >>> Message-ID: >>> ? ? ? ? >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> Hey all, this is just a heads up that i have made a fork of >>> rxtxSerial. Some of the features we have added: >>> >> >> Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >> a ten-foot pole. >> > > Let me back up a second (perhaps to make up for my lack of diplomacy) > and state that I think any progress w/ rxtx is good. > > If an rxtx fork were LGPL (or some other non-spreading open source > license) and leading in a good direction, I'd gladly return the favor > by posting any improvements or bugfixes I found to the community. > > --Jason > > > ------------------------------ > > Message: 5 > Date: Mon, 7 Mar 2011 15:36:13 -0500 > From: Jason Sachs > To: rxtx at qbang.org, kharrington at neuronrobotics.com > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > Kevin: could you clarify the license? > > http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java > has the RXTX 2.1 license > (LGPL v 2.1 + Linking Over Controlled Interface.) > > but http://code.google.com/p/nrjavaserial/ says GPLv3. > > --Jason > > > ------------------------------ > > Message: 6 > Date: Mon, 7 Mar 2011 16:00:02 -0500 > From: Kevin Harrington NR > To: Jason Sachs > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > The one downside to google code is that it does not allow custom > licensing. You have to pick from a drop-down list. Treat the licences > on the files themselves as the licence to be concerned with, and > ignore the "project licence". Sorry for the confusion. > > On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >> Kevin: could you clarify the license? >> >> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >> has the RXTX 2.1 license >> (LGPL v 2.1 + Linking Over Controlled Interface.) >> >> but http://code.google.com/p/nrjavaserial/ says GPLv3. >> >> --Jason >> > > > ------------------------------ > > Message: 7 > Date: Tue, 8 Mar 2011 08:08:18 +1100 > From: iqzw2r602 at sneakemail.com > To: Rxtx at qbang.org > Subject: Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > ? ? ? ?papercuts! > Message-ID: <11253-1299532098-811882 at sneakemail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Nice! > > Out of curiosity, did you use the patch that I sent Trent about two years > ago to do the native library loading, or did you implement your own > solution? > > Cheers, > > Uwe > > On Tue, Mar 8, 2011 at 5:46 AM, Kustaa Nyholm Kustaa.Nyholm-at-planmeca.com| > rxtx.org mailing list/Example Allow| wrote: > >> On 3/7/11 19:47, "Kevin Harrington NR" >> wrote: >> >> >Hey all, this is just a heads up that i have made a fork of >> >rxtxSerial. Some of the features we have added >> >> >> >> great! If also does what it says on the tin: brilliant! >> >> Congrats and thanks. >> >> br Kusti >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 8 > Date: Mon, 7 Mar 2011 17:31:47 -0500 > From: Aaron Wolfe > To: rxtx at qbang.org > Subject: Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > ? ? ? ?papercuts! > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR > wrote: >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> >> * Self deployment of native libraries ( all native code is stored >> inside the jar and deployed at runtime). No more manual install of >> native code. >> * Arm Cortex support (Gumstix) >> * Android Support (requires a rooted phone for now) >> * Google Code (SVN) repository for easy code and jar access >> * Single makefile compile (simplifies the compilation of project binaries) >> * Ant build script for jar creation >> * Removal of partialy implemented code to streamline the lib for just >> serial port access >> * Full Eclipse integration, for testing application code against sources. >> >> And a bunch of bug fixes: >> >> * Fixed the memory access error that causes OSX to crash the JVM when >> serial.close() is cvalled >> * Fixed the windows serial port zombie bind that prevents re-accessing >> serial ports when exiting on an exception >> * Fixed erronious printouts of native library mis-match >> >> To check it out, take a look at our page here: >> >> http://code.google.com/p/nrjavaserial/ > > This is interesting, getting the native libs set up has been an issue > for some of my users. ?Will have to check it out. > > Out of curiosity, what Android devices provide a serial port? ?Or are > there some that allow USB host mode and then a usb-serial adapter? ?I > have only an Android cell phone, don't think it can do anything serial > but would love to be wrong about that. > > > ------------------------------ > > Message: 9 > Date: Mon, 07 Mar 2011 15:54:39 -0700 > From: > To: aaron at aaronwolfe.com, rxtx at qbang.org > Subject: Re: [Rxtx] [SPAM] Re: ?NRJavaSerial, a fork of rxtx that > ? ? ? ?fixes the papercuts! > Message-ID: > ? ? ? ?<20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe at email13.secureserver.net> > > Content-Type: text/plain; charset="us-ascii" > > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 10 > Date: Mon, 7 Mar 2011 16:53:50 -0700 (MST) > From: Trent Jarvi > To: rxtx at qbang.org > Cc: Jason Sachs > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > Hi Kevin, > > Until Google fixes the options as developers have requested, I'd suggest > the least misleading dropdown option is "Other Open Source" with a > clarification about LGPL 2.1 on the project page. > > If you are not supporting the CommAPI SPI interface that was available > prior to the current JSR so that applications work in the javax.comm > namespace, there is no need for the linking over controlled interfaces > exception. ?RXTX 2.0 is used in that fashion but RXTX 2.1 is not. ?The > exception explicitly states it can be removed if the source has been > modified. ?The license is then explicitly OSI reviewed and approved as > Google requests but is not in their drop down box as it should be and is > for the GPL v2. > > ? ? ? ?http://opensource.org/licenses/alphabetical > ? ? ? ?http://opensource.org/licenses/lgpl-2.1 > > The drawback would be that the library effectively could never be used in > that SPI/controlled interface fashion again. > > On Mon, 7 Mar 2011, Kevin Harrington NR wrote: > >> The one downside to google code is that it does not allow custom >> licensing. You have to pick from a drop-down list. Treat the licences >> on the files themselves as the licence to be concerned with, and >> ignore the "project licence". Sorry for the confusion. >> >> On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >>> Kevin: could you clarify the license? >>> >>> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >>> has the RXTX 2.1 license >>> (LGPL v 2.1 + Linking Over Controlled Interface.) >>> >>> but http://code.google.com/p/nrjavaserial/ says GPLv3. >>> >>> --Jason >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > ------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > End of Rxtx Digest, Vol 43, Issue 7 > *********************************** > From Kustaa.Nyholm at planmeca.com Mon Mar 7 21:43:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 8 Mar 2011 06:43:57 +0200 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307205116.8ef0e5b4a80cef441275a6330ffad77d.9b325137d1.wbe@email13.secureserver.net> Message-ID: On 3/8/11 05:51, "jfh at greenhousepc.com" wrote: >Curtis, > > >None of that is relevant, as long as the UART is reasonable and the code >implements a proper half duplex protocol. > >If I understand correctly, you send a byte, the sensor sends back two >bytes. So long as you don't send the next byte until the two bytes are >in the UART receiver FIFO, you're fine. You don't have to actually >=read= them, just know they are available. To the OP, are you using a serial USB port, like FTDI? This has a built in latency of 10ms ie nothing is actually sent out of the device if you send less than 64 bytes until 10 msec timeout. This has nothing to do with RxTx. If you search the list archives you'll find more about this issue and IIRC someone reported that there is some diver parameter you can tweak to get rid of that latency. I'm sure the FTDI people had a good reason for this but it really brings down the communication speed if your protocol uses short messages and need to wait for a response. Sorry if this has already been mentioned or if this is not relevant, I've not been paying attention to this thread. br Kusti From bob_jacobsen at lbl.gov Tue Mar 8 00:02:28 2011 From: bob_jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 8 Mar 2011 00:02:28 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D759CA1.8010903@gmail.com> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> Message-ID: If you're transferring three bytes total at 1953 baud, it's going to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to wait 20msec to get the data back instead of 15.4 msec doesn't seem to be as big a problem as you're making it sound. Bob On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. > > To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. > > So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. > > in.read(data, 0, 2); > ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? > > On 03/07/11 18:50, jfh at greenhousepc.com wrote: >> Curtis, >> >> No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker >> Date: Mon, March 07, 2011 8:24 pm >> To: rxtx at qbang.org >> >> Sample code ? >> >> I don't necessarily want to read the byte I just wrote, but wait till >> the que depth is 2. >> >> Setup a thread without a sleep timer: >> if (in.available() > 1) { >> do_stuff(); >> } >> >> ?? >> >> On 03/07/11 18:08, Adrian Crum wrote: >> > Drop the requests into a queue, and then have a separate thread >> > service the queue. >> > >> > -Adrian >> > >> > On 3/7/2011 5:55 PM, Curtis Hacker wrote: >> >> I have finally deduced my slow data logging to a latency issue. >> >> >> >> I write software for dsms, and the protocol is request / receive, you >> >> cannot do more than 1 sensor at a time. So when you log multiple >> >> sensors, +20ms per item, sampling rate drops like a rock. >> >> >> >> I was wondering if there is any ideas besides going completely native >> >> with my application to reduce latency. With or without events I don't >> >> care at this point I need to kill as much of the latency as possible. >> >> Realistically I need no more than 1ms. >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From hakcenter at gmail.com Tue Mar 8 01:33:24 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 00:33:24 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> Message-ID: <4D75E9D4.5090307@gmail.com> I am going to try a couple things today and hopefully figure something out. Bob I don't want to pop your bubble, but a native application named 'TunerPro' can sample the same data, over 30 sensors, in less than 25ms. I've exchanged some emails with the author and it is a native C, polling, no events just timeouts. Kusta thanks for the FTDI notice, I believe that is tunable, however I have a particular user using a Keyspan converter and verified sampling rate with 'TunerPro' and its just off the charts. Chris thank you, I'll look into the queing. On 03/07/11 23:02, Bob Jacobsen wrote: > If you're transferring three bytes total at 1953 baud, it's going to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to wait 20msec to get the data back instead of 15.4 msec doesn't seem to be as big a problem as you're making it sound. > > Bob > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > >> I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. >> >> To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. >> >> So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. >> >> in.read(data, 0, 2); >> ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? >> >> On 03/07/11 18:50, jfh at greenhousepc.com wrote: >>> Curtis, >>> >>> No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. >>> -- >>> Julie Haugh >>> Senior Design Engineer >>> greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype From msemtd at googlemail.com Tue Mar 8 01:50:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 8 Mar 2011 08:50:15 +0000 Subject: [Rxtx] Latency Woes In-Reply-To: <4D75E9D4.5090307@gmail.com> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> <4D75E9D4.5090307@gmail.com> Message-ID: On 8 March 2011 08:33, Curtis Hacker wrote: > I am going to try a couple things today and hopefully figure something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than 25ms. > I've exchanged some emails with the author and it is a native C, polling, no > events just timeouts. Perhaps the author of TunerPro will let you use his native code - sounds just what you need. Regards, Michael Erskine. From jfh at greenhousepc.com Tue Mar 8 04:00:18 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 04:00:18 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 12:33:35 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 11:33:35 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> Message-ID: <4D76848F.5080809@gmail.com> Cable schematic: http://i1106.photobucket.com/albums/h377/vigilart/jackal%20logging%20set%20up/RS232SCHEMATIC.jpg 0.00268554 TunerPro.exe IOCTL_SERIAL_SET_BAUD_RATE VCP0 SUCCESS Rate: 1952 0.00305178 TunerPro.exe IOCTL_SERIAL_SET_RTS VCP0 SUCCESS 0.00297524 TunerPro.exe IOCTL_SERIAL_SET_DTR VCP0 SUCCESS 0.00297384 TunerPro.exe IOCTL_SERIAL_SET_LINE_CONTROL VCP0 SUCCESS StopBits: 1 Parity: NONE WordLength: 8 0.00000335 TunerPro.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 0.00202540 TunerPro.exe IOCTL_SERIAL_SET_HANDFLOW VCP0 SUCCESS Shake:1 Replace:40 XonLimit:2048 XoffLimit:512 0.00000335 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:300 RM:0 RC:2000 WM:0 WC:110 0.00000279 TunerPro.exe IOCTL_SERIAL_SET_QUEUE_SIZE VCP0 SUCCESS InSize: 1024 OutSize: 512 0.00000307 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000279 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:300 RM:0 RC:2000 WM:0 WC:110 0.00000307 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:75 RM:0 RC:400 WM:0 WC:300 0.00000559 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: RXCLEAR 0.00000335 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: TXCLEAR 0.00064980 TunerPro.exe IRP_MJ_WRITE VCP0 SUCCESS Length 1: . 0.01498738 TunerPro.exe IRP_MJ_READ VCP0 SUCCESS Length 1: . 0.00000363 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:200 RM:0 RC:20 WM:0 WC:300 0.02042774 TunerPro.exe IRP_MJ_READ VCP0 TIMEOUT Length 0: That is time on the left side. Now I'm with you on timing, it doesn't make a lot of sense, but that is how the logs come out. You can view the logs yourself. Tunerpro log : http://www.ds-map.net/tunerpro_log.csv My apps log : http://www.ds-map.net/my_log.csv 2nd app log : http://www.ds-map.net/my_log2.csv All these logs, were done from the same car, same cable. I have some older logs with some palm software, that was 13 sensors, and had a total 45-55ms between each set of 13. More info about the car / ecu at http://mmcdlogger.sourceforge.net Disassembly on the ecu: [SS1:SS0] is baud rate divider, 00(16) 01(128) 10(1024) 11(4096), assuming basic clock of 2MHZ, we get 125000baud, 15625baud, 1953baud, 488baud In any event, I attempted a no sleep thread, that waited till in.available > 1, and it wasn't any faster than running the events. Then I tried a read write thread, that slept from 1ms to 30ms after it wrote (so it wouldn't read what it just wrote). And couldn't get it doing much. I wish I had more of an understanding of all of this, which is why I'm asking for help. On 03/08/11 03:00, jfh at greenhousepc.com wrote: > Curtis, > > At the risk of being told "No, they really say it can be done", 30 > sensors is 30 * 3 character times (are you sure it's not a single byte > response?). At 1953 baud, a single character time is 10 bits * (1 / > 1953) seconds, or 15.4ms as Bob pointed out. 30 * 15.4ms is 460ms, > and that assumes everything works perfectly, no turnaround times, etc. > > If you can come up with some other way to make the math work, I'd love > to hear it. > > Short and sweet -- just because TunerPro can talk to an ECM/ECU that > is running faster than 1953 baud doesn't mean your Mitsubishi (or > whatever car you've got that runs at 1953 baud) runs at that faster > baud rate. > > Also, are you sure your data cable is correct? What cable are you > using? What's the schematic? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 2:33 am > To: rxtx at qbang.org > > I am going to try a couple things today and hopefully figure > something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than > 25ms. > I've exchanged some emails with the author and it is a native C, > polling, no events just timeouts. > > Kusta thanks for the FTDI notice, I believe that is tunable, > however I > have a particular user using a Keyspan converter and verified > sampling > rate with 'TunerPro' and its just off the charts. > > Chris thank you, I'll look into the queing. > > On 03/07/11 23:02, Bob Jacobsen wrote: > > If you're transferring three bytes total at 1953 baud, it's going > to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to > wait 20msec to get the data back instead of 15.4 msec doesn't seem > to be as big a problem as you're making it sound. > > > > Bob > > > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > > > >> I guess I'm gunna need some serious help with this then, because > of the scenario I'm stuck with. > >> > >> To communicate there is only 1 data line, rx/tx tied together > with a diode protecting the tx. No RTS/CTS handshaking nothing.. > >> > >> So the ecu can't process the next byte of info, without you > pulling the 2 bytes back. I wish this was standard, but even the > baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard > spot with this.. > >> > >> in.read(data , 0, 2); > >> ^ would the above wait till the timeout to read 2 bytes ? or > read 1 byte wait for the 2nd ? or just read the 1 ?? > >> > >> On 03/07/11 18:50, jfh at greenhousepc.com > wrote: > >>> Curtis, > >>> > >>> No, I assume he means a real queue, not just "don't read all > the bytes at once." However, if you know you can process some > number of requests in some amount of time, allowing data to pile > up (receiver FIFO space permitting) can be a valid strategy. > Inserting gobs of Thread.yield() and notify() can help pep things > up as well. > >>> -- > >>> Julie Haugh > >>> Senior Design Engineer > >>> greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 13:12:03 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 12:12:03 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> Message-ID: <4D768D93.1030504@gmail.com> So I looked over the Tunerpro log again today.. is it me or does it appear to be reusing values ? On 03/08/11 03:00, jfh at greenhousepc.com wrote: > Curtis, > > At the risk of being told "No, they really say it can be done", 30 > sensors is 30 * 3 character times (are you sure it's not a single byte > response?). At 1953 baud, a single character time is 10 bits * (1 / > 1953) seconds, or 15.4ms as Bob pointed out. 30 * 15.4ms is 460ms, > and that assumes everything works perfectly, no turnaround times, etc. > > If you can come up with some other way to make the math work, I'd love > to hear it. > > Short and sweet -- just because TunerPro can talk to an ECM/ECU that > is running faster than 1953 baud doesn't mean your Mitsubishi (or > whatever car you've got that runs at 1953 baud) runs at that faster > baud rate. > > Also, are you sure your data cable is correct? What cable are you > using? What's the schematic? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 2:33 am > To: rxtx at qbang.org > > I am going to try a couple things today and hopefully figure > something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than > 25ms. > I've exchanged some emails with the author and it is a native C, > polling, no events just timeouts. > > Kusta thanks for the FTDI notice, I believe that is tunable, > however I > have a particular user using a Keyspan converter and verified > sampling > rate with 'TunerPro' and its just off the charts. > > Chris thank you, I'll look into the queing. > > On 03/07/11 23:02, Bob Jacobsen wrote: > > If you're transferring three bytes total at 1953 baud, it's going > to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to > wait 20msec to get the data back instead of 15.4 msec doesn't seem > to be as big a problem as you're making it sound. > > > > Bob > > > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > > > >> I guess I'm gunna need some serious help with this then, because > of the scenario I'm stuck with. > >> > >> To communicate there is only 1 data line, rx/tx tied together > with a diode protecting the tx. No RTS/CTS handshaking nothing.. > >> > >> So the ecu can't process the next byte of info, without you > pulling the 2 bytes back. I wish this was standard, but even the > baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard > spot with this.. > >> > >> in.read(data , 0, 2); > >> ^ would the above wait till the timeout to read 2 bytes ? or > read 1 byte wait for the 2nd ? or just read the 1 ?? > >> > >> On 03/07/11 18:50, jfh at greenhousepc.com > wrote: > >>> Curtis, > >>> > >>> No, I assume he means a real queue, not just "don't read all > the bytes at once." However, if you know you can process some > number of requests in some amount of time, allowing data to pile > up (receiver FIFO space permitting) can be a valid strategy. > Inserting gobs of Thread.yield() and notify() can help pep things > up as well. > >>> -- > >>> Julie Haugh > >>> Senior Design Engineer > >>> greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 13:51:13 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 13:51:13 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308135113.8ef0e5b4a80cef441275a6330ffad77d.a5fff5bbc7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From bob_jacobsen at lbl.gov Tue Mar 8 14:14:57 2011 From: bob_jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 8 Mar 2011 14:14:57 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D76848F.5080809@gmail.com> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> Message-ID: <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > Tunerpro log : http://www.ds-map.net/tunerpro_log.csv It's only reading one sensor per line. Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT changed in lines 16 and 40; every 24 lines but at a different phase. GramsRev in lines 23 and 47; every 24 lines, at yet another phase. Looks like (69-1) readings in 1.30 seconds = 19msec per reading. Arithmetic still works! Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From hakcenter at gmail.com Tue Mar 8 14:27:12 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 13:27:12 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> Message-ID: <4D769F30.9050807@gmail.com> Thank you guys, cause I was really worried there. I guess another win for math today hahaha. So what is the imposed latency that rxtx has ? maybe 5-10ms ? On 03/08/11 13:14, Bob Jacobsen wrote: > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > It's only reading one sensor per line. > > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT changed in lines 16 and 40; every 24 lines but at a different phase. GramsRev in lines 23 and 47; every 24 lines, at yet another phase. > > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. Arithmetic still works! > > Bob > -- > Bob Jacobsen, LBNL > Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue Mar 8 14:07:24 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Mar 2011 14:07:24 -0700 (MST) Subject: [Rxtx] Latency Woes In-Reply-To: <4D769F30.9050807@gmail.com> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> <4D769F30.9050807@gmail.com> Message-ID: Hi Curtis While not your exact question, a simple test I performed can give you a ballpark idea. Writing a byte to a loopback at 9600 baud and displaying elapsed time on the data available event takes ~10 ms round trip in a large application. There are occasional 20 ms latencies. I used a typical linux desktop to try it just now without any special considerations. Windows NT was a little faster - maybe 8 ms - when I tried several years ago. On Tue, 8 Mar 2011, Curtis Hacker wrote: > Thank you guys, cause I was really worried there. I guess another win for > math today hahaha. So what is the imposed latency that rxtx has ? maybe > 5-10ms ? > > On 03/08/11 13:14, Bob Jacobsen wrote: >> On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >>> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> It's only reading one sensor per line. >> >> Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT >> changed in lines 16 and 40; every 24 lines but at a different phase. >> GramsRev in lines 23 and 47; every 24 lines, at yet another phase. >> >> Looks like (69-1) readings in 1.30 seconds = 19msec per reading. >> Arithmetic still works! >> >> Bob >> -- >> Bob Jacobsen, LBNL >> Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >> JacobsenRG >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Wei.Shen at Honeywell.com Tue Mar 8 15:15:32 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Tue, 8 Mar 2011 17:15:32 -0500 Subject: [Rxtx] [rxtx] disconnect event Message-ID: <83B3B1411349194D9D05821CEF48E78C02284B17@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 16:05:12 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 16:05:12 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 16:26:15 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 15:26:15 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> References: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> Message-ID: <4D76BB17.2090305@gmail.com> So if I could get the baud up 15625, theoretical maximum latency is 1.92ms ? Basically 500 samples/sec ? 125000, theoretical maximum latency is 0.24ms ? Basically 4167 samples/sec ? Keeping the protocol the same. On 03/08/11 15:05, jfh at greenhousepc.com wrote: > Curtis, > > It's nowhere near that bad. I'd measured it once before, and I > believe it's sub-millisecond. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 3:27 pm > To: rxtx at qbang.org > > Thank you guys, cause I was really worried there. I guess another win > for math today hahaha. So what is the imposed latency that rxtx has ? > maybe 5-10ms ? > > On 03/08/11 13:14, Bob Jacobsen wrote: > > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > > It's only reading one sensor per line. > > > > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 > lines. IAT changed in lines 16 and 40; every 24 lines but at a > different phase. GramsRev in lines 23 and 47; every 24 lines, at > yet another phase. > > > > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. > Arithmetic still works! > > > > Bob > > -- > > Bob Jacobsen, LBNL > > Bob_Jacobsen at lbl.gov > +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Tue Mar 8 17:40:36 2011 From: jredman at ergotech.com (Jim Redman) Date: Tue, 08 Mar 2011 17:40:36 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D76BB17.2090305@gmail.com> References: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> <4D76BB17.2090305@gmail.com> Message-ID: <4D76CC84.9040307@ergotech.com> How long does it take the device to generate a response? Increasing the baud rate may not help you much if the device takes a significant amount of time to process the request. On 03/08/2011 04:26 PM, Curtis Hacker wrote: > So if I could get the baud up > 15625, theoretical maximum latency is 1.92ms ? Basically 500 samples/sec ? > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 samples/sec ? > > Keeping the protocol the same. > > On 03/08/11 15:05, jfh at greenhousepc.com wrote: >> Curtis, >> >> It's nowhere near that bad. I'd measured it once before, and I >> believe it's sub-millisecond. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker > >> Date: Tue, March 08, 2011 3:27 pm >> To: rxtx at qbang.org >> >> Thank you guys, cause I was really worried there. I guess another win >> for math today hahaha. So what is the imposed latency that rxtx has ? >> maybe 5-10ms ? >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> > It's only reading one sensor per line. >> > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 >> lines. IAT changed in lines 16 and 40; every 24 lines but at a >> different phase. GramsRev in lines 23 and 47; every 24 lines, at >> yet another phase. >> > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. >> Arithmetic still works! >> > >> > Bob >> > -- >> > Bob Jacobsen, LBNL >> > Bob_Jacobsen at lbl.gov >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 jfh at greenhousepc.com Tue Mar 8 17:58:24 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 17:58:24 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 18:06:04 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 18:06:04 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 18:14:14 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 17:14:14 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> References: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> Message-ID: <4D76D466.7060303@gmail.com> I can edit the ECU eeprom to change the baud rate divisor to bump it up from 1953, to 15625 or 125000. But as Jim asked how fast the device can respond.. not very fast in its stock form. I can recode a lot of the eeprom for the ecu to alter the ecus baud rate, and put the response code into its own interrupt. I just wanted to make sure that in order to lower latency and increase sampling rate. I have to increase the baud rate of the ecu and the user right ? Or change the protocol.. to respond with more sensors per request. On 03/08/11 16:58, jfh at greenhousepc.com wrote: > Unless the ECU can auto-detect the baud rate, it won't even work. > > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Jim Redman > > Date: Tue, March 08, 2011 6:40 pm > To: rxtx at qbang.org > > How long does it take the device to generate a response? > > Increasing the baud rate may not help you much if the device takes a > significant amount of time to process the request. > > > On 03/08/2011 04:26 PM, Curtis Hacker wrote: > > So if I could get the baud up > > 15625, theoretical maximum latency is 1.92ms ? Basically 500 > samples/sec ? > > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 > samples/sec ? > > > > Keeping the protocol the same. > > > > On 03/08/11 15:05, jfh at greenhousepc.com > wrote: > >> Curtis, > >> > >> It's nowhere near that bad. I'd measured it once before, and I > >> believe it's sub-millisecond. > >> -- > >> Julie Haugh > >> Senior Design Engineer > >> greenHouse Computers, LLC // jfh at greenhousepc.com > > >> ; // > greenHousePC on Skype > >> > >> > >> -------- Original Message -------- > >> Subject: Re: [Rxtx] Latency Woes > >> From: Curtis Hacker > > >> Date: Tue, March 08, 2011 3:27 pm > >> To: rxtx at qbang.org > >> > >> Thank you guys, cause I was really worried there. I guess > another win > >> for math today hahaha. So what is the imposed latency that rxtx > has ? > >> maybe 5-10ms ? > >> > >> On 03/08/11 13:14, Bob Jacobsen wrote: > >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > >> > It's only reading one sensor per line. > >> > > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 > >> lines. IAT changed in lines 16 and 40; every 24 lines but at a > >> different phase. GramsRev in lines 23 and 47; every 24 lines, at > >> yet another phase. > >> > > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. > >> Arithmetic still works! > >> > > >> > Bob > >> > -- > >> > Bob Jacobsen, LBNL > >> > Bob_Jacobsen at lbl.gov > > >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > >> > > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Tue Mar 8 18:19:14 2011 From: jredman at ergotech.com (Jim Redman) Date: Tue, 08 Mar 2011 18:19:14 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> References: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> Message-ID: <4D76D592.9000802@ergotech.com> I'm no expert on this, but isn't the underlying ODB-II CAN bus or something similar. They always seem to require a dongle that converts to something. I know you can get serial, bluetooth, USB, etc. converters. I've seen serial dongles that claim multiple baud rates, so I suspect that whatever's providing the conversion may significantly affect the performance. A big second on the required timing comment. I suspect some intelligent consideration of what values change quickly (RPM, Speed, maybe things like fuel pressure) and read values like fuel levels, coolant temps, etc. much less frequently. On 03/08/2011 06:06 PM, jfh at greenhousepc.com wrote: > Curtis, > > You can't just increase the baud rate and have the device adapt to that > rate. Embedded systems tend to have their communications parameters > either hard coded in a memory location or else they are using a hardware > timebase. You're welcome to try increasing the baud rate, but there is > no guarantee it will even work. > > Whoever designed the ECU probably selected the baud rate for a good > reason. My suggestion would be to look at how the sensor values are all > laid out and go from there. Also, look at what the sensor represent and > consider the physical properties of what is being measured. It's > extremely unlikely that, for example, the coolant temperature is going > to rise more than 1* per second. If that much. Some values might change > more often, but do they really matter on a sub-second measurement basis? > > Part of software =engineering= is understanding the problem. Anyone can > sling code in the hope it works. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 5:26 pm > To: rxtx at qbang.org > > So if I could get the baud up > 15625, theoretical maximum latency is 1.92ms ? Basically 500 > samples/sec ? > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 > samples/sec ? > > Keeping the protocol the same. > > On 03/08/11 15:05, jfh at greenhousepc.com wrote: >> Curtis, >> >> It's nowhere near that bad. I'd measured it once before, and I >> believe it's sub-millisecond. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker > > >> Date: Tue, March 08, 2011 3:27 pm >> To: rxtx at qbang.org >> >> Thank you guys, cause I was really worried there. I guess >> another win >> for math today hahaha. So what is the imposed latency that >> rxtx has ? >> maybe 5-10ms ? >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> > It's only reading one sensor per line. >> > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every >> 24 lines. IAT changed in lines 16 and 40; every 24 lines but >> at a different phase. GramsRev in lines 23 and 47; every 24 >> lines, at yet another phase. >> > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per >> reading. Arithmetic still works! >> > >> > Bob >> > -- >> > Bob Jacobsen, LBNL >> > Bob_Jacobsen at lbl.gov >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > ------------------------------------------------------------------------ > _______________________________________________ > Rxtx mailing list > Rxtx 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 jfh at greenhousepc.com Tue Mar 8 18:32:28 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 18:32:28 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 19:45:00 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 18:45:00 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> References: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> Message-ID: <4D76E9AC.8050909@gmail.com> Julie, I really am not looking at the practicality of it. I was just wondering if that is how it works. I don't know a whole lot about rs232, which is the main reason I've been on this mailing list for a couple years. I have full control over the ecu eeprom code, I can change its baud rate, I can re-write the logging interface, I could update the ADC's on the ecu in the interface so that when you request said sensor it updates the ADC then replies it. But I wanted to know if the underlying issue with a 2mhz/8mhz processor is the baud rate keeping sampling down ? On 03/08/11 17:32, jfh at greenhousepc.com wrote: > Curtis, > > You also have to look at the response time of the sensor itself. > > Seriously -- look at what the sensors are reporting and determine if > the underlying physical property can actually change that rapidly. > And even if it can, do you really need to know that. > > I built drag bikes in the 70's and I drive sports cars in my old age. > You don't really need millisecond sampling rates for every single last > sensor coming out of the engine. Boost pressure, fuel pressure, > manifold pressure and RPMs are probably high frequency sensors if you > want to tweak the motor for turbo lag or something, but other than > that, are you really going to be able to make sense of all that data? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 7:14 pm > To: rxtx at qbang.org > > I can edit the ECU eeprom to change the baud rate divisor to bump > it up from 1953, to 15625 or 125000. But as Jim asked how fast the > device can respond.. not very fast in its stock form. > > I can recode a lot of the eeprom for the ecu to alter the ecus > baud rate, and put the response code into its own interrupt. > > I just wanted to make sure that in order to lower latency and > increase sampling rate. I have to increase the baud rate of the > ecu and the user right ? Or change the protocol.. to respond with > more sensors per request. > > On 03/08/11 16:58, jfh at greenhousepc.com wrote: >> Unless the ECU can auto-detect the baud rate, it won't even work. >> >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Jim Redman > > >> Date: Tue, March 08, 2011 6:40 pm >> To: rxtx at qbang.org >> >> How long does it take the device to generate a response? >> >> Increasing the baud rate may not help you much if the device >> takes a >> significant amount of time to process the request. >> >> >> On 03/08/2011 04:26 PM, Curtis Hacker wrote: >> > So if I could get the baud up >> > 15625, theoretical maximum latency is 1.92ms ? Basically 500 >> samples/sec ? >> > 125000, theoretical maximum latency is 0.24ms ? Basically >> 4167 samples/sec ? >> > >> > Keeping the protocol the same. >> > >> > On 03/08/11 15:05, jfh at greenhousepc.com >> wrote: >> >> Curtis, >> >> >> >> It's nowhere near that bad. I'd measured it once before, and I >> >> believe it's sub-millisecond. >> >> -- >> >> Julie Haugh >> >> Senior Design Engineer >> >> greenHouse Computers, LLC // jfh at greenhousepc.com >> >> >> ; // >> greenHousePC on Skype >> >> >> >> >> >> -------- Original Message -------- >> >> Subject: Re: [Rxtx] Latency Woes >> >> From: Curtis Hacker > > >> >> Date: Tue, March 08, 2011 3:27 pm >> >> To: rxtx at qbang.org >> >> >> >> >> Thank you guys, cause I was really worried there. I guess >> another win >> >> for math today hahaha. So what is the imposed latency that >> rxtx has ? >> >> maybe 5-10ms ? >> >> >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> >> > It's only reading one sensor per line. >> >> > >> >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; >> every 24 >> >> lines. IAT changed in lines 16 and 40; every 24 lines but at a >> >> different phase. GramsRev in lines 23 and 47; every 24 >> lines, at >> >> yet another phase. >> >> > >> >> > Looks like (69-1) readings in 1.30 seconds = 19msec per >> reading. >> >> Arithmetic still works! >> >> > >> >> > Bob >> >> > -- >> >> > Bob Jacobsen, LBNL >> >> > Bob_Jacobsen at lbl.gov >> >> >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Rxtx mailing list >> >> > Rxtx at qbang.org >> >> >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > ------------------------------------------------------------------------ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 20:43:11 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 20:43:11 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308204311.8ef0e5b4a80cef441275a6330ffad77d.e9b135168c.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From andrea.antonello at gmail.com Wed Mar 9 06:50:07 2011 From: andrea.antonello at gmail.com (andrea antonello) Date: Wed, 9 Mar 2011 14:50:07 +0100 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> References: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> Message-ID: Has anyone tried the lib? I am not sure if it is appropriate to write to the list about this, if not, I apologize. I wanted to try your fork out for our application which is an eclipse rcp plugin based one. It has been easy to substitute the 6 plugins with your library (that is one of the things I like). But then when I run it, it tries to load it from: ---- Loading: /tmp/libNRJavaSerial_moovida_0/libNRJavaSerial.so Trying to load: NRJavaSerial Trying to load: libNRJavaSerial Trying to load: rxtxSerial ---- So it is extracting the native lib to a tmp folder. But that one is not in the library path, so it fails. Is there any docs to try the lib out? Thanks, Andrea On Mon, Mar 7, 2011 at 11:54 PM, wrote: > Aaron, > > It should be possible for an Android to do BlueTooth serial.? If I were > looking for a serial solution, that's how I'd go. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on > Skype > > -------- Original Message -------- > Subject: [SPAM] Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > papercuts! > From: Aaron Wolfe > Date: Mon, March 07, 2011 4:31 pm > To: rxtx at qbang.org > > On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR > wrote: >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> >> * Self deployment of native libraries ( all native code is stored >> inside the jar and deployed at runtime). No more manual install of >> native code. >> * Arm Cortex support (Gumstix) >> * Android Support (requires a rooted phone for now) >> * Google Code (SVN) repository for easy code and jar access >> * Single makefile compile (simplifies the compilation of project binaries) >> * Ant build script for jar creation >> * Removal of partialy implemented code to streamline the lib for just >> serial port access >> * Full Eclipse integration, for testing application code against sources. >> >> And a bunch of bug fixes: >> >> * Fixed the memory access error that causes OSX to crash the JVM when >> serial.close() is cvalled >> * Fixed the windows serial port zombie bind that prevents re-accessing >> serial ports when exiting on an exception >> * Fixed erronious printouts of native library mis-match >> >> To check it out, take a look at our page here: >> >> http://code.google.com/p/nrjavaserial/ > > This is interesting, getting the native libs set up has been an issue > for some of my users. Will have to check it out. > > Out of curiosity, what Android devices provide a serial port? Or are > there some that allow USB host mode and then a usb-serial adapter? I > have only an Android cell phone, don't think it can do anything serial > but would love to be wrong 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 Cougar at CasaDelGato.Com Wed Mar 9 10:02:24 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 09 Mar 2011 09:02:24 -0800 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> References: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> Message-ID: <4D77B2A0.8020004@CasaDelGato.Com> On 3/7/2011 2:54 PM, jfh at greenhousepc.com wrote: > Aaron, > > It should be possible for an Android to do BlueTooth serial. If I > were looking for a serial solution, that's how I'd go. Actually, I can't figure out WHY you would need RxTx on an Android device. The built in bluetooth support works just fine with a serial-bluetooth converter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Mar 1 00:54:17 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 09:54:17 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> Message-ID: Adrian, had a look at your code/rewrite and it looks rather clean/nice. I was looking at the code to gain insight (not related to the rewrite) into what is involved in serial port programming in Windows. Or rather, to refresh my memory and see how others have done, because I've been there done that. So my questions are just to satisfy my curiosity, not to criticize or suggest improvements. 1) It looks like a new thread (EventMonitor) is created for each Serial port, is that correct? Many people seem to try to avoid using many threads in this sort of situation, and like to use something like unix select(). I personally find using threads more natural and better impedance match to the problem being solved here. I guess 'many people' above refers to those implementing thousands of connections and who cannot live with the overhead and limited number of threads available. 2) The EventMonitor basically polls for events at 50 msec interval? 3) There is a comment in the source code near the sleep(50) : // Sufficient up to 19200 baud I'm sure you thought about this carefully, so again not criticizing, but seeking to understand how or why, because at 50 msec would seem to limit through in some cases. Like if you send one byte and need to wait for one to return, then this limits speed to 200 chars/sec? 4) I've done something similar to a few years back from Java using JNI to access Win32 API serial port, and I seem to recall that I had threading issues ie when I submitted a read (ReadFile) and there was no data coming in, the thread would not only block but also consume a lot of CPU cycles ie it was not sleeping properly inside the ReadFile call when the serial port blocked. Im a bit fuzzy about the details after five years, so my question is have you checked if there an issue here? 5) AFAIK the select() on Windows does not work serial ports but there is some other mechanism (events?) to implement the same functionality, did you consider that? Probably, so you decided against it, why? br Kusti From adrian.crum at sandglass-software.com Tue Mar 1 04:13:34 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:13:34 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: References: Message-ID: <4D6CD4DE.7040501@sandglass-software.com> The javax.comm API specification requires one event monitor thread per port. I don't like the idea of having a thread per port either, but one of the rewrite's design goals is strict conformance to the specification. The 50 mS polling interval is just a placeholder. The final design of that is yet to be decided. In Windows, you have two choices for I/O: overlapped and non-overlapped. In overlapped I/O a thread is blocked, waiting for something to happen. In non-overlapped I/O a thread does not block. I chose non-overlapped I/O to avoid thread blocking at the OS level - instead, the thread blocking is kept in Java. -Adrian On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > Adrian, > > had a look at your code/rewrite and it looks rather clean/nice. > > I was looking at the code to gain insight (not related to the > rewrite) into what is involved in serial port programming > in Windows. Or rather, to refresh my memory and see how others have > done, because I've been there done that. > > So my questions are just to satisfy my curiosity, not to criticize > or suggest improvements. > > 1) It looks like a new thread (EventMonitor) is created for > each Serial port, is that correct? > > Many people seem to try to avoid using many threads in this sort > of situation, and like to use something like unix select(). > I personally find using threads more natural and better impedance > match to the problem being solved here. I guess 'many people' above > > refers to those implementing thousands of connections and > who cannot live with the overhead and limited number of threads > available. > > 2) The EventMonitor basically polls for events at 50 msec interval? > > 3) There is a comment in the source code near the sleep(50) : > > // Sufficient up to 19200 baud > > > I'm sure you thought about this carefully, so again not > criticizing, but seeking to understand how or why, because > at 50 msec would seem to limit through in some cases. Like > if you send one byte and need to wait for one to return, > then this limits speed to 200 chars/sec? > > 4) I've done something similar to a few years back from > Java using JNI to access Win32 API serial port, and > I seem to recall that I had threading issues ie when > I submitted a read (ReadFile) and there was no data coming > in, the thread would not only block but also consume a > lot of CPU cycles ie it was not sleeping properly inside > the ReadFile call when the serial port blocked. > > Im a bit fuzzy about the details after five years, so my question is > have you checked if there an issue here? > > > 5) AFAIK the select() on Windows does not work serial ports > but there is some other mechanism (events?) to implement the > same functionality, did you consider that? Probably, so you > decided against it, why? > > > br Kusti > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Tue Mar 1 04:25:23 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:25:23 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C2E90.9010601@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > My question would be: Why would you do that? The rewrite does > most of the work for you - all you have to do is implement > two C++ virtual classes and two C++ functions. You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? I just took a short look, maybe it could be discussed further, but I don't think I like it much. BTW, the main interface defined there is called gnu.io.Dispatcher? I thought the package names should be used in a way to avoid clashes, e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name space authority :)). > In Windows that took me a few hours. where is the implementation? I found commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp with things like const bool SerialPortImpl::isDataAvailable() const { // Needs implementation return true; } and timeouts.ReadIntervalTimeout = MAXDWORD;* timeouts.ReadTotalTimeoutMultiplier = 0; timeouts.ReadTotalTimeoutConstant = 0; timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 0; if (!SetCommTimeouts(hComm, &timeouts)) throw IOException(); which seems to be oversimplified or some prototype only? I think (and I wrote about this already in the past years) that correct timeout handling is one of the challenges, so I think this should be prototyped first - for each system flavor - before cementation of the (JNI-) interfaces. Personally, I would vote to form it in a way allowing to be implemented on embedded devices, for example. Another big challenge is to prove a rewrite fully working (and probably compatible to the old implementation) on "all" the supported OSes. Not a big problem for linux and windows, just use some thousand lines test code, test drivers and serial loopbacks etc, but for the exotic platforms, probably a high number of, this probably won't be too easy... (there are more challenges, such as being comfortable and threadsafe [are read and write permitted at the same time?], detailed and helpful exceptions on user API level [not necessarily on JNI/JNA layer], how to have a configurable threadsafe logging/tracing [maybe also from native code to assist porting / testing on exotic OSes, such as OSes where the developers have no direct access too, which can be quite hard to usually leads to good log messages], just to name a few.). So even it might seem easy for one platform and I agree with Micheal that > > * yay! let's start a rewrite is unlikely to succeede soon... However, when considering this, before IMHO a powerful Java API has to be defined, because according to my experiences for implementing non-trivial protocols InputStream/OutputStream might not be comfortable/powerfull enough (eventually I consider both wrong) and have some InputStream derivation available as wrapper (so applications can use InputStream and whatever high-level-API they want). The JNI interface shall make such a powerful implementation possible, thus the interface of it is driving the JNI interface design and thus I think it had to be done first. All this surely requires much work: agreements on the APIs, safeness for the users, design, documentation, all the implementations and the testing. As long as such bug amount of work cannot be spent, for example if some employee would get half a year time paid for it or so :-), probably it is unlikely to progress on this. Otherwise, I'm afraid, patches, improvements, new design ideas and even rewrites wouldn't become complete and thus won't form a new rxtx version (3.0); thus either collect dust in some forgotten CVS branch or could generate a split... > I can't imagine other ports taking > much longer than that - especially since POSIX-based code can > be shared between ports. Things are more complex than they seem to be... I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select on serial ports isn't supported; maybe it is non-trivial to "map" (like mapping select() to WaitForMultipleObjects() which might have different semantics etc.) or maybe some different approach has to be used. A system may have POSIX like termios interfaces but not support timeouts or have any other interoperability bug... You never run out of things that can go wrong. And if something can go wrong, it will... :-) Or, as Michael wrote: > > I seriously don't believe anyone will come up with anything better anytime soon. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue Mar 1 04:39:37 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:39:37 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com><13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED6B@COSNPREXC3.usr.ingenico.loc> > 3. Write all of the native (or non-native) code to implement > the native interface. > > Is that correct? If yes, how is that easier than the simple > implementation the current rewrite design uses? To have it complete, reliable, traceable, maintainable and well tested, it is much more work, I'm afraid. A prototype can be done within a few days (maybe on one day), but getting it right (including a passed review) IMHO is a completely different story. In the end you may end up with an average of ten lines per day, when assuming four major native packs (common, win, mac, termios/select) with let's say just 5000 lines each (with logging messages and detailed exceptions this is not much) we would have to estimate a total effort of nine man-years (20000/10/220)... oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 04:40:18 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:40:18 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6CDB22.9070401@sandglass-software.com> Every journey begins with a single step. -Adrian On 3/1/2011 3:25 AM, Steffen DETTMER wrote: > * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> My question would be: Why would you do that? The rewrite does >> most of the work for you - all you have to do is implement >> two C++ virtual classes and two C++ functions. > You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? > I just took a short look, maybe it could be discussed further, > but I don't think I like it much. > BTW, the main interface defined there is called gnu.io.Dispatcher? > I thought the package names should be used in a way to avoid clashes, > e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name > space authority :)). > >> In Windows that took me a few hours. > where is the implementation? > I found > commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp > with things like > > const bool SerialPortImpl::isDataAvailable() const > { > // Needs implementation > return true; > } > > and > > timeouts.ReadIntervalTimeout = MAXDWORD;* > timeouts.ReadTotalTimeoutMultiplier = 0; > timeouts.ReadTotalTimeoutConstant = 0; > timeouts.WriteTotalTimeoutMultiplier = 0; > timeouts.WriteTotalTimeoutConstant = 0; > if (!SetCommTimeouts(hComm,&timeouts)) > throw IOException(); > > which seems to be oversimplified or some prototype only? > > I think (and I wrote about this already in the past years) that correct > timeout handling is one of the challenges, so I think this should be > prototyped first - for each system flavor - before cementation of the > (JNI-) interfaces. Personally, I would vote to form it in a way allowing > to be implemented on embedded devices, for example. > > Another big challenge is to prove a rewrite fully working (and probably > compatible to the old implementation) on "all" the supported OSes. Not a > big problem for linux and windows, just use some thousand lines test > code, test drivers and serial loopbacks etc, but for the exotic > platforms, probably a high number of, this probably won't be too easy... > (there are more challenges, such as being comfortable and threadsafe > [are read and write permitted at the same time?], detailed and helpful > exceptions on user API level [not necessarily on JNI/JNA layer], how to > have a configurable threadsafe logging/tracing [maybe also from native > code to assist porting / testing on exotic OSes, such as OSes where the > developers have no direct access too, which can be quite hard to usually > leads to good log messages], just to name a few.). > > So even it might seem easy for one platform and I agree with Micheal > that > >>> * yay! let's start a rewrite > is unlikely to succeede soon... > > However, when considering this, before IMHO a powerful Java API has to > be defined, because according to my experiences for implementing > non-trivial protocols InputStream/OutputStream might not be > comfortable/powerfull enough (eventually I consider both wrong) and have > some InputStream derivation available as wrapper (so applications can > use InputStream and whatever high-level-API they want). > The JNI interface shall make such a powerful implementation possible, > thus the interface of it is driving the JNI interface design and thus I > think it had to be done first. > > All this surely requires much work: agreements on the APIs, safeness for > the users, design, documentation, all the implementations and the > testing. As long as such bug amount of work cannot be spent, for example > if some employee would get half a year time paid for it or so :-), > probably it is unlikely to progress on this. > > Otherwise, I'm afraid, patches, improvements, new design ideas and even > rewrites wouldn't become complete and thus won't form a new rxtx version > (3.0); thus either collect dust in some forgotten CVS branch or could > generate a split... > >> I can't imagine other ports taking >> much longer than that - especially since POSIX-based code can >> be shared between ports. > Things are more complex than they seem to be... > > I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select > on serial ports isn't supported; maybe it is non-trivial to "map" (like > mapping select() to WaitForMultipleObjects() which might have different > semantics etc.) or maybe some different approach has to be used. A > system may have POSIX like termios interfaces but not support timeouts > or have any other interoperability bug... > You never run out of things that can go wrong. And if something can go > wrong, it will... :-) > > Or, as Michael wrote: > >>> I seriously don't believe anyone will come up with anything better > anytime soon. > > oki, > > Steffen > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Kustaa.Nyholm at planmeca.com Tue Mar 1 04:57:02 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 13:57:02 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: On 3/1/11 13:13, "Adrian Crum" wrote: >The javax.comm API specification requires one event monitor thread per >port. I don't like the idea of having a thread per port either, but one >of the rewrite's design goals is strict conformance to the specification. Ah, had not spotted that requirement. > >The 50 mS polling interval is just a placeholder. The final design of >that is yet to be decided. > >In Windows, you have two choices for I/O: overlapped and non-overlapped. >In overlapped I/O a thread is blocked, waiting for something to happen. >In non-overlapped I/O a thread does not block. I chose non-overlapped >I/O to avoid thread blocking at the OS level - instead, the thread >blocking is kept in Java. > >-Adrian thanks for the explanation. br Kusti From iqzw2r602 at sneakemail.com Tue Mar 1 05:08:17 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:08:17 +1100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <32684-1298981297-704398@sneakemail.com> This reminds me of a nasty problem I had with overlapped I/O on windows with jpathwatch. You can't start an I/O request in one thread and then do the check if that request completed in another thread. Very strange things happen when you attempt that; made me change the design of the Windows implementation quite drastically (one thread on a command queue that executes requests from other threads instead of letting them wildly call into GetOverlappedResult()). Out of curiosity: Did you come across that too? Or are all requests handled in the same thread they're issued? Cheers, Uwe On Tue, Mar 1, 2011 at 10:13 PM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > The javax.comm API specification requires one event monitor thread per > port. I don't like the idea of having a thread per port either, but one of > the rewrite's design goals is strict conformance to the specification. > > The 50 mS polling interval is just a placeholder. The final design of that > is yet to be decided. > > In Windows, you have two choices for I/O: overlapped and non-overlapped. In > overlapped I/O a thread is blocked, waiting for something to happen. In > non-overlapped I/O a thread does not block. I chose non-overlapped I/O to > avoid thread blocking at the OS level - instead, the thread blocking is kept > in Java. > > -Adrian > > > On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > >> Adrian, >> >> had a look at your code/rewrite and it looks rather clean/nice. >> >> I was looking at the code to gain insight (not related to the >> rewrite) into what is involved in serial port programming >> in Windows. Or rather, to refresh my memory and see how others have >> done, because I've been there done that. >> >> So my questions are just to satisfy my curiosity, not to criticize >> or suggest improvements. >> >> 1) It looks like a new thread (EventMonitor) is created for >> each Serial port, is that correct? >> >> Many people seem to try to avoid using many threads in this sort >> of situation, and like to use something like unix select(). >> I personally find using threads more natural and better impedance >> match to the problem being solved here. I guess 'many people' above >> >> refers to those implementing thousands of connections and >> who cannot live with the overhead and limited number of threads >> available. >> >> 2) The EventMonitor basically polls for events at 50 msec interval? >> >> 3) There is a comment in the source code near the sleep(50) : >> >> // Sufficient up to 19200 baud >> >> >> I'm sure you thought about this carefully, so again not >> criticizing, but seeking to understand how or why, because >> at 50 msec would seem to limit through in some cases. Like >> if you send one byte and need to wait for one to return, >> then this limits speed to 200 chars/sec? >> >> 4) I've done something similar to a few years back from >> Java using JNI to access Win32 API serial port, and >> I seem to recall that I had threading issues ie when >> I submitted a read (ReadFile) and there was no data coming >> in, the thread would not only block but also consume a >> lot of CPU cycles ie it was not sleeping properly inside >> the ReadFile call when the serial port blocked. >> >> Im a bit fuzzy about the details after five years, so my question is >> have you checked if there an issue here? >> >> >> 5) AFAIK the select() on Windows does not work serial ports >> but there is some other mechanism (events?) to implement the >> same functionality, did you consider that? Probably, so you >> decided against it, why? >> >> >> br Kusti >> >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 05:37:07 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:37:07 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <1142-1298983027-957144@sneakemail.com> On Tue, Mar 1, 2011 at 1:32 PM, Adrian Crum wrote: > Just to make sure I'm understanding you correctly, anyone porting RxTx to > a new platform would have to do the following: > > 1. Write their own Java implementation of an abstract Dispatcher class. > yep. I'd probably put all my calls to native OS wrappers in there two, looks the most straight-forward to me. > 2. Write a native (JNI or JNA) interface for the abstract class > implementation. > yes. For POSIX you'd probably only write one piece of code that provides implementations for open(), close(), and friends. You can compile that on all posix platforms (yeah, the devil is in the detail, but it's very little code, still). So this does open() (when using ***, but you can also use +++) // Unix.java class Unix{ public static native int open(String filename, int flags, int mode); .... } // Unix.cpp JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) { const char* pathname = env->GetStringUTFChars(jpathname, 0); if(pathname == 0) return -1; // java throws an out of memory error in this case int result = open(pathname, flags, mode); Unix_cacheErrno(); // handle interference between JVM and errno; env->ReleaseStringUTFChars(jpathname, pathname); return result; } .... 3. Write all of the native (or non-native) code to implement the native > interface. > Not sure what you mean by that. I've done the OS wrappers in step 2. step 1. implements that Dispatcher. What else do I need? > Is that correct? If yes, how is that easier than the simple implementation > the current rewrite design uses? > Yes, except for 3 (see above). How it is easier: I can debug the Java code directly. I can step from the read() call of an input stream directly into the guts of the RXTX implementation on my platform and see e.g. why it's hanging, because I see all the way up the call stack right where it calls Unix.read(). You can't easily do that with a fat native library, especially if you have no second set of devtools installed (the ones for native development). And I bet anyone knowing both languages can write it faster in Java, with less bugs. > On a side note: there is no requirement to write native code using C++. If > C++ is a real obstacle to adoption, then regular C could be used instead. In > that case, there would be a Dispatcher.c file that contains function > protoypes that need to be implemented. Dispatcher.c would still maintain the > same role as Dispatcher.cpp - which is to shield native code developers from > the details of JNI. Just build out the missing functions using C data types > and you're ready to go. > As I said, whatever works for you. Java works for me better than C++ in this case... Cheers, Uwe -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Mar 1 08:26:41 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 16:26:41 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> > The javax.comm API specification requires one event monitor > thread per port. Where does it require this? Do you mean "All the events received by this listener are generated by one dedicated thread that belongs to the SerialPort object. "? I think this is an implementation detail, isn't it? At least it is mentioned after "The current implementation only allows one listener per SerialPort". A bit bad that javadoc does not distinguish between API spec and implementation documentation. Also I don't think that TooManyListenersException MUST be thrown (I think it CAN be thrown). > I don't like the idea of having a thread per > port either, but one of the rewrite's design goals is strict > conformance to the specification. (but not necessarily on JNI layer) > The 50 mS polling interval is just a placeholder. The final > design of that is yet to be decided. I though no polling would be wanted; what could be the placeholder stand for? Do you mean a different interval duration or do you mean something completely different? > In Windows, you have two choices for I/O: overlapped and > non-overlapped. > In overlapped I/O a thread is blocked, waiting for something > to happen. > In non-overlapped I/O a thread does not block. I chose > non-overlapped I/O to avoid thread blocking at the OS level - > instead, the thread blocking is kept in Java. Isn't "overlapped" (asynchronous) I/O meaning that you invoke some ReadFile(..., &overlapped, ...) INSTEAD of performing a synchronous (blocking) function call blocking the thread? As far as I see, W32_Support.cpp uses CreateFile without FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O operations are serialized, even if the calls to the read and write functions specify an OVERLAPPED structure." [1] and "A synchronous handle behaves such that I/O function calls using that handle are blocked until they complete" [2] Given that CCOMTIMEOUTS get: "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the bytes that have already been received, even if no bytes have been received." [3] It looks likes this implementation relies on polling, which probably would waste much computing power. What did I miss? oki, Steffen [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro nous_and_asynchronous_i_o_handles [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 09:23:47 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:23:47 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6D1D93.6090306@sandglass-software.com> Unfortunately, the javax.comm API specification includes a lot of implementation details. That is one of the weaknesses of the specification in my opinion. The bottom line is, anyone wanting to use RxTx as a javax.comm implementation is going to expect it to do the things the specification says it does. -Adrian On 3/1/2011 7:26 AM, Steffen DETTMER wrote: >> The javax.comm API specification requires one event monitor >> thread per port. > Where does it require this? > > Do you mean "All the events received by this listener are generated > by one dedicated thread that belongs to the SerialPort object. "? > > I think this is an implementation detail, isn't it? At least it is > mentioned after "The current implementation only allows one listener per > SerialPort". A bit bad that javadoc does not distinguish between API > spec and implementation documentation. Also I don't think that > TooManyListenersException MUST be thrown (I think it CAN be thrown). > >> I don't like the idea of having a thread per >> port either, but one of the rewrite's design goals is strict >> conformance to the specification. > (but not necessarily on JNI layer) > >> The 50 mS polling interval is just a placeholder. The final >> design of that is yet to be decided. > I though no polling would be wanted; what could be the placeholder stand > for? Do you mean a different interval duration or do you mean something > completely different? > >> In Windows, you have two choices for I/O: overlapped and >> non-overlapped. >> In overlapped I/O a thread is blocked, waiting for something >> to happen. >> In non-overlapped I/O a thread does not block. I chose >> non-overlapped I/O to avoid thread blocking at the OS level - >> instead, the thread blocking is kept in Java. > Isn't "overlapped" (asynchronous) I/O meaning that you invoke some > ReadFile(...,&overlapped, ...) > INSTEAD of performing a synchronous (blocking) function call blocking > the thread? > > As far as I see, W32_Support.cpp uses CreateFile without > FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O > operations are serialized, even if the calls to the read and write > functions specify an OVERLAPPED structure." [1] and "A synchronous > handle behaves such that I/O function calls using that handle are > blocked until they complete" [2] > > Given that CCOMTIMEOUTS get: > "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values > for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier > members, specifies that the read operation is to return immediately with > the bytes that have already been received, even if no bytes have been > received." [3] > > It looks likes this implementation relies on polling, which probably > would waste much computing power. > > What did I miss? > > oki, > > Steffen > > [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx > [2] > http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro > nous_and_asynchronous_i_o_handles > [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at sandglass-software.com Tue Mar 1 09:55:29 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:55:29 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <1142-1298983027-957144@sneakemail.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> Message-ID: <4D6D2501.1020803@sandglass-software.com> That code duplicates what is in Dispatcher.cpp. A Unix port would only need to implement CommPortFactory::getInstance(portName, portType). -Adrian On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 15:07:46 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 2 Mar 2011 09:07:46 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6D2501.1020803@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> <4D6D2501.1020803@sandglass-software.com> Message-ID: <23749-1299017266-991798@sneakemail.com> What is this duplicating? A Unix port will need to call open() anyways (just so we're talking about the same thing here: open() is the Unix equivalent of CreateFile()) On Wed, Mar 2, 2011 at 3:55 AM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > That code duplicates what is in Dispatcher.cpp. A Unix port would only > need to implement CommPortFactory::getInstance(portName, portType). > > -Adrian > > > On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Tue Mar 1 22:53:07 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 00:53:07 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: Hi, I haven't seen any response to my question below. Is this not the right place to ask? If not, where would be a better place to ask? Any suggestions? Thanks, Ryan On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >> Hi, >> >> I have a receive thread that does nothing but call read() on the serial >> port input stream. It works fine for a while but after running for a long >> time it eventually returns -1 which means EOF. This is my first problem, as >> the device I'm talking to runs forever, I don't know why it would return -1. >> I am calling disableReceiveThreshold() and disableReceiveTimeout() at >> initialization which according to the documentation means read will return >> as soon as any data is available and it will block forever when data is not >> available, so -1 should never be returned from read, right? >> >> I have been unable to figure out why read returns -1 after a long while >> but I have found that if I kill my application and restart it everything >> works fine again. Therefore I tried to work around the problem by having my >> code close the port and reopen it when read returns -1. My second problem is >> that in this case when I call close() on the port it blocks forever. I did >> find this old bug >> >> http://bugzilla.qbang.org/show_bug.cgi?id=53 >> >> which describes close() hanging on OSX, but it says that bug was fixed >> with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have >> any idea why read might be returning -1 in the first place? If I can avoid >> that I don't care about close() hanging because I would never close the >> port. If not, does anyone know why close() might block forever and how I can >> prevent this? I'm using RXTX version 2.1-7. >> >> Thanks, >> -- >> Ryan >> >> > > > -- > Ryan Boder > 1 614 598-6339 > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Mar 2 01:34:48 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 2 Mar 2011 10:34:48 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/2/11 07:53, "Ryan Boder" wrote: Can you / have you made a simple test to ensure that rxtx is the issue? Can you write a simple C-program to see if this exhibits the same problem? I've never encountered this sort of problem with rxtx, it mostly just works. But I'm on Mac so can't say about Windows (7) br Kusti >Hi, > >I haven't seen any response to my question below. Is this not the right >place to ask? If not, where would be a better place to ask? Any >suggestions? > >Thanks, >Ryan > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > >I mis-spoke, I don't have my own thread calling read, I am calling >read in the event handler after receiving a >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be >accurate though. > >Ryan > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >Hi, > >I have a receive thread that does nothing but call read() on the serial >port input stream. It works fine for a while but after running for a long >time it eventually returns -1 which means EOF. This is my first problem, >as the device I'm talking to runs forever, I don't know why it would >return -1. I am calling disableReceiveThreshold() and >disableReceiveTimeout() at initialization which according to the >documentation means read will return as soon as any data is available and >it will block forever when data is not available, so -1 should never be >returned from read, right? > >I have been unable to figure out why read returns -1 after a long while >but I have found that if I kill my application and restart it everything >works fine again. Therefore I tried to work around the problem by having >my code close the port and reopen it when read returns -1. My second >problem is that in this case when I call close() on the port it blocks >forever. I did find this old bug > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > >which describes close() hanging on OSX, but it says that bug was fixed >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone >have any idea why read might be returning -1 in the first place? If I can >avoid that I don't care about close() hanging because I would never close >the port. If not, does anyone know why close() might block forever and >how I can prevent this? I'm using RXTX version 2.1-7. > >Thanks, >-- >Ryan > > > > > > > > > >-- >Ryan Boder >1 614 598-6339 > > > > > > >-- >Ryan Boder >1 614 598-6339 > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From Steffen.DETTMER at ingenico.com Wed Mar 2 03:08:57 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:08:57 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <32684-1298981297-704398@sneakemail.com> References: <4D6CD4DE.7040501@sandglass-software.com> <32684-1298981297-704398@sneakemail.com> Message-ID: <20110302100857.GB8030@elberon.bln.de.ingenico.com> * iqzw2r602 at sneakemail.com wrote on Tue, Mar 01, 2011 at 23:08 +1100: > This reminds me of a nasty problem I had with overlapped I/O on windows Yeah, those thousands of complex, difficult to use and exception-containing WinAPI is really hard to use... About strange effects on overlapped&multithreading, MSDN has: `the calling thread uses the GetOverlappedResult function or one of the wait functions' [1] also also mentiones I/O Completion Ports [2], and later continues: `If an application reuses OVERLAPPED structures on multiple threads and calls GetOverlappedResult with the bWait parameter set to TRUE, the application must ensure that the associated event is set before the application reuses the structure. This can be accomplished by using the WaitForSingleObject function after calling GetOverlappedResult to force the thread to wait until the operation completes. Note that the event object must be a manual-reset event object. If an autoreset event object is used, calling GetOverlappedResult with the bWait parameter set to TRUE causes the function to be blocked indefinitely.' also [1] oki, Steffen [1] http://msdn.microsoft.com/en-us/library/ms686358%28v=vs.85%29.aspx [2] http://msdn.microsoft.com/en-us/library/aa365198%28v=vs.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:15:11 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:15:11 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6D1D93.6090306@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> <4D6D1D93.6090306@sandglass-software.com> Message-ID: <20110302101511.GC8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 08:23 -0800: > Unfortunately, the javax.comm API specification includes a lot of > implementation details. That is one of the weaknesses of the > specification in my opinion. The bottom line is, anyone wanting to use > RxTx as a javax.comm implementation is going to expect it to do the > things the specification says it does. Yeah ok, but even then the implementation could check for the TooManyListenersException situations (if it really is required to support applications relying on that exception) but internally use just a single I/O thread waiting for events on any open file descriptors. Of course an implementation supporting all sort of concurrency could become quite complex (especially if open-read-close should work fast, I think would be difficult to implement, because a new file descriptors had to be added to the waitFor/select list, and who knows how systems behave here in detail...). oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:25:15 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:25:15 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6CDB22.9070401@sandglass-software.com> References: <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> <4D6CDB22.9070401@sandglass-software.com> Message-ID: <20110302102515.GD8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 03:40 -0800: > * from some older mail: > > My question would be: Why would you do that? The rewrite does > > most of the work for you - all you have to do is implement > > two C++ virtual classes and two C++ functions. > > > > In Windows that took me a few hours. > > Every journey begins with a single step. Yes, of course, but then it shouldn't be used as base for new effort estimations like `In Windows that took a few hours' ;-) (BTW, calling a single step `the rewrite' may sound a bit ambitious ;)) But of course a prototype demonstrating something can be really helpful, sure. I just wanted to tell that interfaces should be easy to use and powerful at the same time and may non-trivial initial considerations before starting to implement them. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From ryan.boder at gmail.com Wed Mar 2 18:44:35 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:44:35 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: While running the tests you requested I may have stumbled on the problem, I just don't know how to fix it. According to the documentation, if both the receive timeout and receive threshold are disabled then read() should block forever until data is available. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#getInputStream%28%29 On my system using RXTX read() is returning -1 when no data is available even though I have disabled both thresholds. The reason my program was running fine for a while without this problem showing up is that I was using the DATA_AVAILABLE event to be notified when data is available and only calling read() to read an entire frame whenever the DATA_AVAILABLE event occurred, until eventually my device (I'm guessing) probably took longer than normal to send the entire data frame and therefore I called read when no data was available and it returned -1. The following Java program demonstrates my problem, it returns -1 as soon as no data is available, even though I think it should block until data is available. import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; public class Main implements SerialPortEventListener { public static void main(String[] args) throws Exception { new Main().run(); } private void run() throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier("COM4"); SerialPort port = (SerialPort) portIdentifier.open(Main.class.getName(), 2000); port.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); port.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); port.disableReceiveThreshold(); port.disableReceiveTimeout(); BufferedInputStream in = new BufferedInputStream(port.getInputStream()); BufferedOutputStream out = new BufferedOutputStream(port.getOutputStream()); port.addEventListener(this); Thread.sleep(1000); out.write(new byte[] {0x02, 0x60}); out.flush(); while (true) { int x = in.read(); if (x == -1) { System.out.println("EOF"); Thread.sleep(1000000000); } String s = Integer.toHexString(x & 0xFF); if (s.length() == 1) s = "0" + s; System.out.print(s + " "); System.out.flush(); } } public void serialEvent(SerialPortEvent arg0) { System.out.println("Serial port event"); } } However, the follow C# program ran all day today without ever read ever returning -1, as I would expect. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.IO.Ports; using System.Threading; namespace RXTXReadTest1 { class Program { static void Main(string[] args) { new Program().run(); } private void run() { SerialPort port = new SerialPort("COM4", 19200, Parity.None, 8, StopBits.One); port.Open(); port.Write(new byte[] { 0x02, 0x60 }, 0, 2); while (true) { int x = port.ReadByte(); if (x == -1) { Console.WriteLine("EOF"); Thread.Sleep(1000000000); } String s = x.ToString("X"); if (s.Length == 1 ) s = "0" + s; Console.Out.Write(s + " "); Console.Out.Flush(); } } } } Now I am experimenting with what happens if I set the receive timeout to it's maximum value (apparently 1600ms) and only call read() when I am expecting data. Hopefully it will never be more than 1600ms late. This is still only a work around, not solving the problem. Am I doing something wrong in my code above or is RXTX retuning -1 when it should be blocking? Thanks, Ryan On Wed, Mar 2, 2011 at 3:34 AM, Kustaa Nyholm wrote: > On 3/2/11 07:53, "Ryan Boder" wrote: > Can you / have you made a simple test to ensure that rxtx is the issue? > > Can you write a simple C-program to see if this exhibits the same problem? > > I've never encountered this sort of problem with rxtx, it mostly just > works. > > But I'm on Mac so can't say about Windows (7) > > br Kusti > > > > > >Hi, > > > >I haven't seen any response to my question below. Is this not the right > >place to ask? If not, where would be a better place to ask? Any > >suggestions? > > > >Thanks, > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder > wrote: > > > >I mis-spoke, I don't have my own thread calling read, I am calling > >read in the event handler after receiving a > >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be > >accurate though. > > > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder > wrote: > > > >Hi, > > > >I have a receive thread that does nothing but call read() on the serial > >port input stream. It works fine for a while but after running for a long > >time it eventually returns -1 which means EOF. This is my first problem, > >as the device I'm talking to runs forever, I don't know why it would > >return -1. I am calling disableReceiveThreshold() and > >disableReceiveTimeout() at initialization which according to the > >documentation means read will return as soon as any data is available and > >it will block forever when data is not available, so -1 should never be > >returned from read, right? > > > >I have been unable to figure out why read returns -1 after a long while > >but I have found that if I kill my application and restart it everything > >works fine again. Therefore I tried to work around the problem by having > >my code close the port and reopen it when read returns -1. My second > >problem is that in this case when I call close() on the port it blocks > >forever. I did find this old bug > > > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > > > >which describes close() hanging on OSX, but it says that bug was fixed > >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone > >have any idea why read might be returning -1 in the first place? If I can > >avoid that I don't care about close() hanging because I would never close > >the port. If not, does anyone know why close() might block forever and > >how I can prevent this? I'm using RXTX version 2.1-7. > > > >Thanks, > >-- > >Ryan > > > > > > > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Wed Mar 2 18:46:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:46:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: <-1051064942000733580@unknownmsgid> References: <-1051064942000733580@unknownmsgid> Message-ID: It is USB and seems very reliable with the C# test program in my previous email. On Wed, Mar 2, 2011 at 6:58 PM, Bruce Griffith wrote: > How reliable is your serial port ? is it USB or Bluetooth? > > > > Bruce Griffith > > 303-532-4778 > > > > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On Behalf > Of *Ryan Boder > *Sent:* Tuesday, 01 March 2011 10:53 PM > *To:* rxtx at qbang.org > *Subject:* Re: [Rxtx] RXTX serial port read() returns -1 unexpectedly and > then blocks forever on close() > > > > Hi, > > I haven't seen any response to my question below. Is this not the right > place to ask? If not, where would be a better place to ask? Any suggestions? > > Thanks, > Ryan > > On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > > Hi, > > I have a receive thread that does nothing but call read() on the serial > port input stream. It works fine for a while but after running for a long > time it eventually returns -1 which means EOF. This is my first problem, as > the device I'm talking to runs forever, I don't know why it would return -1. > I am calling disableReceiveThreshold() and disableReceiveTimeout() at > initialization which according to the documentation means read will return > as soon as any data is available and it will block forever when data is not > available, so -1 should never be returned from read, right? > > I have been unable to figure out why read returns -1 after a long while but > I have found that if I kill my application and restart it everything works > fine again. Therefore I tried to work around the problem by having my code > close the port and reopen it when read returns -1. My second problem is that > in this case when I call close() on the port it blocks forever. I did find > this old bug > > http://bugzilla.qbang.org/show_bug.cgi?id=53 > > which describes close() hanging on OSX, but it says that bug was fixed with > a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have any > idea why read might be returning -1 in the first place? If I can avoid that > I don't care about close() hanging because I would never close the port. If > not, does anyone know why close() might block forever and how I can prevent > this? I'm using RXTX version 2.1-7. > > Thanks, > -- > Ryan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Mar 3 02:50:20 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 3 Mar 2011 09:50:20 +0000 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: So if -1 is unexpectedly returned from read, and we have demonstrated that your USB-serial adapter can actually causes this to happen in RXTX, why not just ignore the -1 value? What happens when you try this? As for a hang on close, are your closing your port from within your serial event handler? I know that this can cause some serious problems. Regards, Michael Erskine. From Kustaa.Nyholm at planmeca.com Thu Mar 3 03:39:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 12:39:34 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 03:44, "Ryan Boder" wrote: >While running the tests you requested I may have stumbled on the problem, >I just don't know how to fix it. According to the documentation, if both >the receive timeout and receive threshold are disabled then read() should >block forever until data is available. > >http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/re >ference/api/javax/comm/CommPort.html#getInputStream%28%29 > >On my system using RXTX read() is returning -1 when no data is available >even though I have disabled both thresholds. The reason my program was >running fine for a while without this problem showing up is that I was >using the DATA_AVAILABLE event to be notified when data is available and >only calling read() to read an entire frame whenever the DATA_AVAILABLE >event occurred, until eventually my device (I'm guessing) probably took >longer than normal to send the entire data frame and therefore I called >read when no data was available and it returned -1. As a workaround have you tried to perform another read() if it returns -1? The javadoc says (see getInputStream): "Note, however, that framing errors may cause the Timeout and Threshold values to complete prematurely without raising an exception." I read this as a hint that read might return even if no data is available. Because of the above and that read() can only return -1 or the byte received it would be somewhat logical to return -1 in case of framing error ? I'm not claiming that my interpretation of the specification, such as it is, is correct, just speculating that the behavior could be something like that. It might give you some more insight if you used the read(bytes[],int,int) method, because this can and will return 0 in case of timeout (and presumably might do so in case of framing error, maybe some other error condition too). That might allow you to handle or work around the problem in this case. You have not shown your complete code (no need) but your comments and the example makes me wonder if the code is otherwise as it should be, meaning are you assuming that when you get the DATA_AVAILABLE event all of your frame has arrived and that you can just blindly read it away from the input stream? That is not guaranteed of course. Also using read(), instead of read(bytes[],int,int), is not very efficient and might be masking other problems as mused above. BTE you can print a byte in hex with leading zeros more easily with: System.out.printf("%02X",x); br Kusti From ryan.boder at gmail.com Thu Mar 3 07:56:16 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:56:16 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 5:39 AM, Kustaa Nyholm wrote: > > As a workaround have you tried to perform another read() if it returns -1? > I tried that and it did work sometimes but not all the time. > > The javadoc says (see getInputStream): > > "Note, however, that framing errors may cause the Timeout and Threshold > values to complete prematurely without raising an exception." > > I read this as a hint that read might return even if no data is available. > > Because of the above and that read() can only return -1 or the byte > received > it would be somewhat logical to return -1 in case of framing error ? > > I'm not claiming that my interpretation of the specification, such as it > is, > is correct, just speculating that the behavior could be something like > that. > Receive framing is not enabled by default. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#enableReceiveFraming%28int%29 My choice of word might be misleading, when I said frame I just meant a contiguous message from the device. I am not enabling receive framing. Can you have a framing error when receive framing is disabled? > > It might give you some more insight if you used the read(bytes[],int,int) > method, because > this can and will return 0 in case of timeout (and presumably might do so > in case of framing > error, maybe some other error condition too). > > That might allow you to handle or work around the problem in this case. > > You have not shown your complete code (no need) but your comments and the > example > makes me wonder if the code is otherwise as it should be, meaning are you > assuming > that when you get the DATA_AVAILABLE event all of your frame has arrived > and that > you can just blindly read it away from the input stream? That is not > guaranteed of course. > I'm not assuming the entire message has arrived, I'm just assuming it either has arrived or will arrive soon which is why I'm using a (supposedly) blocking read(). > > Also using read(), instead of read(bytes[],int,int), is not very efficient > and > might be masking other problems as mused above. > True, I'm reading one byte at a time because I don't know how long the message will be until I read and parse some of it. I suppose I can use read(bytes[],int,int) once I figure out how long the message will be. > > BTE you can print a byte in hex with leading zeros more easily with: > > > System.out.printf("%02X",x); > I did it the dumb way in that test program so I could copy and paste the code from C# to Java without having to figure out how to do the same in C# which I'm not as familiar with. Thanks and BR, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 07:58:24 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:58:24 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: Yes I was doing the close in the serial event handler, I didn't realize that caused a problem. Thanks, I'll fix it. On Thu, Mar 3, 2011 at 4:50 AM, Michael Erskine wrote: > So if -1 is unexpectedly returned from read, and we have demonstrated > that your USB-serial adapter can actually causes this to happen in > RXTX, why not just ignore the -1 value? What happens when you try > this? As for a hang on close, are your closing your port from within > your serial event handler? I know that this can cause some serious > problems. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 11:48:20 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 13:48:20 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm wrote: > On 3/3/11 16:56, "Ryan Boder" wrote: > > > >I'm not assuming the entire message has arrived, I'm just assuming it > >either has arrived or will arrive soon which is why I'm using a > >(supposedly) blocking read(). > > > I've been giving this some further thought. > > It does not feel healthy to block without timeout, especially > from within a thread that is essentially internal to the rxtx. > > I've never done that, I always use a time out, read(byte[],int,int) > for the expected number of bytes, check how much I got and issue > more reads until I get everything. > > You have not described how your communication works so I'm only > speculating. > > If your device needs some response to send more bytes (from your > code it looks like this is not the case) then a missing byte > would block your read and prevent you from responding and > getting more data. But as said, looks like that is not the case. > > Anyway, if this was my problem, I would enable the timeout > and use read(byte[],int,int) and loop until I get what I need. > You are right, I should and will use a timeout. In fact, my program has been running flawlessly for 12 hours and the only change I made was to enable a timeout, no change in the logic at all. Without the timeout read() was returning -1 usually after it ran for an hour or two. I will change the code to make use of the timeout and handle it appropriately. It still seems to me that RXTX's behavior doesn't match the documentation when rx timeout and rx threshold are disabled read() should block until data is available instead of immediately returning -1. I don't believe that a framing error is occurring immediately every time data is not available causing read() to return -1. Especially since the C# test program above runs all day with no error and the Java program above runs all day with no error when a timeout is enabled. To me it seems like enabling the timeout is what is causing read() to block until data is available, even if only for 1600ms, and without the timeout read() is returning -1 immediately when it should be blocking. Thanks for all the help and best regards, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Thu Mar 3 13:02:30 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 22:02:30 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 20:48, "Ryan Boder" wrote: >On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm > wrote: > >On 3/3/11 16:56, "Ryan Boder" wrote: >> > >>I'm not assuming the entire message has arrived, I'm just assuming it >>either has arrived or will arrive soon which is why I'm using a >>(supposedly) blocking read(). > > > >I've been giving this some further thought. > >It does not feel healthy to block without timeout, especially >from within a thread that is essentially internal to the rxtx. > >I've never done that, I always use a time out, read(byte[],int,int) >for the expected number of bytes, check how much I got and issue >more reads until I get everything. > >You have not described how your communication works so I'm only >speculating. > >If your device needs some response to send more bytes (from your >code it looks like this is not the case) then a missing byte >would block your read and prevent you from responding and >getting more data. But as said, looks like that is not the case. > >Anyway, if this was my problem, I would enable the timeout >and use read(byte[],int,int) and loop until I get what I need. > > > > >You are right, I should and will use a timeout. In fact, my program has >been running flawlessly for 12 hours and the only change I made was to >enable a timeout, no change in the logic at all. Without the timeout >read() was returning -1 usually after it ran for an hour or two. I will >change the code to make use of the timeout and handle it appropriately. That's nice! > >It still seems to me that RXTX's behavior doesn't match the documentation >when rx timeout and rx threshold are disabled read() should block until >data is available instead of immediately returning -1. Yeah, it does look like bug. However this might be related to some Windows specific serial port issue. Years ago I had issues with JavaComm (not RxTx) where I did a blocking read and I had huge issues with my program consuming all resources. I curser the Sun and JavaComm and re-code my own SerialPort using JNI to access the Win32 API directly. And I run into the same problems as with the Sun's implementation! So I ditched my code, changed my code to use timeouts and problems disappeared. > I don't believe that a framing error is occurring immediately every time >data is not available causing read() to return -1. Especially since the >C# test program above runs all day with no error and the Java program >above runs all day with no error when a timeout is enabled. I think so too, all things considered I don't really believe in framing errors in this case. > To me it seems like enabling the timeout is what is causing read() to >block until data is available, even if only for 1600ms, and without the >timeout read() is returning -1 immediately when it should be blocking. Yeah, I had a peek at the innards of RxTx Windows serial port a week or so ago and also read MSDN documentation about serial ports and the way overlapped and non-overlapped (non blocking and blocking) IO is handled is a way different. So yeah, it can well be that there is an issue lurking there somewhere inside RxTx in Windows. > > >Thanks for all the help and best regards, >-- >Ryan Boder I'm happy if I was of any assistance. br Kusti From tjarvi at qbang.org Thu Mar 3 18:52:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Mar 2011 18:52:50 -0700 (MST) Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: >> Without the timeout >> read() was returning -1 usually after it ran for an hour or two. There is a big hammer in rxtx causing that behavior. >> It still seems to me that RXTX's behavior doesn't match the documentation >> when rx timeout and rx threshold are disabled read() should block until >> data is available instead of immediately returning -1. > > Yeah, it does look like bug. However this might be related to some > Windows specific serial port issue. Years ago I had issues with > JavaComm (not RxTx) where I did a blocking read and I had huge > issues with my program consuming all resources. I curser the Sun > and JavaComm and re-code my own SerialPort using JNI to access > the Win32 API directly. And I run into the same problems as > with the Sun's implementation! So I ditched my code, changed > my code to use timeouts and problems disappeared. > > >> To me it seems like enabling the timeout is what is causing read() to >> block until data is available, even if only for 1600ms, and without the >> timeout read() is returning -1 immediately when it should be blocking. > > Yeah, I had a peek at the innards of RxTx Windows serial port a week > or so ago and also read MSDN documentation about serial ports and > the way overlapped and non-overlapped (non blocking and blocking) > IO is handled is a way different. So yeah, it can well be that > there is an issue lurking there somewhere inside RxTx in Windows. > > Yes. RXTX was patched to behave the way it does. I don't fully understand the issue behind the patch. Marc noticed the odd behavior as well and offered a fix which was greeted with resistance. The windows implementation was done without real documentatino of the windows API. I think I had an example from the late 80's early 90's on Microsoft's site and some API documentation that was obviously not microsofts in Europe. Wayne Roberts had a real need for windows support and fixed some major issues it had. My interest at the time was mingw32. I then cleaned it up for some specific uses I had later. The read returning -1 when it should block didn't impact anybody and appeared to help some people. It isnt the documented behavior though. There could be all sorts of latent bugs in that code but in the real world, it gets by in almost all use cases. Its a hack but it worked for 100's of thousands of people over a 14 year period. Maybe its time to revisit the code but there is more risk than gain for most people. How do you move forward and avoid the risk? Some have expressed interests in coding C++ or other efforts. I'm all for such efforts but feel some unit tests that work with a null modem cables are the only thing that will move rxtx (and perhaps CommAPI) forward. If we have a test suite in place as a qualification for implementations, progress can be made in the right direction regardless of the implementation details. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Fri Mar 4 02:57:16 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 4 Mar 2011 11:57:16 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/4/11 03:52, "Trent Jarvi" wrote: >Yes. RXTX was patched to behave the way it does. I don't fully >understand the issue behind the patch. Marc noticed the odd behavior as >well and offered a fix which was greeted with resistance. > >The windows implementation was done without real documentatino of the >windows API. I think I had an example from the late 80's early 90's on >Microsoft's site and some API documentation that was obviously not >microsofts in Europe. Wayne Roberts had a real need for windows support >and fixed some major issues it had. My interest at the time was mingw32. >I then cleaned it up for some specific uses I had later. The read >returning -1 when it should block didn't impact anybody and appeared to >help some people. It isnt the documented behavior though. > >There could be all sorts of latent bugs in that code but in the real >world, it gets by in almost all use cases. I think so too, never had any problems with it. > Its a hack but it worked for 100's of thousands of people over a 14 year >period. Yeah! Thanks for everyone who has contributed over the years, job well done! >Maybe its time to >revisit the code but there is more risk than gain for most people. How >do >you move forward and avoid the risk? My view is that it is quite risky and rather pointless to move forward, other than fixing bugs that really affect people. At the moment the major issue IMO is just that it seems (not been following this too carefully, so maybe I'm wrong, so in case this FUD, my apologies) that 'official' binaries are not available. I think the rewrite, tempting as it is in some respects is not the way forward. Just gentle maintenance to iron out real issues and then get the binaries out. br Kusti From ryan.boder at gmail.com Fri Mar 4 07:24:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Fri, 4 Mar 2011 09:24:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 8:52 PM, Trent Jarvi wrote: > > The windows implementation was done without real documentatino of the > windows API. I think I had an example from the late 80's early 90's on > Microsoft's site and some API documentation that was obviously not > microsofts in Europe. Wayne Roberts had a real need for windows support and > fixed some major issues it had. My interest at the time was mingw32. I then > cleaned it up for some specific uses I had later. The read returning -1 > when it should block didn't impact anybody and appeared to help some people. > It isnt the documented behavior though. > > There could be all sorts of latent bugs in that code but in the real world, > it gets by in almost all use cases. Its a hack but it worked for 100's of > thousands of people over a 14 year period. Maybe its time to revisit the > code but there is more risk than gain for most people. How do you move > forward and avoid the risk? > The safest and easiest solution would be to add a javadoc comment to disableReceiveTimeout explaining the difference between the RXTX behavior and Sunacle's documented behavior so that when someone uses the method in an IDE like Eclipse a little box would pop up informing them. Generating javadoc HTML and hosting it on the RXTX website would go a long way too, when something behaves differently than I expect the first thing I do is look for the javadoc online. -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From kharrington at neuronrobotics.com Mon Mar 7 10:47:26 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 12:47:26 -0500 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! Message-ID: Hey all, this is just a heads up that i have made a fork of rxtxSerial. Some of the features we have added: * Self deployment of native libraries ( all native code is stored inside the jar and deployed at runtime). No more manual install of native code. * Arm Cortex support (Gumstix) * Android Support (requires a rooted phone for now) * Google Code (SVN) repository for easy code and jar access * Single makefile compile (simplifies the compilation of project binaries) * Ant build script for jar creation * Removal of partialy implemented code to streamline the lib for just serial port access * Full Eclipse integration, for testing application code against sources. And a bunch of bug fixes: * Fixed the memory access error that causes OSX to crash the JVM when serial.close() is cvalled * Fixed the windows serial port zombie bind that prevents re-accessing serial ports when exiting on an exception * Fixed erronious printouts of native library mis-match To check it out, take a look at our page here: http://code.google.com/p/nrjavaserial/ From Kustaa.Nyholm at planmeca.com Mon Mar 7 11:46:26 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Mar 2011 20:46:26 +0200 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: Message-ID: On 3/7/11 19:47, "Kevin Harrington NR" wrote: >Hey all, this is just a heads up that i have made a fork of >rxtxSerial. Some of the features we have added great! If also does what it says on the tin: brilliant! Congrats and thanks. br Kusti From jmsachs at gmail.com Mon Mar 7 12:50:33 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 14:50:33 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: > From: Kevin Harrington NR > To: rxtx at qbang.org > Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > Hey all, this is just a heads up that i have made a fork of > rxtxSerial. Some of the features we have added: > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with a ten-foot pole. From Kustaa.Nyholm at planmeca.com Mon Mar 7 13:10:43 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Mar 2011 22:10:43 +0200 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: Message-ID: On 3/7/11 21:50, "Jason Sachs" wrote: > >Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >a ten-foot pole. >_______________________________________________ Oh crap, makes it useless for me and many others. Also I see no provision in RxTx license to change it so how could anyone change it to GPLv3? br Kusti From showard314 at gmail.com Mon Mar 7 13:24:08 2011 From: showard314 at gmail.com (Scott Howard) Date: Mon, 7 Mar 2011 15:24:08 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 3:10 PM, Kustaa Nyholm wrote: > Also I see no provision in RxTx license to change > it so how could anyone change it to GPLv3? I think this is allowed: 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. From jmsachs at gmail.com Mon Mar 7 13:24:47 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 15:24:47 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 2:50 PM, Jason Sachs wrote: >> From: Kevin Harrington NR >> To: rxtx at qbang.org >> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> > > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with > a ten-foot pole. > Let me back up a second (perhaps to make up for my lack of diplomacy) and state that I think any progress w/ rxtx is good. If an rxtx fork were LGPL (or some other non-spreading open source license) and leading in a good direction, I'd gladly return the favor by posting any improvements or bugfixes I found to the community. --Jason From jmsachs at gmail.com Mon Mar 7 13:36:13 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 15:36:13 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: Kevin: could you clarify the license? http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java has the RXTX 2.1 license (LGPL v 2.1 + Linking Over Controlled Interface.) but http://code.google.com/p/nrjavaserial/ says GPLv3. --Jason From kharrington at neuronrobotics.com Mon Mar 7 14:00:02 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 16:00:02 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: The one downside to google code is that it does not allow custom licensing. You have to pick from a drop-down list. Treat the licences on the files themselves as the licence to be concerned with, and ignore the "project licence". Sorry for the confusion. On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: > Kevin: could you clarify the license? > > http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java > has the RXTX 2.1 license > (LGPL v 2.1 + Linking Over Controlled Interface.) > > but http://code.google.com/p/nrjavaserial/ says GPLv3. > > --Jason > From iqzw2r602 at sneakemail.com Mon Mar 7 14:08:18 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 8 Mar 2011 08:08:18 +1100 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: References: Message-ID: <11253-1299532098-811882@sneakemail.com> Nice! Out of curiosity, did you use the patch that I sent Trent about two years ago to do the native library loading, or did you implement your own solution? Cheers, Uwe On Tue, Mar 8, 2011 at 5:46 AM, Kustaa Nyholm Kustaa.Nyholm-at-planmeca.com| rxtx.org mailing list/Example Allow| wrote: > On 3/7/11 19:47, "Kevin Harrington NR" > wrote: > > >Hey all, this is just a heads up that i have made a fork of > >rxtxSerial. Some of the features we have added > > > > great! If also does what it says on the tin: brilliant! > > Congrats and thanks. > > br Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aawolfe at gmail.com Mon Mar 7 15:31:47 2011 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 7 Mar 2011 17:31:47 -0500 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR wrote: > Hey all, this is just a heads up that i have made a fork of > rxtxSerial. Some of the features we have added: > > * Self deployment of native libraries ( all native code is stored > inside the jar and deployed at runtime). No more manual install of > native code. > * Arm Cortex support (Gumstix) > * Android Support (requires a rooted phone for now) > * Google Code (SVN) repository for easy code and jar access > * Single makefile compile (simplifies the compilation of project binaries) > * Ant build script for jar creation > * Removal of partialy implemented code to streamline the lib for just > serial port access > * Full Eclipse integration, for testing application code against sources. > > And a bunch of bug fixes: > > * Fixed the memory access error that causes OSX to crash the JVM when > serial.close() is cvalled > * Fixed the windows serial port zombie bind that prevents re-accessing > serial ports when exiting on an exception > * Fixed erronious printouts of native library mis-match > > To check it out, take a look at our page here: > > http://code.google.com/p/nrjavaserial/ This is interesting, getting the native libs set up has been an issue for some of my users. Will have to check it out. Out of curiosity, what Android devices provide a serial port? Or are there some that allow USB host mode and then a usb-serial adapter? I have only an Android cell phone, don't think it can do anything serial but would love to be wrong about that. From jfh at greenhousepc.com Mon Mar 7 15:54:39 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 15:54:39 -0700 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! Message-ID: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Mon Mar 7 16:53:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Mar 2011 16:53:50 -0700 (MST) Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: Hi Kevin, Until Google fixes the options as developers have requested, I'd suggest the least misleading dropdown option is "Other Open Source" with a clarification about LGPL 2.1 on the project page. If you are not supporting the CommAPI SPI interface that was available prior to the current JSR so that applications work in the javax.comm namespace, there is no need for the linking over controlled interfaces exception. RXTX 2.0 is used in that fashion but RXTX 2.1 is not. The exception explicitly states it can be removed if the source has been modified. The license is then explicitly OSI reviewed and approved as Google requests but is not in their drop down box as it should be and is for the GPL v2. http://opensource.org/licenses/alphabetical http://opensource.org/licenses/lgpl-2.1 The drawback would be that the library effectively could never be used in that SPI/controlled interface fashion again. On Mon, 7 Mar 2011, Kevin Harrington NR wrote: > The one downside to google code is that it does not allow custom > licensing. You have to pick from a drop-down list. Treat the licences > on the files themselves as the licence to be concerned with, and > ignore the "project licence". Sorry for the confusion. > > On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >> Kevin: could you clarify the license? >> >> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >> has the RXTX 2.1 license >> (LGPL v 2.1 + Linking Over Controlled Interface.) >> >> but http://code.google.com/p/nrjavaserial/ says GPLv3. >> >> --Jason >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From hakcenter at gmail.com Mon Mar 7 18:55:57 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 17:55:57 -0800 Subject: [Rxtx] Latency Woes Message-ID: <4D758CAD.2010602@gmail.com> I have finally deduced my slow data logging to a latency issue. I write software for dsms, and the protocol is request / receive, you cannot do more than 1 sensor at a time. So when you log multiple sensors, +20ms per item, sampling rate drops like a rock. I was wondering if there is any ideas besides going completely native with my application to reduce latency. With or without events I don't care at this point I need to kill as much of the latency as possible. Realistically I need no more than 1ms. From adrian.crum at sandglass-software.com Mon Mar 7 19:08:21 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Mon, 07 Mar 2011 18:08:21 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D758CAD.2010602@gmail.com> References: <4D758CAD.2010602@gmail.com> Message-ID: <4D758F95.90800@sandglass-software.com> Drop the requests into a queue, and then have a separate thread service the queue. -Adrian On 3/7/2011 5:55 PM, Curtis Hacker wrote: > I have finally deduced my slow data logging to a latency issue. > > I write software for dsms, and the protocol is request / receive, you > cannot do more than 1 sensor at a time. So when you log multiple > sensors, +20ms per item, sampling rate drops like a rock. > > I was wondering if there is any ideas besides going completely native > with my application to reduce latency. With or without events I don't > care at this point I need to kill as much of the latency as possible. > Realistically I need no more than 1ms. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From hakcenter at gmail.com Mon Mar 7 19:24:16 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 18:24:16 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D758F95.90800@sandglass-software.com> References: <4D758CAD.2010602@gmail.com> <4D758F95.90800@sandglass-software.com> Message-ID: <4D759350.8060402@gmail.com> Sample code ? I don't necessarily want to read the byte I just wrote, but wait till the que depth is 2. Setup a thread without a sleep timer: if (in.available() > 1) { do_stuff(); } ?? On 03/07/11 18:08, Adrian Crum wrote: > Drop the requests into a queue, and then have a separate thread > service the queue. > > -Adrian > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: >> I have finally deduced my slow data logging to a latency issue. >> >> I write software for dsms, and the protocol is request / receive, you >> cannot do more than 1 sensor at a time. So when you log multiple >> sensors, +20ms per item, sampling rate drops like a rock. >> >> I was wondering if there is any ideas besides going completely native >> with my application to reduce latency. With or without events I don't >> care at this point I need to kill as much of the latency as possible. >> Realistically I need no more than 1ms. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adrian.crum at sandglass-software.com Mon Mar 7 19:46:02 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Mon, 07 Mar 2011 18:46:02 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D759350.8060402@gmail.com> References: <4D758CAD.2010602@gmail.com> <4D758F95.90800@sandglass-software.com> <4D759350.8060402@gmail.com> Message-ID: <4D75986A.6020003@sandglass-software.com> http://download.oracle.com/javase/tutorial/essential/concurrency/executors.html -Adrian On 3/7/2011 6:24 PM, Curtis Hacker wrote: > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: >> Drop the requests into a queue, and then have a separate thread >> service the queue. >> >> -Adrian >> >> On 3/7/2011 5:55 PM, Curtis Hacker wrote: >>> I have finally deduced my slow data logging to a latency issue. >>> >>> I write software for dsms, and the protocol is request / receive, >>> you cannot do more than 1 sensor at a time. So when you log multiple >>> sensors, +20ms per item, sampling rate drops like a rock. >>> >>> I was wondering if there is any ideas besides going completely >>> native with my application to reduce latency. With or without events >>> I don't care at this point I need to kill as much of the latency as >>> possible. Realistically I need no more than 1ms. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Mon Mar 7 19:50:45 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 19:50:45 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Mon Mar 7 20:04:01 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 19:04:01 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> Message-ID: <4D759CA1.8010903@gmail.com> I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. in.read(data, 0, 2); ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? On 03/07/11 18:50, jfh at greenhousepc.com wrote: > Curtis, > > No, I assume he means a real queue, not just "don't read all the bytes > at once." However, if you know you can process some number of > requests in some amount of time, allowing data to pile up (receiver > FIFO space permitting) can be a valid strategy. Inserting gobs of > Thread.yield() and notify() can help pep things up as well. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Mon, March 07, 2011 8:24 pm > To: rxtx at qbang.org > > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: > > Drop the requests into a queue, and then have a separate thread > > service the queue. > > > > -Adrian > > > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: > >> I have finally deduced my slow data logging to a latency issue. > >> > >> I write software for dsms, and the protocol is request / > receive, you > >> cannot do more than 1 sensor at a time. So when you log multiple > >> sensors, +20ms per item, sampling rate drops like a rock. > >> > >> I was wondering if there is any ideas besides going completely > native > >> with my application to reduce latency. With or without events I > don't > >> care at this point I need to kill as much of the latency as > possible. > >> Realistically I need no more than 1ms. > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From bartley at cmu.edu Mon Mar 7 20:08:05 2011 From: bartley at cmu.edu (Chris Bartley) Date: Mon, 7 Mar 2011 22:08:05 -0500 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> Message-ID: <9B1804F9-DBD0-476D-9345-806D00065A97@cmu.edu> We use a queue for all our request/response serial communications, and have found it really easy to work with. Code is here: http://code.google.com/p/create-lab-commons/source/browse/trunk/java/code/serial/src/edu/cmu/ri/createlab/serial/SerialPortCommandExecutionQueue.java It's assuming a command & response scheme that's specific to the protocol we use to talk to our robots, but it should be easy to modify for your needs. Hope this helps. Let me know if you have questions. Chris On Mar 7, 2011, at 9:50 PM, wrote: > Curtis, > > No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > Date: Mon, March 07, 2011 8:24 pm > To: rxtx at qbang.org > > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: > > Drop the requests into a queue, and then have a separate thread > > service the queue. > > > > -Adrian > > > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: > >> I have finally deduced my slow data logging to a latency issue. > >> > >> I write software for dsms, and the protocol is request / receive, you > >> cannot do more than 1 sensor at a time. So when you log multiple > >> sensors, +20ms per item, sampling rate drops like a rock. > >> > >> I was wondering if there is any ideas besides going completely native > >> with my application to reduce latency. With or without events I don't > >> care at this point I need to kill as much of the latency as possible. > >> Realistically I need no more than 1ms. > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Mon Mar 7 20:51:17 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 20:51:17 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110307205116.8ef0e5b4a80cef441275a6330ffad77d.9b325137d1.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From kharrington at neuronrobotics.com Mon Mar 7 20:55:23 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 22:55:23 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 7 In-Reply-To: References: Message-ID: To answer a few of you, I have changed the license to "Other open source license" as suggested. My company is modifying and maintaining this fork to support our robotics development library (http://code.google.com/p/nr-sdk/ http://dev.neuronrobotics.com). We will be implementing the standard serial port interface only, as it is the only one we need or care about. As for where the implementation came from, i would have to refer to my other developer to answer that. I wrote the build scripts and make files, as well as streamlining the C build process. I have remover the configure script, as it ends up being more confusing then compiling 3 C files needs to be. if you guys want to bring any of this into the main line, that's cool, but up to you to port over. Our fork will be focusing on polishing up the serial interface,and hopefully making it faster. I hope some of you will find our improvements useful! On Mon, Mar 7, 2011 at 6:53 PM, wrote: > Send Rxtx mailing list submissions to > ? ? ? ?rxtx at qbang.org > > To subscribe or unsubscribe via the World Wide Web, visit > ? ? ? ?http://mailman.qbang.org/mailman/listinfo/rxtx > or, via email, send a message with subject or body 'help' to > ? ? ? ?rxtx-request at qbang.org > > You can reach the person managing the list at > ? ? ? ?rxtx-owner at qbang.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Rxtx digest..." > > > Today's Topics: > > ? 1. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 2. Re: Rxtx Digest, Vol 43, Issue 6 (Kustaa Nyholm) > ? 3. Re: Rxtx Digest, Vol 43, Issue 6 (Scott Howard) > ? 4. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 5. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 6. Re: Rxtx Digest, Vol 43, Issue 6 (Kevin Harrington NR) > ? 7. Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! > ? ? ?(iqzw2r602 at sneakemail.com) > ? 8. Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! > ? ? ?(Aaron Wolfe) > ? 9. Re: [SPAM] Re: ?NRJavaSerial, a fork of rxtx that fixes the > ? ? ?papercuts! (jfh at greenhousepc.com) > ?10. Re: Rxtx Digest, Vol 43, Issue 6 (Trent Jarvi) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 7 Mar 2011 14:50:33 -0500 > From: Jason Sachs > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > >> From: Kevin Harrington NR >> To: rxtx at qbang.org >> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> > > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with > a ten-foot pole. > > > ------------------------------ > > Message: 2 > Date: Mon, 7 Mar 2011 22:10:43 +0200 > From: Kustaa Nyholm > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > On 3/7/11 21:50, "Jason Sachs" wrote: >> >>Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >>a ten-foot pole. >>_______________________________________________ > > Oh crap, makes it useless for me and many others. > > Also I see no provision in RxTx license to change > it so how could anyone change it to GPLv3? > > br Kusti > > > > ------------------------------ > > Message: 3 > Date: Mon, 7 Mar 2011 15:24:08 -0500 > From: Scott Howard > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 3:10 PM, Kustaa Nyholm > wrote: >> Also I see no provision in RxTx license to change >> it so how could anyone change it to GPLv3? > > I think this is allowed: > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. ?To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. ?(If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) ?Do not make any other change in > these notices. > > ? Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > ? This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > > ------------------------------ > > Message: 4 > Date: Mon, 7 Mar 2011 15:24:47 -0500 > From: Jason Sachs > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 2:50 PM, Jason Sachs wrote: >>> From: Kevin Harrington NR >>> To: rxtx at qbang.org >>> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >>> Message-ID: >>> ? ? ? ? >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> Hey all, this is just a heads up that i have made a fork of >>> rxtxSerial. Some of the features we have added: >>> >> >> Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >> a ten-foot pole. >> > > Let me back up a second (perhaps to make up for my lack of diplomacy) > and state that I think any progress w/ rxtx is good. > > If an rxtx fork were LGPL (or some other non-spreading open source > license) and leading in a good direction, I'd gladly return the favor > by posting any improvements or bugfixes I found to the community. > > --Jason > > > ------------------------------ > > Message: 5 > Date: Mon, 7 Mar 2011 15:36:13 -0500 > From: Jason Sachs > To: rxtx at qbang.org, kharrington at neuronrobotics.com > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > Kevin: could you clarify the license? > > http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java > has the RXTX 2.1 license > (LGPL v 2.1 + Linking Over Controlled Interface.) > > but http://code.google.com/p/nrjavaserial/ says GPLv3. > > --Jason > > > ------------------------------ > > Message: 6 > Date: Mon, 7 Mar 2011 16:00:02 -0500 > From: Kevin Harrington NR > To: Jason Sachs > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > The one downside to google code is that it does not allow custom > licensing. You have to pick from a drop-down list. Treat the licences > on the files themselves as the licence to be concerned with, and > ignore the "project licence". Sorry for the confusion. > > On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >> Kevin: could you clarify the license? >> >> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >> has the RXTX 2.1 license >> (LGPL v 2.1 + Linking Over Controlled Interface.) >> >> but http://code.google.com/p/nrjavaserial/ says GPLv3. >> >> --Jason >> > > > ------------------------------ > > Message: 7 > Date: Tue, 8 Mar 2011 08:08:18 +1100 > From: iqzw2r602 at sneakemail.com > To: Rxtx at qbang.org > Subject: Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > ? ? ? ?papercuts! > Message-ID: <11253-1299532098-811882 at sneakemail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Nice! > > Out of curiosity, did you use the patch that I sent Trent about two years > ago to do the native library loading, or did you implement your own > solution? > > Cheers, > > Uwe > > On Tue, Mar 8, 2011 at 5:46 AM, Kustaa Nyholm Kustaa.Nyholm-at-planmeca.com| > rxtx.org mailing list/Example Allow| wrote: > >> On 3/7/11 19:47, "Kevin Harrington NR" >> wrote: >> >> >Hey all, this is just a heads up that i have made a fork of >> >rxtxSerial. Some of the features we have added >> >> >> >> great! If also does what it says on the tin: brilliant! >> >> Congrats and thanks. >> >> br Kusti >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 8 > Date: Mon, 7 Mar 2011 17:31:47 -0500 > From: Aaron Wolfe > To: rxtx at qbang.org > Subject: Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > ? ? ? ?papercuts! > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR > wrote: >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> >> * Self deployment of native libraries ( all native code is stored >> inside the jar and deployed at runtime). No more manual install of >> native code. >> * Arm Cortex support (Gumstix) >> * Android Support (requires a rooted phone for now) >> * Google Code (SVN) repository for easy code and jar access >> * Single makefile compile (simplifies the compilation of project binaries) >> * Ant build script for jar creation >> * Removal of partialy implemented code to streamline the lib for just >> serial port access >> * Full Eclipse integration, for testing application code against sources. >> >> And a bunch of bug fixes: >> >> * Fixed the memory access error that causes OSX to crash the JVM when >> serial.close() is cvalled >> * Fixed the windows serial port zombie bind that prevents re-accessing >> serial ports when exiting on an exception >> * Fixed erronious printouts of native library mis-match >> >> To check it out, take a look at our page here: >> >> http://code.google.com/p/nrjavaserial/ > > This is interesting, getting the native libs set up has been an issue > for some of my users. ?Will have to check it out. > > Out of curiosity, what Android devices provide a serial port? ?Or are > there some that allow USB host mode and then a usb-serial adapter? ?I > have only an Android cell phone, don't think it can do anything serial > but would love to be wrong about that. > > > ------------------------------ > > Message: 9 > Date: Mon, 07 Mar 2011 15:54:39 -0700 > From: > To: aaron at aaronwolfe.com, rxtx at qbang.org > Subject: Re: [Rxtx] [SPAM] Re: ?NRJavaSerial, a fork of rxtx that > ? ? ? ?fixes the papercuts! > Message-ID: > ? ? ? ?<20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe at email13.secureserver.net> > > Content-Type: text/plain; charset="us-ascii" > > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 10 > Date: Mon, 7 Mar 2011 16:53:50 -0700 (MST) > From: Trent Jarvi > To: rxtx at qbang.org > Cc: Jason Sachs > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > Hi Kevin, > > Until Google fixes the options as developers have requested, I'd suggest > the least misleading dropdown option is "Other Open Source" with a > clarification about LGPL 2.1 on the project page. > > If you are not supporting the CommAPI SPI interface that was available > prior to the current JSR so that applications work in the javax.comm > namespace, there is no need for the linking over controlled interfaces > exception. ?RXTX 2.0 is used in that fashion but RXTX 2.1 is not. ?The > exception explicitly states it can be removed if the source has been > modified. ?The license is then explicitly OSI reviewed and approved as > Google requests but is not in their drop down box as it should be and is > for the GPL v2. > > ? ? ? ?http://opensource.org/licenses/alphabetical > ? ? ? ?http://opensource.org/licenses/lgpl-2.1 > > The drawback would be that the library effectively could never be used in > that SPI/controlled interface fashion again. > > On Mon, 7 Mar 2011, Kevin Harrington NR wrote: > >> The one downside to google code is that it does not allow custom >> licensing. You have to pick from a drop-down list. Treat the licences >> on the files themselves as the licence to be concerned with, and >> ignore the "project licence". Sorry for the confusion. >> >> On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >>> Kevin: could you clarify the license? >>> >>> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >>> has the RXTX 2.1 license >>> (LGPL v 2.1 + Linking Over Controlled Interface.) >>> >>> but http://code.google.com/p/nrjavaserial/ says GPLv3. >>> >>> --Jason >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > ------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > End of Rxtx Digest, Vol 43, Issue 7 > *********************************** > From Kustaa.Nyholm at planmeca.com Mon Mar 7 21:43:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 8 Mar 2011 06:43:57 +0200 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307205116.8ef0e5b4a80cef441275a6330ffad77d.9b325137d1.wbe@email13.secureserver.net> Message-ID: On 3/8/11 05:51, "jfh at greenhousepc.com" wrote: >Curtis, > > >None of that is relevant, as long as the UART is reasonable and the code >implements a proper half duplex protocol. > >If I understand correctly, you send a byte, the sensor sends back two >bytes. So long as you don't send the next byte until the two bytes are >in the UART receiver FIFO, you're fine. You don't have to actually >=read= them, just know they are available. To the OP, are you using a serial USB port, like FTDI? This has a built in latency of 10ms ie nothing is actually sent out of the device if you send less than 64 bytes until 10 msec timeout. This has nothing to do with RxTx. If you search the list archives you'll find more about this issue and IIRC someone reported that there is some diver parameter you can tweak to get rid of that latency. I'm sure the FTDI people had a good reason for this but it really brings down the communication speed if your protocol uses short messages and need to wait for a response. Sorry if this has already been mentioned or if this is not relevant, I've not been paying attention to this thread. br Kusti From bob_jacobsen at lbl.gov Tue Mar 8 00:02:28 2011 From: bob_jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 8 Mar 2011 00:02:28 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D759CA1.8010903@gmail.com> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> Message-ID: If you're transferring three bytes total at 1953 baud, it's going to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to wait 20msec to get the data back instead of 15.4 msec doesn't seem to be as big a problem as you're making it sound. Bob On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. > > To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. > > So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. > > in.read(data, 0, 2); > ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? > > On 03/07/11 18:50, jfh at greenhousepc.com wrote: >> Curtis, >> >> No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker >> Date: Mon, March 07, 2011 8:24 pm >> To: rxtx at qbang.org >> >> Sample code ? >> >> I don't necessarily want to read the byte I just wrote, but wait till >> the que depth is 2. >> >> Setup a thread without a sleep timer: >> if (in.available() > 1) { >> do_stuff(); >> } >> >> ?? >> >> On 03/07/11 18:08, Adrian Crum wrote: >> > Drop the requests into a queue, and then have a separate thread >> > service the queue. >> > >> > -Adrian >> > >> > On 3/7/2011 5:55 PM, Curtis Hacker wrote: >> >> I have finally deduced my slow data logging to a latency issue. >> >> >> >> I write software for dsms, and the protocol is request / receive, you >> >> cannot do more than 1 sensor at a time. So when you log multiple >> >> sensors, +20ms per item, sampling rate drops like a rock. >> >> >> >> I was wondering if there is any ideas besides going completely native >> >> with my application to reduce latency. With or without events I don't >> >> care at this point I need to kill as much of the latency as possible. >> >> Realistically I need no more than 1ms. >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From hakcenter at gmail.com Tue Mar 8 01:33:24 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 00:33:24 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> Message-ID: <4D75E9D4.5090307@gmail.com> I am going to try a couple things today and hopefully figure something out. Bob I don't want to pop your bubble, but a native application named 'TunerPro' can sample the same data, over 30 sensors, in less than 25ms. I've exchanged some emails with the author and it is a native C, polling, no events just timeouts. Kusta thanks for the FTDI notice, I believe that is tunable, however I have a particular user using a Keyspan converter and verified sampling rate with 'TunerPro' and its just off the charts. Chris thank you, I'll look into the queing. On 03/07/11 23:02, Bob Jacobsen wrote: > If you're transferring three bytes total at 1953 baud, it's going to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to wait 20msec to get the data back instead of 15.4 msec doesn't seem to be as big a problem as you're making it sound. > > Bob > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > >> I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. >> >> To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. >> >> So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. >> >> in.read(data, 0, 2); >> ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? >> >> On 03/07/11 18:50, jfh at greenhousepc.com wrote: >>> Curtis, >>> >>> No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. >>> -- >>> Julie Haugh >>> Senior Design Engineer >>> greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype From msemtd at googlemail.com Tue Mar 8 01:50:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 8 Mar 2011 08:50:15 +0000 Subject: [Rxtx] Latency Woes In-Reply-To: <4D75E9D4.5090307@gmail.com> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> <4D75E9D4.5090307@gmail.com> Message-ID: On 8 March 2011 08:33, Curtis Hacker wrote: > I am going to try a couple things today and hopefully figure something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than 25ms. > I've exchanged some emails with the author and it is a native C, polling, no > events just timeouts. Perhaps the author of TunerPro will let you use his native code - sounds just what you need. Regards, Michael Erskine. From jfh at greenhousepc.com Tue Mar 8 04:00:18 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 04:00:18 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 12:33:35 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 11:33:35 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> Message-ID: <4D76848F.5080809@gmail.com> Cable schematic: http://i1106.photobucket.com/albums/h377/vigilart/jackal%20logging%20set%20up/RS232SCHEMATIC.jpg 0.00268554 TunerPro.exe IOCTL_SERIAL_SET_BAUD_RATE VCP0 SUCCESS Rate: 1952 0.00305178 TunerPro.exe IOCTL_SERIAL_SET_RTS VCP0 SUCCESS 0.00297524 TunerPro.exe IOCTL_SERIAL_SET_DTR VCP0 SUCCESS 0.00297384 TunerPro.exe IOCTL_SERIAL_SET_LINE_CONTROL VCP0 SUCCESS StopBits: 1 Parity: NONE WordLength: 8 0.00000335 TunerPro.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 0.00202540 TunerPro.exe IOCTL_SERIAL_SET_HANDFLOW VCP0 SUCCESS Shake:1 Replace:40 XonLimit:2048 XoffLimit:512 0.00000335 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:300 RM:0 RC:2000 WM:0 WC:110 0.00000279 TunerPro.exe IOCTL_SERIAL_SET_QUEUE_SIZE VCP0 SUCCESS InSize: 1024 OutSize: 512 0.00000307 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000279 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:300 RM:0 RC:2000 WM:0 WC:110 0.00000307 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:75 RM:0 RC:400 WM:0 WC:300 0.00000559 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: RXCLEAR 0.00000335 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: TXCLEAR 0.00064980 TunerPro.exe IRP_MJ_WRITE VCP0 SUCCESS Length 1: . 0.01498738 TunerPro.exe IRP_MJ_READ VCP0 SUCCESS Length 1: . 0.00000363 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:200 RM:0 RC:20 WM:0 WC:300 0.02042774 TunerPro.exe IRP_MJ_READ VCP0 TIMEOUT Length 0: That is time on the left side. Now I'm with you on timing, it doesn't make a lot of sense, but that is how the logs come out. You can view the logs yourself. Tunerpro log : http://www.ds-map.net/tunerpro_log.csv My apps log : http://www.ds-map.net/my_log.csv 2nd app log : http://www.ds-map.net/my_log2.csv All these logs, were done from the same car, same cable. I have some older logs with some palm software, that was 13 sensors, and had a total 45-55ms between each set of 13. More info about the car / ecu at http://mmcdlogger.sourceforge.net Disassembly on the ecu: [SS1:SS0] is baud rate divider, 00(16) 01(128) 10(1024) 11(4096), assuming basic clock of 2MHZ, we get 125000baud, 15625baud, 1953baud, 488baud In any event, I attempted a no sleep thread, that waited till in.available > 1, and it wasn't any faster than running the events. Then I tried a read write thread, that slept from 1ms to 30ms after it wrote (so it wouldn't read what it just wrote). And couldn't get it doing much. I wish I had more of an understanding of all of this, which is why I'm asking for help. On 03/08/11 03:00, jfh at greenhousepc.com wrote: > Curtis, > > At the risk of being told "No, they really say it can be done", 30 > sensors is 30 * 3 character times (are you sure it's not a single byte > response?). At 1953 baud, a single character time is 10 bits * (1 / > 1953) seconds, or 15.4ms as Bob pointed out. 30 * 15.4ms is 460ms, > and that assumes everything works perfectly, no turnaround times, etc. > > If you can come up with some other way to make the math work, I'd love > to hear it. > > Short and sweet -- just because TunerPro can talk to an ECM/ECU that > is running faster than 1953 baud doesn't mean your Mitsubishi (or > whatever car you've got that runs at 1953 baud) runs at that faster > baud rate. > > Also, are you sure your data cable is correct? What cable are you > using? What's the schematic? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 2:33 am > To: rxtx at qbang.org > > I am going to try a couple things today and hopefully figure > something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than > 25ms. > I've exchanged some emails with the author and it is a native C, > polling, no events just timeouts. > > Kusta thanks for the FTDI notice, I believe that is tunable, > however I > have a particular user using a Keyspan converter and verified > sampling > rate with 'TunerPro' and its just off the charts. > > Chris thank you, I'll look into the queing. > > On 03/07/11 23:02, Bob Jacobsen wrote: > > If you're transferring three bytes total at 1953 baud, it's going > to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to > wait 20msec to get the data back instead of 15.4 msec doesn't seem > to be as big a problem as you're making it sound. > > > > Bob > > > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > > > >> I guess I'm gunna need some serious help with this then, because > of the scenario I'm stuck with. > >> > >> To communicate there is only 1 data line, rx/tx tied together > with a diode protecting the tx. No RTS/CTS handshaking nothing.. > >> > >> So the ecu can't process the next byte of info, without you > pulling the 2 bytes back. I wish this was standard, but even the > baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard > spot with this.. > >> > >> in.read(data , 0, 2); > >> ^ would the above wait till the timeout to read 2 bytes ? or > read 1 byte wait for the 2nd ? or just read the 1 ?? > >> > >> On 03/07/11 18:50, jfh at greenhousepc.com > wrote: > >>> Curtis, > >>> > >>> No, I assume he means a real queue, not just "don't read all > the bytes at once." However, if you know you can process some > number of requests in some amount of time, allowing data to pile > up (receiver FIFO space permitting) can be a valid strategy. > Inserting gobs of Thread.yield() and notify() can help pep things > up as well. > >>> -- > >>> Julie Haugh > >>> Senior Design Engineer > >>> greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 13:12:03 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 12:12:03 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> Message-ID: <4D768D93.1030504@gmail.com> So I looked over the Tunerpro log again today.. is it me or does it appear to be reusing values ? On 03/08/11 03:00, jfh at greenhousepc.com wrote: > Curtis, > > At the risk of being told "No, they really say it can be done", 30 > sensors is 30 * 3 character times (are you sure it's not a single byte > response?). At 1953 baud, a single character time is 10 bits * (1 / > 1953) seconds, or 15.4ms as Bob pointed out. 30 * 15.4ms is 460ms, > and that assumes everything works perfectly, no turnaround times, etc. > > If you can come up with some other way to make the math work, I'd love > to hear it. > > Short and sweet -- just because TunerPro can talk to an ECM/ECU that > is running faster than 1953 baud doesn't mean your Mitsubishi (or > whatever car you've got that runs at 1953 baud) runs at that faster > baud rate. > > Also, are you sure your data cable is correct? What cable are you > using? What's the schematic? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 2:33 am > To: rxtx at qbang.org > > I am going to try a couple things today and hopefully figure > something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than > 25ms. > I've exchanged some emails with the author and it is a native C, > polling, no events just timeouts. > > Kusta thanks for the FTDI notice, I believe that is tunable, > however I > have a particular user using a Keyspan converter and verified > sampling > rate with 'TunerPro' and its just off the charts. > > Chris thank you, I'll look into the queing. > > On 03/07/11 23:02, Bob Jacobsen wrote: > > If you're transferring three bytes total at 1953 baud, it's going > to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to > wait 20msec to get the data back instead of 15.4 msec doesn't seem > to be as big a problem as you're making it sound. > > > > Bob > > > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > > > >> I guess I'm gunna need some serious help with this then, because > of the scenario I'm stuck with. > >> > >> To communicate there is only 1 data line, rx/tx tied together > with a diode protecting the tx. No RTS/CTS handshaking nothing.. > >> > >> So the ecu can't process the next byte of info, without you > pulling the 2 bytes back. I wish this was standard, but even the > baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard > spot with this.. > >> > >> in.read(data , 0, 2); > >> ^ would the above wait till the timeout to read 2 bytes ? or > read 1 byte wait for the 2nd ? or just read the 1 ?? > >> > >> On 03/07/11 18:50, jfh at greenhousepc.com > wrote: > >>> Curtis, > >>> > >>> No, I assume he means a real queue, not just "don't read all > the bytes at once." However, if you know you can process some > number of requests in some amount of time, allowing data to pile > up (receiver FIFO space permitting) can be a valid strategy. > Inserting gobs of Thread.yield() and notify() can help pep things > up as well. > >>> -- > >>> Julie Haugh > >>> Senior Design Engineer > >>> greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 13:51:13 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 13:51:13 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308135113.8ef0e5b4a80cef441275a6330ffad77d.a5fff5bbc7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From bob_jacobsen at lbl.gov Tue Mar 8 14:14:57 2011 From: bob_jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 8 Mar 2011 14:14:57 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D76848F.5080809@gmail.com> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> Message-ID: <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > Tunerpro log : http://www.ds-map.net/tunerpro_log.csv It's only reading one sensor per line. Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT changed in lines 16 and 40; every 24 lines but at a different phase. GramsRev in lines 23 and 47; every 24 lines, at yet another phase. Looks like (69-1) readings in 1.30 seconds = 19msec per reading. Arithmetic still works! Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From hakcenter at gmail.com Tue Mar 8 14:27:12 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 13:27:12 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> Message-ID: <4D769F30.9050807@gmail.com> Thank you guys, cause I was really worried there. I guess another win for math today hahaha. So what is the imposed latency that rxtx has ? maybe 5-10ms ? On 03/08/11 13:14, Bob Jacobsen wrote: > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > It's only reading one sensor per line. > > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT changed in lines 16 and 40; every 24 lines but at a different phase. GramsRev in lines 23 and 47; every 24 lines, at yet another phase. > > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. Arithmetic still works! > > Bob > -- > Bob Jacobsen, LBNL > Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue Mar 8 14:07:24 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Mar 2011 14:07:24 -0700 (MST) Subject: [Rxtx] Latency Woes In-Reply-To: <4D769F30.9050807@gmail.com> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> <4D769F30.9050807@gmail.com> Message-ID: Hi Curtis While not your exact question, a simple test I performed can give you a ballpark idea. Writing a byte to a loopback at 9600 baud and displaying elapsed time on the data available event takes ~10 ms round trip in a large application. There are occasional 20 ms latencies. I used a typical linux desktop to try it just now without any special considerations. Windows NT was a little faster - maybe 8 ms - when I tried several years ago. On Tue, 8 Mar 2011, Curtis Hacker wrote: > Thank you guys, cause I was really worried there. I guess another win for > math today hahaha. So what is the imposed latency that rxtx has ? maybe > 5-10ms ? > > On 03/08/11 13:14, Bob Jacobsen wrote: >> On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >>> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> It's only reading one sensor per line. >> >> Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT >> changed in lines 16 and 40; every 24 lines but at a different phase. >> GramsRev in lines 23 and 47; every 24 lines, at yet another phase. >> >> Looks like (69-1) readings in 1.30 seconds = 19msec per reading. >> Arithmetic still works! >> >> Bob >> -- >> Bob Jacobsen, LBNL >> Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >> JacobsenRG >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Wei.Shen at Honeywell.com Tue Mar 8 15:15:32 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Tue, 8 Mar 2011 17:15:32 -0500 Subject: [Rxtx] [rxtx] disconnect event Message-ID: <83B3B1411349194D9D05821CEF48E78C02284B17@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 16:05:12 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 16:05:12 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 16:26:15 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 15:26:15 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> References: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> Message-ID: <4D76BB17.2090305@gmail.com> So if I could get the baud up 15625, theoretical maximum latency is 1.92ms ? Basically 500 samples/sec ? 125000, theoretical maximum latency is 0.24ms ? Basically 4167 samples/sec ? Keeping the protocol the same. On 03/08/11 15:05, jfh at greenhousepc.com wrote: > Curtis, > > It's nowhere near that bad. I'd measured it once before, and I > believe it's sub-millisecond. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 3:27 pm > To: rxtx at qbang.org > > Thank you guys, cause I was really worried there. I guess another win > for math today hahaha. So what is the imposed latency that rxtx has ? > maybe 5-10ms ? > > On 03/08/11 13:14, Bob Jacobsen wrote: > > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > > It's only reading one sensor per line. > > > > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 > lines. IAT changed in lines 16 and 40; every 24 lines but at a > different phase. GramsRev in lines 23 and 47; every 24 lines, at > yet another phase. > > > > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. > Arithmetic still works! > > > > Bob > > -- > > Bob Jacobsen, LBNL > > Bob_Jacobsen at lbl.gov > +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Tue Mar 8 17:40:36 2011 From: jredman at ergotech.com (Jim Redman) Date: Tue, 08 Mar 2011 17:40:36 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D76BB17.2090305@gmail.com> References: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> <4D76BB17.2090305@gmail.com> Message-ID: <4D76CC84.9040307@ergotech.com> How long does it take the device to generate a response? Increasing the baud rate may not help you much if the device takes a significant amount of time to process the request. On 03/08/2011 04:26 PM, Curtis Hacker wrote: > So if I could get the baud up > 15625, theoretical maximum latency is 1.92ms ? Basically 500 samples/sec ? > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 samples/sec ? > > Keeping the protocol the same. > > On 03/08/11 15:05, jfh at greenhousepc.com wrote: >> Curtis, >> >> It's nowhere near that bad. I'd measured it once before, and I >> believe it's sub-millisecond. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker > >> Date: Tue, March 08, 2011 3:27 pm >> To: rxtx at qbang.org >> >> Thank you guys, cause I was really worried there. I guess another win >> for math today hahaha. So what is the imposed latency that rxtx has ? >> maybe 5-10ms ? >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> > It's only reading one sensor per line. >> > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 >> lines. IAT changed in lines 16 and 40; every 24 lines but at a >> different phase. GramsRev in lines 23 and 47; every 24 lines, at >> yet another phase. >> > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. >> Arithmetic still works! >> > >> > Bob >> > -- >> > Bob Jacobsen, LBNL >> > Bob_Jacobsen at lbl.gov >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 jfh at greenhousepc.com Tue Mar 8 17:58:24 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 17:58:24 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 18:06:04 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 18:06:04 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 18:14:14 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 17:14:14 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> References: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> Message-ID: <4D76D466.7060303@gmail.com> I can edit the ECU eeprom to change the baud rate divisor to bump it up from 1953, to 15625 or 125000. But as Jim asked how fast the device can respond.. not very fast in its stock form. I can recode a lot of the eeprom for the ecu to alter the ecus baud rate, and put the response code into its own interrupt. I just wanted to make sure that in order to lower latency and increase sampling rate. I have to increase the baud rate of the ecu and the user right ? Or change the protocol.. to respond with more sensors per request. On 03/08/11 16:58, jfh at greenhousepc.com wrote: > Unless the ECU can auto-detect the baud rate, it won't even work. > > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Jim Redman > > Date: Tue, March 08, 2011 6:40 pm > To: rxtx at qbang.org > > How long does it take the device to generate a response? > > Increasing the baud rate may not help you much if the device takes a > significant amount of time to process the request. > > > On 03/08/2011 04:26 PM, Curtis Hacker wrote: > > So if I could get the baud up > > 15625, theoretical maximum latency is 1.92ms ? Basically 500 > samples/sec ? > > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 > samples/sec ? > > > > Keeping the protocol the same. > > > > On 03/08/11 15:05, jfh at greenhousepc.com > wrote: > >> Curtis, > >> > >> It's nowhere near that bad. I'd measured it once before, and I > >> believe it's sub-millisecond. > >> -- > >> Julie Haugh > >> Senior Design Engineer > >> greenHouse Computers, LLC // jfh at greenhousepc.com > > >> ; // > greenHousePC on Skype > >> > >> > >> -------- Original Message -------- > >> Subject: Re: [Rxtx] Latency Woes > >> From: Curtis Hacker > > >> Date: Tue, March 08, 2011 3:27 pm > >> To: rxtx at qbang.org > >> > >> Thank you guys, cause I was really worried there. I guess > another win > >> for math today hahaha. So what is the imposed latency that rxtx > has ? > >> maybe 5-10ms ? > >> > >> On 03/08/11 13:14, Bob Jacobsen wrote: > >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > >> > It's only reading one sensor per line. > >> > > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 > >> lines. IAT changed in lines 16 and 40; every 24 lines but at a > >> different phase. GramsRev in lines 23 and 47; every 24 lines, at > >> yet another phase. > >> > > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. > >> Arithmetic still works! > >> > > >> > Bob > >> > -- > >> > Bob Jacobsen, LBNL > >> > Bob_Jacobsen at lbl.gov > > >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > >> > > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Tue Mar 8 18:19:14 2011 From: jredman at ergotech.com (Jim Redman) Date: Tue, 08 Mar 2011 18:19:14 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> References: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> Message-ID: <4D76D592.9000802@ergotech.com> I'm no expert on this, but isn't the underlying ODB-II CAN bus or something similar. They always seem to require a dongle that converts to something. I know you can get serial, bluetooth, USB, etc. converters. I've seen serial dongles that claim multiple baud rates, so I suspect that whatever's providing the conversion may significantly affect the performance. A big second on the required timing comment. I suspect some intelligent consideration of what values change quickly (RPM, Speed, maybe things like fuel pressure) and read values like fuel levels, coolant temps, etc. much less frequently. On 03/08/2011 06:06 PM, jfh at greenhousepc.com wrote: > Curtis, > > You can't just increase the baud rate and have the device adapt to that > rate. Embedded systems tend to have their communications parameters > either hard coded in a memory location or else they are using a hardware > timebase. You're welcome to try increasing the baud rate, but there is > no guarantee it will even work. > > Whoever designed the ECU probably selected the baud rate for a good > reason. My suggestion would be to look at how the sensor values are all > laid out and go from there. Also, look at what the sensor represent and > consider the physical properties of what is being measured. It's > extremely unlikely that, for example, the coolant temperature is going > to rise more than 1* per second. If that much. Some values might change > more often, but do they really matter on a sub-second measurement basis? > > Part of software =engineering= is understanding the problem. Anyone can > sling code in the hope it works. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 5:26 pm > To: rxtx at qbang.org > > So if I could get the baud up > 15625, theoretical maximum latency is 1.92ms ? Basically 500 > samples/sec ? > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 > samples/sec ? > > Keeping the protocol the same. > > On 03/08/11 15:05, jfh at greenhousepc.com wrote: >> Curtis, >> >> It's nowhere near that bad. I'd measured it once before, and I >> believe it's sub-millisecond. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker > > >> Date: Tue, March 08, 2011 3:27 pm >> To: rxtx at qbang.org >> >> Thank you guys, cause I was really worried there. I guess >> another win >> for math today hahaha. So what is the imposed latency that >> rxtx has ? >> maybe 5-10ms ? >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> > It's only reading one sensor per line. >> > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every >> 24 lines. IAT changed in lines 16 and 40; every 24 lines but >> at a different phase. GramsRev in lines 23 and 47; every 24 >> lines, at yet another phase. >> > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per >> reading. Arithmetic still works! >> > >> > Bob >> > -- >> > Bob Jacobsen, LBNL >> > Bob_Jacobsen at lbl.gov >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > ------------------------------------------------------------------------ > _______________________________________________ > Rxtx mailing list > Rxtx 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 jfh at greenhousepc.com Tue Mar 8 18:32:28 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 18:32:28 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 19:45:00 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 18:45:00 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> References: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> Message-ID: <4D76E9AC.8050909@gmail.com> Julie, I really am not looking at the practicality of it. I was just wondering if that is how it works. I don't know a whole lot about rs232, which is the main reason I've been on this mailing list for a couple years. I have full control over the ecu eeprom code, I can change its baud rate, I can re-write the logging interface, I could update the ADC's on the ecu in the interface so that when you request said sensor it updates the ADC then replies it. But I wanted to know if the underlying issue with a 2mhz/8mhz processor is the baud rate keeping sampling down ? On 03/08/11 17:32, jfh at greenhousepc.com wrote: > Curtis, > > You also have to look at the response time of the sensor itself. > > Seriously -- look at what the sensors are reporting and determine if > the underlying physical property can actually change that rapidly. > And even if it can, do you really need to know that. > > I built drag bikes in the 70's and I drive sports cars in my old age. > You don't really need millisecond sampling rates for every single last > sensor coming out of the engine. Boost pressure, fuel pressure, > manifold pressure and RPMs are probably high frequency sensors if you > want to tweak the motor for turbo lag or something, but other than > that, are you really going to be able to make sense of all that data? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 7:14 pm > To: rxtx at qbang.org > > I can edit the ECU eeprom to change the baud rate divisor to bump > it up from 1953, to 15625 or 125000. But as Jim asked how fast the > device can respond.. not very fast in its stock form. > > I can recode a lot of the eeprom for the ecu to alter the ecus > baud rate, and put the response code into its own interrupt. > > I just wanted to make sure that in order to lower latency and > increase sampling rate. I have to increase the baud rate of the > ecu and the user right ? Or change the protocol.. to respond with > more sensors per request. > > On 03/08/11 16:58, jfh at greenhousepc.com wrote: >> Unless the ECU can auto-detect the baud rate, it won't even work. >> >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Jim Redman > > >> Date: Tue, March 08, 2011 6:40 pm >> To: rxtx at qbang.org >> >> How long does it take the device to generate a response? >> >> Increasing the baud rate may not help you much if the device >> takes a >> significant amount of time to process the request. >> >> >> On 03/08/2011 04:26 PM, Curtis Hacker wrote: >> > So if I could get the baud up >> > 15625, theoretical maximum latency is 1.92ms ? Basically 500 >> samples/sec ? >> > 125000, theoretical maximum latency is 0.24ms ? Basically >> 4167 samples/sec ? >> > >> > Keeping the protocol the same. >> > >> > On 03/08/11 15:05, jfh at greenhousepc.com >> wrote: >> >> Curtis, >> >> >> >> It's nowhere near that bad. I'd measured it once before, and I >> >> believe it's sub-millisecond. >> >> -- >> >> Julie Haugh >> >> Senior Design Engineer >> >> greenHouse Computers, LLC // jfh at greenhousepc.com >> >> >> ; // >> greenHousePC on Skype >> >> >> >> >> >> -------- Original Message -------- >> >> Subject: Re: [Rxtx] Latency Woes >> >> From: Curtis Hacker > > >> >> Date: Tue, March 08, 2011 3:27 pm >> >> To: rxtx at qbang.org >> >> >> >> >> Thank you guys, cause I was really worried there. I guess >> another win >> >> for math today hahaha. So what is the imposed latency that >> rxtx has ? >> >> maybe 5-10ms ? >> >> >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> >> > It's only reading one sensor per line. >> >> > >> >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; >> every 24 >> >> lines. IAT changed in lines 16 and 40; every 24 lines but at a >> >> different phase. GramsRev in lines 23 and 47; every 24 >> lines, at >> >> yet another phase. >> >> > >> >> > Looks like (69-1) readings in 1.30 seconds = 19msec per >> reading. >> >> Arithmetic still works! >> >> > >> >> > Bob >> >> > -- >> >> > Bob Jacobsen, LBNL >> >> > Bob_Jacobsen at lbl.gov >> >> >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Rxtx mailing list >> >> > Rxtx at qbang.org >> >> >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > ------------------------------------------------------------------------ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 20:43:11 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 20:43:11 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308204311.8ef0e5b4a80cef441275a6330ffad77d.e9b135168c.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From andrea.antonello at gmail.com Wed Mar 9 06:50:07 2011 From: andrea.antonello at gmail.com (andrea antonello) Date: Wed, 9 Mar 2011 14:50:07 +0100 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> References: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> Message-ID: Has anyone tried the lib? I am not sure if it is appropriate to write to the list about this, if not, I apologize. I wanted to try your fork out for our application which is an eclipse rcp plugin based one. It has been easy to substitute the 6 plugins with your library (that is one of the things I like). But then when I run it, it tries to load it from: ---- Loading: /tmp/libNRJavaSerial_moovida_0/libNRJavaSerial.so Trying to load: NRJavaSerial Trying to load: libNRJavaSerial Trying to load: rxtxSerial ---- So it is extracting the native lib to a tmp folder. But that one is not in the library path, so it fails. Is there any docs to try the lib out? Thanks, Andrea On Mon, Mar 7, 2011 at 11:54 PM, wrote: > Aaron, > > It should be possible for an Android to do BlueTooth serial.? If I were > looking for a serial solution, that's how I'd go. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on > Skype > > -------- Original Message -------- > Subject: [SPAM] Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > papercuts! > From: Aaron Wolfe > Date: Mon, March 07, 2011 4:31 pm > To: rxtx at qbang.org > > On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR > wrote: >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> >> * Self deployment of native libraries ( all native code is stored >> inside the jar and deployed at runtime). No more manual install of >> native code. >> * Arm Cortex support (Gumstix) >> * Android Support (requires a rooted phone for now) >> * Google Code (SVN) repository for easy code and jar access >> * Single makefile compile (simplifies the compilation of project binaries) >> * Ant build script for jar creation >> * Removal of partialy implemented code to streamline the lib for just >> serial port access >> * Full Eclipse integration, for testing application code against sources. >> >> And a bunch of bug fixes: >> >> * Fixed the memory access error that causes OSX to crash the JVM when >> serial.close() is cvalled >> * Fixed the windows serial port zombie bind that prevents re-accessing >> serial ports when exiting on an exception >> * Fixed erronious printouts of native library mis-match >> >> To check it out, take a look at our page here: >> >> http://code.google.com/p/nrjavaserial/ > > This is interesting, getting the native libs set up has been an issue > for some of my users. Will have to check it out. > > Out of curiosity, what Android devices provide a serial port? Or are > there some that allow USB host mode and then a usb-serial adapter? I > have only an Android cell phone, don't think it can do anything serial > but would love to be wrong 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 Cougar at CasaDelGato.Com Wed Mar 9 10:02:24 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 09 Mar 2011 09:02:24 -0800 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> References: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> Message-ID: <4D77B2A0.8020004@CasaDelGato.Com> On 3/7/2011 2:54 PM, jfh at greenhousepc.com wrote: > Aaron, > > It should be possible for an Android to do BlueTooth serial. If I > were looking for a serial solution, that's how I'd go. Actually, I can't figure out WHY you would need RxTx on an Android device. The built in bluetooth support works just fine with a serial-bluetooth converter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Mar 1 00:54:17 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 09:54:17 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> Message-ID: Adrian, had a look at your code/rewrite and it looks rather clean/nice. I was looking at the code to gain insight (not related to the rewrite) into what is involved in serial port programming in Windows. Or rather, to refresh my memory and see how others have done, because I've been there done that. So my questions are just to satisfy my curiosity, not to criticize or suggest improvements. 1) It looks like a new thread (EventMonitor) is created for each Serial port, is that correct? Many people seem to try to avoid using many threads in this sort of situation, and like to use something like unix select(). I personally find using threads more natural and better impedance match to the problem being solved here. I guess 'many people' above refers to those implementing thousands of connections and who cannot live with the overhead and limited number of threads available. 2) The EventMonitor basically polls for events at 50 msec interval? 3) There is a comment in the source code near the sleep(50) : // Sufficient up to 19200 baud I'm sure you thought about this carefully, so again not criticizing, but seeking to understand how or why, because at 50 msec would seem to limit through in some cases. Like if you send one byte and need to wait for one to return, then this limits speed to 200 chars/sec? 4) I've done something similar to a few years back from Java using JNI to access Win32 API serial port, and I seem to recall that I had threading issues ie when I submitted a read (ReadFile) and there was no data coming in, the thread would not only block but also consume a lot of CPU cycles ie it was not sleeping properly inside the ReadFile call when the serial port blocked. Im a bit fuzzy about the details after five years, so my question is have you checked if there an issue here? 5) AFAIK the select() on Windows does not work serial ports but there is some other mechanism (events?) to implement the same functionality, did you consider that? Probably, so you decided against it, why? br Kusti From adrian.crum at sandglass-software.com Tue Mar 1 04:13:34 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:13:34 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: References: Message-ID: <4D6CD4DE.7040501@sandglass-software.com> The javax.comm API specification requires one event monitor thread per port. I don't like the idea of having a thread per port either, but one of the rewrite's design goals is strict conformance to the specification. The 50 mS polling interval is just a placeholder. The final design of that is yet to be decided. In Windows, you have two choices for I/O: overlapped and non-overlapped. In overlapped I/O a thread is blocked, waiting for something to happen. In non-overlapped I/O a thread does not block. I chose non-overlapped I/O to avoid thread blocking at the OS level - instead, the thread blocking is kept in Java. -Adrian On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > Adrian, > > had a look at your code/rewrite and it looks rather clean/nice. > > I was looking at the code to gain insight (not related to the > rewrite) into what is involved in serial port programming > in Windows. Or rather, to refresh my memory and see how others have > done, because I've been there done that. > > So my questions are just to satisfy my curiosity, not to criticize > or suggest improvements. > > 1) It looks like a new thread (EventMonitor) is created for > each Serial port, is that correct? > > Many people seem to try to avoid using many threads in this sort > of situation, and like to use something like unix select(). > I personally find using threads more natural and better impedance > match to the problem being solved here. I guess 'many people' above > > refers to those implementing thousands of connections and > who cannot live with the overhead and limited number of threads > available. > > 2) The EventMonitor basically polls for events at 50 msec interval? > > 3) There is a comment in the source code near the sleep(50) : > > // Sufficient up to 19200 baud > > > I'm sure you thought about this carefully, so again not > criticizing, but seeking to understand how or why, because > at 50 msec would seem to limit through in some cases. Like > if you send one byte and need to wait for one to return, > then this limits speed to 200 chars/sec? > > 4) I've done something similar to a few years back from > Java using JNI to access Win32 API serial port, and > I seem to recall that I had threading issues ie when > I submitted a read (ReadFile) and there was no data coming > in, the thread would not only block but also consume a > lot of CPU cycles ie it was not sleeping properly inside > the ReadFile call when the serial port blocked. > > Im a bit fuzzy about the details after five years, so my question is > have you checked if there an issue here? > > > 5) AFAIK the select() on Windows does not work serial ports > but there is some other mechanism (events?) to implement the > same functionality, did you consider that? Probably, so you > decided against it, why? > > > br Kusti > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Tue Mar 1 04:25:23 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:25:23 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C2E90.9010601@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > My question would be: Why would you do that? The rewrite does > most of the work for you - all you have to do is implement > two C++ virtual classes and two C++ functions. You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? I just took a short look, maybe it could be discussed further, but I don't think I like it much. BTW, the main interface defined there is called gnu.io.Dispatcher? I thought the package names should be used in a way to avoid clashes, e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name space authority :)). > In Windows that took me a few hours. where is the implementation? I found commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp with things like const bool SerialPortImpl::isDataAvailable() const { // Needs implementation return true; } and timeouts.ReadIntervalTimeout = MAXDWORD;* timeouts.ReadTotalTimeoutMultiplier = 0; timeouts.ReadTotalTimeoutConstant = 0; timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 0; if (!SetCommTimeouts(hComm, &timeouts)) throw IOException(); which seems to be oversimplified or some prototype only? I think (and I wrote about this already in the past years) that correct timeout handling is one of the challenges, so I think this should be prototyped first - for each system flavor - before cementation of the (JNI-) interfaces. Personally, I would vote to form it in a way allowing to be implemented on embedded devices, for example. Another big challenge is to prove a rewrite fully working (and probably compatible to the old implementation) on "all" the supported OSes. Not a big problem for linux and windows, just use some thousand lines test code, test drivers and serial loopbacks etc, but for the exotic platforms, probably a high number of, this probably won't be too easy... (there are more challenges, such as being comfortable and threadsafe [are read and write permitted at the same time?], detailed and helpful exceptions on user API level [not necessarily on JNI/JNA layer], how to have a configurable threadsafe logging/tracing [maybe also from native code to assist porting / testing on exotic OSes, such as OSes where the developers have no direct access too, which can be quite hard to usually leads to good log messages], just to name a few.). So even it might seem easy for one platform and I agree with Micheal that > > * yay! let's start a rewrite is unlikely to succeede soon... However, when considering this, before IMHO a powerful Java API has to be defined, because according to my experiences for implementing non-trivial protocols InputStream/OutputStream might not be comfortable/powerfull enough (eventually I consider both wrong) and have some InputStream derivation available as wrapper (so applications can use InputStream and whatever high-level-API they want). The JNI interface shall make such a powerful implementation possible, thus the interface of it is driving the JNI interface design and thus I think it had to be done first. All this surely requires much work: agreements on the APIs, safeness for the users, design, documentation, all the implementations and the testing. As long as such bug amount of work cannot be spent, for example if some employee would get half a year time paid for it or so :-), probably it is unlikely to progress on this. Otherwise, I'm afraid, patches, improvements, new design ideas and even rewrites wouldn't become complete and thus won't form a new rxtx version (3.0); thus either collect dust in some forgotten CVS branch or could generate a split... > I can't imagine other ports taking > much longer than that - especially since POSIX-based code can > be shared between ports. Things are more complex than they seem to be... I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select on serial ports isn't supported; maybe it is non-trivial to "map" (like mapping select() to WaitForMultipleObjects() which might have different semantics etc.) or maybe some different approach has to be used. A system may have POSIX like termios interfaces but not support timeouts or have any other interoperability bug... You never run out of things that can go wrong. And if something can go wrong, it will... :-) Or, as Michael wrote: > > I seriously don't believe anyone will come up with anything better anytime soon. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue Mar 1 04:39:37 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:39:37 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com><13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED6B@COSNPREXC3.usr.ingenico.loc> > 3. Write all of the native (or non-native) code to implement > the native interface. > > Is that correct? If yes, how is that easier than the simple > implementation the current rewrite design uses? To have it complete, reliable, traceable, maintainable and well tested, it is much more work, I'm afraid. A prototype can be done within a few days (maybe on one day), but getting it right (including a passed review) IMHO is a completely different story. In the end you may end up with an average of ten lines per day, when assuming four major native packs (common, win, mac, termios/select) with let's say just 5000 lines each (with logging messages and detailed exceptions this is not much) we would have to estimate a total effort of nine man-years (20000/10/220)... oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 04:40:18 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:40:18 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6CDB22.9070401@sandglass-software.com> Every journey begins with a single step. -Adrian On 3/1/2011 3:25 AM, Steffen DETTMER wrote: > * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> My question would be: Why would you do that? The rewrite does >> most of the work for you - all you have to do is implement >> two C++ virtual classes and two C++ functions. > You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? > I just took a short look, maybe it could be discussed further, > but I don't think I like it much. > BTW, the main interface defined there is called gnu.io.Dispatcher? > I thought the package names should be used in a way to avoid clashes, > e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name > space authority :)). > >> In Windows that took me a few hours. > where is the implementation? > I found > commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp > with things like > > const bool SerialPortImpl::isDataAvailable() const > { > // Needs implementation > return true; > } > > and > > timeouts.ReadIntervalTimeout = MAXDWORD;* > timeouts.ReadTotalTimeoutMultiplier = 0; > timeouts.ReadTotalTimeoutConstant = 0; > timeouts.WriteTotalTimeoutMultiplier = 0; > timeouts.WriteTotalTimeoutConstant = 0; > if (!SetCommTimeouts(hComm,&timeouts)) > throw IOException(); > > which seems to be oversimplified or some prototype only? > > I think (and I wrote about this already in the past years) that correct > timeout handling is one of the challenges, so I think this should be > prototyped first - for each system flavor - before cementation of the > (JNI-) interfaces. Personally, I would vote to form it in a way allowing > to be implemented on embedded devices, for example. > > Another big challenge is to prove a rewrite fully working (and probably > compatible to the old implementation) on "all" the supported OSes. Not a > big problem for linux and windows, just use some thousand lines test > code, test drivers and serial loopbacks etc, but for the exotic > platforms, probably a high number of, this probably won't be too easy... > (there are more challenges, such as being comfortable and threadsafe > [are read and write permitted at the same time?], detailed and helpful > exceptions on user API level [not necessarily on JNI/JNA layer], how to > have a configurable threadsafe logging/tracing [maybe also from native > code to assist porting / testing on exotic OSes, such as OSes where the > developers have no direct access too, which can be quite hard to usually > leads to good log messages], just to name a few.). > > So even it might seem easy for one platform and I agree with Micheal > that > >>> * yay! let's start a rewrite > is unlikely to succeede soon... > > However, when considering this, before IMHO a powerful Java API has to > be defined, because according to my experiences for implementing > non-trivial protocols InputStream/OutputStream might not be > comfortable/powerfull enough (eventually I consider both wrong) and have > some InputStream derivation available as wrapper (so applications can > use InputStream and whatever high-level-API they want). > The JNI interface shall make such a powerful implementation possible, > thus the interface of it is driving the JNI interface design and thus I > think it had to be done first. > > All this surely requires much work: agreements on the APIs, safeness for > the users, design, documentation, all the implementations and the > testing. As long as such bug amount of work cannot be spent, for example > if some employee would get half a year time paid for it or so :-), > probably it is unlikely to progress on this. > > Otherwise, I'm afraid, patches, improvements, new design ideas and even > rewrites wouldn't become complete and thus won't form a new rxtx version > (3.0); thus either collect dust in some forgotten CVS branch or could > generate a split... > >> I can't imagine other ports taking >> much longer than that - especially since POSIX-based code can >> be shared between ports. > Things are more complex than they seem to be... > > I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select > on serial ports isn't supported; maybe it is non-trivial to "map" (like > mapping select() to WaitForMultipleObjects() which might have different > semantics etc.) or maybe some different approach has to be used. A > system may have POSIX like termios interfaces but not support timeouts > or have any other interoperability bug... > You never run out of things that can go wrong. And if something can go > wrong, it will... :-) > > Or, as Michael wrote: > >>> I seriously don't believe anyone will come up with anything better > anytime soon. > > oki, > > Steffen > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Kustaa.Nyholm at planmeca.com Tue Mar 1 04:57:02 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 13:57:02 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: On 3/1/11 13:13, "Adrian Crum" wrote: >The javax.comm API specification requires one event monitor thread per >port. I don't like the idea of having a thread per port either, but one >of the rewrite's design goals is strict conformance to the specification. Ah, had not spotted that requirement. > >The 50 mS polling interval is just a placeholder. The final design of >that is yet to be decided. > >In Windows, you have two choices for I/O: overlapped and non-overlapped. >In overlapped I/O a thread is blocked, waiting for something to happen. >In non-overlapped I/O a thread does not block. I chose non-overlapped >I/O to avoid thread blocking at the OS level - instead, the thread >blocking is kept in Java. > >-Adrian thanks for the explanation. br Kusti From iqzw2r602 at sneakemail.com Tue Mar 1 05:08:17 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:08:17 +1100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <32684-1298981297-704398@sneakemail.com> This reminds me of a nasty problem I had with overlapped I/O on windows with jpathwatch. You can't start an I/O request in one thread and then do the check if that request completed in another thread. Very strange things happen when you attempt that; made me change the design of the Windows implementation quite drastically (one thread on a command queue that executes requests from other threads instead of letting them wildly call into GetOverlappedResult()). Out of curiosity: Did you come across that too? Or are all requests handled in the same thread they're issued? Cheers, Uwe On Tue, Mar 1, 2011 at 10:13 PM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > The javax.comm API specification requires one event monitor thread per > port. I don't like the idea of having a thread per port either, but one of > the rewrite's design goals is strict conformance to the specification. > > The 50 mS polling interval is just a placeholder. The final design of that > is yet to be decided. > > In Windows, you have two choices for I/O: overlapped and non-overlapped. In > overlapped I/O a thread is blocked, waiting for something to happen. In > non-overlapped I/O a thread does not block. I chose non-overlapped I/O to > avoid thread blocking at the OS level - instead, the thread blocking is kept > in Java. > > -Adrian > > > On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > >> Adrian, >> >> had a look at your code/rewrite and it looks rather clean/nice. >> >> I was looking at the code to gain insight (not related to the >> rewrite) into what is involved in serial port programming >> in Windows. Or rather, to refresh my memory and see how others have >> done, because I've been there done that. >> >> So my questions are just to satisfy my curiosity, not to criticize >> or suggest improvements. >> >> 1) It looks like a new thread (EventMonitor) is created for >> each Serial port, is that correct? >> >> Many people seem to try to avoid using many threads in this sort >> of situation, and like to use something like unix select(). >> I personally find using threads more natural and better impedance >> match to the problem being solved here. I guess 'many people' above >> >> refers to those implementing thousands of connections and >> who cannot live with the overhead and limited number of threads >> available. >> >> 2) The EventMonitor basically polls for events at 50 msec interval? >> >> 3) There is a comment in the source code near the sleep(50) : >> >> // Sufficient up to 19200 baud >> >> >> I'm sure you thought about this carefully, so again not >> criticizing, but seeking to understand how or why, because >> at 50 msec would seem to limit through in some cases. Like >> if you send one byte and need to wait for one to return, >> then this limits speed to 200 chars/sec? >> >> 4) I've done something similar to a few years back from >> Java using JNI to access Win32 API serial port, and >> I seem to recall that I had threading issues ie when >> I submitted a read (ReadFile) and there was no data coming >> in, the thread would not only block but also consume a >> lot of CPU cycles ie it was not sleeping properly inside >> the ReadFile call when the serial port blocked. >> >> Im a bit fuzzy about the details after five years, so my question is >> have you checked if there an issue here? >> >> >> 5) AFAIK the select() on Windows does not work serial ports >> but there is some other mechanism (events?) to implement the >> same functionality, did you consider that? Probably, so you >> decided against it, why? >> >> >> br Kusti >> >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 05:37:07 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:37:07 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <1142-1298983027-957144@sneakemail.com> On Tue, Mar 1, 2011 at 1:32 PM, Adrian Crum wrote: > Just to make sure I'm understanding you correctly, anyone porting RxTx to > a new platform would have to do the following: > > 1. Write their own Java implementation of an abstract Dispatcher class. > yep. I'd probably put all my calls to native OS wrappers in there two, looks the most straight-forward to me. > 2. Write a native (JNI or JNA) interface for the abstract class > implementation. > yes. For POSIX you'd probably only write one piece of code that provides implementations for open(), close(), and friends. You can compile that on all posix platforms (yeah, the devil is in the detail, but it's very little code, still). So this does open() (when using ***, but you can also use +++) // Unix.java class Unix{ public static native int open(String filename, int flags, int mode); .... } // Unix.cpp JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) { const char* pathname = env->GetStringUTFChars(jpathname, 0); if(pathname == 0) return -1; // java throws an out of memory error in this case int result = open(pathname, flags, mode); Unix_cacheErrno(); // handle interference between JVM and errno; env->ReleaseStringUTFChars(jpathname, pathname); return result; } .... 3. Write all of the native (or non-native) code to implement the native > interface. > Not sure what you mean by that. I've done the OS wrappers in step 2. step 1. implements that Dispatcher. What else do I need? > Is that correct? If yes, how is that easier than the simple implementation > the current rewrite design uses? > Yes, except for 3 (see above). How it is easier: I can debug the Java code directly. I can step from the read() call of an input stream directly into the guts of the RXTX implementation on my platform and see e.g. why it's hanging, because I see all the way up the call stack right where it calls Unix.read(). You can't easily do that with a fat native library, especially if you have no second set of devtools installed (the ones for native development). And I bet anyone knowing both languages can write it faster in Java, with less bugs. > On a side note: there is no requirement to write native code using C++. If > C++ is a real obstacle to adoption, then regular C could be used instead. In > that case, there would be a Dispatcher.c file that contains function > protoypes that need to be implemented. Dispatcher.c would still maintain the > same role as Dispatcher.cpp - which is to shield native code developers from > the details of JNI. Just build out the missing functions using C data types > and you're ready to go. > As I said, whatever works for you. Java works for me better than C++ in this case... Cheers, Uwe -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Mar 1 08:26:41 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 16:26:41 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> > The javax.comm API specification requires one event monitor > thread per port. Where does it require this? Do you mean "All the events received by this listener are generated by one dedicated thread that belongs to the SerialPort object. "? I think this is an implementation detail, isn't it? At least it is mentioned after "The current implementation only allows one listener per SerialPort". A bit bad that javadoc does not distinguish between API spec and implementation documentation. Also I don't think that TooManyListenersException MUST be thrown (I think it CAN be thrown). > I don't like the idea of having a thread per > port either, but one of the rewrite's design goals is strict > conformance to the specification. (but not necessarily on JNI layer) > The 50 mS polling interval is just a placeholder. The final > design of that is yet to be decided. I though no polling would be wanted; what could be the placeholder stand for? Do you mean a different interval duration or do you mean something completely different? > In Windows, you have two choices for I/O: overlapped and > non-overlapped. > In overlapped I/O a thread is blocked, waiting for something > to happen. > In non-overlapped I/O a thread does not block. I chose > non-overlapped I/O to avoid thread blocking at the OS level - > instead, the thread blocking is kept in Java. Isn't "overlapped" (asynchronous) I/O meaning that you invoke some ReadFile(..., &overlapped, ...) INSTEAD of performing a synchronous (blocking) function call blocking the thread? As far as I see, W32_Support.cpp uses CreateFile without FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O operations are serialized, even if the calls to the read and write functions specify an OVERLAPPED structure." [1] and "A synchronous handle behaves such that I/O function calls using that handle are blocked until they complete" [2] Given that CCOMTIMEOUTS get: "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the bytes that have already been received, even if no bytes have been received." [3] It looks likes this implementation relies on polling, which probably would waste much computing power. What did I miss? oki, Steffen [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro nous_and_asynchronous_i_o_handles [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 09:23:47 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:23:47 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6D1D93.6090306@sandglass-software.com> Unfortunately, the javax.comm API specification includes a lot of implementation details. That is one of the weaknesses of the specification in my opinion. The bottom line is, anyone wanting to use RxTx as a javax.comm implementation is going to expect it to do the things the specification says it does. -Adrian On 3/1/2011 7:26 AM, Steffen DETTMER wrote: >> The javax.comm API specification requires one event monitor >> thread per port. > Where does it require this? > > Do you mean "All the events received by this listener are generated > by one dedicated thread that belongs to the SerialPort object. "? > > I think this is an implementation detail, isn't it? At least it is > mentioned after "The current implementation only allows one listener per > SerialPort". A bit bad that javadoc does not distinguish between API > spec and implementation documentation. Also I don't think that > TooManyListenersException MUST be thrown (I think it CAN be thrown). > >> I don't like the idea of having a thread per >> port either, but one of the rewrite's design goals is strict >> conformance to the specification. > (but not necessarily on JNI layer) > >> The 50 mS polling interval is just a placeholder. The final >> design of that is yet to be decided. > I though no polling would be wanted; what could be the placeholder stand > for? Do you mean a different interval duration or do you mean something > completely different? > >> In Windows, you have two choices for I/O: overlapped and >> non-overlapped. >> In overlapped I/O a thread is blocked, waiting for something >> to happen. >> In non-overlapped I/O a thread does not block. I chose >> non-overlapped I/O to avoid thread blocking at the OS level - >> instead, the thread blocking is kept in Java. > Isn't "overlapped" (asynchronous) I/O meaning that you invoke some > ReadFile(...,&overlapped, ...) > INSTEAD of performing a synchronous (blocking) function call blocking > the thread? > > As far as I see, W32_Support.cpp uses CreateFile without > FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O > operations are serialized, even if the calls to the read and write > functions specify an OVERLAPPED structure." [1] and "A synchronous > handle behaves such that I/O function calls using that handle are > blocked until they complete" [2] > > Given that CCOMTIMEOUTS get: > "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values > for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier > members, specifies that the read operation is to return immediately with > the bytes that have already been received, even if no bytes have been > received." [3] > > It looks likes this implementation relies on polling, which probably > would waste much computing power. > > What did I miss? > > oki, > > Steffen > > [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx > [2] > http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro > nous_and_asynchronous_i_o_handles > [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at sandglass-software.com Tue Mar 1 09:55:29 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:55:29 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <1142-1298983027-957144@sneakemail.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> Message-ID: <4D6D2501.1020803@sandglass-software.com> That code duplicates what is in Dispatcher.cpp. A Unix port would only need to implement CommPortFactory::getInstance(portName, portType). -Adrian On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 15:07:46 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 2 Mar 2011 09:07:46 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6D2501.1020803@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> <4D6D2501.1020803@sandglass-software.com> Message-ID: <23749-1299017266-991798@sneakemail.com> What is this duplicating? A Unix port will need to call open() anyways (just so we're talking about the same thing here: open() is the Unix equivalent of CreateFile()) On Wed, Mar 2, 2011 at 3:55 AM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > That code duplicates what is in Dispatcher.cpp. A Unix port would only > need to implement CommPortFactory::getInstance(portName, portType). > > -Adrian > > > On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Tue Mar 1 22:53:07 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 00:53:07 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: Hi, I haven't seen any response to my question below. Is this not the right place to ask? If not, where would be a better place to ask? Any suggestions? Thanks, Ryan On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >> Hi, >> >> I have a receive thread that does nothing but call read() on the serial >> port input stream. It works fine for a while but after running for a long >> time it eventually returns -1 which means EOF. This is my first problem, as >> the device I'm talking to runs forever, I don't know why it would return -1. >> I am calling disableReceiveThreshold() and disableReceiveTimeout() at >> initialization which according to the documentation means read will return >> as soon as any data is available and it will block forever when data is not >> available, so -1 should never be returned from read, right? >> >> I have been unable to figure out why read returns -1 after a long while >> but I have found that if I kill my application and restart it everything >> works fine again. Therefore I tried to work around the problem by having my >> code close the port and reopen it when read returns -1. My second problem is >> that in this case when I call close() on the port it blocks forever. I did >> find this old bug >> >> http://bugzilla.qbang.org/show_bug.cgi?id=53 >> >> which describes close() hanging on OSX, but it says that bug was fixed >> with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have >> any idea why read might be returning -1 in the first place? If I can avoid >> that I don't care about close() hanging because I would never close the >> port. If not, does anyone know why close() might block forever and how I can >> prevent this? I'm using RXTX version 2.1-7. >> >> Thanks, >> -- >> Ryan >> >> > > > -- > Ryan Boder > 1 614 598-6339 > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Mar 2 01:34:48 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 2 Mar 2011 10:34:48 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/2/11 07:53, "Ryan Boder" wrote: Can you / have you made a simple test to ensure that rxtx is the issue? Can you write a simple C-program to see if this exhibits the same problem? I've never encountered this sort of problem with rxtx, it mostly just works. But I'm on Mac so can't say about Windows (7) br Kusti >Hi, > >I haven't seen any response to my question below. Is this not the right >place to ask? If not, where would be a better place to ask? Any >suggestions? > >Thanks, >Ryan > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > >I mis-spoke, I don't have my own thread calling read, I am calling >read in the event handler after receiving a >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be >accurate though. > >Ryan > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >Hi, > >I have a receive thread that does nothing but call read() on the serial >port input stream. It works fine for a while but after running for a long >time it eventually returns -1 which means EOF. This is my first problem, >as the device I'm talking to runs forever, I don't know why it would >return -1. I am calling disableReceiveThreshold() and >disableReceiveTimeout() at initialization which according to the >documentation means read will return as soon as any data is available and >it will block forever when data is not available, so -1 should never be >returned from read, right? > >I have been unable to figure out why read returns -1 after a long while >but I have found that if I kill my application and restart it everything >works fine again. Therefore I tried to work around the problem by having >my code close the port and reopen it when read returns -1. My second >problem is that in this case when I call close() on the port it blocks >forever. I did find this old bug > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > >which describes close() hanging on OSX, but it says that bug was fixed >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone >have any idea why read might be returning -1 in the first place? If I can >avoid that I don't care about close() hanging because I would never close >the port. If not, does anyone know why close() might block forever and >how I can prevent this? I'm using RXTX version 2.1-7. > >Thanks, >-- >Ryan > > > > > > > > > >-- >Ryan Boder >1 614 598-6339 > > > > > > >-- >Ryan Boder >1 614 598-6339 > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From Steffen.DETTMER at ingenico.com Wed Mar 2 03:08:57 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:08:57 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <32684-1298981297-704398@sneakemail.com> References: <4D6CD4DE.7040501@sandglass-software.com> <32684-1298981297-704398@sneakemail.com> Message-ID: <20110302100857.GB8030@elberon.bln.de.ingenico.com> * iqzw2r602 at sneakemail.com wrote on Tue, Mar 01, 2011 at 23:08 +1100: > This reminds me of a nasty problem I had with overlapped I/O on windows Yeah, those thousands of complex, difficult to use and exception-containing WinAPI is really hard to use... About strange effects on overlapped&multithreading, MSDN has: `the calling thread uses the GetOverlappedResult function or one of the wait functions' [1] also also mentiones I/O Completion Ports [2], and later continues: `If an application reuses OVERLAPPED structures on multiple threads and calls GetOverlappedResult with the bWait parameter set to TRUE, the application must ensure that the associated event is set before the application reuses the structure. This can be accomplished by using the WaitForSingleObject function after calling GetOverlappedResult to force the thread to wait until the operation completes. Note that the event object must be a manual-reset event object. If an autoreset event object is used, calling GetOverlappedResult with the bWait parameter set to TRUE causes the function to be blocked indefinitely.' also [1] oki, Steffen [1] http://msdn.microsoft.com/en-us/library/ms686358%28v=vs.85%29.aspx [2] http://msdn.microsoft.com/en-us/library/aa365198%28v=vs.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:15:11 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:15:11 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6D1D93.6090306@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> <4D6D1D93.6090306@sandglass-software.com> Message-ID: <20110302101511.GC8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 08:23 -0800: > Unfortunately, the javax.comm API specification includes a lot of > implementation details. That is one of the weaknesses of the > specification in my opinion. The bottom line is, anyone wanting to use > RxTx as a javax.comm implementation is going to expect it to do the > things the specification says it does. Yeah ok, but even then the implementation could check for the TooManyListenersException situations (if it really is required to support applications relying on that exception) but internally use just a single I/O thread waiting for events on any open file descriptors. Of course an implementation supporting all sort of concurrency could become quite complex (especially if open-read-close should work fast, I think would be difficult to implement, because a new file descriptors had to be added to the waitFor/select list, and who knows how systems behave here in detail...). oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:25:15 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:25:15 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6CDB22.9070401@sandglass-software.com> References: <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> <4D6CDB22.9070401@sandglass-software.com> Message-ID: <20110302102515.GD8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 03:40 -0800: > * from some older mail: > > My question would be: Why would you do that? The rewrite does > > most of the work for you - all you have to do is implement > > two C++ virtual classes and two C++ functions. > > > > In Windows that took me a few hours. > > Every journey begins with a single step. Yes, of course, but then it shouldn't be used as base for new effort estimations like `In Windows that took a few hours' ;-) (BTW, calling a single step `the rewrite' may sound a bit ambitious ;)) But of course a prototype demonstrating something can be really helpful, sure. I just wanted to tell that interfaces should be easy to use and powerful at the same time and may non-trivial initial considerations before starting to implement them. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From ryan.boder at gmail.com Wed Mar 2 18:44:35 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:44:35 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: While running the tests you requested I may have stumbled on the problem, I just don't know how to fix it. According to the documentation, if both the receive timeout and receive threshold are disabled then read() should block forever until data is available. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#getInputStream%28%29 On my system using RXTX read() is returning -1 when no data is available even though I have disabled both thresholds. The reason my program was running fine for a while without this problem showing up is that I was using the DATA_AVAILABLE event to be notified when data is available and only calling read() to read an entire frame whenever the DATA_AVAILABLE event occurred, until eventually my device (I'm guessing) probably took longer than normal to send the entire data frame and therefore I called read when no data was available and it returned -1. The following Java program demonstrates my problem, it returns -1 as soon as no data is available, even though I think it should block until data is available. import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; public class Main implements SerialPortEventListener { public static void main(String[] args) throws Exception { new Main().run(); } private void run() throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier("COM4"); SerialPort port = (SerialPort) portIdentifier.open(Main.class.getName(), 2000); port.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); port.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); port.disableReceiveThreshold(); port.disableReceiveTimeout(); BufferedInputStream in = new BufferedInputStream(port.getInputStream()); BufferedOutputStream out = new BufferedOutputStream(port.getOutputStream()); port.addEventListener(this); Thread.sleep(1000); out.write(new byte[] {0x02, 0x60}); out.flush(); while (true) { int x = in.read(); if (x == -1) { System.out.println("EOF"); Thread.sleep(1000000000); } String s = Integer.toHexString(x & 0xFF); if (s.length() == 1) s = "0" + s; System.out.print(s + " "); System.out.flush(); } } public void serialEvent(SerialPortEvent arg0) { System.out.println("Serial port event"); } } However, the follow C# program ran all day today without ever read ever returning -1, as I would expect. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.IO.Ports; using System.Threading; namespace RXTXReadTest1 { class Program { static void Main(string[] args) { new Program().run(); } private void run() { SerialPort port = new SerialPort("COM4", 19200, Parity.None, 8, StopBits.One); port.Open(); port.Write(new byte[] { 0x02, 0x60 }, 0, 2); while (true) { int x = port.ReadByte(); if (x == -1) { Console.WriteLine("EOF"); Thread.Sleep(1000000000); } String s = x.ToString("X"); if (s.Length == 1 ) s = "0" + s; Console.Out.Write(s + " "); Console.Out.Flush(); } } } } Now I am experimenting with what happens if I set the receive timeout to it's maximum value (apparently 1600ms) and only call read() when I am expecting data. Hopefully it will never be more than 1600ms late. This is still only a work around, not solving the problem. Am I doing something wrong in my code above or is RXTX retuning -1 when it should be blocking? Thanks, Ryan On Wed, Mar 2, 2011 at 3:34 AM, Kustaa Nyholm wrote: > On 3/2/11 07:53, "Ryan Boder" wrote: > Can you / have you made a simple test to ensure that rxtx is the issue? > > Can you write a simple C-program to see if this exhibits the same problem? > > I've never encountered this sort of problem with rxtx, it mostly just > works. > > But I'm on Mac so can't say about Windows (7) > > br Kusti > > > > > >Hi, > > > >I haven't seen any response to my question below. Is this not the right > >place to ask? If not, where would be a better place to ask? Any > >suggestions? > > > >Thanks, > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder > wrote: > > > >I mis-spoke, I don't have my own thread calling read, I am calling > >read in the event handler after receiving a > >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be > >accurate though. > > > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder > wrote: > > > >Hi, > > > >I have a receive thread that does nothing but call read() on the serial > >port input stream. It works fine for a while but after running for a long > >time it eventually returns -1 which means EOF. This is my first problem, > >as the device I'm talking to runs forever, I don't know why it would > >return -1. I am calling disableReceiveThreshold() and > >disableReceiveTimeout() at initialization which according to the > >documentation means read will return as soon as any data is available and > >it will block forever when data is not available, so -1 should never be > >returned from read, right? > > > >I have been unable to figure out why read returns -1 after a long while > >but I have found that if I kill my application and restart it everything > >works fine again. Therefore I tried to work around the problem by having > >my code close the port and reopen it when read returns -1. My second > >problem is that in this case when I call close() on the port it blocks > >forever. I did find this old bug > > > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > > > >which describes close() hanging on OSX, but it says that bug was fixed > >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone > >have any idea why read might be returning -1 in the first place? If I can > >avoid that I don't care about close() hanging because I would never close > >the port. If not, does anyone know why close() might block forever and > >how I can prevent this? I'm using RXTX version 2.1-7. > > > >Thanks, > >-- > >Ryan > > > > > > > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Wed Mar 2 18:46:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:46:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: <-1051064942000733580@unknownmsgid> References: <-1051064942000733580@unknownmsgid> Message-ID: It is USB and seems very reliable with the C# test program in my previous email. On Wed, Mar 2, 2011 at 6:58 PM, Bruce Griffith wrote: > How reliable is your serial port ? is it USB or Bluetooth? > > > > Bruce Griffith > > 303-532-4778 > > > > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On Behalf > Of *Ryan Boder > *Sent:* Tuesday, 01 March 2011 10:53 PM > *To:* rxtx at qbang.org > *Subject:* Re: [Rxtx] RXTX serial port read() returns -1 unexpectedly and > then blocks forever on close() > > > > Hi, > > I haven't seen any response to my question below. Is this not the right > place to ask? If not, where would be a better place to ask? Any suggestions? > > Thanks, > Ryan > > On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > > Hi, > > I have a receive thread that does nothing but call read() on the serial > port input stream. It works fine for a while but after running for a long > time it eventually returns -1 which means EOF. This is my first problem, as > the device I'm talking to runs forever, I don't know why it would return -1. > I am calling disableReceiveThreshold() and disableReceiveTimeout() at > initialization which according to the documentation means read will return > as soon as any data is available and it will block forever when data is not > available, so -1 should never be returned from read, right? > > I have been unable to figure out why read returns -1 after a long while but > I have found that if I kill my application and restart it everything works > fine again. Therefore I tried to work around the problem by having my code > close the port and reopen it when read returns -1. My second problem is that > in this case when I call close() on the port it blocks forever. I did find > this old bug > > http://bugzilla.qbang.org/show_bug.cgi?id=53 > > which describes close() hanging on OSX, but it says that bug was fixed with > a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have any > idea why read might be returning -1 in the first place? If I can avoid that > I don't care about close() hanging because I would never close the port. If > not, does anyone know why close() might block forever and how I can prevent > this? I'm using RXTX version 2.1-7. > > Thanks, > -- > Ryan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Mar 3 02:50:20 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 3 Mar 2011 09:50:20 +0000 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: So if -1 is unexpectedly returned from read, and we have demonstrated that your USB-serial adapter can actually causes this to happen in RXTX, why not just ignore the -1 value? What happens when you try this? As for a hang on close, are your closing your port from within your serial event handler? I know that this can cause some serious problems. Regards, Michael Erskine. From Kustaa.Nyholm at planmeca.com Thu Mar 3 03:39:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 12:39:34 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 03:44, "Ryan Boder" wrote: >While running the tests you requested I may have stumbled on the problem, >I just don't know how to fix it. According to the documentation, if both >the receive timeout and receive threshold are disabled then read() should >block forever until data is available. > >http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/re >ference/api/javax/comm/CommPort.html#getInputStream%28%29 > >On my system using RXTX read() is returning -1 when no data is available >even though I have disabled both thresholds. The reason my program was >running fine for a while without this problem showing up is that I was >using the DATA_AVAILABLE event to be notified when data is available and >only calling read() to read an entire frame whenever the DATA_AVAILABLE >event occurred, until eventually my device (I'm guessing) probably took >longer than normal to send the entire data frame and therefore I called >read when no data was available and it returned -1. As a workaround have you tried to perform another read() if it returns -1? The javadoc says (see getInputStream): "Note, however, that framing errors may cause the Timeout and Threshold values to complete prematurely without raising an exception." I read this as a hint that read might return even if no data is available. Because of the above and that read() can only return -1 or the byte received it would be somewhat logical to return -1 in case of framing error ? I'm not claiming that my interpretation of the specification, such as it is, is correct, just speculating that the behavior could be something like that. It might give you some more insight if you used the read(bytes[],int,int) method, because this can and will return 0 in case of timeout (and presumably might do so in case of framing error, maybe some other error condition too). That might allow you to handle or work around the problem in this case. You have not shown your complete code (no need) but your comments and the example makes me wonder if the code is otherwise as it should be, meaning are you assuming that when you get the DATA_AVAILABLE event all of your frame has arrived and that you can just blindly read it away from the input stream? That is not guaranteed of course. Also using read(), instead of read(bytes[],int,int), is not very efficient and might be masking other problems as mused above. BTE you can print a byte in hex with leading zeros more easily with: System.out.printf("%02X",x); br Kusti From ryan.boder at gmail.com Thu Mar 3 07:56:16 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:56:16 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 5:39 AM, Kustaa Nyholm wrote: > > As a workaround have you tried to perform another read() if it returns -1? > I tried that and it did work sometimes but not all the time. > > The javadoc says (see getInputStream): > > "Note, however, that framing errors may cause the Timeout and Threshold > values to complete prematurely without raising an exception." > > I read this as a hint that read might return even if no data is available. > > Because of the above and that read() can only return -1 or the byte > received > it would be somewhat logical to return -1 in case of framing error ? > > I'm not claiming that my interpretation of the specification, such as it > is, > is correct, just speculating that the behavior could be something like > that. > Receive framing is not enabled by default. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#enableReceiveFraming%28int%29 My choice of word might be misleading, when I said frame I just meant a contiguous message from the device. I am not enabling receive framing. Can you have a framing error when receive framing is disabled? > > It might give you some more insight if you used the read(bytes[],int,int) > method, because > this can and will return 0 in case of timeout (and presumably might do so > in case of framing > error, maybe some other error condition too). > > That might allow you to handle or work around the problem in this case. > > You have not shown your complete code (no need) but your comments and the > example > makes me wonder if the code is otherwise as it should be, meaning are you > assuming > that when you get the DATA_AVAILABLE event all of your frame has arrived > and that > you can just blindly read it away from the input stream? That is not > guaranteed of course. > I'm not assuming the entire message has arrived, I'm just assuming it either has arrived or will arrive soon which is why I'm using a (supposedly) blocking read(). > > Also using read(), instead of read(bytes[],int,int), is not very efficient > and > might be masking other problems as mused above. > True, I'm reading one byte at a time because I don't know how long the message will be until I read and parse some of it. I suppose I can use read(bytes[],int,int) once I figure out how long the message will be. > > BTE you can print a byte in hex with leading zeros more easily with: > > > System.out.printf("%02X",x); > I did it the dumb way in that test program so I could copy and paste the code from C# to Java without having to figure out how to do the same in C# which I'm not as familiar with. Thanks and BR, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 07:58:24 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:58:24 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: Yes I was doing the close in the serial event handler, I didn't realize that caused a problem. Thanks, I'll fix it. On Thu, Mar 3, 2011 at 4:50 AM, Michael Erskine wrote: > So if -1 is unexpectedly returned from read, and we have demonstrated > that your USB-serial adapter can actually causes this to happen in > RXTX, why not just ignore the -1 value? What happens when you try > this? As for a hang on close, are your closing your port from within > your serial event handler? I know that this can cause some serious > problems. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 11:48:20 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 13:48:20 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm wrote: > On 3/3/11 16:56, "Ryan Boder" wrote: > > > >I'm not assuming the entire message has arrived, I'm just assuming it > >either has arrived or will arrive soon which is why I'm using a > >(supposedly) blocking read(). > > > I've been giving this some further thought. > > It does not feel healthy to block without timeout, especially > from within a thread that is essentially internal to the rxtx. > > I've never done that, I always use a time out, read(byte[],int,int) > for the expected number of bytes, check how much I got and issue > more reads until I get everything. > > You have not described how your communication works so I'm only > speculating. > > If your device needs some response to send more bytes (from your > code it looks like this is not the case) then a missing byte > would block your read and prevent you from responding and > getting more data. But as said, looks like that is not the case. > > Anyway, if this was my problem, I would enable the timeout > and use read(byte[],int,int) and loop until I get what I need. > You are right, I should and will use a timeout. In fact, my program has been running flawlessly for 12 hours and the only change I made was to enable a timeout, no change in the logic at all. Without the timeout read() was returning -1 usually after it ran for an hour or two. I will change the code to make use of the timeout and handle it appropriately. It still seems to me that RXTX's behavior doesn't match the documentation when rx timeout and rx threshold are disabled read() should block until data is available instead of immediately returning -1. I don't believe that a framing error is occurring immediately every time data is not available causing read() to return -1. Especially since the C# test program above runs all day with no error and the Java program above runs all day with no error when a timeout is enabled. To me it seems like enabling the timeout is what is causing read() to block until data is available, even if only for 1600ms, and without the timeout read() is returning -1 immediately when it should be blocking. Thanks for all the help and best regards, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Thu Mar 3 13:02:30 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 22:02:30 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 20:48, "Ryan Boder" wrote: >On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm > wrote: > >On 3/3/11 16:56, "Ryan Boder" wrote: >> > >>I'm not assuming the entire message has arrived, I'm just assuming it >>either has arrived or will arrive soon which is why I'm using a >>(supposedly) blocking read(). > > > >I've been giving this some further thought. > >It does not feel healthy to block without timeout, especially >from within a thread that is essentially internal to the rxtx. > >I've never done that, I always use a time out, read(byte[],int,int) >for the expected number of bytes, check how much I got and issue >more reads until I get everything. > >You have not described how your communication works so I'm only >speculating. > >If your device needs some response to send more bytes (from your >code it looks like this is not the case) then a missing byte >would block your read and prevent you from responding and >getting more data. But as said, looks like that is not the case. > >Anyway, if this was my problem, I would enable the timeout >and use read(byte[],int,int) and loop until I get what I need. > > > > >You are right, I should and will use a timeout. In fact, my program has >been running flawlessly for 12 hours and the only change I made was to >enable a timeout, no change in the logic at all. Without the timeout >read() was returning -1 usually after it ran for an hour or two. I will >change the code to make use of the timeout and handle it appropriately. That's nice! > >It still seems to me that RXTX's behavior doesn't match the documentation >when rx timeout and rx threshold are disabled read() should block until >data is available instead of immediately returning -1. Yeah, it does look like bug. However this might be related to some Windows specific serial port issue. Years ago I had issues with JavaComm (not RxTx) where I did a blocking read and I had huge issues with my program consuming all resources. I curser the Sun and JavaComm and re-code my own SerialPort using JNI to access the Win32 API directly. And I run into the same problems as with the Sun's implementation! So I ditched my code, changed my code to use timeouts and problems disappeared. > I don't believe that a framing error is occurring immediately every time >data is not available causing read() to return -1. Especially since the >C# test program above runs all day with no error and the Java program >above runs all day with no error when a timeout is enabled. I think so too, all things considered I don't really believe in framing errors in this case. > To me it seems like enabling the timeout is what is causing read() to >block until data is available, even if only for 1600ms, and without the >timeout read() is returning -1 immediately when it should be blocking. Yeah, I had a peek at the innards of RxTx Windows serial port a week or so ago and also read MSDN documentation about serial ports and the way overlapped and non-overlapped (non blocking and blocking) IO is handled is a way different. So yeah, it can well be that there is an issue lurking there somewhere inside RxTx in Windows. > > >Thanks for all the help and best regards, >-- >Ryan Boder I'm happy if I was of any assistance. br Kusti From tjarvi at qbang.org Thu Mar 3 18:52:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Mar 2011 18:52:50 -0700 (MST) Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: >> Without the timeout >> read() was returning -1 usually after it ran for an hour or two. There is a big hammer in rxtx causing that behavior. >> It still seems to me that RXTX's behavior doesn't match the documentation >> when rx timeout and rx threshold are disabled read() should block until >> data is available instead of immediately returning -1. > > Yeah, it does look like bug. However this might be related to some > Windows specific serial port issue. Years ago I had issues with > JavaComm (not RxTx) where I did a blocking read and I had huge > issues with my program consuming all resources. I curser the Sun > and JavaComm and re-code my own SerialPort using JNI to access > the Win32 API directly. And I run into the same problems as > with the Sun's implementation! So I ditched my code, changed > my code to use timeouts and problems disappeared. > > >> To me it seems like enabling the timeout is what is causing read() to >> block until data is available, even if only for 1600ms, and without the >> timeout read() is returning -1 immediately when it should be blocking. > > Yeah, I had a peek at the innards of RxTx Windows serial port a week > or so ago and also read MSDN documentation about serial ports and > the way overlapped and non-overlapped (non blocking and blocking) > IO is handled is a way different. So yeah, it can well be that > there is an issue lurking there somewhere inside RxTx in Windows. > > Yes. RXTX was patched to behave the way it does. I don't fully understand the issue behind the patch. Marc noticed the odd behavior as well and offered a fix which was greeted with resistance. The windows implementation was done without real documentatino of the windows API. I think I had an example from the late 80's early 90's on Microsoft's site and some API documentation that was obviously not microsofts in Europe. Wayne Roberts had a real need for windows support and fixed some major issues it had. My interest at the time was mingw32. I then cleaned it up for some specific uses I had later. The read returning -1 when it should block didn't impact anybody and appeared to help some people. It isnt the documented behavior though. There could be all sorts of latent bugs in that code but in the real world, it gets by in almost all use cases. Its a hack but it worked for 100's of thousands of people over a 14 year period. Maybe its time to revisit the code but there is more risk than gain for most people. How do you move forward and avoid the risk? Some have expressed interests in coding C++ or other efforts. I'm all for such efforts but feel some unit tests that work with a null modem cables are the only thing that will move rxtx (and perhaps CommAPI) forward. If we have a test suite in place as a qualification for implementations, progress can be made in the right direction regardless of the implementation details. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Fri Mar 4 02:57:16 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 4 Mar 2011 11:57:16 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/4/11 03:52, "Trent Jarvi" wrote: >Yes. RXTX was patched to behave the way it does. I don't fully >understand the issue behind the patch. Marc noticed the odd behavior as >well and offered a fix which was greeted with resistance. > >The windows implementation was done without real documentatino of the >windows API. I think I had an example from the late 80's early 90's on >Microsoft's site and some API documentation that was obviously not >microsofts in Europe. Wayne Roberts had a real need for windows support >and fixed some major issues it had. My interest at the time was mingw32. >I then cleaned it up for some specific uses I had later. The read >returning -1 when it should block didn't impact anybody and appeared to >help some people. It isnt the documented behavior though. > >There could be all sorts of latent bugs in that code but in the real >world, it gets by in almost all use cases. I think so too, never had any problems with it. > Its a hack but it worked for 100's of thousands of people over a 14 year >period. Yeah! Thanks for everyone who has contributed over the years, job well done! >Maybe its time to >revisit the code but there is more risk than gain for most people. How >do >you move forward and avoid the risk? My view is that it is quite risky and rather pointless to move forward, other than fixing bugs that really affect people. At the moment the major issue IMO is just that it seems (not been following this too carefully, so maybe I'm wrong, so in case this FUD, my apologies) that 'official' binaries are not available. I think the rewrite, tempting as it is in some respects is not the way forward. Just gentle maintenance to iron out real issues and then get the binaries out. br Kusti From ryan.boder at gmail.com Fri Mar 4 07:24:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Fri, 4 Mar 2011 09:24:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 8:52 PM, Trent Jarvi wrote: > > The windows implementation was done without real documentatino of the > windows API. I think I had an example from the late 80's early 90's on > Microsoft's site and some API documentation that was obviously not > microsofts in Europe. Wayne Roberts had a real need for windows support and > fixed some major issues it had. My interest at the time was mingw32. I then > cleaned it up for some specific uses I had later. The read returning -1 > when it should block didn't impact anybody and appeared to help some people. > It isnt the documented behavior though. > > There could be all sorts of latent bugs in that code but in the real world, > it gets by in almost all use cases. Its a hack but it worked for 100's of > thousands of people over a 14 year period. Maybe its time to revisit the > code but there is more risk than gain for most people. How do you move > forward and avoid the risk? > The safest and easiest solution would be to add a javadoc comment to disableReceiveTimeout explaining the difference between the RXTX behavior and Sunacle's documented behavior so that when someone uses the method in an IDE like Eclipse a little box would pop up informing them. Generating javadoc HTML and hosting it on the RXTX website would go a long way too, when something behaves differently than I expect the first thing I do is look for the javadoc online. -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From kharrington at neuronrobotics.com Mon Mar 7 10:47:26 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 12:47:26 -0500 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! Message-ID: Hey all, this is just a heads up that i have made a fork of rxtxSerial. Some of the features we have added: * Self deployment of native libraries ( all native code is stored inside the jar and deployed at runtime). No more manual install of native code. * Arm Cortex support (Gumstix) * Android Support (requires a rooted phone for now) * Google Code (SVN) repository for easy code and jar access * Single makefile compile (simplifies the compilation of project binaries) * Ant build script for jar creation * Removal of partialy implemented code to streamline the lib for just serial port access * Full Eclipse integration, for testing application code against sources. And a bunch of bug fixes: * Fixed the memory access error that causes OSX to crash the JVM when serial.close() is cvalled * Fixed the windows serial port zombie bind that prevents re-accessing serial ports when exiting on an exception * Fixed erronious printouts of native library mis-match To check it out, take a look at our page here: http://code.google.com/p/nrjavaserial/ From Kustaa.Nyholm at planmeca.com Mon Mar 7 11:46:26 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Mar 2011 20:46:26 +0200 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: Message-ID: On 3/7/11 19:47, "Kevin Harrington NR" wrote: >Hey all, this is just a heads up that i have made a fork of >rxtxSerial. Some of the features we have added great! If also does what it says on the tin: brilliant! Congrats and thanks. br Kusti From jmsachs at gmail.com Mon Mar 7 12:50:33 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 14:50:33 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: > From: Kevin Harrington NR > To: rxtx at qbang.org > Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > Hey all, this is just a heads up that i have made a fork of > rxtxSerial. Some of the features we have added: > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with a ten-foot pole. From Kustaa.Nyholm at planmeca.com Mon Mar 7 13:10:43 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Mar 2011 22:10:43 +0200 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: Message-ID: On 3/7/11 21:50, "Jason Sachs" wrote: > >Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >a ten-foot pole. >_______________________________________________ Oh crap, makes it useless for me and many others. Also I see no provision in RxTx license to change it so how could anyone change it to GPLv3? br Kusti From showard314 at gmail.com Mon Mar 7 13:24:08 2011 From: showard314 at gmail.com (Scott Howard) Date: Mon, 7 Mar 2011 15:24:08 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 3:10 PM, Kustaa Nyholm wrote: > Also I see no provision in RxTx license to change > it so how could anyone change it to GPLv3? I think this is allowed: 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. From jmsachs at gmail.com Mon Mar 7 13:24:47 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 15:24:47 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 2:50 PM, Jason Sachs wrote: >> From: Kevin Harrington NR >> To: rxtx at qbang.org >> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> > > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with > a ten-foot pole. > Let me back up a second (perhaps to make up for my lack of diplomacy) and state that I think any progress w/ rxtx is good. If an rxtx fork were LGPL (or some other non-spreading open source license) and leading in a good direction, I'd gladly return the favor by posting any improvements or bugfixes I found to the community. --Jason From jmsachs at gmail.com Mon Mar 7 13:36:13 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 15:36:13 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: Kevin: could you clarify the license? http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java has the RXTX 2.1 license (LGPL v 2.1 + Linking Over Controlled Interface.) but http://code.google.com/p/nrjavaserial/ says GPLv3. --Jason From kharrington at neuronrobotics.com Mon Mar 7 14:00:02 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 16:00:02 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: The one downside to google code is that it does not allow custom licensing. You have to pick from a drop-down list. Treat the licences on the files themselves as the licence to be concerned with, and ignore the "project licence". Sorry for the confusion. On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: > Kevin: could you clarify the license? > > http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java > has the RXTX 2.1 license > (LGPL v 2.1 + Linking Over Controlled Interface.) > > but http://code.google.com/p/nrjavaserial/ says GPLv3. > > --Jason > From iqzw2r602 at sneakemail.com Mon Mar 7 14:08:18 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 8 Mar 2011 08:08:18 +1100 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: References: Message-ID: <11253-1299532098-811882@sneakemail.com> Nice! Out of curiosity, did you use the patch that I sent Trent about two years ago to do the native library loading, or did you implement your own solution? Cheers, Uwe On Tue, Mar 8, 2011 at 5:46 AM, Kustaa Nyholm Kustaa.Nyholm-at-planmeca.com| rxtx.org mailing list/Example Allow| wrote: > On 3/7/11 19:47, "Kevin Harrington NR" > wrote: > > >Hey all, this is just a heads up that i have made a fork of > >rxtxSerial. Some of the features we have added > > > > great! If also does what it says on the tin: brilliant! > > Congrats and thanks. > > br Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aawolfe at gmail.com Mon Mar 7 15:31:47 2011 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 7 Mar 2011 17:31:47 -0500 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR wrote: > Hey all, this is just a heads up that i have made a fork of > rxtxSerial. Some of the features we have added: > > * Self deployment of native libraries ( all native code is stored > inside the jar and deployed at runtime). No more manual install of > native code. > * Arm Cortex support (Gumstix) > * Android Support (requires a rooted phone for now) > * Google Code (SVN) repository for easy code and jar access > * Single makefile compile (simplifies the compilation of project binaries) > * Ant build script for jar creation > * Removal of partialy implemented code to streamline the lib for just > serial port access > * Full Eclipse integration, for testing application code against sources. > > And a bunch of bug fixes: > > * Fixed the memory access error that causes OSX to crash the JVM when > serial.close() is cvalled > * Fixed the windows serial port zombie bind that prevents re-accessing > serial ports when exiting on an exception > * Fixed erronious printouts of native library mis-match > > To check it out, take a look at our page here: > > http://code.google.com/p/nrjavaserial/ This is interesting, getting the native libs set up has been an issue for some of my users. Will have to check it out. Out of curiosity, what Android devices provide a serial port? Or are there some that allow USB host mode and then a usb-serial adapter? I have only an Android cell phone, don't think it can do anything serial but would love to be wrong about that. From jfh at greenhousepc.com Mon Mar 7 15:54:39 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 15:54:39 -0700 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! Message-ID: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Mon Mar 7 16:53:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Mar 2011 16:53:50 -0700 (MST) Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: Hi Kevin, Until Google fixes the options as developers have requested, I'd suggest the least misleading dropdown option is "Other Open Source" with a clarification about LGPL 2.1 on the project page. If you are not supporting the CommAPI SPI interface that was available prior to the current JSR so that applications work in the javax.comm namespace, there is no need for the linking over controlled interfaces exception. RXTX 2.0 is used in that fashion but RXTX 2.1 is not. The exception explicitly states it can be removed if the source has been modified. The license is then explicitly OSI reviewed and approved as Google requests but is not in their drop down box as it should be and is for the GPL v2. http://opensource.org/licenses/alphabetical http://opensource.org/licenses/lgpl-2.1 The drawback would be that the library effectively could never be used in that SPI/controlled interface fashion again. On Mon, 7 Mar 2011, Kevin Harrington NR wrote: > The one downside to google code is that it does not allow custom > licensing. You have to pick from a drop-down list. Treat the licences > on the files themselves as the licence to be concerned with, and > ignore the "project licence". Sorry for the confusion. > > On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >> Kevin: could you clarify the license? >> >> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >> has the RXTX 2.1 license >> (LGPL v 2.1 + Linking Over Controlled Interface.) >> >> but http://code.google.com/p/nrjavaserial/ says GPLv3. >> >> --Jason >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From hakcenter at gmail.com Mon Mar 7 18:55:57 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 17:55:57 -0800 Subject: [Rxtx] Latency Woes Message-ID: <4D758CAD.2010602@gmail.com> I have finally deduced my slow data logging to a latency issue. I write software for dsms, and the protocol is request / receive, you cannot do more than 1 sensor at a time. So when you log multiple sensors, +20ms per item, sampling rate drops like a rock. I was wondering if there is any ideas besides going completely native with my application to reduce latency. With or without events I don't care at this point I need to kill as much of the latency as possible. Realistically I need no more than 1ms. From adrian.crum at sandglass-software.com Mon Mar 7 19:08:21 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Mon, 07 Mar 2011 18:08:21 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D758CAD.2010602@gmail.com> References: <4D758CAD.2010602@gmail.com> Message-ID: <4D758F95.90800@sandglass-software.com> Drop the requests into a queue, and then have a separate thread service the queue. -Adrian On 3/7/2011 5:55 PM, Curtis Hacker wrote: > I have finally deduced my slow data logging to a latency issue. > > I write software for dsms, and the protocol is request / receive, you > cannot do more than 1 sensor at a time. So when you log multiple > sensors, +20ms per item, sampling rate drops like a rock. > > I was wondering if there is any ideas besides going completely native > with my application to reduce latency. With or without events I don't > care at this point I need to kill as much of the latency as possible. > Realistically I need no more than 1ms. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From hakcenter at gmail.com Mon Mar 7 19:24:16 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 18:24:16 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D758F95.90800@sandglass-software.com> References: <4D758CAD.2010602@gmail.com> <4D758F95.90800@sandglass-software.com> Message-ID: <4D759350.8060402@gmail.com> Sample code ? I don't necessarily want to read the byte I just wrote, but wait till the que depth is 2. Setup a thread without a sleep timer: if (in.available() > 1) { do_stuff(); } ?? On 03/07/11 18:08, Adrian Crum wrote: > Drop the requests into a queue, and then have a separate thread > service the queue. > > -Adrian > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: >> I have finally deduced my slow data logging to a latency issue. >> >> I write software for dsms, and the protocol is request / receive, you >> cannot do more than 1 sensor at a time. So when you log multiple >> sensors, +20ms per item, sampling rate drops like a rock. >> >> I was wondering if there is any ideas besides going completely native >> with my application to reduce latency. With or without events I don't >> care at this point I need to kill as much of the latency as possible. >> Realistically I need no more than 1ms. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adrian.crum at sandglass-software.com Mon Mar 7 19:46:02 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Mon, 07 Mar 2011 18:46:02 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D759350.8060402@gmail.com> References: <4D758CAD.2010602@gmail.com> <4D758F95.90800@sandglass-software.com> <4D759350.8060402@gmail.com> Message-ID: <4D75986A.6020003@sandglass-software.com> http://download.oracle.com/javase/tutorial/essential/concurrency/executors.html -Adrian On 3/7/2011 6:24 PM, Curtis Hacker wrote: > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: >> Drop the requests into a queue, and then have a separate thread >> service the queue. >> >> -Adrian >> >> On 3/7/2011 5:55 PM, Curtis Hacker wrote: >>> I have finally deduced my slow data logging to a latency issue. >>> >>> I write software for dsms, and the protocol is request / receive, >>> you cannot do more than 1 sensor at a time. So when you log multiple >>> sensors, +20ms per item, sampling rate drops like a rock. >>> >>> I was wondering if there is any ideas besides going completely >>> native with my application to reduce latency. With or without events >>> I don't care at this point I need to kill as much of the latency as >>> possible. Realistically I need no more than 1ms. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Mon Mar 7 19:50:45 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 19:50:45 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Mon Mar 7 20:04:01 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 19:04:01 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> Message-ID: <4D759CA1.8010903@gmail.com> I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. in.read(data, 0, 2); ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? On 03/07/11 18:50, jfh at greenhousepc.com wrote: > Curtis, > > No, I assume he means a real queue, not just "don't read all the bytes > at once." However, if you know you can process some number of > requests in some amount of time, allowing data to pile up (receiver > FIFO space permitting) can be a valid strategy. Inserting gobs of > Thread.yield() and notify() can help pep things up as well. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Mon, March 07, 2011 8:24 pm > To: rxtx at qbang.org > > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: > > Drop the requests into a queue, and then have a separate thread > > service the queue. > > > > -Adrian > > > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: > >> I have finally deduced my slow data logging to a latency issue. > >> > >> I write software for dsms, and the protocol is request / > receive, you > >> cannot do more than 1 sensor at a time. So when you log multiple > >> sensors, +20ms per item, sampling rate drops like a rock. > >> > >> I was wondering if there is any ideas besides going completely > native > >> with my application to reduce latency. With or without events I > don't > >> care at this point I need to kill as much of the latency as > possible. > >> Realistically I need no more than 1ms. > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From bartley at cmu.edu Mon Mar 7 20:08:05 2011 From: bartley at cmu.edu (Chris Bartley) Date: Mon, 7 Mar 2011 22:08:05 -0500 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> Message-ID: <9B1804F9-DBD0-476D-9345-806D00065A97@cmu.edu> We use a queue for all our request/response serial communications, and have found it really easy to work with. Code is here: http://code.google.com/p/create-lab-commons/source/browse/trunk/java/code/serial/src/edu/cmu/ri/createlab/serial/SerialPortCommandExecutionQueue.java It's assuming a command & response scheme that's specific to the protocol we use to talk to our robots, but it should be easy to modify for your needs. Hope this helps. Let me know if you have questions. Chris On Mar 7, 2011, at 9:50 PM, wrote: > Curtis, > > No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > Date: Mon, March 07, 2011 8:24 pm > To: rxtx at qbang.org > > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: > > Drop the requests into a queue, and then have a separate thread > > service the queue. > > > > -Adrian > > > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: > >> I have finally deduced my slow data logging to a latency issue. > >> > >> I write software for dsms, and the protocol is request / receive, you > >> cannot do more than 1 sensor at a time. So when you log multiple > >> sensors, +20ms per item, sampling rate drops like a rock. > >> > >> I was wondering if there is any ideas besides going completely native > >> with my application to reduce latency. With or without events I don't > >> care at this point I need to kill as much of the latency as possible. > >> Realistically I need no more than 1ms. > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Mon Mar 7 20:51:17 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 20:51:17 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110307205116.8ef0e5b4a80cef441275a6330ffad77d.9b325137d1.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From kharrington at neuronrobotics.com Mon Mar 7 20:55:23 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 22:55:23 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 7 In-Reply-To: References: Message-ID: To answer a few of you, I have changed the license to "Other open source license" as suggested. My company is modifying and maintaining this fork to support our robotics development library (http://code.google.com/p/nr-sdk/ http://dev.neuronrobotics.com). We will be implementing the standard serial port interface only, as it is the only one we need or care about. As for where the implementation came from, i would have to refer to my other developer to answer that. I wrote the build scripts and make files, as well as streamlining the C build process. I have remover the configure script, as it ends up being more confusing then compiling 3 C files needs to be. if you guys want to bring any of this into the main line, that's cool, but up to you to port over. Our fork will be focusing on polishing up the serial interface,and hopefully making it faster. I hope some of you will find our improvements useful! On Mon, Mar 7, 2011 at 6:53 PM, wrote: > Send Rxtx mailing list submissions to > ? ? ? ?rxtx at qbang.org > > To subscribe or unsubscribe via the World Wide Web, visit > ? ? ? ?http://mailman.qbang.org/mailman/listinfo/rxtx > or, via email, send a message with subject or body 'help' to > ? ? ? ?rxtx-request at qbang.org > > You can reach the person managing the list at > ? ? ? ?rxtx-owner at qbang.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Rxtx digest..." > > > Today's Topics: > > ? 1. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 2. Re: Rxtx Digest, Vol 43, Issue 6 (Kustaa Nyholm) > ? 3. Re: Rxtx Digest, Vol 43, Issue 6 (Scott Howard) > ? 4. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 5. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 6. Re: Rxtx Digest, Vol 43, Issue 6 (Kevin Harrington NR) > ? 7. Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! > ? ? ?(iqzw2r602 at sneakemail.com) > ? 8. Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! > ? ? ?(Aaron Wolfe) > ? 9. Re: [SPAM] Re: ?NRJavaSerial, a fork of rxtx that fixes the > ? ? ?papercuts! (jfh at greenhousepc.com) > ?10. Re: Rxtx Digest, Vol 43, Issue 6 (Trent Jarvi) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 7 Mar 2011 14:50:33 -0500 > From: Jason Sachs > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > >> From: Kevin Harrington NR >> To: rxtx at qbang.org >> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> > > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with > a ten-foot pole. > > > ------------------------------ > > Message: 2 > Date: Mon, 7 Mar 2011 22:10:43 +0200 > From: Kustaa Nyholm > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > On 3/7/11 21:50, "Jason Sachs" wrote: >> >>Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >>a ten-foot pole. >>_______________________________________________ > > Oh crap, makes it useless for me and many others. > > Also I see no provision in RxTx license to change > it so how could anyone change it to GPLv3? > > br Kusti > > > > ------------------------------ > > Message: 3 > Date: Mon, 7 Mar 2011 15:24:08 -0500 > From: Scott Howard > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 3:10 PM, Kustaa Nyholm > wrote: >> Also I see no provision in RxTx license to change >> it so how could anyone change it to GPLv3? > > I think this is allowed: > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. ?To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. ?(If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) ?Do not make any other change in > these notices. > > ? Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > ? This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > > ------------------------------ > > Message: 4 > Date: Mon, 7 Mar 2011 15:24:47 -0500 > From: Jason Sachs > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 2:50 PM, Jason Sachs wrote: >>> From: Kevin Harrington NR >>> To: rxtx at qbang.org >>> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >>> Message-ID: >>> ? ? ? ? >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> Hey all, this is just a heads up that i have made a fork of >>> rxtxSerial. Some of the features we have added: >>> >> >> Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >> a ten-foot pole. >> > > Let me back up a second (perhaps to make up for my lack of diplomacy) > and state that I think any progress w/ rxtx is good. > > If an rxtx fork were LGPL (or some other non-spreading open source > license) and leading in a good direction, I'd gladly return the favor > by posting any improvements or bugfixes I found to the community. > > --Jason > > > ------------------------------ > > Message: 5 > Date: Mon, 7 Mar 2011 15:36:13 -0500 > From: Jason Sachs > To: rxtx at qbang.org, kharrington at neuronrobotics.com > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > Kevin: could you clarify the license? > > http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java > has the RXTX 2.1 license > (LGPL v 2.1 + Linking Over Controlled Interface.) > > but http://code.google.com/p/nrjavaserial/ says GPLv3. > > --Jason > > > ------------------------------ > > Message: 6 > Date: Mon, 7 Mar 2011 16:00:02 -0500 > From: Kevin Harrington NR > To: Jason Sachs > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > The one downside to google code is that it does not allow custom > licensing. You have to pick from a drop-down list. Treat the licences > on the files themselves as the licence to be concerned with, and > ignore the "project licence". Sorry for the confusion. > > On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >> Kevin: could you clarify the license? >> >> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >> has the RXTX 2.1 license >> (LGPL v 2.1 + Linking Over Controlled Interface.) >> >> but http://code.google.com/p/nrjavaserial/ says GPLv3. >> >> --Jason >> > > > ------------------------------ > > Message: 7 > Date: Tue, 8 Mar 2011 08:08:18 +1100 > From: iqzw2r602 at sneakemail.com > To: Rxtx at qbang.org > Subject: Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > ? ? ? ?papercuts! > Message-ID: <11253-1299532098-811882 at sneakemail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Nice! > > Out of curiosity, did you use the patch that I sent Trent about two years > ago to do the native library loading, or did you implement your own > solution? > > Cheers, > > Uwe > > On Tue, Mar 8, 2011 at 5:46 AM, Kustaa Nyholm Kustaa.Nyholm-at-planmeca.com| > rxtx.org mailing list/Example Allow| wrote: > >> On 3/7/11 19:47, "Kevin Harrington NR" >> wrote: >> >> >Hey all, this is just a heads up that i have made a fork of >> >rxtxSerial. Some of the features we have added >> >> >> >> great! If also does what it says on the tin: brilliant! >> >> Congrats and thanks. >> >> br Kusti >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 8 > Date: Mon, 7 Mar 2011 17:31:47 -0500 > From: Aaron Wolfe > To: rxtx at qbang.org > Subject: Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > ? ? ? ?papercuts! > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR > wrote: >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> >> * Self deployment of native libraries ( all native code is stored >> inside the jar and deployed at runtime). No more manual install of >> native code. >> * Arm Cortex support (Gumstix) >> * Android Support (requires a rooted phone for now) >> * Google Code (SVN) repository for easy code and jar access >> * Single makefile compile (simplifies the compilation of project binaries) >> * Ant build script for jar creation >> * Removal of partialy implemented code to streamline the lib for just >> serial port access >> * Full Eclipse integration, for testing application code against sources. >> >> And a bunch of bug fixes: >> >> * Fixed the memory access error that causes OSX to crash the JVM when >> serial.close() is cvalled >> * Fixed the windows serial port zombie bind that prevents re-accessing >> serial ports when exiting on an exception >> * Fixed erronious printouts of native library mis-match >> >> To check it out, take a look at our page here: >> >> http://code.google.com/p/nrjavaserial/ > > This is interesting, getting the native libs set up has been an issue > for some of my users. ?Will have to check it out. > > Out of curiosity, what Android devices provide a serial port? ?Or are > there some that allow USB host mode and then a usb-serial adapter? ?I > have only an Android cell phone, don't think it can do anything serial > but would love to be wrong about that. > > > ------------------------------ > > Message: 9 > Date: Mon, 07 Mar 2011 15:54:39 -0700 > From: > To: aaron at aaronwolfe.com, rxtx at qbang.org > Subject: Re: [Rxtx] [SPAM] Re: ?NRJavaSerial, a fork of rxtx that > ? ? ? ?fixes the papercuts! > Message-ID: > ? ? ? ?<20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe at email13.secureserver.net> > > Content-Type: text/plain; charset="us-ascii" > > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 10 > Date: Mon, 7 Mar 2011 16:53:50 -0700 (MST) > From: Trent Jarvi > To: rxtx at qbang.org > Cc: Jason Sachs > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > Hi Kevin, > > Until Google fixes the options as developers have requested, I'd suggest > the least misleading dropdown option is "Other Open Source" with a > clarification about LGPL 2.1 on the project page. > > If you are not supporting the CommAPI SPI interface that was available > prior to the current JSR so that applications work in the javax.comm > namespace, there is no need for the linking over controlled interfaces > exception. ?RXTX 2.0 is used in that fashion but RXTX 2.1 is not. ?The > exception explicitly states it can be removed if the source has been > modified. ?The license is then explicitly OSI reviewed and approved as > Google requests but is not in their drop down box as it should be and is > for the GPL v2. > > ? ? ? ?http://opensource.org/licenses/alphabetical > ? ? ? ?http://opensource.org/licenses/lgpl-2.1 > > The drawback would be that the library effectively could never be used in > that SPI/controlled interface fashion again. > > On Mon, 7 Mar 2011, Kevin Harrington NR wrote: > >> The one downside to google code is that it does not allow custom >> licensing. You have to pick from a drop-down list. Treat the licences >> on the files themselves as the licence to be concerned with, and >> ignore the "project licence". Sorry for the confusion. >> >> On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >>> Kevin: could you clarify the license? >>> >>> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >>> has the RXTX 2.1 license >>> (LGPL v 2.1 + Linking Over Controlled Interface.) >>> >>> but http://code.google.com/p/nrjavaserial/ says GPLv3. >>> >>> --Jason >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > ------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > End of Rxtx Digest, Vol 43, Issue 7 > *********************************** > From Kustaa.Nyholm at planmeca.com Mon Mar 7 21:43:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 8 Mar 2011 06:43:57 +0200 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307205116.8ef0e5b4a80cef441275a6330ffad77d.9b325137d1.wbe@email13.secureserver.net> Message-ID: On 3/8/11 05:51, "jfh at greenhousepc.com" wrote: >Curtis, > > >None of that is relevant, as long as the UART is reasonable and the code >implements a proper half duplex protocol. > >If I understand correctly, you send a byte, the sensor sends back two >bytes. So long as you don't send the next byte until the two bytes are >in the UART receiver FIFO, you're fine. You don't have to actually >=read= them, just know they are available. To the OP, are you using a serial USB port, like FTDI? This has a built in latency of 10ms ie nothing is actually sent out of the device if you send less than 64 bytes until 10 msec timeout. This has nothing to do with RxTx. If you search the list archives you'll find more about this issue and IIRC someone reported that there is some diver parameter you can tweak to get rid of that latency. I'm sure the FTDI people had a good reason for this but it really brings down the communication speed if your protocol uses short messages and need to wait for a response. Sorry if this has already been mentioned or if this is not relevant, I've not been paying attention to this thread. br Kusti From bob_jacobsen at lbl.gov Tue Mar 8 00:02:28 2011 From: bob_jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 8 Mar 2011 00:02:28 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D759CA1.8010903@gmail.com> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> Message-ID: If you're transferring three bytes total at 1953 baud, it's going to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to wait 20msec to get the data back instead of 15.4 msec doesn't seem to be as big a problem as you're making it sound. Bob On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. > > To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. > > So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. > > in.read(data, 0, 2); > ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? > > On 03/07/11 18:50, jfh at greenhousepc.com wrote: >> Curtis, >> >> No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker >> Date: Mon, March 07, 2011 8:24 pm >> To: rxtx at qbang.org >> >> Sample code ? >> >> I don't necessarily want to read the byte I just wrote, but wait till >> the que depth is 2. >> >> Setup a thread without a sleep timer: >> if (in.available() > 1) { >> do_stuff(); >> } >> >> ?? >> >> On 03/07/11 18:08, Adrian Crum wrote: >> > Drop the requests into a queue, and then have a separate thread >> > service the queue. >> > >> > -Adrian >> > >> > On 3/7/2011 5:55 PM, Curtis Hacker wrote: >> >> I have finally deduced my slow data logging to a latency issue. >> >> >> >> I write software for dsms, and the protocol is request / receive, you >> >> cannot do more than 1 sensor at a time. So when you log multiple >> >> sensors, +20ms per item, sampling rate drops like a rock. >> >> >> >> I was wondering if there is any ideas besides going completely native >> >> with my application to reduce latency. With or without events I don't >> >> care at this point I need to kill as much of the latency as possible. >> >> Realistically I need no more than 1ms. >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From hakcenter at gmail.com Tue Mar 8 01:33:24 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 00:33:24 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> Message-ID: <4D75E9D4.5090307@gmail.com> I am going to try a couple things today and hopefully figure something out. Bob I don't want to pop your bubble, but a native application named 'TunerPro' can sample the same data, over 30 sensors, in less than 25ms. I've exchanged some emails with the author and it is a native C, polling, no events just timeouts. Kusta thanks for the FTDI notice, I believe that is tunable, however I have a particular user using a Keyspan converter and verified sampling rate with 'TunerPro' and its just off the charts. Chris thank you, I'll look into the queing. On 03/07/11 23:02, Bob Jacobsen wrote: > If you're transferring three bytes total at 1953 baud, it's going to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to wait 20msec to get the data back instead of 15.4 msec doesn't seem to be as big a problem as you're making it sound. > > Bob > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > >> I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. >> >> To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. >> >> So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. >> >> in.read(data, 0, 2); >> ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? >> >> On 03/07/11 18:50, jfh at greenhousepc.com wrote: >>> Curtis, >>> >>> No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. >>> -- >>> Julie Haugh >>> Senior Design Engineer >>> greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype From msemtd at googlemail.com Tue Mar 8 01:50:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 8 Mar 2011 08:50:15 +0000 Subject: [Rxtx] Latency Woes In-Reply-To: <4D75E9D4.5090307@gmail.com> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> <4D75E9D4.5090307@gmail.com> Message-ID: On 8 March 2011 08:33, Curtis Hacker wrote: > I am going to try a couple things today and hopefully figure something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than 25ms. > I've exchanged some emails with the author and it is a native C, polling, no > events just timeouts. Perhaps the author of TunerPro will let you use his native code - sounds just what you need. Regards, Michael Erskine. From jfh at greenhousepc.com Tue Mar 8 04:00:18 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 04:00:18 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 12:33:35 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 11:33:35 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> Message-ID: <4D76848F.5080809@gmail.com> Cable schematic: http://i1106.photobucket.com/albums/h377/vigilart/jackal%20logging%20set%20up/RS232SCHEMATIC.jpg 0.00268554 TunerPro.exe IOCTL_SERIAL_SET_BAUD_RATE VCP0 SUCCESS Rate: 1952 0.00305178 TunerPro.exe IOCTL_SERIAL_SET_RTS VCP0 SUCCESS 0.00297524 TunerPro.exe IOCTL_SERIAL_SET_DTR VCP0 SUCCESS 0.00297384 TunerPro.exe IOCTL_SERIAL_SET_LINE_CONTROL VCP0 SUCCESS StopBits: 1 Parity: NONE WordLength: 8 0.00000335 TunerPro.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 0.00202540 TunerPro.exe IOCTL_SERIAL_SET_HANDFLOW VCP0 SUCCESS Shake:1 Replace:40 XonLimit:2048 XoffLimit:512 0.00000335 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:300 RM:0 RC:2000 WM:0 WC:110 0.00000279 TunerPro.exe IOCTL_SERIAL_SET_QUEUE_SIZE VCP0 SUCCESS InSize: 1024 OutSize: 512 0.00000307 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000279 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:300 RM:0 RC:2000 WM:0 WC:110 0.00000307 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:75 RM:0 RC:400 WM:0 WC:300 0.00000559 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: RXCLEAR 0.00000335 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: TXCLEAR 0.00064980 TunerPro.exe IRP_MJ_WRITE VCP0 SUCCESS Length 1: . 0.01498738 TunerPro.exe IRP_MJ_READ VCP0 SUCCESS Length 1: . 0.00000363 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:200 RM:0 RC:20 WM:0 WC:300 0.02042774 TunerPro.exe IRP_MJ_READ VCP0 TIMEOUT Length 0: That is time on the left side. Now I'm with you on timing, it doesn't make a lot of sense, but that is how the logs come out. You can view the logs yourself. Tunerpro log : http://www.ds-map.net/tunerpro_log.csv My apps log : http://www.ds-map.net/my_log.csv 2nd app log : http://www.ds-map.net/my_log2.csv All these logs, were done from the same car, same cable. I have some older logs with some palm software, that was 13 sensors, and had a total 45-55ms between each set of 13. More info about the car / ecu at http://mmcdlogger.sourceforge.net Disassembly on the ecu: [SS1:SS0] is baud rate divider, 00(16) 01(128) 10(1024) 11(4096), assuming basic clock of 2MHZ, we get 125000baud, 15625baud, 1953baud, 488baud In any event, I attempted a no sleep thread, that waited till in.available > 1, and it wasn't any faster than running the events. Then I tried a read write thread, that slept from 1ms to 30ms after it wrote (so it wouldn't read what it just wrote). And couldn't get it doing much. I wish I had more of an understanding of all of this, which is why I'm asking for help. On 03/08/11 03:00, jfh at greenhousepc.com wrote: > Curtis, > > At the risk of being told "No, they really say it can be done", 30 > sensors is 30 * 3 character times (are you sure it's not a single byte > response?). At 1953 baud, a single character time is 10 bits * (1 / > 1953) seconds, or 15.4ms as Bob pointed out. 30 * 15.4ms is 460ms, > and that assumes everything works perfectly, no turnaround times, etc. > > If you can come up with some other way to make the math work, I'd love > to hear it. > > Short and sweet -- just because TunerPro can talk to an ECM/ECU that > is running faster than 1953 baud doesn't mean your Mitsubishi (or > whatever car you've got that runs at 1953 baud) runs at that faster > baud rate. > > Also, are you sure your data cable is correct? What cable are you > using? What's the schematic? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 2:33 am > To: rxtx at qbang.org > > I am going to try a couple things today and hopefully figure > something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than > 25ms. > I've exchanged some emails with the author and it is a native C, > polling, no events just timeouts. > > Kusta thanks for the FTDI notice, I believe that is tunable, > however I > have a particular user using a Keyspan converter and verified > sampling > rate with 'TunerPro' and its just off the charts. > > Chris thank you, I'll look into the queing. > > On 03/07/11 23:02, Bob Jacobsen wrote: > > If you're transferring three bytes total at 1953 baud, it's going > to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to > wait 20msec to get the data back instead of 15.4 msec doesn't seem > to be as big a problem as you're making it sound. > > > > Bob > > > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > > > >> I guess I'm gunna need some serious help with this then, because > of the scenario I'm stuck with. > >> > >> To communicate there is only 1 data line, rx/tx tied together > with a diode protecting the tx. No RTS/CTS handshaking nothing.. > >> > >> So the ecu can't process the next byte of info, without you > pulling the 2 bytes back. I wish this was standard, but even the > baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard > spot with this.. > >> > >> in.read(data , 0, 2); > >> ^ would the above wait till the timeout to read 2 bytes ? or > read 1 byte wait for the 2nd ? or just read the 1 ?? > >> > >> On 03/07/11 18:50, jfh at greenhousepc.com > wrote: > >>> Curtis, > >>> > >>> No, I assume he means a real queue, not just "don't read all > the bytes at once." However, if you know you can process some > number of requests in some amount of time, allowing data to pile > up (receiver FIFO space permitting) can be a valid strategy. > Inserting gobs of Thread.yield() and notify() can help pep things > up as well. > >>> -- > >>> Julie Haugh > >>> Senior Design Engineer > >>> greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 13:12:03 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 12:12:03 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> Message-ID: <4D768D93.1030504@gmail.com> So I looked over the Tunerpro log again today.. is it me or does it appear to be reusing values ? On 03/08/11 03:00, jfh at greenhousepc.com wrote: > Curtis, > > At the risk of being told "No, they really say it can be done", 30 > sensors is 30 * 3 character times (are you sure it's not a single byte > response?). At 1953 baud, a single character time is 10 bits * (1 / > 1953) seconds, or 15.4ms as Bob pointed out. 30 * 15.4ms is 460ms, > and that assumes everything works perfectly, no turnaround times, etc. > > If you can come up with some other way to make the math work, I'd love > to hear it. > > Short and sweet -- just because TunerPro can talk to an ECM/ECU that > is running faster than 1953 baud doesn't mean your Mitsubishi (or > whatever car you've got that runs at 1953 baud) runs at that faster > baud rate. > > Also, are you sure your data cable is correct? What cable are you > using? What's the schematic? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 2:33 am > To: rxtx at qbang.org > > I am going to try a couple things today and hopefully figure > something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than > 25ms. > I've exchanged some emails with the author and it is a native C, > polling, no events just timeouts. > > Kusta thanks for the FTDI notice, I believe that is tunable, > however I > have a particular user using a Keyspan converter and verified > sampling > rate with 'TunerPro' and its just off the charts. > > Chris thank you, I'll look into the queing. > > On 03/07/11 23:02, Bob Jacobsen wrote: > > If you're transferring three bytes total at 1953 baud, it's going > to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to > wait 20msec to get the data back instead of 15.4 msec doesn't seem > to be as big a problem as you're making it sound. > > > > Bob > > > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > > > >> I guess I'm gunna need some serious help with this then, because > of the scenario I'm stuck with. > >> > >> To communicate there is only 1 data line, rx/tx tied together > with a diode protecting the tx. No RTS/CTS handshaking nothing.. > >> > >> So the ecu can't process the next byte of info, without you > pulling the 2 bytes back. I wish this was standard, but even the > baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard > spot with this.. > >> > >> in.read(data , 0, 2); > >> ^ would the above wait till the timeout to read 2 bytes ? or > read 1 byte wait for the 2nd ? or just read the 1 ?? > >> > >> On 03/07/11 18:50, jfh at greenhousepc.com > wrote: > >>> Curtis, > >>> > >>> No, I assume he means a real queue, not just "don't read all > the bytes at once." However, if you know you can process some > number of requests in some amount of time, allowing data to pile > up (receiver FIFO space permitting) can be a valid strategy. > Inserting gobs of Thread.yield() and notify() can help pep things > up as well. > >>> -- > >>> Julie Haugh > >>> Senior Design Engineer > >>> greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 13:51:13 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 13:51:13 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308135113.8ef0e5b4a80cef441275a6330ffad77d.a5fff5bbc7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From bob_jacobsen at lbl.gov Tue Mar 8 14:14:57 2011 From: bob_jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 8 Mar 2011 14:14:57 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D76848F.5080809@gmail.com> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> Message-ID: <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > Tunerpro log : http://www.ds-map.net/tunerpro_log.csv It's only reading one sensor per line. Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT changed in lines 16 and 40; every 24 lines but at a different phase. GramsRev in lines 23 and 47; every 24 lines, at yet another phase. Looks like (69-1) readings in 1.30 seconds = 19msec per reading. Arithmetic still works! Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From hakcenter at gmail.com Tue Mar 8 14:27:12 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 13:27:12 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> Message-ID: <4D769F30.9050807@gmail.com> Thank you guys, cause I was really worried there. I guess another win for math today hahaha. So what is the imposed latency that rxtx has ? maybe 5-10ms ? On 03/08/11 13:14, Bob Jacobsen wrote: > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > It's only reading one sensor per line. > > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT changed in lines 16 and 40; every 24 lines but at a different phase. GramsRev in lines 23 and 47; every 24 lines, at yet another phase. > > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. Arithmetic still works! > > Bob > -- > Bob Jacobsen, LBNL > Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue Mar 8 14:07:24 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Mar 2011 14:07:24 -0700 (MST) Subject: [Rxtx] Latency Woes In-Reply-To: <4D769F30.9050807@gmail.com> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> <4D769F30.9050807@gmail.com> Message-ID: Hi Curtis While not your exact question, a simple test I performed can give you a ballpark idea. Writing a byte to a loopback at 9600 baud and displaying elapsed time on the data available event takes ~10 ms round trip in a large application. There are occasional 20 ms latencies. I used a typical linux desktop to try it just now without any special considerations. Windows NT was a little faster - maybe 8 ms - when I tried several years ago. On Tue, 8 Mar 2011, Curtis Hacker wrote: > Thank you guys, cause I was really worried there. I guess another win for > math today hahaha. So what is the imposed latency that rxtx has ? maybe > 5-10ms ? > > On 03/08/11 13:14, Bob Jacobsen wrote: >> On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >>> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> It's only reading one sensor per line. >> >> Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT >> changed in lines 16 and 40; every 24 lines but at a different phase. >> GramsRev in lines 23 and 47; every 24 lines, at yet another phase. >> >> Looks like (69-1) readings in 1.30 seconds = 19msec per reading. >> Arithmetic still works! >> >> Bob >> -- >> Bob Jacobsen, LBNL >> Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >> JacobsenRG >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Wei.Shen at Honeywell.com Tue Mar 8 15:15:32 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Tue, 8 Mar 2011 17:15:32 -0500 Subject: [Rxtx] [rxtx] disconnect event Message-ID: <83B3B1411349194D9D05821CEF48E78C02284B17@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 16:05:12 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 16:05:12 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 16:26:15 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 15:26:15 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> References: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> Message-ID: <4D76BB17.2090305@gmail.com> So if I could get the baud up 15625, theoretical maximum latency is 1.92ms ? Basically 500 samples/sec ? 125000, theoretical maximum latency is 0.24ms ? Basically 4167 samples/sec ? Keeping the protocol the same. On 03/08/11 15:05, jfh at greenhousepc.com wrote: > Curtis, > > It's nowhere near that bad. I'd measured it once before, and I > believe it's sub-millisecond. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 3:27 pm > To: rxtx at qbang.org > > Thank you guys, cause I was really worried there. I guess another win > for math today hahaha. So what is the imposed latency that rxtx has ? > maybe 5-10ms ? > > On 03/08/11 13:14, Bob Jacobsen wrote: > > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > > It's only reading one sensor per line. > > > > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 > lines. IAT changed in lines 16 and 40; every 24 lines but at a > different phase. GramsRev in lines 23 and 47; every 24 lines, at > yet another phase. > > > > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. > Arithmetic still works! > > > > Bob > > -- > > Bob Jacobsen, LBNL > > Bob_Jacobsen at lbl.gov > +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Tue Mar 8 17:40:36 2011 From: jredman at ergotech.com (Jim Redman) Date: Tue, 08 Mar 2011 17:40:36 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D76BB17.2090305@gmail.com> References: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> <4D76BB17.2090305@gmail.com> Message-ID: <4D76CC84.9040307@ergotech.com> How long does it take the device to generate a response? Increasing the baud rate may not help you much if the device takes a significant amount of time to process the request. On 03/08/2011 04:26 PM, Curtis Hacker wrote: > So if I could get the baud up > 15625, theoretical maximum latency is 1.92ms ? Basically 500 samples/sec ? > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 samples/sec ? > > Keeping the protocol the same. > > On 03/08/11 15:05, jfh at greenhousepc.com wrote: >> Curtis, >> >> It's nowhere near that bad. I'd measured it once before, and I >> believe it's sub-millisecond. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker > >> Date: Tue, March 08, 2011 3:27 pm >> To: rxtx at qbang.org >> >> Thank you guys, cause I was really worried there. I guess another win >> for math today hahaha. So what is the imposed latency that rxtx has ? >> maybe 5-10ms ? >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> > It's only reading one sensor per line. >> > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 >> lines. IAT changed in lines 16 and 40; every 24 lines but at a >> different phase. GramsRev in lines 23 and 47; every 24 lines, at >> yet another phase. >> > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. >> Arithmetic still works! >> > >> > Bob >> > -- >> > Bob Jacobsen, LBNL >> > Bob_Jacobsen at lbl.gov >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 jfh at greenhousepc.com Tue Mar 8 17:58:24 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 17:58:24 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 18:06:04 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 18:06:04 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 18:14:14 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 17:14:14 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> References: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> Message-ID: <4D76D466.7060303@gmail.com> I can edit the ECU eeprom to change the baud rate divisor to bump it up from 1953, to 15625 or 125000. But as Jim asked how fast the device can respond.. not very fast in its stock form. I can recode a lot of the eeprom for the ecu to alter the ecus baud rate, and put the response code into its own interrupt. I just wanted to make sure that in order to lower latency and increase sampling rate. I have to increase the baud rate of the ecu and the user right ? Or change the protocol.. to respond with more sensors per request. On 03/08/11 16:58, jfh at greenhousepc.com wrote: > Unless the ECU can auto-detect the baud rate, it won't even work. > > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Jim Redman > > Date: Tue, March 08, 2011 6:40 pm > To: rxtx at qbang.org > > How long does it take the device to generate a response? > > Increasing the baud rate may not help you much if the device takes a > significant amount of time to process the request. > > > On 03/08/2011 04:26 PM, Curtis Hacker wrote: > > So if I could get the baud up > > 15625, theoretical maximum latency is 1.92ms ? Basically 500 > samples/sec ? > > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 > samples/sec ? > > > > Keeping the protocol the same. > > > > On 03/08/11 15:05, jfh at greenhousepc.com > wrote: > >> Curtis, > >> > >> It's nowhere near that bad. I'd measured it once before, and I > >> believe it's sub-millisecond. > >> -- > >> Julie Haugh > >> Senior Design Engineer > >> greenHouse Computers, LLC // jfh at greenhousepc.com > > >> ; // > greenHousePC on Skype > >> > >> > >> -------- Original Message -------- > >> Subject: Re: [Rxtx] Latency Woes > >> From: Curtis Hacker > > >> Date: Tue, March 08, 2011 3:27 pm > >> To: rxtx at qbang.org > >> > >> Thank you guys, cause I was really worried there. I guess > another win > >> for math today hahaha. So what is the imposed latency that rxtx > has ? > >> maybe 5-10ms ? > >> > >> On 03/08/11 13:14, Bob Jacobsen wrote: > >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > >> > It's only reading one sensor per line. > >> > > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 > >> lines. IAT changed in lines 16 and 40; every 24 lines but at a > >> different phase. GramsRev in lines 23 and 47; every 24 lines, at > >> yet another phase. > >> > > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. > >> Arithmetic still works! > >> > > >> > Bob > >> > -- > >> > Bob Jacobsen, LBNL > >> > Bob_Jacobsen at lbl.gov > > >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > >> > > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Tue Mar 8 18:19:14 2011 From: jredman at ergotech.com (Jim Redman) Date: Tue, 08 Mar 2011 18:19:14 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> References: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> Message-ID: <4D76D592.9000802@ergotech.com> I'm no expert on this, but isn't the underlying ODB-II CAN bus or something similar. They always seem to require a dongle that converts to something. I know you can get serial, bluetooth, USB, etc. converters. I've seen serial dongles that claim multiple baud rates, so I suspect that whatever's providing the conversion may significantly affect the performance. A big second on the required timing comment. I suspect some intelligent consideration of what values change quickly (RPM, Speed, maybe things like fuel pressure) and read values like fuel levels, coolant temps, etc. much less frequently. On 03/08/2011 06:06 PM, jfh at greenhousepc.com wrote: > Curtis, > > You can't just increase the baud rate and have the device adapt to that > rate. Embedded systems tend to have their communications parameters > either hard coded in a memory location or else they are using a hardware > timebase. You're welcome to try increasing the baud rate, but there is > no guarantee it will even work. > > Whoever designed the ECU probably selected the baud rate for a good > reason. My suggestion would be to look at how the sensor values are all > laid out and go from there. Also, look at what the sensor represent and > consider the physical properties of what is being measured. It's > extremely unlikely that, for example, the coolant temperature is going > to rise more than 1* per second. If that much. Some values might change > more often, but do they really matter on a sub-second measurement basis? > > Part of software =engineering= is understanding the problem. Anyone can > sling code in the hope it works. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 5:26 pm > To: rxtx at qbang.org > > So if I could get the baud up > 15625, theoretical maximum latency is 1.92ms ? Basically 500 > samples/sec ? > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 > samples/sec ? > > Keeping the protocol the same. > > On 03/08/11 15:05, jfh at greenhousepc.com wrote: >> Curtis, >> >> It's nowhere near that bad. I'd measured it once before, and I >> believe it's sub-millisecond. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker > > >> Date: Tue, March 08, 2011 3:27 pm >> To: rxtx at qbang.org >> >> Thank you guys, cause I was really worried there. I guess >> another win >> for math today hahaha. So what is the imposed latency that >> rxtx has ? >> maybe 5-10ms ? >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> > It's only reading one sensor per line. >> > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every >> 24 lines. IAT changed in lines 16 and 40; every 24 lines but >> at a different phase. GramsRev in lines 23 and 47; every 24 >> lines, at yet another phase. >> > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per >> reading. Arithmetic still works! >> > >> > Bob >> > -- >> > Bob Jacobsen, LBNL >> > Bob_Jacobsen at lbl.gov >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > ------------------------------------------------------------------------ > _______________________________________________ > Rxtx mailing list > Rxtx 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 jfh at greenhousepc.com Tue Mar 8 18:32:28 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 18:32:28 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 19:45:00 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 18:45:00 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> References: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> Message-ID: <4D76E9AC.8050909@gmail.com> Julie, I really am not looking at the practicality of it. I was just wondering if that is how it works. I don't know a whole lot about rs232, which is the main reason I've been on this mailing list for a couple years. I have full control over the ecu eeprom code, I can change its baud rate, I can re-write the logging interface, I could update the ADC's on the ecu in the interface so that when you request said sensor it updates the ADC then replies it. But I wanted to know if the underlying issue with a 2mhz/8mhz processor is the baud rate keeping sampling down ? On 03/08/11 17:32, jfh at greenhousepc.com wrote: > Curtis, > > You also have to look at the response time of the sensor itself. > > Seriously -- look at what the sensors are reporting and determine if > the underlying physical property can actually change that rapidly. > And even if it can, do you really need to know that. > > I built drag bikes in the 70's and I drive sports cars in my old age. > You don't really need millisecond sampling rates for every single last > sensor coming out of the engine. Boost pressure, fuel pressure, > manifold pressure and RPMs are probably high frequency sensors if you > want to tweak the motor for turbo lag or something, but other than > that, are you really going to be able to make sense of all that data? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 7:14 pm > To: rxtx at qbang.org > > I can edit the ECU eeprom to change the baud rate divisor to bump > it up from 1953, to 15625 or 125000. But as Jim asked how fast the > device can respond.. not very fast in its stock form. > > I can recode a lot of the eeprom for the ecu to alter the ecus > baud rate, and put the response code into its own interrupt. > > I just wanted to make sure that in order to lower latency and > increase sampling rate. I have to increase the baud rate of the > ecu and the user right ? Or change the protocol.. to respond with > more sensors per request. > > On 03/08/11 16:58, jfh at greenhousepc.com wrote: >> Unless the ECU can auto-detect the baud rate, it won't even work. >> >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Jim Redman > > >> Date: Tue, March 08, 2011 6:40 pm >> To: rxtx at qbang.org >> >> How long does it take the device to generate a response? >> >> Increasing the baud rate may not help you much if the device >> takes a >> significant amount of time to process the request. >> >> >> On 03/08/2011 04:26 PM, Curtis Hacker wrote: >> > So if I could get the baud up >> > 15625, theoretical maximum latency is 1.92ms ? Basically 500 >> samples/sec ? >> > 125000, theoretical maximum latency is 0.24ms ? Basically >> 4167 samples/sec ? >> > >> > Keeping the protocol the same. >> > >> > On 03/08/11 15:05, jfh at greenhousepc.com >> wrote: >> >> Curtis, >> >> >> >> It's nowhere near that bad. I'd measured it once before, and I >> >> believe it's sub-millisecond. >> >> -- >> >> Julie Haugh >> >> Senior Design Engineer >> >> greenHouse Computers, LLC // jfh at greenhousepc.com >> >> >> ; // >> greenHousePC on Skype >> >> >> >> >> >> -------- Original Message -------- >> >> Subject: Re: [Rxtx] Latency Woes >> >> From: Curtis Hacker > > >> >> Date: Tue, March 08, 2011 3:27 pm >> >> To: rxtx at qbang.org >> >> >> >> >> Thank you guys, cause I was really worried there. I guess >> another win >> >> for math today hahaha. So what is the imposed latency that >> rxtx has ? >> >> maybe 5-10ms ? >> >> >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> >> > It's only reading one sensor per line. >> >> > >> >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; >> every 24 >> >> lines. IAT changed in lines 16 and 40; every 24 lines but at a >> >> different phase. GramsRev in lines 23 and 47; every 24 >> lines, at >> >> yet another phase. >> >> > >> >> > Looks like (69-1) readings in 1.30 seconds = 19msec per >> reading. >> >> Arithmetic still works! >> >> > >> >> > Bob >> >> > -- >> >> > Bob Jacobsen, LBNL >> >> > Bob_Jacobsen at lbl.gov >> >> >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Rxtx mailing list >> >> > Rxtx at qbang.org >> >> >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > ------------------------------------------------------------------------ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 20:43:11 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 20:43:11 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308204311.8ef0e5b4a80cef441275a6330ffad77d.e9b135168c.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From andrea.antonello at gmail.com Wed Mar 9 06:50:07 2011 From: andrea.antonello at gmail.com (andrea antonello) Date: Wed, 9 Mar 2011 14:50:07 +0100 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> References: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> Message-ID: Has anyone tried the lib? I am not sure if it is appropriate to write to the list about this, if not, I apologize. I wanted to try your fork out for our application which is an eclipse rcp plugin based one. It has been easy to substitute the 6 plugins with your library (that is one of the things I like). But then when I run it, it tries to load it from: ---- Loading: /tmp/libNRJavaSerial_moovida_0/libNRJavaSerial.so Trying to load: NRJavaSerial Trying to load: libNRJavaSerial Trying to load: rxtxSerial ---- So it is extracting the native lib to a tmp folder. But that one is not in the library path, so it fails. Is there any docs to try the lib out? Thanks, Andrea On Mon, Mar 7, 2011 at 11:54 PM, wrote: > Aaron, > > It should be possible for an Android to do BlueTooth serial.? If I were > looking for a serial solution, that's how I'd go. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on > Skype > > -------- Original Message -------- > Subject: [SPAM] Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > papercuts! > From: Aaron Wolfe > Date: Mon, March 07, 2011 4:31 pm > To: rxtx at qbang.org > > On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR > wrote: >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> >> * Self deployment of native libraries ( all native code is stored >> inside the jar and deployed at runtime). No more manual install of >> native code. >> * Arm Cortex support (Gumstix) >> * Android Support (requires a rooted phone for now) >> * Google Code (SVN) repository for easy code and jar access >> * Single makefile compile (simplifies the compilation of project binaries) >> * Ant build script for jar creation >> * Removal of partialy implemented code to streamline the lib for just >> serial port access >> * Full Eclipse integration, for testing application code against sources. >> >> And a bunch of bug fixes: >> >> * Fixed the memory access error that causes OSX to crash the JVM when >> serial.close() is cvalled >> * Fixed the windows serial port zombie bind that prevents re-accessing >> serial ports when exiting on an exception >> * Fixed erronious printouts of native library mis-match >> >> To check it out, take a look at our page here: >> >> http://code.google.com/p/nrjavaserial/ > > This is interesting, getting the native libs set up has been an issue > for some of my users. Will have to check it out. > > Out of curiosity, what Android devices provide a serial port? Or are > there some that allow USB host mode and then a usb-serial adapter? I > have only an Android cell phone, don't think it can do anything serial > but would love to be wrong 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 Cougar at CasaDelGato.Com Wed Mar 9 10:02:24 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 09 Mar 2011 09:02:24 -0800 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> References: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> Message-ID: <4D77B2A0.8020004@CasaDelGato.Com> On 3/7/2011 2:54 PM, jfh at greenhousepc.com wrote: > Aaron, > > It should be possible for an Android to do BlueTooth serial. If I > were looking for a serial solution, that's how I'd go. Actually, I can't figure out WHY you would need RxTx on an Android device. The built in bluetooth support works just fine with a serial-bluetooth converter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Mar 1 00:54:17 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 09:54:17 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> Message-ID: Adrian, had a look at your code/rewrite and it looks rather clean/nice. I was looking at the code to gain insight (not related to the rewrite) into what is involved in serial port programming in Windows. Or rather, to refresh my memory and see how others have done, because I've been there done that. So my questions are just to satisfy my curiosity, not to criticize or suggest improvements. 1) It looks like a new thread (EventMonitor) is created for each Serial port, is that correct? Many people seem to try to avoid using many threads in this sort of situation, and like to use something like unix select(). I personally find using threads more natural and better impedance match to the problem being solved here. I guess 'many people' above refers to those implementing thousands of connections and who cannot live with the overhead and limited number of threads available. 2) The EventMonitor basically polls for events at 50 msec interval? 3) There is a comment in the source code near the sleep(50) : // Sufficient up to 19200 baud I'm sure you thought about this carefully, so again not criticizing, but seeking to understand how or why, because at 50 msec would seem to limit through in some cases. Like if you send one byte and need to wait for one to return, then this limits speed to 200 chars/sec? 4) I've done something similar to a few years back from Java using JNI to access Win32 API serial port, and I seem to recall that I had threading issues ie when I submitted a read (ReadFile) and there was no data coming in, the thread would not only block but also consume a lot of CPU cycles ie it was not sleeping properly inside the ReadFile call when the serial port blocked. Im a bit fuzzy about the details after five years, so my question is have you checked if there an issue here? 5) AFAIK the select() on Windows does not work serial ports but there is some other mechanism (events?) to implement the same functionality, did you consider that? Probably, so you decided against it, why? br Kusti From adrian.crum at sandglass-software.com Tue Mar 1 04:13:34 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:13:34 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: References: Message-ID: <4D6CD4DE.7040501@sandglass-software.com> The javax.comm API specification requires one event monitor thread per port. I don't like the idea of having a thread per port either, but one of the rewrite's design goals is strict conformance to the specification. The 50 mS polling interval is just a placeholder. The final design of that is yet to be decided. In Windows, you have two choices for I/O: overlapped and non-overlapped. In overlapped I/O a thread is blocked, waiting for something to happen. In non-overlapped I/O a thread does not block. I chose non-overlapped I/O to avoid thread blocking at the OS level - instead, the thread blocking is kept in Java. -Adrian On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > Adrian, > > had a look at your code/rewrite and it looks rather clean/nice. > > I was looking at the code to gain insight (not related to the > rewrite) into what is involved in serial port programming > in Windows. Or rather, to refresh my memory and see how others have > done, because I've been there done that. > > So my questions are just to satisfy my curiosity, not to criticize > or suggest improvements. > > 1) It looks like a new thread (EventMonitor) is created for > each Serial port, is that correct? > > Many people seem to try to avoid using many threads in this sort > of situation, and like to use something like unix select(). > I personally find using threads more natural and better impedance > match to the problem being solved here. I guess 'many people' above > > refers to those implementing thousands of connections and > who cannot live with the overhead and limited number of threads > available. > > 2) The EventMonitor basically polls for events at 50 msec interval? > > 3) There is a comment in the source code near the sleep(50) : > > // Sufficient up to 19200 baud > > > I'm sure you thought about this carefully, so again not > criticizing, but seeking to understand how or why, because > at 50 msec would seem to limit through in some cases. Like > if you send one byte and need to wait for one to return, > then this limits speed to 200 chars/sec? > > 4) I've done something similar to a few years back from > Java using JNI to access Win32 API serial port, and > I seem to recall that I had threading issues ie when > I submitted a read (ReadFile) and there was no data coming > in, the thread would not only block but also consume a > lot of CPU cycles ie it was not sleeping properly inside > the ReadFile call when the serial port blocked. > > Im a bit fuzzy about the details after five years, so my question is > have you checked if there an issue here? > > > 5) AFAIK the select() on Windows does not work serial ports > but there is some other mechanism (events?) to implement the > same functionality, did you consider that? Probably, so you > decided against it, why? > > > br Kusti > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Tue Mar 1 04:25:23 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:25:23 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C2E90.9010601@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > My question would be: Why would you do that? The rewrite does > most of the work for you - all you have to do is implement > two C++ virtual classes and two C++ functions. You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? I just took a short look, maybe it could be discussed further, but I don't think I like it much. BTW, the main interface defined there is called gnu.io.Dispatcher? I thought the package names should be used in a way to avoid clashes, e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name space authority :)). > In Windows that took me a few hours. where is the implementation? I found commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp with things like const bool SerialPortImpl::isDataAvailable() const { // Needs implementation return true; } and timeouts.ReadIntervalTimeout = MAXDWORD;* timeouts.ReadTotalTimeoutMultiplier = 0; timeouts.ReadTotalTimeoutConstant = 0; timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 0; if (!SetCommTimeouts(hComm, &timeouts)) throw IOException(); which seems to be oversimplified or some prototype only? I think (and I wrote about this already in the past years) that correct timeout handling is one of the challenges, so I think this should be prototyped first - for each system flavor - before cementation of the (JNI-) interfaces. Personally, I would vote to form it in a way allowing to be implemented on embedded devices, for example. Another big challenge is to prove a rewrite fully working (and probably compatible to the old implementation) on "all" the supported OSes. Not a big problem for linux and windows, just use some thousand lines test code, test drivers and serial loopbacks etc, but for the exotic platforms, probably a high number of, this probably won't be too easy... (there are more challenges, such as being comfortable and threadsafe [are read and write permitted at the same time?], detailed and helpful exceptions on user API level [not necessarily on JNI/JNA layer], how to have a configurable threadsafe logging/tracing [maybe also from native code to assist porting / testing on exotic OSes, such as OSes where the developers have no direct access too, which can be quite hard to usually leads to good log messages], just to name a few.). So even it might seem easy for one platform and I agree with Micheal that > > * yay! let's start a rewrite is unlikely to succeede soon... However, when considering this, before IMHO a powerful Java API has to be defined, because according to my experiences for implementing non-trivial protocols InputStream/OutputStream might not be comfortable/powerfull enough (eventually I consider both wrong) and have some InputStream derivation available as wrapper (so applications can use InputStream and whatever high-level-API they want). The JNI interface shall make such a powerful implementation possible, thus the interface of it is driving the JNI interface design and thus I think it had to be done first. All this surely requires much work: agreements on the APIs, safeness for the users, design, documentation, all the implementations and the testing. As long as such bug amount of work cannot be spent, for example if some employee would get half a year time paid for it or so :-), probably it is unlikely to progress on this. Otherwise, I'm afraid, patches, improvements, new design ideas and even rewrites wouldn't become complete and thus won't form a new rxtx version (3.0); thus either collect dust in some forgotten CVS branch or could generate a split... > I can't imagine other ports taking > much longer than that - especially since POSIX-based code can > be shared between ports. Things are more complex than they seem to be... I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select on serial ports isn't supported; maybe it is non-trivial to "map" (like mapping select() to WaitForMultipleObjects() which might have different semantics etc.) or maybe some different approach has to be used. A system may have POSIX like termios interfaces but not support timeouts or have any other interoperability bug... You never run out of things that can go wrong. And if something can go wrong, it will... :-) Or, as Michael wrote: > > I seriously don't believe anyone will come up with anything better anytime soon. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue Mar 1 04:39:37 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:39:37 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com><13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED6B@COSNPREXC3.usr.ingenico.loc> > 3. Write all of the native (or non-native) code to implement > the native interface. > > Is that correct? If yes, how is that easier than the simple > implementation the current rewrite design uses? To have it complete, reliable, traceable, maintainable and well tested, it is much more work, I'm afraid. A prototype can be done within a few days (maybe on one day), but getting it right (including a passed review) IMHO is a completely different story. In the end you may end up with an average of ten lines per day, when assuming four major native packs (common, win, mac, termios/select) with let's say just 5000 lines each (with logging messages and detailed exceptions this is not much) we would have to estimate a total effort of nine man-years (20000/10/220)... oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 04:40:18 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:40:18 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6CDB22.9070401@sandglass-software.com> Every journey begins with a single step. -Adrian On 3/1/2011 3:25 AM, Steffen DETTMER wrote: > * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> My question would be: Why would you do that? The rewrite does >> most of the work for you - all you have to do is implement >> two C++ virtual classes and two C++ functions. > You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? > I just took a short look, maybe it could be discussed further, > but I don't think I like it much. > BTW, the main interface defined there is called gnu.io.Dispatcher? > I thought the package names should be used in a way to avoid clashes, > e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name > space authority :)). > >> In Windows that took me a few hours. > where is the implementation? > I found > commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp > with things like > > const bool SerialPortImpl::isDataAvailable() const > { > // Needs implementation > return true; > } > > and > > timeouts.ReadIntervalTimeout = MAXDWORD;* > timeouts.ReadTotalTimeoutMultiplier = 0; > timeouts.ReadTotalTimeoutConstant = 0; > timeouts.WriteTotalTimeoutMultiplier = 0; > timeouts.WriteTotalTimeoutConstant = 0; > if (!SetCommTimeouts(hComm,&timeouts)) > throw IOException(); > > which seems to be oversimplified or some prototype only? > > I think (and I wrote about this already in the past years) that correct > timeout handling is one of the challenges, so I think this should be > prototyped first - for each system flavor - before cementation of the > (JNI-) interfaces. Personally, I would vote to form it in a way allowing > to be implemented on embedded devices, for example. > > Another big challenge is to prove a rewrite fully working (and probably > compatible to the old implementation) on "all" the supported OSes. Not a > big problem for linux and windows, just use some thousand lines test > code, test drivers and serial loopbacks etc, but for the exotic > platforms, probably a high number of, this probably won't be too easy... > (there are more challenges, such as being comfortable and threadsafe > [are read and write permitted at the same time?], detailed and helpful > exceptions on user API level [not necessarily on JNI/JNA layer], how to > have a configurable threadsafe logging/tracing [maybe also from native > code to assist porting / testing on exotic OSes, such as OSes where the > developers have no direct access too, which can be quite hard to usually > leads to good log messages], just to name a few.). > > So even it might seem easy for one platform and I agree with Micheal > that > >>> * yay! let's start a rewrite > is unlikely to succeede soon... > > However, when considering this, before IMHO a powerful Java API has to > be defined, because according to my experiences for implementing > non-trivial protocols InputStream/OutputStream might not be > comfortable/powerfull enough (eventually I consider both wrong) and have > some InputStream derivation available as wrapper (so applications can > use InputStream and whatever high-level-API they want). > The JNI interface shall make such a powerful implementation possible, > thus the interface of it is driving the JNI interface design and thus I > think it had to be done first. > > All this surely requires much work: agreements on the APIs, safeness for > the users, design, documentation, all the implementations and the > testing. As long as such bug amount of work cannot be spent, for example > if some employee would get half a year time paid for it or so :-), > probably it is unlikely to progress on this. > > Otherwise, I'm afraid, patches, improvements, new design ideas and even > rewrites wouldn't become complete and thus won't form a new rxtx version > (3.0); thus either collect dust in some forgotten CVS branch or could > generate a split... > >> I can't imagine other ports taking >> much longer than that - especially since POSIX-based code can >> be shared between ports. > Things are more complex than they seem to be... > > I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select > on serial ports isn't supported; maybe it is non-trivial to "map" (like > mapping select() to WaitForMultipleObjects() which might have different > semantics etc.) or maybe some different approach has to be used. A > system may have POSIX like termios interfaces but not support timeouts > or have any other interoperability bug... > You never run out of things that can go wrong. And if something can go > wrong, it will... :-) > > Or, as Michael wrote: > >>> I seriously don't believe anyone will come up with anything better > anytime soon. > > oki, > > Steffen > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Kustaa.Nyholm at planmeca.com Tue Mar 1 04:57:02 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 13:57:02 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: On 3/1/11 13:13, "Adrian Crum" wrote: >The javax.comm API specification requires one event monitor thread per >port. I don't like the idea of having a thread per port either, but one >of the rewrite's design goals is strict conformance to the specification. Ah, had not spotted that requirement. > >The 50 mS polling interval is just a placeholder. The final design of >that is yet to be decided. > >In Windows, you have two choices for I/O: overlapped and non-overlapped. >In overlapped I/O a thread is blocked, waiting for something to happen. >In non-overlapped I/O a thread does not block. I chose non-overlapped >I/O to avoid thread blocking at the OS level - instead, the thread >blocking is kept in Java. > >-Adrian thanks for the explanation. br Kusti From iqzw2r602 at sneakemail.com Tue Mar 1 05:08:17 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:08:17 +1100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <32684-1298981297-704398@sneakemail.com> This reminds me of a nasty problem I had with overlapped I/O on windows with jpathwatch. You can't start an I/O request in one thread and then do the check if that request completed in another thread. Very strange things happen when you attempt that; made me change the design of the Windows implementation quite drastically (one thread on a command queue that executes requests from other threads instead of letting them wildly call into GetOverlappedResult()). Out of curiosity: Did you come across that too? Or are all requests handled in the same thread they're issued? Cheers, Uwe On Tue, Mar 1, 2011 at 10:13 PM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > The javax.comm API specification requires one event monitor thread per > port. I don't like the idea of having a thread per port either, but one of > the rewrite's design goals is strict conformance to the specification. > > The 50 mS polling interval is just a placeholder. The final design of that > is yet to be decided. > > In Windows, you have two choices for I/O: overlapped and non-overlapped. In > overlapped I/O a thread is blocked, waiting for something to happen. In > non-overlapped I/O a thread does not block. I chose non-overlapped I/O to > avoid thread blocking at the OS level - instead, the thread blocking is kept > in Java. > > -Adrian > > > On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > >> Adrian, >> >> had a look at your code/rewrite and it looks rather clean/nice. >> >> I was looking at the code to gain insight (not related to the >> rewrite) into what is involved in serial port programming >> in Windows. Or rather, to refresh my memory and see how others have >> done, because I've been there done that. >> >> So my questions are just to satisfy my curiosity, not to criticize >> or suggest improvements. >> >> 1) It looks like a new thread (EventMonitor) is created for >> each Serial port, is that correct? >> >> Many people seem to try to avoid using many threads in this sort >> of situation, and like to use something like unix select(). >> I personally find using threads more natural and better impedance >> match to the problem being solved here. I guess 'many people' above >> >> refers to those implementing thousands of connections and >> who cannot live with the overhead and limited number of threads >> available. >> >> 2) The EventMonitor basically polls for events at 50 msec interval? >> >> 3) There is a comment in the source code near the sleep(50) : >> >> // Sufficient up to 19200 baud >> >> >> I'm sure you thought about this carefully, so again not >> criticizing, but seeking to understand how or why, because >> at 50 msec would seem to limit through in some cases. Like >> if you send one byte and need to wait for one to return, >> then this limits speed to 200 chars/sec? >> >> 4) I've done something similar to a few years back from >> Java using JNI to access Win32 API serial port, and >> I seem to recall that I had threading issues ie when >> I submitted a read (ReadFile) and there was no data coming >> in, the thread would not only block but also consume a >> lot of CPU cycles ie it was not sleeping properly inside >> the ReadFile call when the serial port blocked. >> >> Im a bit fuzzy about the details after five years, so my question is >> have you checked if there an issue here? >> >> >> 5) AFAIK the select() on Windows does not work serial ports >> but there is some other mechanism (events?) to implement the >> same functionality, did you consider that? Probably, so you >> decided against it, why? >> >> >> br Kusti >> >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 05:37:07 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:37:07 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <1142-1298983027-957144@sneakemail.com> On Tue, Mar 1, 2011 at 1:32 PM, Adrian Crum wrote: > Just to make sure I'm understanding you correctly, anyone porting RxTx to > a new platform would have to do the following: > > 1. Write their own Java implementation of an abstract Dispatcher class. > yep. I'd probably put all my calls to native OS wrappers in there two, looks the most straight-forward to me. > 2. Write a native (JNI or JNA) interface for the abstract class > implementation. > yes. For POSIX you'd probably only write one piece of code that provides implementations for open(), close(), and friends. You can compile that on all posix platforms (yeah, the devil is in the detail, but it's very little code, still). So this does open() (when using ***, but you can also use +++) // Unix.java class Unix{ public static native int open(String filename, int flags, int mode); .... } // Unix.cpp JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) { const char* pathname = env->GetStringUTFChars(jpathname, 0); if(pathname == 0) return -1; // java throws an out of memory error in this case int result = open(pathname, flags, mode); Unix_cacheErrno(); // handle interference between JVM and errno; env->ReleaseStringUTFChars(jpathname, pathname); return result; } .... 3. Write all of the native (or non-native) code to implement the native > interface. > Not sure what you mean by that. I've done the OS wrappers in step 2. step 1. implements that Dispatcher. What else do I need? > Is that correct? If yes, how is that easier than the simple implementation > the current rewrite design uses? > Yes, except for 3 (see above). How it is easier: I can debug the Java code directly. I can step from the read() call of an input stream directly into the guts of the RXTX implementation on my platform and see e.g. why it's hanging, because I see all the way up the call stack right where it calls Unix.read(). You can't easily do that with a fat native library, especially if you have no second set of devtools installed (the ones for native development). And I bet anyone knowing both languages can write it faster in Java, with less bugs. > On a side note: there is no requirement to write native code using C++. If > C++ is a real obstacle to adoption, then regular C could be used instead. In > that case, there would be a Dispatcher.c file that contains function > protoypes that need to be implemented. Dispatcher.c would still maintain the > same role as Dispatcher.cpp - which is to shield native code developers from > the details of JNI. Just build out the missing functions using C data types > and you're ready to go. > As I said, whatever works for you. Java works for me better than C++ in this case... Cheers, Uwe -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Mar 1 08:26:41 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 16:26:41 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> > The javax.comm API specification requires one event monitor > thread per port. Where does it require this? Do you mean "All the events received by this listener are generated by one dedicated thread that belongs to the SerialPort object. "? I think this is an implementation detail, isn't it? At least it is mentioned after "The current implementation only allows one listener per SerialPort". A bit bad that javadoc does not distinguish between API spec and implementation documentation. Also I don't think that TooManyListenersException MUST be thrown (I think it CAN be thrown). > I don't like the idea of having a thread per > port either, but one of the rewrite's design goals is strict > conformance to the specification. (but not necessarily on JNI layer) > The 50 mS polling interval is just a placeholder. The final > design of that is yet to be decided. I though no polling would be wanted; what could be the placeholder stand for? Do you mean a different interval duration or do you mean something completely different? > In Windows, you have two choices for I/O: overlapped and > non-overlapped. > In overlapped I/O a thread is blocked, waiting for something > to happen. > In non-overlapped I/O a thread does not block. I chose > non-overlapped I/O to avoid thread blocking at the OS level - > instead, the thread blocking is kept in Java. Isn't "overlapped" (asynchronous) I/O meaning that you invoke some ReadFile(..., &overlapped, ...) INSTEAD of performing a synchronous (blocking) function call blocking the thread? As far as I see, W32_Support.cpp uses CreateFile without FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O operations are serialized, even if the calls to the read and write functions specify an OVERLAPPED structure." [1] and "A synchronous handle behaves such that I/O function calls using that handle are blocked until they complete" [2] Given that CCOMTIMEOUTS get: "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the bytes that have already been received, even if no bytes have been received." [3] It looks likes this implementation relies on polling, which probably would waste much computing power. What did I miss? oki, Steffen [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro nous_and_asynchronous_i_o_handles [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 09:23:47 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:23:47 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6D1D93.6090306@sandglass-software.com> Unfortunately, the javax.comm API specification includes a lot of implementation details. That is one of the weaknesses of the specification in my opinion. The bottom line is, anyone wanting to use RxTx as a javax.comm implementation is going to expect it to do the things the specification says it does. -Adrian On 3/1/2011 7:26 AM, Steffen DETTMER wrote: >> The javax.comm API specification requires one event monitor >> thread per port. > Where does it require this? > > Do you mean "All the events received by this listener are generated > by one dedicated thread that belongs to the SerialPort object. "? > > I think this is an implementation detail, isn't it? At least it is > mentioned after "The current implementation only allows one listener per > SerialPort". A bit bad that javadoc does not distinguish between API > spec and implementation documentation. Also I don't think that > TooManyListenersException MUST be thrown (I think it CAN be thrown). > >> I don't like the idea of having a thread per >> port either, but one of the rewrite's design goals is strict >> conformance to the specification. > (but not necessarily on JNI layer) > >> The 50 mS polling interval is just a placeholder. The final >> design of that is yet to be decided. > I though no polling would be wanted; what could be the placeholder stand > for? Do you mean a different interval duration or do you mean something > completely different? > >> In Windows, you have two choices for I/O: overlapped and >> non-overlapped. >> In overlapped I/O a thread is blocked, waiting for something >> to happen. >> In non-overlapped I/O a thread does not block. I chose >> non-overlapped I/O to avoid thread blocking at the OS level - >> instead, the thread blocking is kept in Java. > Isn't "overlapped" (asynchronous) I/O meaning that you invoke some > ReadFile(...,&overlapped, ...) > INSTEAD of performing a synchronous (blocking) function call blocking > the thread? > > As far as I see, W32_Support.cpp uses CreateFile without > FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O > operations are serialized, even if the calls to the read and write > functions specify an OVERLAPPED structure." [1] and "A synchronous > handle behaves such that I/O function calls using that handle are > blocked until they complete" [2] > > Given that CCOMTIMEOUTS get: > "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values > for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier > members, specifies that the read operation is to return immediately with > the bytes that have already been received, even if no bytes have been > received." [3] > > It looks likes this implementation relies on polling, which probably > would waste much computing power. > > What did I miss? > > oki, > > Steffen > > [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx > [2] > http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro > nous_and_asynchronous_i_o_handles > [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at sandglass-software.com Tue Mar 1 09:55:29 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:55:29 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <1142-1298983027-957144@sneakemail.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> Message-ID: <4D6D2501.1020803@sandglass-software.com> That code duplicates what is in Dispatcher.cpp. A Unix port would only need to implement CommPortFactory::getInstance(portName, portType). -Adrian On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 15:07:46 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 2 Mar 2011 09:07:46 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6D2501.1020803@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> <4D6D2501.1020803@sandglass-software.com> Message-ID: <23749-1299017266-991798@sneakemail.com> What is this duplicating? A Unix port will need to call open() anyways (just so we're talking about the same thing here: open() is the Unix equivalent of CreateFile()) On Wed, Mar 2, 2011 at 3:55 AM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > That code duplicates what is in Dispatcher.cpp. A Unix port would only > need to implement CommPortFactory::getInstance(portName, portType). > > -Adrian > > > On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Tue Mar 1 22:53:07 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 00:53:07 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: Hi, I haven't seen any response to my question below. Is this not the right place to ask? If not, where would be a better place to ask? Any suggestions? Thanks, Ryan On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >> Hi, >> >> I have a receive thread that does nothing but call read() on the serial >> port input stream. It works fine for a while but after running for a long >> time it eventually returns -1 which means EOF. This is my first problem, as >> the device I'm talking to runs forever, I don't know why it would return -1. >> I am calling disableReceiveThreshold() and disableReceiveTimeout() at >> initialization which according to the documentation means read will return >> as soon as any data is available and it will block forever when data is not >> available, so -1 should never be returned from read, right? >> >> I have been unable to figure out why read returns -1 after a long while >> but I have found that if I kill my application and restart it everything >> works fine again. Therefore I tried to work around the problem by having my >> code close the port and reopen it when read returns -1. My second problem is >> that in this case when I call close() on the port it blocks forever. I did >> find this old bug >> >> http://bugzilla.qbang.org/show_bug.cgi?id=53 >> >> which describes close() hanging on OSX, but it says that bug was fixed >> with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have >> any idea why read might be returning -1 in the first place? If I can avoid >> that I don't care about close() hanging because I would never close the >> port. If not, does anyone know why close() might block forever and how I can >> prevent this? I'm using RXTX version 2.1-7. >> >> Thanks, >> -- >> Ryan >> >> > > > -- > Ryan Boder > 1 614 598-6339 > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Mar 2 01:34:48 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 2 Mar 2011 10:34:48 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/2/11 07:53, "Ryan Boder" wrote: Can you / have you made a simple test to ensure that rxtx is the issue? Can you write a simple C-program to see if this exhibits the same problem? I've never encountered this sort of problem with rxtx, it mostly just works. But I'm on Mac so can't say about Windows (7) br Kusti >Hi, > >I haven't seen any response to my question below. Is this not the right >place to ask? If not, where would be a better place to ask? Any >suggestions? > >Thanks, >Ryan > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > >I mis-spoke, I don't have my own thread calling read, I am calling >read in the event handler after receiving a >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be >accurate though. > >Ryan > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >Hi, > >I have a receive thread that does nothing but call read() on the serial >port input stream. It works fine for a while but after running for a long >time it eventually returns -1 which means EOF. This is my first problem, >as the device I'm talking to runs forever, I don't know why it would >return -1. I am calling disableReceiveThreshold() and >disableReceiveTimeout() at initialization which according to the >documentation means read will return as soon as any data is available and >it will block forever when data is not available, so -1 should never be >returned from read, right? > >I have been unable to figure out why read returns -1 after a long while >but I have found that if I kill my application and restart it everything >works fine again. Therefore I tried to work around the problem by having >my code close the port and reopen it when read returns -1. My second >problem is that in this case when I call close() on the port it blocks >forever. I did find this old bug > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > >which describes close() hanging on OSX, but it says that bug was fixed >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone >have any idea why read might be returning -1 in the first place? If I can >avoid that I don't care about close() hanging because I would never close >the port. If not, does anyone know why close() might block forever and >how I can prevent this? I'm using RXTX version 2.1-7. > >Thanks, >-- >Ryan > > > > > > > > > >-- >Ryan Boder >1 614 598-6339 > > > > > > >-- >Ryan Boder >1 614 598-6339 > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From Steffen.DETTMER at ingenico.com Wed Mar 2 03:08:57 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:08:57 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <32684-1298981297-704398@sneakemail.com> References: <4D6CD4DE.7040501@sandglass-software.com> <32684-1298981297-704398@sneakemail.com> Message-ID: <20110302100857.GB8030@elberon.bln.de.ingenico.com> * iqzw2r602 at sneakemail.com wrote on Tue, Mar 01, 2011 at 23:08 +1100: > This reminds me of a nasty problem I had with overlapped I/O on windows Yeah, those thousands of complex, difficult to use and exception-containing WinAPI is really hard to use... About strange effects on overlapped&multithreading, MSDN has: `the calling thread uses the GetOverlappedResult function or one of the wait functions' [1] also also mentiones I/O Completion Ports [2], and later continues: `If an application reuses OVERLAPPED structures on multiple threads and calls GetOverlappedResult with the bWait parameter set to TRUE, the application must ensure that the associated event is set before the application reuses the structure. This can be accomplished by using the WaitForSingleObject function after calling GetOverlappedResult to force the thread to wait until the operation completes. Note that the event object must be a manual-reset event object. If an autoreset event object is used, calling GetOverlappedResult with the bWait parameter set to TRUE causes the function to be blocked indefinitely.' also [1] oki, Steffen [1] http://msdn.microsoft.com/en-us/library/ms686358%28v=vs.85%29.aspx [2] http://msdn.microsoft.com/en-us/library/aa365198%28v=vs.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:15:11 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:15:11 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6D1D93.6090306@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> <4D6D1D93.6090306@sandglass-software.com> Message-ID: <20110302101511.GC8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 08:23 -0800: > Unfortunately, the javax.comm API specification includes a lot of > implementation details. That is one of the weaknesses of the > specification in my opinion. The bottom line is, anyone wanting to use > RxTx as a javax.comm implementation is going to expect it to do the > things the specification says it does. Yeah ok, but even then the implementation could check for the TooManyListenersException situations (if it really is required to support applications relying on that exception) but internally use just a single I/O thread waiting for events on any open file descriptors. Of course an implementation supporting all sort of concurrency could become quite complex (especially if open-read-close should work fast, I think would be difficult to implement, because a new file descriptors had to be added to the waitFor/select list, and who knows how systems behave here in detail...). oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:25:15 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:25:15 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6CDB22.9070401@sandglass-software.com> References: <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> <4D6CDB22.9070401@sandglass-software.com> Message-ID: <20110302102515.GD8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 03:40 -0800: > * from some older mail: > > My question would be: Why would you do that? The rewrite does > > most of the work for you - all you have to do is implement > > two C++ virtual classes and two C++ functions. > > > > In Windows that took me a few hours. > > Every journey begins with a single step. Yes, of course, but then it shouldn't be used as base for new effort estimations like `In Windows that took a few hours' ;-) (BTW, calling a single step `the rewrite' may sound a bit ambitious ;)) But of course a prototype demonstrating something can be really helpful, sure. I just wanted to tell that interfaces should be easy to use and powerful at the same time and may non-trivial initial considerations before starting to implement them. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From ryan.boder at gmail.com Wed Mar 2 18:44:35 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:44:35 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: While running the tests you requested I may have stumbled on the problem, I just don't know how to fix it. According to the documentation, if both the receive timeout and receive threshold are disabled then read() should block forever until data is available. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#getInputStream%28%29 On my system using RXTX read() is returning -1 when no data is available even though I have disabled both thresholds. The reason my program was running fine for a while without this problem showing up is that I was using the DATA_AVAILABLE event to be notified when data is available and only calling read() to read an entire frame whenever the DATA_AVAILABLE event occurred, until eventually my device (I'm guessing) probably took longer than normal to send the entire data frame and therefore I called read when no data was available and it returned -1. The following Java program demonstrates my problem, it returns -1 as soon as no data is available, even though I think it should block until data is available. import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; public class Main implements SerialPortEventListener { public static void main(String[] args) throws Exception { new Main().run(); } private void run() throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier("COM4"); SerialPort port = (SerialPort) portIdentifier.open(Main.class.getName(), 2000); port.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); port.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); port.disableReceiveThreshold(); port.disableReceiveTimeout(); BufferedInputStream in = new BufferedInputStream(port.getInputStream()); BufferedOutputStream out = new BufferedOutputStream(port.getOutputStream()); port.addEventListener(this); Thread.sleep(1000); out.write(new byte[] {0x02, 0x60}); out.flush(); while (true) { int x = in.read(); if (x == -1) { System.out.println("EOF"); Thread.sleep(1000000000); } String s = Integer.toHexString(x & 0xFF); if (s.length() == 1) s = "0" + s; System.out.print(s + " "); System.out.flush(); } } public void serialEvent(SerialPortEvent arg0) { System.out.println("Serial port event"); } } However, the follow C# program ran all day today without ever read ever returning -1, as I would expect. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.IO.Ports; using System.Threading; namespace RXTXReadTest1 { class Program { static void Main(string[] args) { new Program().run(); } private void run() { SerialPort port = new SerialPort("COM4", 19200, Parity.None, 8, StopBits.One); port.Open(); port.Write(new byte[] { 0x02, 0x60 }, 0, 2); while (true) { int x = port.ReadByte(); if (x == -1) { Console.WriteLine("EOF"); Thread.Sleep(1000000000); } String s = x.ToString("X"); if (s.Length == 1 ) s = "0" + s; Console.Out.Write(s + " "); Console.Out.Flush(); } } } } Now I am experimenting with what happens if I set the receive timeout to it's maximum value (apparently 1600ms) and only call read() when I am expecting data. Hopefully it will never be more than 1600ms late. This is still only a work around, not solving the problem. Am I doing something wrong in my code above or is RXTX retuning -1 when it should be blocking? Thanks, Ryan On Wed, Mar 2, 2011 at 3:34 AM, Kustaa Nyholm wrote: > On 3/2/11 07:53, "Ryan Boder" wrote: > Can you / have you made a simple test to ensure that rxtx is the issue? > > Can you write a simple C-program to see if this exhibits the same problem? > > I've never encountered this sort of problem with rxtx, it mostly just > works. > > But I'm on Mac so can't say about Windows (7) > > br Kusti > > > > > >Hi, > > > >I haven't seen any response to my question below. Is this not the right > >place to ask? If not, where would be a better place to ask? Any > >suggestions? > > > >Thanks, > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder > wrote: > > > >I mis-spoke, I don't have my own thread calling read, I am calling > >read in the event handler after receiving a > >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be > >accurate though. > > > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder > wrote: > > > >Hi, > > > >I have a receive thread that does nothing but call read() on the serial > >port input stream. It works fine for a while but after running for a long > >time it eventually returns -1 which means EOF. This is my first problem, > >as the device I'm talking to runs forever, I don't know why it would > >return -1. I am calling disableReceiveThreshold() and > >disableReceiveTimeout() at initialization which according to the > >documentation means read will return as soon as any data is available and > >it will block forever when data is not available, so -1 should never be > >returned from read, right? > > > >I have been unable to figure out why read returns -1 after a long while > >but I have found that if I kill my application and restart it everything > >works fine again. Therefore I tried to work around the problem by having > >my code close the port and reopen it when read returns -1. My second > >problem is that in this case when I call close() on the port it blocks > >forever. I did find this old bug > > > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > > > >which describes close() hanging on OSX, but it says that bug was fixed > >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone > >have any idea why read might be returning -1 in the first place? If I can > >avoid that I don't care about close() hanging because I would never close > >the port. If not, does anyone know why close() might block forever and > >how I can prevent this? I'm using RXTX version 2.1-7. > > > >Thanks, > >-- > >Ryan > > > > > > > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Wed Mar 2 18:46:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:46:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: <-1051064942000733580@unknownmsgid> References: <-1051064942000733580@unknownmsgid> Message-ID: It is USB and seems very reliable with the C# test program in my previous email. On Wed, Mar 2, 2011 at 6:58 PM, Bruce Griffith wrote: > How reliable is your serial port ? is it USB or Bluetooth? > > > > Bruce Griffith > > 303-532-4778 > > > > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On Behalf > Of *Ryan Boder > *Sent:* Tuesday, 01 March 2011 10:53 PM > *To:* rxtx at qbang.org > *Subject:* Re: [Rxtx] RXTX serial port read() returns -1 unexpectedly and > then blocks forever on close() > > > > Hi, > > I haven't seen any response to my question below. Is this not the right > place to ask? If not, where would be a better place to ask? Any suggestions? > > Thanks, > Ryan > > On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > > Hi, > > I have a receive thread that does nothing but call read() on the serial > port input stream. It works fine for a while but after running for a long > time it eventually returns -1 which means EOF. This is my first problem, as > the device I'm talking to runs forever, I don't know why it would return -1. > I am calling disableReceiveThreshold() and disableReceiveTimeout() at > initialization which according to the documentation means read will return > as soon as any data is available and it will block forever when data is not > available, so -1 should never be returned from read, right? > > I have been unable to figure out why read returns -1 after a long while but > I have found that if I kill my application and restart it everything works > fine again. Therefore I tried to work around the problem by having my code > close the port and reopen it when read returns -1. My second problem is that > in this case when I call close() on the port it blocks forever. I did find > this old bug > > http://bugzilla.qbang.org/show_bug.cgi?id=53 > > which describes close() hanging on OSX, but it says that bug was fixed with > a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have any > idea why read might be returning -1 in the first place? If I can avoid that > I don't care about close() hanging because I would never close the port. If > not, does anyone know why close() might block forever and how I can prevent > this? I'm using RXTX version 2.1-7. > > Thanks, > -- > Ryan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Mar 3 02:50:20 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 3 Mar 2011 09:50:20 +0000 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: So if -1 is unexpectedly returned from read, and we have demonstrated that your USB-serial adapter can actually causes this to happen in RXTX, why not just ignore the -1 value? What happens when you try this? As for a hang on close, are your closing your port from within your serial event handler? I know that this can cause some serious problems. Regards, Michael Erskine. From Kustaa.Nyholm at planmeca.com Thu Mar 3 03:39:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 12:39:34 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 03:44, "Ryan Boder" wrote: >While running the tests you requested I may have stumbled on the problem, >I just don't know how to fix it. According to the documentation, if both >the receive timeout and receive threshold are disabled then read() should >block forever until data is available. > >http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/re >ference/api/javax/comm/CommPort.html#getInputStream%28%29 > >On my system using RXTX read() is returning -1 when no data is available >even though I have disabled both thresholds. The reason my program was >running fine for a while without this problem showing up is that I was >using the DATA_AVAILABLE event to be notified when data is available and >only calling read() to read an entire frame whenever the DATA_AVAILABLE >event occurred, until eventually my device (I'm guessing) probably took >longer than normal to send the entire data frame and therefore I called >read when no data was available and it returned -1. As a workaround have you tried to perform another read() if it returns -1? The javadoc says (see getInputStream): "Note, however, that framing errors may cause the Timeout and Threshold values to complete prematurely without raising an exception." I read this as a hint that read might return even if no data is available. Because of the above and that read() can only return -1 or the byte received it would be somewhat logical to return -1 in case of framing error ? I'm not claiming that my interpretation of the specification, such as it is, is correct, just speculating that the behavior could be something like that. It might give you some more insight if you used the read(bytes[],int,int) method, because this can and will return 0 in case of timeout (and presumably might do so in case of framing error, maybe some other error condition too). That might allow you to handle or work around the problem in this case. You have not shown your complete code (no need) but your comments and the example makes me wonder if the code is otherwise as it should be, meaning are you assuming that when you get the DATA_AVAILABLE event all of your frame has arrived and that you can just blindly read it away from the input stream? That is not guaranteed of course. Also using read(), instead of read(bytes[],int,int), is not very efficient and might be masking other problems as mused above. BTE you can print a byte in hex with leading zeros more easily with: System.out.printf("%02X",x); br Kusti From ryan.boder at gmail.com Thu Mar 3 07:56:16 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:56:16 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 5:39 AM, Kustaa Nyholm wrote: > > As a workaround have you tried to perform another read() if it returns -1? > I tried that and it did work sometimes but not all the time. > > The javadoc says (see getInputStream): > > "Note, however, that framing errors may cause the Timeout and Threshold > values to complete prematurely without raising an exception." > > I read this as a hint that read might return even if no data is available. > > Because of the above and that read() can only return -1 or the byte > received > it would be somewhat logical to return -1 in case of framing error ? > > I'm not claiming that my interpretation of the specification, such as it > is, > is correct, just speculating that the behavior could be something like > that. > Receive framing is not enabled by default. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#enableReceiveFraming%28int%29 My choice of word might be misleading, when I said frame I just meant a contiguous message from the device. I am not enabling receive framing. Can you have a framing error when receive framing is disabled? > > It might give you some more insight if you used the read(bytes[],int,int) > method, because > this can and will return 0 in case of timeout (and presumably might do so > in case of framing > error, maybe some other error condition too). > > That might allow you to handle or work around the problem in this case. > > You have not shown your complete code (no need) but your comments and the > example > makes me wonder if the code is otherwise as it should be, meaning are you > assuming > that when you get the DATA_AVAILABLE event all of your frame has arrived > and that > you can just blindly read it away from the input stream? That is not > guaranteed of course. > I'm not assuming the entire message has arrived, I'm just assuming it either has arrived or will arrive soon which is why I'm using a (supposedly) blocking read(). > > Also using read(), instead of read(bytes[],int,int), is not very efficient > and > might be masking other problems as mused above. > True, I'm reading one byte at a time because I don't know how long the message will be until I read and parse some of it. I suppose I can use read(bytes[],int,int) once I figure out how long the message will be. > > BTE you can print a byte in hex with leading zeros more easily with: > > > System.out.printf("%02X",x); > I did it the dumb way in that test program so I could copy and paste the code from C# to Java without having to figure out how to do the same in C# which I'm not as familiar with. Thanks and BR, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 07:58:24 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:58:24 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: Yes I was doing the close in the serial event handler, I didn't realize that caused a problem. Thanks, I'll fix it. On Thu, Mar 3, 2011 at 4:50 AM, Michael Erskine wrote: > So if -1 is unexpectedly returned from read, and we have demonstrated > that your USB-serial adapter can actually causes this to happen in > RXTX, why not just ignore the -1 value? What happens when you try > this? As for a hang on close, are your closing your port from within > your serial event handler? I know that this can cause some serious > problems. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 11:48:20 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 13:48:20 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm wrote: > On 3/3/11 16:56, "Ryan Boder" wrote: > > > >I'm not assuming the entire message has arrived, I'm just assuming it > >either has arrived or will arrive soon which is why I'm using a > >(supposedly) blocking read(). > > > I've been giving this some further thought. > > It does not feel healthy to block without timeout, especially > from within a thread that is essentially internal to the rxtx. > > I've never done that, I always use a time out, read(byte[],int,int) > for the expected number of bytes, check how much I got and issue > more reads until I get everything. > > You have not described how your communication works so I'm only > speculating. > > If your device needs some response to send more bytes (from your > code it looks like this is not the case) then a missing byte > would block your read and prevent you from responding and > getting more data. But as said, looks like that is not the case. > > Anyway, if this was my problem, I would enable the timeout > and use read(byte[],int,int) and loop until I get what I need. > You are right, I should and will use a timeout. In fact, my program has been running flawlessly for 12 hours and the only change I made was to enable a timeout, no change in the logic at all. Without the timeout read() was returning -1 usually after it ran for an hour or two. I will change the code to make use of the timeout and handle it appropriately. It still seems to me that RXTX's behavior doesn't match the documentation when rx timeout and rx threshold are disabled read() should block until data is available instead of immediately returning -1. I don't believe that a framing error is occurring immediately every time data is not available causing read() to return -1. Especially since the C# test program above runs all day with no error and the Java program above runs all day with no error when a timeout is enabled. To me it seems like enabling the timeout is what is causing read() to block until data is available, even if only for 1600ms, and without the timeout read() is returning -1 immediately when it should be blocking. Thanks for all the help and best regards, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Thu Mar 3 13:02:30 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 22:02:30 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 20:48, "Ryan Boder" wrote: >On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm > wrote: > >On 3/3/11 16:56, "Ryan Boder" wrote: >> > >>I'm not assuming the entire message has arrived, I'm just assuming it >>either has arrived or will arrive soon which is why I'm using a >>(supposedly) blocking read(). > > > >I've been giving this some further thought. > >It does not feel healthy to block without timeout, especially >from within a thread that is essentially internal to the rxtx. > >I've never done that, I always use a time out, read(byte[],int,int) >for the expected number of bytes, check how much I got and issue >more reads until I get everything. > >You have not described how your communication works so I'm only >speculating. > >If your device needs some response to send more bytes (from your >code it looks like this is not the case) then a missing byte >would block your read and prevent you from responding and >getting more data. But as said, looks like that is not the case. > >Anyway, if this was my problem, I would enable the timeout >and use read(byte[],int,int) and loop until I get what I need. > > > > >You are right, I should and will use a timeout. In fact, my program has >been running flawlessly for 12 hours and the only change I made was to >enable a timeout, no change in the logic at all. Without the timeout >read() was returning -1 usually after it ran for an hour or two. I will >change the code to make use of the timeout and handle it appropriately. That's nice! > >It still seems to me that RXTX's behavior doesn't match the documentation >when rx timeout and rx threshold are disabled read() should block until >data is available instead of immediately returning -1. Yeah, it does look like bug. However this might be related to some Windows specific serial port issue. Years ago I had issues with JavaComm (not RxTx) where I did a blocking read and I had huge issues with my program consuming all resources. I curser the Sun and JavaComm and re-code my own SerialPort using JNI to access the Win32 API directly. And I run into the same problems as with the Sun's implementation! So I ditched my code, changed my code to use timeouts and problems disappeared. > I don't believe that a framing error is occurring immediately every time >data is not available causing read() to return -1. Especially since the >C# test program above runs all day with no error and the Java program >above runs all day with no error when a timeout is enabled. I think so too, all things considered I don't really believe in framing errors in this case. > To me it seems like enabling the timeout is what is causing read() to >block until data is available, even if only for 1600ms, and without the >timeout read() is returning -1 immediately when it should be blocking. Yeah, I had a peek at the innards of RxTx Windows serial port a week or so ago and also read MSDN documentation about serial ports and the way overlapped and non-overlapped (non blocking and blocking) IO is handled is a way different. So yeah, it can well be that there is an issue lurking there somewhere inside RxTx in Windows. > > >Thanks for all the help and best regards, >-- >Ryan Boder I'm happy if I was of any assistance. br Kusti From tjarvi at qbang.org Thu Mar 3 18:52:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Mar 2011 18:52:50 -0700 (MST) Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: >> Without the timeout >> read() was returning -1 usually after it ran for an hour or two. There is a big hammer in rxtx causing that behavior. >> It still seems to me that RXTX's behavior doesn't match the documentation >> when rx timeout and rx threshold are disabled read() should block until >> data is available instead of immediately returning -1. > > Yeah, it does look like bug. However this might be related to some > Windows specific serial port issue. Years ago I had issues with > JavaComm (not RxTx) where I did a blocking read and I had huge > issues with my program consuming all resources. I curser the Sun > and JavaComm and re-code my own SerialPort using JNI to access > the Win32 API directly. And I run into the same problems as > with the Sun's implementation! So I ditched my code, changed > my code to use timeouts and problems disappeared. > > >> To me it seems like enabling the timeout is what is causing read() to >> block until data is available, even if only for 1600ms, and without the >> timeout read() is returning -1 immediately when it should be blocking. > > Yeah, I had a peek at the innards of RxTx Windows serial port a week > or so ago and also read MSDN documentation about serial ports and > the way overlapped and non-overlapped (non blocking and blocking) > IO is handled is a way different. So yeah, it can well be that > there is an issue lurking there somewhere inside RxTx in Windows. > > Yes. RXTX was patched to behave the way it does. I don't fully understand the issue behind the patch. Marc noticed the odd behavior as well and offered a fix which was greeted with resistance. The windows implementation was done without real documentatino of the windows API. I think I had an example from the late 80's early 90's on Microsoft's site and some API documentation that was obviously not microsofts in Europe. Wayne Roberts had a real need for windows support and fixed some major issues it had. My interest at the time was mingw32. I then cleaned it up for some specific uses I had later. The read returning -1 when it should block didn't impact anybody and appeared to help some people. It isnt the documented behavior though. There could be all sorts of latent bugs in that code but in the real world, it gets by in almost all use cases. Its a hack but it worked for 100's of thousands of people over a 14 year period. Maybe its time to revisit the code but there is more risk than gain for most people. How do you move forward and avoid the risk? Some have expressed interests in coding C++ or other efforts. I'm all for such efforts but feel some unit tests that work with a null modem cables are the only thing that will move rxtx (and perhaps CommAPI) forward. If we have a test suite in place as a qualification for implementations, progress can be made in the right direction regardless of the implementation details. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Fri Mar 4 02:57:16 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 4 Mar 2011 11:57:16 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/4/11 03:52, "Trent Jarvi" wrote: >Yes. RXTX was patched to behave the way it does. I don't fully >understand the issue behind the patch. Marc noticed the odd behavior as >well and offered a fix which was greeted with resistance. > >The windows implementation was done without real documentatino of the >windows API. I think I had an example from the late 80's early 90's on >Microsoft's site and some API documentation that was obviously not >microsofts in Europe. Wayne Roberts had a real need for windows support >and fixed some major issues it had. My interest at the time was mingw32. >I then cleaned it up for some specific uses I had later. The read >returning -1 when it should block didn't impact anybody and appeared to >help some people. It isnt the documented behavior though. > >There could be all sorts of latent bugs in that code but in the real >world, it gets by in almost all use cases. I think so too, never had any problems with it. > Its a hack but it worked for 100's of thousands of people over a 14 year >period. Yeah! Thanks for everyone who has contributed over the years, job well done! >Maybe its time to >revisit the code but there is more risk than gain for most people. How >do >you move forward and avoid the risk? My view is that it is quite risky and rather pointless to move forward, other than fixing bugs that really affect people. At the moment the major issue IMO is just that it seems (not been following this too carefully, so maybe I'm wrong, so in case this FUD, my apologies) that 'official' binaries are not available. I think the rewrite, tempting as it is in some respects is not the way forward. Just gentle maintenance to iron out real issues and then get the binaries out. br Kusti From ryan.boder at gmail.com Fri Mar 4 07:24:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Fri, 4 Mar 2011 09:24:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 8:52 PM, Trent Jarvi wrote: > > The windows implementation was done without real documentatino of the > windows API. I think I had an example from the late 80's early 90's on > Microsoft's site and some API documentation that was obviously not > microsofts in Europe. Wayne Roberts had a real need for windows support and > fixed some major issues it had. My interest at the time was mingw32. I then > cleaned it up for some specific uses I had later. The read returning -1 > when it should block didn't impact anybody and appeared to help some people. > It isnt the documented behavior though. > > There could be all sorts of latent bugs in that code but in the real world, > it gets by in almost all use cases. Its a hack but it worked for 100's of > thousands of people over a 14 year period. Maybe its time to revisit the > code but there is more risk than gain for most people. How do you move > forward and avoid the risk? > The safest and easiest solution would be to add a javadoc comment to disableReceiveTimeout explaining the difference between the RXTX behavior and Sunacle's documented behavior so that when someone uses the method in an IDE like Eclipse a little box would pop up informing them. Generating javadoc HTML and hosting it on the RXTX website would go a long way too, when something behaves differently than I expect the first thing I do is look for the javadoc online. -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From kharrington at neuronrobotics.com Mon Mar 7 10:47:26 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 12:47:26 -0500 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! Message-ID: Hey all, this is just a heads up that i have made a fork of rxtxSerial. Some of the features we have added: * Self deployment of native libraries ( all native code is stored inside the jar and deployed at runtime). No more manual install of native code. * Arm Cortex support (Gumstix) * Android Support (requires a rooted phone for now) * Google Code (SVN) repository for easy code and jar access * Single makefile compile (simplifies the compilation of project binaries) * Ant build script for jar creation * Removal of partialy implemented code to streamline the lib for just serial port access * Full Eclipse integration, for testing application code against sources. And a bunch of bug fixes: * Fixed the memory access error that causes OSX to crash the JVM when serial.close() is cvalled * Fixed the windows serial port zombie bind that prevents re-accessing serial ports when exiting on an exception * Fixed erronious printouts of native library mis-match To check it out, take a look at our page here: http://code.google.com/p/nrjavaserial/ From Kustaa.Nyholm at planmeca.com Mon Mar 7 11:46:26 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Mar 2011 20:46:26 +0200 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: Message-ID: On 3/7/11 19:47, "Kevin Harrington NR" wrote: >Hey all, this is just a heads up that i have made a fork of >rxtxSerial. Some of the features we have added great! If also does what it says on the tin: brilliant! Congrats and thanks. br Kusti From jmsachs at gmail.com Mon Mar 7 12:50:33 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 14:50:33 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: > From: Kevin Harrington NR > To: rxtx at qbang.org > Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > Hey all, this is just a heads up that i have made a fork of > rxtxSerial. Some of the features we have added: > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with a ten-foot pole. From Kustaa.Nyholm at planmeca.com Mon Mar 7 13:10:43 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Mar 2011 22:10:43 +0200 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: Message-ID: On 3/7/11 21:50, "Jason Sachs" wrote: > >Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >a ten-foot pole. >_______________________________________________ Oh crap, makes it useless for me and many others. Also I see no provision in RxTx license to change it so how could anyone change it to GPLv3? br Kusti From showard314 at gmail.com Mon Mar 7 13:24:08 2011 From: showard314 at gmail.com (Scott Howard) Date: Mon, 7 Mar 2011 15:24:08 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 3:10 PM, Kustaa Nyholm wrote: > Also I see no provision in RxTx license to change > it so how could anyone change it to GPLv3? I think this is allowed: 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. From jmsachs at gmail.com Mon Mar 7 13:24:47 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 15:24:47 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 2:50 PM, Jason Sachs wrote: >> From: Kevin Harrington NR >> To: rxtx at qbang.org >> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> > > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with > a ten-foot pole. > Let me back up a second (perhaps to make up for my lack of diplomacy) and state that I think any progress w/ rxtx is good. If an rxtx fork were LGPL (or some other non-spreading open source license) and leading in a good direction, I'd gladly return the favor by posting any improvements or bugfixes I found to the community. --Jason From jmsachs at gmail.com Mon Mar 7 13:36:13 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 15:36:13 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: Kevin: could you clarify the license? http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java has the RXTX 2.1 license (LGPL v 2.1 + Linking Over Controlled Interface.) but http://code.google.com/p/nrjavaserial/ says GPLv3. --Jason From kharrington at neuronrobotics.com Mon Mar 7 14:00:02 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 16:00:02 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: The one downside to google code is that it does not allow custom licensing. You have to pick from a drop-down list. Treat the licences on the files themselves as the licence to be concerned with, and ignore the "project licence". Sorry for the confusion. On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: > Kevin: could you clarify the license? > > http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java > has the RXTX 2.1 license > (LGPL v 2.1 + Linking Over Controlled Interface.) > > but http://code.google.com/p/nrjavaserial/ says GPLv3. > > --Jason > From iqzw2r602 at sneakemail.com Mon Mar 7 14:08:18 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 8 Mar 2011 08:08:18 +1100 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: References: Message-ID: <11253-1299532098-811882@sneakemail.com> Nice! Out of curiosity, did you use the patch that I sent Trent about two years ago to do the native library loading, or did you implement your own solution? Cheers, Uwe On Tue, Mar 8, 2011 at 5:46 AM, Kustaa Nyholm Kustaa.Nyholm-at-planmeca.com| rxtx.org mailing list/Example Allow| wrote: > On 3/7/11 19:47, "Kevin Harrington NR" > wrote: > > >Hey all, this is just a heads up that i have made a fork of > >rxtxSerial. Some of the features we have added > > > > great! If also does what it says on the tin: brilliant! > > Congrats and thanks. > > br Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aawolfe at gmail.com Mon Mar 7 15:31:47 2011 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 7 Mar 2011 17:31:47 -0500 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR wrote: > Hey all, this is just a heads up that i have made a fork of > rxtxSerial. Some of the features we have added: > > * Self deployment of native libraries ( all native code is stored > inside the jar and deployed at runtime). No more manual install of > native code. > * Arm Cortex support (Gumstix) > * Android Support (requires a rooted phone for now) > * Google Code (SVN) repository for easy code and jar access > * Single makefile compile (simplifies the compilation of project binaries) > * Ant build script for jar creation > * Removal of partialy implemented code to streamline the lib for just > serial port access > * Full Eclipse integration, for testing application code against sources. > > And a bunch of bug fixes: > > * Fixed the memory access error that causes OSX to crash the JVM when > serial.close() is cvalled > * Fixed the windows serial port zombie bind that prevents re-accessing > serial ports when exiting on an exception > * Fixed erronious printouts of native library mis-match > > To check it out, take a look at our page here: > > http://code.google.com/p/nrjavaserial/ This is interesting, getting the native libs set up has been an issue for some of my users. Will have to check it out. Out of curiosity, what Android devices provide a serial port? Or are there some that allow USB host mode and then a usb-serial adapter? I have only an Android cell phone, don't think it can do anything serial but would love to be wrong about that. From jfh at greenhousepc.com Mon Mar 7 15:54:39 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 15:54:39 -0700 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! Message-ID: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Mon Mar 7 16:53:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Mar 2011 16:53:50 -0700 (MST) Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: Hi Kevin, Until Google fixes the options as developers have requested, I'd suggest the least misleading dropdown option is "Other Open Source" with a clarification about LGPL 2.1 on the project page. If you are not supporting the CommAPI SPI interface that was available prior to the current JSR so that applications work in the javax.comm namespace, there is no need for the linking over controlled interfaces exception. RXTX 2.0 is used in that fashion but RXTX 2.1 is not. The exception explicitly states it can be removed if the source has been modified. The license is then explicitly OSI reviewed and approved as Google requests but is not in their drop down box as it should be and is for the GPL v2. http://opensource.org/licenses/alphabetical http://opensource.org/licenses/lgpl-2.1 The drawback would be that the library effectively could never be used in that SPI/controlled interface fashion again. On Mon, 7 Mar 2011, Kevin Harrington NR wrote: > The one downside to google code is that it does not allow custom > licensing. You have to pick from a drop-down list. Treat the licences > on the files themselves as the licence to be concerned with, and > ignore the "project licence". Sorry for the confusion. > > On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >> Kevin: could you clarify the license? >> >> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >> has the RXTX 2.1 license >> (LGPL v 2.1 + Linking Over Controlled Interface.) >> >> but http://code.google.com/p/nrjavaserial/ says GPLv3. >> >> --Jason >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From hakcenter at gmail.com Mon Mar 7 18:55:57 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 17:55:57 -0800 Subject: [Rxtx] Latency Woes Message-ID: <4D758CAD.2010602@gmail.com> I have finally deduced my slow data logging to a latency issue. I write software for dsms, and the protocol is request / receive, you cannot do more than 1 sensor at a time. So when you log multiple sensors, +20ms per item, sampling rate drops like a rock. I was wondering if there is any ideas besides going completely native with my application to reduce latency. With or without events I don't care at this point I need to kill as much of the latency as possible. Realistically I need no more than 1ms. From adrian.crum at sandglass-software.com Mon Mar 7 19:08:21 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Mon, 07 Mar 2011 18:08:21 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D758CAD.2010602@gmail.com> References: <4D758CAD.2010602@gmail.com> Message-ID: <4D758F95.90800@sandglass-software.com> Drop the requests into a queue, and then have a separate thread service the queue. -Adrian On 3/7/2011 5:55 PM, Curtis Hacker wrote: > I have finally deduced my slow data logging to a latency issue. > > I write software for dsms, and the protocol is request / receive, you > cannot do more than 1 sensor at a time. So when you log multiple > sensors, +20ms per item, sampling rate drops like a rock. > > I was wondering if there is any ideas besides going completely native > with my application to reduce latency. With or without events I don't > care at this point I need to kill as much of the latency as possible. > Realistically I need no more than 1ms. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From hakcenter at gmail.com Mon Mar 7 19:24:16 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 18:24:16 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D758F95.90800@sandglass-software.com> References: <4D758CAD.2010602@gmail.com> <4D758F95.90800@sandglass-software.com> Message-ID: <4D759350.8060402@gmail.com> Sample code ? I don't necessarily want to read the byte I just wrote, but wait till the que depth is 2. Setup a thread without a sleep timer: if (in.available() > 1) { do_stuff(); } ?? On 03/07/11 18:08, Adrian Crum wrote: > Drop the requests into a queue, and then have a separate thread > service the queue. > > -Adrian > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: >> I have finally deduced my slow data logging to a latency issue. >> >> I write software for dsms, and the protocol is request / receive, you >> cannot do more than 1 sensor at a time. So when you log multiple >> sensors, +20ms per item, sampling rate drops like a rock. >> >> I was wondering if there is any ideas besides going completely native >> with my application to reduce latency. With or without events I don't >> care at this point I need to kill as much of the latency as possible. >> Realistically I need no more than 1ms. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adrian.crum at sandglass-software.com Mon Mar 7 19:46:02 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Mon, 07 Mar 2011 18:46:02 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D759350.8060402@gmail.com> References: <4D758CAD.2010602@gmail.com> <4D758F95.90800@sandglass-software.com> <4D759350.8060402@gmail.com> Message-ID: <4D75986A.6020003@sandglass-software.com> http://download.oracle.com/javase/tutorial/essential/concurrency/executors.html -Adrian On 3/7/2011 6:24 PM, Curtis Hacker wrote: > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: >> Drop the requests into a queue, and then have a separate thread >> service the queue. >> >> -Adrian >> >> On 3/7/2011 5:55 PM, Curtis Hacker wrote: >>> I have finally deduced my slow data logging to a latency issue. >>> >>> I write software for dsms, and the protocol is request / receive, >>> you cannot do more than 1 sensor at a time. So when you log multiple >>> sensors, +20ms per item, sampling rate drops like a rock. >>> >>> I was wondering if there is any ideas besides going completely >>> native with my application to reduce latency. With or without events >>> I don't care at this point I need to kill as much of the latency as >>> possible. Realistically I need no more than 1ms. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Mon Mar 7 19:50:45 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 19:50:45 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Mon Mar 7 20:04:01 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 19:04:01 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> Message-ID: <4D759CA1.8010903@gmail.com> I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. in.read(data, 0, 2); ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? On 03/07/11 18:50, jfh at greenhousepc.com wrote: > Curtis, > > No, I assume he means a real queue, not just "don't read all the bytes > at once." However, if you know you can process some number of > requests in some amount of time, allowing data to pile up (receiver > FIFO space permitting) can be a valid strategy. Inserting gobs of > Thread.yield() and notify() can help pep things up as well. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Mon, March 07, 2011 8:24 pm > To: rxtx at qbang.org > > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: > > Drop the requests into a queue, and then have a separate thread > > service the queue. > > > > -Adrian > > > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: > >> I have finally deduced my slow data logging to a latency issue. > >> > >> I write software for dsms, and the protocol is request / > receive, you > >> cannot do more than 1 sensor at a time. So when you log multiple > >> sensors, +20ms per item, sampling rate drops like a rock. > >> > >> I was wondering if there is any ideas besides going completely > native > >> with my application to reduce latency. With or without events I > don't > >> care at this point I need to kill as much of the latency as > possible. > >> Realistically I need no more than 1ms. > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From bartley at cmu.edu Mon Mar 7 20:08:05 2011 From: bartley at cmu.edu (Chris Bartley) Date: Mon, 7 Mar 2011 22:08:05 -0500 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> Message-ID: <9B1804F9-DBD0-476D-9345-806D00065A97@cmu.edu> We use a queue for all our request/response serial communications, and have found it really easy to work with. Code is here: http://code.google.com/p/create-lab-commons/source/browse/trunk/java/code/serial/src/edu/cmu/ri/createlab/serial/SerialPortCommandExecutionQueue.java It's assuming a command & response scheme that's specific to the protocol we use to talk to our robots, but it should be easy to modify for your needs. Hope this helps. Let me know if you have questions. Chris On Mar 7, 2011, at 9:50 PM, wrote: > Curtis, > > No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > Date: Mon, March 07, 2011 8:24 pm > To: rxtx at qbang.org > > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: > > Drop the requests into a queue, and then have a separate thread > > service the queue. > > > > -Adrian > > > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: > >> I have finally deduced my slow data logging to a latency issue. > >> > >> I write software for dsms, and the protocol is request / receive, you > >> cannot do more than 1 sensor at a time. So when you log multiple > >> sensors, +20ms per item, sampling rate drops like a rock. > >> > >> I was wondering if there is any ideas besides going completely native > >> with my application to reduce latency. With or without events I don't > >> care at this point I need to kill as much of the latency as possible. > >> Realistically I need no more than 1ms. > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Mon Mar 7 20:51:17 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 20:51:17 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110307205116.8ef0e5b4a80cef441275a6330ffad77d.9b325137d1.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From kharrington at neuronrobotics.com Mon Mar 7 20:55:23 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 22:55:23 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 7 In-Reply-To: References: Message-ID: To answer a few of you, I have changed the license to "Other open source license" as suggested. My company is modifying and maintaining this fork to support our robotics development library (http://code.google.com/p/nr-sdk/ http://dev.neuronrobotics.com). We will be implementing the standard serial port interface only, as it is the only one we need or care about. As for where the implementation came from, i would have to refer to my other developer to answer that. I wrote the build scripts and make files, as well as streamlining the C build process. I have remover the configure script, as it ends up being more confusing then compiling 3 C files needs to be. if you guys want to bring any of this into the main line, that's cool, but up to you to port over. Our fork will be focusing on polishing up the serial interface,and hopefully making it faster. I hope some of you will find our improvements useful! On Mon, Mar 7, 2011 at 6:53 PM, wrote: > Send Rxtx mailing list submissions to > ? ? ? ?rxtx at qbang.org > > To subscribe or unsubscribe via the World Wide Web, visit > ? ? ? ?http://mailman.qbang.org/mailman/listinfo/rxtx > or, via email, send a message with subject or body 'help' to > ? ? ? ?rxtx-request at qbang.org > > You can reach the person managing the list at > ? ? ? ?rxtx-owner at qbang.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Rxtx digest..." > > > Today's Topics: > > ? 1. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 2. Re: Rxtx Digest, Vol 43, Issue 6 (Kustaa Nyholm) > ? 3. Re: Rxtx Digest, Vol 43, Issue 6 (Scott Howard) > ? 4. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 5. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 6. Re: Rxtx Digest, Vol 43, Issue 6 (Kevin Harrington NR) > ? 7. Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! > ? ? ?(iqzw2r602 at sneakemail.com) > ? 8. Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! > ? ? ?(Aaron Wolfe) > ? 9. Re: [SPAM] Re: ?NRJavaSerial, a fork of rxtx that fixes the > ? ? ?papercuts! (jfh at greenhousepc.com) > ?10. Re: Rxtx Digest, Vol 43, Issue 6 (Trent Jarvi) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 7 Mar 2011 14:50:33 -0500 > From: Jason Sachs > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > >> From: Kevin Harrington NR >> To: rxtx at qbang.org >> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> > > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with > a ten-foot pole. > > > ------------------------------ > > Message: 2 > Date: Mon, 7 Mar 2011 22:10:43 +0200 > From: Kustaa Nyholm > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > On 3/7/11 21:50, "Jason Sachs" wrote: >> >>Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >>a ten-foot pole. >>_______________________________________________ > > Oh crap, makes it useless for me and many others. > > Also I see no provision in RxTx license to change > it so how could anyone change it to GPLv3? > > br Kusti > > > > ------------------------------ > > Message: 3 > Date: Mon, 7 Mar 2011 15:24:08 -0500 > From: Scott Howard > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 3:10 PM, Kustaa Nyholm > wrote: >> Also I see no provision in RxTx license to change >> it so how could anyone change it to GPLv3? > > I think this is allowed: > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. ?To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. ?(If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) ?Do not make any other change in > these notices. > > ? Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > ? This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > > ------------------------------ > > Message: 4 > Date: Mon, 7 Mar 2011 15:24:47 -0500 > From: Jason Sachs > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 2:50 PM, Jason Sachs wrote: >>> From: Kevin Harrington NR >>> To: rxtx at qbang.org >>> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >>> Message-ID: >>> ? ? ? ? >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> Hey all, this is just a heads up that i have made a fork of >>> rxtxSerial. Some of the features we have added: >>> >> >> Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >> a ten-foot pole. >> > > Let me back up a second (perhaps to make up for my lack of diplomacy) > and state that I think any progress w/ rxtx is good. > > If an rxtx fork were LGPL (or some other non-spreading open source > license) and leading in a good direction, I'd gladly return the favor > by posting any improvements or bugfixes I found to the community. > > --Jason > > > ------------------------------ > > Message: 5 > Date: Mon, 7 Mar 2011 15:36:13 -0500 > From: Jason Sachs > To: rxtx at qbang.org, kharrington at neuronrobotics.com > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > Kevin: could you clarify the license? > > http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java > has the RXTX 2.1 license > (LGPL v 2.1 + Linking Over Controlled Interface.) > > but http://code.google.com/p/nrjavaserial/ says GPLv3. > > --Jason > > > ------------------------------ > > Message: 6 > Date: Mon, 7 Mar 2011 16:00:02 -0500 > From: Kevin Harrington NR > To: Jason Sachs > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > The one downside to google code is that it does not allow custom > licensing. You have to pick from a drop-down list. Treat the licences > on the files themselves as the licence to be concerned with, and > ignore the "project licence". Sorry for the confusion. > > On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >> Kevin: could you clarify the license? >> >> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >> has the RXTX 2.1 license >> (LGPL v 2.1 + Linking Over Controlled Interface.) >> >> but http://code.google.com/p/nrjavaserial/ says GPLv3. >> >> --Jason >> > > > ------------------------------ > > Message: 7 > Date: Tue, 8 Mar 2011 08:08:18 +1100 > From: iqzw2r602 at sneakemail.com > To: Rxtx at qbang.org > Subject: Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > ? ? ? ?papercuts! > Message-ID: <11253-1299532098-811882 at sneakemail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Nice! > > Out of curiosity, did you use the patch that I sent Trent about two years > ago to do the native library loading, or did you implement your own > solution? > > Cheers, > > Uwe > > On Tue, Mar 8, 2011 at 5:46 AM, Kustaa Nyholm Kustaa.Nyholm-at-planmeca.com| > rxtx.org mailing list/Example Allow| wrote: > >> On 3/7/11 19:47, "Kevin Harrington NR" >> wrote: >> >> >Hey all, this is just a heads up that i have made a fork of >> >rxtxSerial. Some of the features we have added >> >> >> >> great! If also does what it says on the tin: brilliant! >> >> Congrats and thanks. >> >> br Kusti >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 8 > Date: Mon, 7 Mar 2011 17:31:47 -0500 > From: Aaron Wolfe > To: rxtx at qbang.org > Subject: Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > ? ? ? ?papercuts! > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR > wrote: >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> >> * Self deployment of native libraries ( all native code is stored >> inside the jar and deployed at runtime). No more manual install of >> native code. >> * Arm Cortex support (Gumstix) >> * Android Support (requires a rooted phone for now) >> * Google Code (SVN) repository for easy code and jar access >> * Single makefile compile (simplifies the compilation of project binaries) >> * Ant build script for jar creation >> * Removal of partialy implemented code to streamline the lib for just >> serial port access >> * Full Eclipse integration, for testing application code against sources. >> >> And a bunch of bug fixes: >> >> * Fixed the memory access error that causes OSX to crash the JVM when >> serial.close() is cvalled >> * Fixed the windows serial port zombie bind that prevents re-accessing >> serial ports when exiting on an exception >> * Fixed erronious printouts of native library mis-match >> >> To check it out, take a look at our page here: >> >> http://code.google.com/p/nrjavaserial/ > > This is interesting, getting the native libs set up has been an issue > for some of my users. ?Will have to check it out. > > Out of curiosity, what Android devices provide a serial port? ?Or are > there some that allow USB host mode and then a usb-serial adapter? ?I > have only an Android cell phone, don't think it can do anything serial > but would love to be wrong about that. > > > ------------------------------ > > Message: 9 > Date: Mon, 07 Mar 2011 15:54:39 -0700 > From: > To: aaron at aaronwolfe.com, rxtx at qbang.org > Subject: Re: [Rxtx] [SPAM] Re: ?NRJavaSerial, a fork of rxtx that > ? ? ? ?fixes the papercuts! > Message-ID: > ? ? ? ?<20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe at email13.secureserver.net> > > Content-Type: text/plain; charset="us-ascii" > > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 10 > Date: Mon, 7 Mar 2011 16:53:50 -0700 (MST) > From: Trent Jarvi > To: rxtx at qbang.org > Cc: Jason Sachs > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > Hi Kevin, > > Until Google fixes the options as developers have requested, I'd suggest > the least misleading dropdown option is "Other Open Source" with a > clarification about LGPL 2.1 on the project page. > > If you are not supporting the CommAPI SPI interface that was available > prior to the current JSR so that applications work in the javax.comm > namespace, there is no need for the linking over controlled interfaces > exception. ?RXTX 2.0 is used in that fashion but RXTX 2.1 is not. ?The > exception explicitly states it can be removed if the source has been > modified. ?The license is then explicitly OSI reviewed and approved as > Google requests but is not in their drop down box as it should be and is > for the GPL v2. > > ? ? ? ?http://opensource.org/licenses/alphabetical > ? ? ? ?http://opensource.org/licenses/lgpl-2.1 > > The drawback would be that the library effectively could never be used in > that SPI/controlled interface fashion again. > > On Mon, 7 Mar 2011, Kevin Harrington NR wrote: > >> The one downside to google code is that it does not allow custom >> licensing. You have to pick from a drop-down list. Treat the licences >> on the files themselves as the licence to be concerned with, and >> ignore the "project licence". Sorry for the confusion. >> >> On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >>> Kevin: could you clarify the license? >>> >>> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >>> has the RXTX 2.1 license >>> (LGPL v 2.1 + Linking Over Controlled Interface.) >>> >>> but http://code.google.com/p/nrjavaserial/ says GPLv3. >>> >>> --Jason >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > ------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > End of Rxtx Digest, Vol 43, Issue 7 > *********************************** > From Kustaa.Nyholm at planmeca.com Mon Mar 7 21:43:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 8 Mar 2011 06:43:57 +0200 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307205116.8ef0e5b4a80cef441275a6330ffad77d.9b325137d1.wbe@email13.secureserver.net> Message-ID: On 3/8/11 05:51, "jfh at greenhousepc.com" wrote: >Curtis, > > >None of that is relevant, as long as the UART is reasonable and the code >implements a proper half duplex protocol. > >If I understand correctly, you send a byte, the sensor sends back two >bytes. So long as you don't send the next byte until the two bytes are >in the UART receiver FIFO, you're fine. You don't have to actually >=read= them, just know they are available. To the OP, are you using a serial USB port, like FTDI? This has a built in latency of 10ms ie nothing is actually sent out of the device if you send less than 64 bytes until 10 msec timeout. This has nothing to do with RxTx. If you search the list archives you'll find more about this issue and IIRC someone reported that there is some diver parameter you can tweak to get rid of that latency. I'm sure the FTDI people had a good reason for this but it really brings down the communication speed if your protocol uses short messages and need to wait for a response. Sorry if this has already been mentioned or if this is not relevant, I've not been paying attention to this thread. br Kusti From bob_jacobsen at lbl.gov Tue Mar 8 00:02:28 2011 From: bob_jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 8 Mar 2011 00:02:28 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D759CA1.8010903@gmail.com> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> Message-ID: If you're transferring three bytes total at 1953 baud, it's going to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to wait 20msec to get the data back instead of 15.4 msec doesn't seem to be as big a problem as you're making it sound. Bob On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. > > To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. > > So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. > > in.read(data, 0, 2); > ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? > > On 03/07/11 18:50, jfh at greenhousepc.com wrote: >> Curtis, >> >> No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker >> Date: Mon, March 07, 2011 8:24 pm >> To: rxtx at qbang.org >> >> Sample code ? >> >> I don't necessarily want to read the byte I just wrote, but wait till >> the que depth is 2. >> >> Setup a thread without a sleep timer: >> if (in.available() > 1) { >> do_stuff(); >> } >> >> ?? >> >> On 03/07/11 18:08, Adrian Crum wrote: >> > Drop the requests into a queue, and then have a separate thread >> > service the queue. >> > >> > -Adrian >> > >> > On 3/7/2011 5:55 PM, Curtis Hacker wrote: >> >> I have finally deduced my slow data logging to a latency issue. >> >> >> >> I write software for dsms, and the protocol is request / receive, you >> >> cannot do more than 1 sensor at a time. So when you log multiple >> >> sensors, +20ms per item, sampling rate drops like a rock. >> >> >> >> I was wondering if there is any ideas besides going completely native >> >> with my application to reduce latency. With or without events I don't >> >> care at this point I need to kill as much of the latency as possible. >> >> Realistically I need no more than 1ms. >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From hakcenter at gmail.com Tue Mar 8 01:33:24 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 00:33:24 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> Message-ID: <4D75E9D4.5090307@gmail.com> I am going to try a couple things today and hopefully figure something out. Bob I don't want to pop your bubble, but a native application named 'TunerPro' can sample the same data, over 30 sensors, in less than 25ms. I've exchanged some emails with the author and it is a native C, polling, no events just timeouts. Kusta thanks for the FTDI notice, I believe that is tunable, however I have a particular user using a Keyspan converter and verified sampling rate with 'TunerPro' and its just off the charts. Chris thank you, I'll look into the queing. On 03/07/11 23:02, Bob Jacobsen wrote: > If you're transferring three bytes total at 1953 baud, it's going to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to wait 20msec to get the data back instead of 15.4 msec doesn't seem to be as big a problem as you're making it sound. > > Bob > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > >> I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. >> >> To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. >> >> So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. >> >> in.read(data, 0, 2); >> ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? >> >> On 03/07/11 18:50, jfh at greenhousepc.com wrote: >>> Curtis, >>> >>> No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. >>> -- >>> Julie Haugh >>> Senior Design Engineer >>> greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype From msemtd at googlemail.com Tue Mar 8 01:50:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 8 Mar 2011 08:50:15 +0000 Subject: [Rxtx] Latency Woes In-Reply-To: <4D75E9D4.5090307@gmail.com> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> <4D75E9D4.5090307@gmail.com> Message-ID: On 8 March 2011 08:33, Curtis Hacker wrote: > I am going to try a couple things today and hopefully figure something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than 25ms. > I've exchanged some emails with the author and it is a native C, polling, no > events just timeouts. Perhaps the author of TunerPro will let you use his native code - sounds just what you need. Regards, Michael Erskine. From jfh at greenhousepc.com Tue Mar 8 04:00:18 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 04:00:18 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 12:33:35 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 11:33:35 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> Message-ID: <4D76848F.5080809@gmail.com> Cable schematic: http://i1106.photobucket.com/albums/h377/vigilart/jackal%20logging%20set%20up/RS232SCHEMATIC.jpg 0.00268554 TunerPro.exe IOCTL_SERIAL_SET_BAUD_RATE VCP0 SUCCESS Rate: 1952 0.00305178 TunerPro.exe IOCTL_SERIAL_SET_RTS VCP0 SUCCESS 0.00297524 TunerPro.exe IOCTL_SERIAL_SET_DTR VCP0 SUCCESS 0.00297384 TunerPro.exe IOCTL_SERIAL_SET_LINE_CONTROL VCP0 SUCCESS StopBits: 1 Parity: NONE WordLength: 8 0.00000335 TunerPro.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 0.00202540 TunerPro.exe IOCTL_SERIAL_SET_HANDFLOW VCP0 SUCCESS Shake:1 Replace:40 XonLimit:2048 XoffLimit:512 0.00000335 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:300 RM:0 RC:2000 WM:0 WC:110 0.00000279 TunerPro.exe IOCTL_SERIAL_SET_QUEUE_SIZE VCP0 SUCCESS InSize: 1024 OutSize: 512 0.00000307 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000279 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:300 RM:0 RC:2000 WM:0 WC:110 0.00000307 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:75 RM:0 RC:400 WM:0 WC:300 0.00000559 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: RXCLEAR 0.00000335 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: TXCLEAR 0.00064980 TunerPro.exe IRP_MJ_WRITE VCP0 SUCCESS Length 1: . 0.01498738 TunerPro.exe IRP_MJ_READ VCP0 SUCCESS Length 1: . 0.00000363 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:200 RM:0 RC:20 WM:0 WC:300 0.02042774 TunerPro.exe IRP_MJ_READ VCP0 TIMEOUT Length 0: That is time on the left side. Now I'm with you on timing, it doesn't make a lot of sense, but that is how the logs come out. You can view the logs yourself. Tunerpro log : http://www.ds-map.net/tunerpro_log.csv My apps log : http://www.ds-map.net/my_log.csv 2nd app log : http://www.ds-map.net/my_log2.csv All these logs, were done from the same car, same cable. I have some older logs with some palm software, that was 13 sensors, and had a total 45-55ms between each set of 13. More info about the car / ecu at http://mmcdlogger.sourceforge.net Disassembly on the ecu: [SS1:SS0] is baud rate divider, 00(16) 01(128) 10(1024) 11(4096), assuming basic clock of 2MHZ, we get 125000baud, 15625baud, 1953baud, 488baud In any event, I attempted a no sleep thread, that waited till in.available > 1, and it wasn't any faster than running the events. Then I tried a read write thread, that slept from 1ms to 30ms after it wrote (so it wouldn't read what it just wrote). And couldn't get it doing much. I wish I had more of an understanding of all of this, which is why I'm asking for help. On 03/08/11 03:00, jfh at greenhousepc.com wrote: > Curtis, > > At the risk of being told "No, they really say it can be done", 30 > sensors is 30 * 3 character times (are you sure it's not a single byte > response?). At 1953 baud, a single character time is 10 bits * (1 / > 1953) seconds, or 15.4ms as Bob pointed out. 30 * 15.4ms is 460ms, > and that assumes everything works perfectly, no turnaround times, etc. > > If you can come up with some other way to make the math work, I'd love > to hear it. > > Short and sweet -- just because TunerPro can talk to an ECM/ECU that > is running faster than 1953 baud doesn't mean your Mitsubishi (or > whatever car you've got that runs at 1953 baud) runs at that faster > baud rate. > > Also, are you sure your data cable is correct? What cable are you > using? What's the schematic? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 2:33 am > To: rxtx at qbang.org > > I am going to try a couple things today and hopefully figure > something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than > 25ms. > I've exchanged some emails with the author and it is a native C, > polling, no events just timeouts. > > Kusta thanks for the FTDI notice, I believe that is tunable, > however I > have a particular user using a Keyspan converter and verified > sampling > rate with 'TunerPro' and its just off the charts. > > Chris thank you, I'll look into the queing. > > On 03/07/11 23:02, Bob Jacobsen wrote: > > If you're transferring three bytes total at 1953 baud, it's going > to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to > wait 20msec to get the data back instead of 15.4 msec doesn't seem > to be as big a problem as you're making it sound. > > > > Bob > > > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > > > >> I guess I'm gunna need some serious help with this then, because > of the scenario I'm stuck with. > >> > >> To communicate there is only 1 data line, rx/tx tied together > with a diode protecting the tx. No RTS/CTS handshaking nothing.. > >> > >> So the ecu can't process the next byte of info, without you > pulling the 2 bytes back. I wish this was standard, but even the > baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard > spot with this.. > >> > >> in.read(data , 0, 2); > >> ^ would the above wait till the timeout to read 2 bytes ? or > read 1 byte wait for the 2nd ? or just read the 1 ?? > >> > >> On 03/07/11 18:50, jfh at greenhousepc.com > wrote: > >>> Curtis, > >>> > >>> No, I assume he means a real queue, not just "don't read all > the bytes at once." However, if you know you can process some > number of requests in some amount of time, allowing data to pile > up (receiver FIFO space permitting) can be a valid strategy. > Inserting gobs of Thread.yield() and notify() can help pep things > up as well. > >>> -- > >>> Julie Haugh > >>> Senior Design Engineer > >>> greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 13:12:03 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 12:12:03 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> Message-ID: <4D768D93.1030504@gmail.com> So I looked over the Tunerpro log again today.. is it me or does it appear to be reusing values ? On 03/08/11 03:00, jfh at greenhousepc.com wrote: > Curtis, > > At the risk of being told "No, they really say it can be done", 30 > sensors is 30 * 3 character times (are you sure it's not a single byte > response?). At 1953 baud, a single character time is 10 bits * (1 / > 1953) seconds, or 15.4ms as Bob pointed out. 30 * 15.4ms is 460ms, > and that assumes everything works perfectly, no turnaround times, etc. > > If you can come up with some other way to make the math work, I'd love > to hear it. > > Short and sweet -- just because TunerPro can talk to an ECM/ECU that > is running faster than 1953 baud doesn't mean your Mitsubishi (or > whatever car you've got that runs at 1953 baud) runs at that faster > baud rate. > > Also, are you sure your data cable is correct? What cable are you > using? What's the schematic? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 2:33 am > To: rxtx at qbang.org > > I am going to try a couple things today and hopefully figure > something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than > 25ms. > I've exchanged some emails with the author and it is a native C, > polling, no events just timeouts. > > Kusta thanks for the FTDI notice, I believe that is tunable, > however I > have a particular user using a Keyspan converter and verified > sampling > rate with 'TunerPro' and its just off the charts. > > Chris thank you, I'll look into the queing. > > On 03/07/11 23:02, Bob Jacobsen wrote: > > If you're transferring three bytes total at 1953 baud, it's going > to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to > wait 20msec to get the data back instead of 15.4 msec doesn't seem > to be as big a problem as you're making it sound. > > > > Bob > > > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > > > >> I guess I'm gunna need some serious help with this then, because > of the scenario I'm stuck with. > >> > >> To communicate there is only 1 data line, rx/tx tied together > with a diode protecting the tx. No RTS/CTS handshaking nothing.. > >> > >> So the ecu can't process the next byte of info, without you > pulling the 2 bytes back. I wish this was standard, but even the > baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard > spot with this.. > >> > >> in.read(data , 0, 2); > >> ^ would the above wait till the timeout to read 2 bytes ? or > read 1 byte wait for the 2nd ? or just read the 1 ?? > >> > >> On 03/07/11 18:50, jfh at greenhousepc.com > wrote: > >>> Curtis, > >>> > >>> No, I assume he means a real queue, not just "don't read all > the bytes at once." However, if you know you can process some > number of requests in some amount of time, allowing data to pile > up (receiver FIFO space permitting) can be a valid strategy. > Inserting gobs of Thread.yield() and notify() can help pep things > up as well. > >>> -- > >>> Julie Haugh > >>> Senior Design Engineer > >>> greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 13:51:13 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 13:51:13 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308135113.8ef0e5b4a80cef441275a6330ffad77d.a5fff5bbc7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From bob_jacobsen at lbl.gov Tue Mar 8 14:14:57 2011 From: bob_jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 8 Mar 2011 14:14:57 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D76848F.5080809@gmail.com> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> Message-ID: <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > Tunerpro log : http://www.ds-map.net/tunerpro_log.csv It's only reading one sensor per line. Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT changed in lines 16 and 40; every 24 lines but at a different phase. GramsRev in lines 23 and 47; every 24 lines, at yet another phase. Looks like (69-1) readings in 1.30 seconds = 19msec per reading. Arithmetic still works! Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From hakcenter at gmail.com Tue Mar 8 14:27:12 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 13:27:12 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> Message-ID: <4D769F30.9050807@gmail.com> Thank you guys, cause I was really worried there. I guess another win for math today hahaha. So what is the imposed latency that rxtx has ? maybe 5-10ms ? On 03/08/11 13:14, Bob Jacobsen wrote: > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > It's only reading one sensor per line. > > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT changed in lines 16 and 40; every 24 lines but at a different phase. GramsRev in lines 23 and 47; every 24 lines, at yet another phase. > > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. Arithmetic still works! > > Bob > -- > Bob Jacobsen, LBNL > Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue Mar 8 14:07:24 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Mar 2011 14:07:24 -0700 (MST) Subject: [Rxtx] Latency Woes In-Reply-To: <4D769F30.9050807@gmail.com> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> <4D769F30.9050807@gmail.com> Message-ID: Hi Curtis While not your exact question, a simple test I performed can give you a ballpark idea. Writing a byte to a loopback at 9600 baud and displaying elapsed time on the data available event takes ~10 ms round trip in a large application. There are occasional 20 ms latencies. I used a typical linux desktop to try it just now without any special considerations. Windows NT was a little faster - maybe 8 ms - when I tried several years ago. On Tue, 8 Mar 2011, Curtis Hacker wrote: > Thank you guys, cause I was really worried there. I guess another win for > math today hahaha. So what is the imposed latency that rxtx has ? maybe > 5-10ms ? > > On 03/08/11 13:14, Bob Jacobsen wrote: >> On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >>> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> It's only reading one sensor per line. >> >> Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT >> changed in lines 16 and 40; every 24 lines but at a different phase. >> GramsRev in lines 23 and 47; every 24 lines, at yet another phase. >> >> Looks like (69-1) readings in 1.30 seconds = 19msec per reading. >> Arithmetic still works! >> >> Bob >> -- >> Bob Jacobsen, LBNL >> Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >> JacobsenRG >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Wei.Shen at Honeywell.com Tue Mar 8 15:15:32 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Tue, 8 Mar 2011 17:15:32 -0500 Subject: [Rxtx] [rxtx] disconnect event Message-ID: <83B3B1411349194D9D05821CEF48E78C02284B17@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 16:05:12 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 16:05:12 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 16:26:15 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 15:26:15 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> References: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> Message-ID: <4D76BB17.2090305@gmail.com> So if I could get the baud up 15625, theoretical maximum latency is 1.92ms ? Basically 500 samples/sec ? 125000, theoretical maximum latency is 0.24ms ? Basically 4167 samples/sec ? Keeping the protocol the same. On 03/08/11 15:05, jfh at greenhousepc.com wrote: > Curtis, > > It's nowhere near that bad. I'd measured it once before, and I > believe it's sub-millisecond. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 3:27 pm > To: rxtx at qbang.org > > Thank you guys, cause I was really worried there. I guess another win > for math today hahaha. So what is the imposed latency that rxtx has ? > maybe 5-10ms ? > > On 03/08/11 13:14, Bob Jacobsen wrote: > > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > > It's only reading one sensor per line. > > > > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 > lines. IAT changed in lines 16 and 40; every 24 lines but at a > different phase. GramsRev in lines 23 and 47; every 24 lines, at > yet another phase. > > > > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. > Arithmetic still works! > > > > Bob > > -- > > Bob Jacobsen, LBNL > > Bob_Jacobsen at lbl.gov > +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Tue Mar 8 17:40:36 2011 From: jredman at ergotech.com (Jim Redman) Date: Tue, 08 Mar 2011 17:40:36 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D76BB17.2090305@gmail.com> References: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> <4D76BB17.2090305@gmail.com> Message-ID: <4D76CC84.9040307@ergotech.com> How long does it take the device to generate a response? Increasing the baud rate may not help you much if the device takes a significant amount of time to process the request. On 03/08/2011 04:26 PM, Curtis Hacker wrote: > So if I could get the baud up > 15625, theoretical maximum latency is 1.92ms ? Basically 500 samples/sec ? > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 samples/sec ? > > Keeping the protocol the same. > > On 03/08/11 15:05, jfh at greenhousepc.com wrote: >> Curtis, >> >> It's nowhere near that bad. I'd measured it once before, and I >> believe it's sub-millisecond. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker > >> Date: Tue, March 08, 2011 3:27 pm >> To: rxtx at qbang.org >> >> Thank you guys, cause I was really worried there. I guess another win >> for math today hahaha. So what is the imposed latency that rxtx has ? >> maybe 5-10ms ? >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> > It's only reading one sensor per line. >> > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 >> lines. IAT changed in lines 16 and 40; every 24 lines but at a >> different phase. GramsRev in lines 23 and 47; every 24 lines, at >> yet another phase. >> > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. >> Arithmetic still works! >> > >> > Bob >> > -- >> > Bob Jacobsen, LBNL >> > Bob_Jacobsen at lbl.gov >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 jfh at greenhousepc.com Tue Mar 8 17:58:24 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 17:58:24 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 18:06:04 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 18:06:04 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 18:14:14 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 17:14:14 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> References: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> Message-ID: <4D76D466.7060303@gmail.com> I can edit the ECU eeprom to change the baud rate divisor to bump it up from 1953, to 15625 or 125000. But as Jim asked how fast the device can respond.. not very fast in its stock form. I can recode a lot of the eeprom for the ecu to alter the ecus baud rate, and put the response code into its own interrupt. I just wanted to make sure that in order to lower latency and increase sampling rate. I have to increase the baud rate of the ecu and the user right ? Or change the protocol.. to respond with more sensors per request. On 03/08/11 16:58, jfh at greenhousepc.com wrote: > Unless the ECU can auto-detect the baud rate, it won't even work. > > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Jim Redman > > Date: Tue, March 08, 2011 6:40 pm > To: rxtx at qbang.org > > How long does it take the device to generate a response? > > Increasing the baud rate may not help you much if the device takes a > significant amount of time to process the request. > > > On 03/08/2011 04:26 PM, Curtis Hacker wrote: > > So if I could get the baud up > > 15625, theoretical maximum latency is 1.92ms ? Basically 500 > samples/sec ? > > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 > samples/sec ? > > > > Keeping the protocol the same. > > > > On 03/08/11 15:05, jfh at greenhousepc.com > wrote: > >> Curtis, > >> > >> It's nowhere near that bad. I'd measured it once before, and I > >> believe it's sub-millisecond. > >> -- > >> Julie Haugh > >> Senior Design Engineer > >> greenHouse Computers, LLC // jfh at greenhousepc.com > > >> ; // > greenHousePC on Skype > >> > >> > >> -------- Original Message -------- > >> Subject: Re: [Rxtx] Latency Woes > >> From: Curtis Hacker > > >> Date: Tue, March 08, 2011 3:27 pm > >> To: rxtx at qbang.org > >> > >> Thank you guys, cause I was really worried there. I guess > another win > >> for math today hahaha. So what is the imposed latency that rxtx > has ? > >> maybe 5-10ms ? > >> > >> On 03/08/11 13:14, Bob Jacobsen wrote: > >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > >> > It's only reading one sensor per line. > >> > > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 > >> lines. IAT changed in lines 16 and 40; every 24 lines but at a > >> different phase. GramsRev in lines 23 and 47; every 24 lines, at > >> yet another phase. > >> > > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. > >> Arithmetic still works! > >> > > >> > Bob > >> > -- > >> > Bob Jacobsen, LBNL > >> > Bob_Jacobsen at lbl.gov > > >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > >> > > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Tue Mar 8 18:19:14 2011 From: jredman at ergotech.com (Jim Redman) Date: Tue, 08 Mar 2011 18:19:14 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> References: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> Message-ID: <4D76D592.9000802@ergotech.com> I'm no expert on this, but isn't the underlying ODB-II CAN bus or something similar. They always seem to require a dongle that converts to something. I know you can get serial, bluetooth, USB, etc. converters. I've seen serial dongles that claim multiple baud rates, so I suspect that whatever's providing the conversion may significantly affect the performance. A big second on the required timing comment. I suspect some intelligent consideration of what values change quickly (RPM, Speed, maybe things like fuel pressure) and read values like fuel levels, coolant temps, etc. much less frequently. On 03/08/2011 06:06 PM, jfh at greenhousepc.com wrote: > Curtis, > > You can't just increase the baud rate and have the device adapt to that > rate. Embedded systems tend to have their communications parameters > either hard coded in a memory location or else they are using a hardware > timebase. You're welcome to try increasing the baud rate, but there is > no guarantee it will even work. > > Whoever designed the ECU probably selected the baud rate for a good > reason. My suggestion would be to look at how the sensor values are all > laid out and go from there. Also, look at what the sensor represent and > consider the physical properties of what is being measured. It's > extremely unlikely that, for example, the coolant temperature is going > to rise more than 1* per second. If that much. Some values might change > more often, but do they really matter on a sub-second measurement basis? > > Part of software =engineering= is understanding the problem. Anyone can > sling code in the hope it works. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 5:26 pm > To: rxtx at qbang.org > > So if I could get the baud up > 15625, theoretical maximum latency is 1.92ms ? Basically 500 > samples/sec ? > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 > samples/sec ? > > Keeping the protocol the same. > > On 03/08/11 15:05, jfh at greenhousepc.com wrote: >> Curtis, >> >> It's nowhere near that bad. I'd measured it once before, and I >> believe it's sub-millisecond. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker > > >> Date: Tue, March 08, 2011 3:27 pm >> To: rxtx at qbang.org >> >> Thank you guys, cause I was really worried there. I guess >> another win >> for math today hahaha. So what is the imposed latency that >> rxtx has ? >> maybe 5-10ms ? >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> > It's only reading one sensor per line. >> > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every >> 24 lines. IAT changed in lines 16 and 40; every 24 lines but >> at a different phase. GramsRev in lines 23 and 47; every 24 >> lines, at yet another phase. >> > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per >> reading. Arithmetic still works! >> > >> > Bob >> > -- >> > Bob Jacobsen, LBNL >> > Bob_Jacobsen at lbl.gov >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > ------------------------------------------------------------------------ > _______________________________________________ > Rxtx mailing list > Rxtx 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 jfh at greenhousepc.com Tue Mar 8 18:32:28 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 18:32:28 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 19:45:00 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 18:45:00 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> References: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> Message-ID: <4D76E9AC.8050909@gmail.com> Julie, I really am not looking at the practicality of it. I was just wondering if that is how it works. I don't know a whole lot about rs232, which is the main reason I've been on this mailing list for a couple years. I have full control over the ecu eeprom code, I can change its baud rate, I can re-write the logging interface, I could update the ADC's on the ecu in the interface so that when you request said sensor it updates the ADC then replies it. But I wanted to know if the underlying issue with a 2mhz/8mhz processor is the baud rate keeping sampling down ? On 03/08/11 17:32, jfh at greenhousepc.com wrote: > Curtis, > > You also have to look at the response time of the sensor itself. > > Seriously -- look at what the sensors are reporting and determine if > the underlying physical property can actually change that rapidly. > And even if it can, do you really need to know that. > > I built drag bikes in the 70's and I drive sports cars in my old age. > You don't really need millisecond sampling rates for every single last > sensor coming out of the engine. Boost pressure, fuel pressure, > manifold pressure and RPMs are probably high frequency sensors if you > want to tweak the motor for turbo lag or something, but other than > that, are you really going to be able to make sense of all that data? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 7:14 pm > To: rxtx at qbang.org > > I can edit the ECU eeprom to change the baud rate divisor to bump > it up from 1953, to 15625 or 125000. But as Jim asked how fast the > device can respond.. not very fast in its stock form. > > I can recode a lot of the eeprom for the ecu to alter the ecus > baud rate, and put the response code into its own interrupt. > > I just wanted to make sure that in order to lower latency and > increase sampling rate. I have to increase the baud rate of the > ecu and the user right ? Or change the protocol.. to respond with > more sensors per request. > > On 03/08/11 16:58, jfh at greenhousepc.com wrote: >> Unless the ECU can auto-detect the baud rate, it won't even work. >> >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Jim Redman > > >> Date: Tue, March 08, 2011 6:40 pm >> To: rxtx at qbang.org >> >> How long does it take the device to generate a response? >> >> Increasing the baud rate may not help you much if the device >> takes a >> significant amount of time to process the request. >> >> >> On 03/08/2011 04:26 PM, Curtis Hacker wrote: >> > So if I could get the baud up >> > 15625, theoretical maximum latency is 1.92ms ? Basically 500 >> samples/sec ? >> > 125000, theoretical maximum latency is 0.24ms ? Basically >> 4167 samples/sec ? >> > >> > Keeping the protocol the same. >> > >> > On 03/08/11 15:05, jfh at greenhousepc.com >> wrote: >> >> Curtis, >> >> >> >> It's nowhere near that bad. I'd measured it once before, and I >> >> believe it's sub-millisecond. >> >> -- >> >> Julie Haugh >> >> Senior Design Engineer >> >> greenHouse Computers, LLC // jfh at greenhousepc.com >> >> >> ; // >> greenHousePC on Skype >> >> >> >> >> >> -------- Original Message -------- >> >> Subject: Re: [Rxtx] Latency Woes >> >> From: Curtis Hacker > > >> >> Date: Tue, March 08, 2011 3:27 pm >> >> To: rxtx at qbang.org >> >> >> >> >> Thank you guys, cause I was really worried there. I guess >> another win >> >> for math today hahaha. So what is the imposed latency that >> rxtx has ? >> >> maybe 5-10ms ? >> >> >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> >> > It's only reading one sensor per line. >> >> > >> >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; >> every 24 >> >> lines. IAT changed in lines 16 and 40; every 24 lines but at a >> >> different phase. GramsRev in lines 23 and 47; every 24 >> lines, at >> >> yet another phase. >> >> > >> >> > Looks like (69-1) readings in 1.30 seconds = 19msec per >> reading. >> >> Arithmetic still works! >> >> > >> >> > Bob >> >> > -- >> >> > Bob Jacobsen, LBNL >> >> > Bob_Jacobsen at lbl.gov >> >> >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Rxtx mailing list >> >> > Rxtx at qbang.org >> >> >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > ------------------------------------------------------------------------ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 20:43:11 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 20:43:11 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308204311.8ef0e5b4a80cef441275a6330ffad77d.e9b135168c.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From andrea.antonello at gmail.com Wed Mar 9 06:50:07 2011 From: andrea.antonello at gmail.com (andrea antonello) Date: Wed, 9 Mar 2011 14:50:07 +0100 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> References: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> Message-ID: Has anyone tried the lib? I am not sure if it is appropriate to write to the list about this, if not, I apologize. I wanted to try your fork out for our application which is an eclipse rcp plugin based one. It has been easy to substitute the 6 plugins with your library (that is one of the things I like). But then when I run it, it tries to load it from: ---- Loading: /tmp/libNRJavaSerial_moovida_0/libNRJavaSerial.so Trying to load: NRJavaSerial Trying to load: libNRJavaSerial Trying to load: rxtxSerial ---- So it is extracting the native lib to a tmp folder. But that one is not in the library path, so it fails. Is there any docs to try the lib out? Thanks, Andrea On Mon, Mar 7, 2011 at 11:54 PM, wrote: > Aaron, > > It should be possible for an Android to do BlueTooth serial.? If I were > looking for a serial solution, that's how I'd go. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on > Skype > > -------- Original Message -------- > Subject: [SPAM] Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > papercuts! > From: Aaron Wolfe > Date: Mon, March 07, 2011 4:31 pm > To: rxtx at qbang.org > > On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR > wrote: >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> >> * Self deployment of native libraries ( all native code is stored >> inside the jar and deployed at runtime). No more manual install of >> native code. >> * Arm Cortex support (Gumstix) >> * Android Support (requires a rooted phone for now) >> * Google Code (SVN) repository for easy code and jar access >> * Single makefile compile (simplifies the compilation of project binaries) >> * Ant build script for jar creation >> * Removal of partialy implemented code to streamline the lib for just >> serial port access >> * Full Eclipse integration, for testing application code against sources. >> >> And a bunch of bug fixes: >> >> * Fixed the memory access error that causes OSX to crash the JVM when >> serial.close() is cvalled >> * Fixed the windows serial port zombie bind that prevents re-accessing >> serial ports when exiting on an exception >> * Fixed erronious printouts of native library mis-match >> >> To check it out, take a look at our page here: >> >> http://code.google.com/p/nrjavaserial/ > > This is interesting, getting the native libs set up has been an issue > for some of my users. Will have to check it out. > > Out of curiosity, what Android devices provide a serial port? Or are > there some that allow USB host mode and then a usb-serial adapter? I > have only an Android cell phone, don't think it can do anything serial > but would love to be wrong 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 Cougar at CasaDelGato.Com Wed Mar 9 10:02:24 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 09 Mar 2011 09:02:24 -0800 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> References: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> Message-ID: <4D77B2A0.8020004@CasaDelGato.Com> On 3/7/2011 2:54 PM, jfh at greenhousepc.com wrote: > Aaron, > > It should be possible for an Android to do BlueTooth serial. If I > were looking for a serial solution, that's how I'd go. Actually, I can't figure out WHY you would need RxTx on an Android device. The built in bluetooth support works just fine with a serial-bluetooth converter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Mar 1 00:54:17 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 09:54:17 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> Message-ID: Adrian, had a look at your code/rewrite and it looks rather clean/nice. I was looking at the code to gain insight (not related to the rewrite) into what is involved in serial port programming in Windows. Or rather, to refresh my memory and see how others have done, because I've been there done that. So my questions are just to satisfy my curiosity, not to criticize or suggest improvements. 1) It looks like a new thread (EventMonitor) is created for each Serial port, is that correct? Many people seem to try to avoid using many threads in this sort of situation, and like to use something like unix select(). I personally find using threads more natural and better impedance match to the problem being solved here. I guess 'many people' above refers to those implementing thousands of connections and who cannot live with the overhead and limited number of threads available. 2) The EventMonitor basically polls for events at 50 msec interval? 3) There is a comment in the source code near the sleep(50) : // Sufficient up to 19200 baud I'm sure you thought about this carefully, so again not criticizing, but seeking to understand how or why, because at 50 msec would seem to limit through in some cases. Like if you send one byte and need to wait for one to return, then this limits speed to 200 chars/sec? 4) I've done something similar to a few years back from Java using JNI to access Win32 API serial port, and I seem to recall that I had threading issues ie when I submitted a read (ReadFile) and there was no data coming in, the thread would not only block but also consume a lot of CPU cycles ie it was not sleeping properly inside the ReadFile call when the serial port blocked. Im a bit fuzzy about the details after five years, so my question is have you checked if there an issue here? 5) AFAIK the select() on Windows does not work serial ports but there is some other mechanism (events?) to implement the same functionality, did you consider that? Probably, so you decided against it, why? br Kusti From adrian.crum at sandglass-software.com Tue Mar 1 04:13:34 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:13:34 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: References: Message-ID: <4D6CD4DE.7040501@sandglass-software.com> The javax.comm API specification requires one event monitor thread per port. I don't like the idea of having a thread per port either, but one of the rewrite's design goals is strict conformance to the specification. The 50 mS polling interval is just a placeholder. The final design of that is yet to be decided. In Windows, you have two choices for I/O: overlapped and non-overlapped. In overlapped I/O a thread is blocked, waiting for something to happen. In non-overlapped I/O a thread does not block. I chose non-overlapped I/O to avoid thread blocking at the OS level - instead, the thread blocking is kept in Java. -Adrian On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > Adrian, > > had a look at your code/rewrite and it looks rather clean/nice. > > I was looking at the code to gain insight (not related to the > rewrite) into what is involved in serial port programming > in Windows. Or rather, to refresh my memory and see how others have > done, because I've been there done that. > > So my questions are just to satisfy my curiosity, not to criticize > or suggest improvements. > > 1) It looks like a new thread (EventMonitor) is created for > each Serial port, is that correct? > > Many people seem to try to avoid using many threads in this sort > of situation, and like to use something like unix select(). > I personally find using threads more natural and better impedance > match to the problem being solved here. I guess 'many people' above > > refers to those implementing thousands of connections and > who cannot live with the overhead and limited number of threads > available. > > 2) The EventMonitor basically polls for events at 50 msec interval? > > 3) There is a comment in the source code near the sleep(50) : > > // Sufficient up to 19200 baud > > > I'm sure you thought about this carefully, so again not > criticizing, but seeking to understand how or why, because > at 50 msec would seem to limit through in some cases. Like > if you send one byte and need to wait for one to return, > then this limits speed to 200 chars/sec? > > 4) I've done something similar to a few years back from > Java using JNI to access Win32 API serial port, and > I seem to recall that I had threading issues ie when > I submitted a read (ReadFile) and there was no data coming > in, the thread would not only block but also consume a > lot of CPU cycles ie it was not sleeping properly inside > the ReadFile call when the serial port blocked. > > Im a bit fuzzy about the details after five years, so my question is > have you checked if there an issue here? > > > 5) AFAIK the select() on Windows does not work serial ports > but there is some other mechanism (events?) to implement the > same functionality, did you consider that? Probably, so you > decided against it, why? > > > br Kusti > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Tue Mar 1 04:25:23 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:25:23 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C2E90.9010601@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > My question would be: Why would you do that? The rewrite does > most of the work for you - all you have to do is implement > two C++ virtual classes and two C++ functions. You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? I just took a short look, maybe it could be discussed further, but I don't think I like it much. BTW, the main interface defined there is called gnu.io.Dispatcher? I thought the package names should be used in a way to avoid clashes, e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name space authority :)). > In Windows that took me a few hours. where is the implementation? I found commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp with things like const bool SerialPortImpl::isDataAvailable() const { // Needs implementation return true; } and timeouts.ReadIntervalTimeout = MAXDWORD;* timeouts.ReadTotalTimeoutMultiplier = 0; timeouts.ReadTotalTimeoutConstant = 0; timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 0; if (!SetCommTimeouts(hComm, &timeouts)) throw IOException(); which seems to be oversimplified or some prototype only? I think (and I wrote about this already in the past years) that correct timeout handling is one of the challenges, so I think this should be prototyped first - for each system flavor - before cementation of the (JNI-) interfaces. Personally, I would vote to form it in a way allowing to be implemented on embedded devices, for example. Another big challenge is to prove a rewrite fully working (and probably compatible to the old implementation) on "all" the supported OSes. Not a big problem for linux and windows, just use some thousand lines test code, test drivers and serial loopbacks etc, but for the exotic platforms, probably a high number of, this probably won't be too easy... (there are more challenges, such as being comfortable and threadsafe [are read and write permitted at the same time?], detailed and helpful exceptions on user API level [not necessarily on JNI/JNA layer], how to have a configurable threadsafe logging/tracing [maybe also from native code to assist porting / testing on exotic OSes, such as OSes where the developers have no direct access too, which can be quite hard to usually leads to good log messages], just to name a few.). So even it might seem easy for one platform and I agree with Micheal that > > * yay! let's start a rewrite is unlikely to succeede soon... However, when considering this, before IMHO a powerful Java API has to be defined, because according to my experiences for implementing non-trivial protocols InputStream/OutputStream might not be comfortable/powerfull enough (eventually I consider both wrong) and have some InputStream derivation available as wrapper (so applications can use InputStream and whatever high-level-API they want). The JNI interface shall make such a powerful implementation possible, thus the interface of it is driving the JNI interface design and thus I think it had to be done first. All this surely requires much work: agreements on the APIs, safeness for the users, design, documentation, all the implementations and the testing. As long as such bug amount of work cannot be spent, for example if some employee would get half a year time paid for it or so :-), probably it is unlikely to progress on this. Otherwise, I'm afraid, patches, improvements, new design ideas and even rewrites wouldn't become complete and thus won't form a new rxtx version (3.0); thus either collect dust in some forgotten CVS branch or could generate a split... > I can't imagine other ports taking > much longer than that - especially since POSIX-based code can > be shared between ports. Things are more complex than they seem to be... I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select on serial ports isn't supported; maybe it is non-trivial to "map" (like mapping select() to WaitForMultipleObjects() which might have different semantics etc.) or maybe some different approach has to be used. A system may have POSIX like termios interfaces but not support timeouts or have any other interoperability bug... You never run out of things that can go wrong. And if something can go wrong, it will... :-) Or, as Michael wrote: > > I seriously don't believe anyone will come up with anything better anytime soon. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue Mar 1 04:39:37 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:39:37 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com><13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED6B@COSNPREXC3.usr.ingenico.loc> > 3. Write all of the native (or non-native) code to implement > the native interface. > > Is that correct? If yes, how is that easier than the simple > implementation the current rewrite design uses? To have it complete, reliable, traceable, maintainable and well tested, it is much more work, I'm afraid. A prototype can be done within a few days (maybe on one day), but getting it right (including a passed review) IMHO is a completely different story. In the end you may end up with an average of ten lines per day, when assuming four major native packs (common, win, mac, termios/select) with let's say just 5000 lines each (with logging messages and detailed exceptions this is not much) we would have to estimate a total effort of nine man-years (20000/10/220)... oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 04:40:18 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:40:18 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6CDB22.9070401@sandglass-software.com> Every journey begins with a single step. -Adrian On 3/1/2011 3:25 AM, Steffen DETTMER wrote: > * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> My question would be: Why would you do that? The rewrite does >> most of the work for you - all you have to do is implement >> two C++ virtual classes and two C++ functions. > You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? > I just took a short look, maybe it could be discussed further, > but I don't think I like it much. > BTW, the main interface defined there is called gnu.io.Dispatcher? > I thought the package names should be used in a way to avoid clashes, > e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name > space authority :)). > >> In Windows that took me a few hours. > where is the implementation? > I found > commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp > with things like > > const bool SerialPortImpl::isDataAvailable() const > { > // Needs implementation > return true; > } > > and > > timeouts.ReadIntervalTimeout = MAXDWORD;* > timeouts.ReadTotalTimeoutMultiplier = 0; > timeouts.ReadTotalTimeoutConstant = 0; > timeouts.WriteTotalTimeoutMultiplier = 0; > timeouts.WriteTotalTimeoutConstant = 0; > if (!SetCommTimeouts(hComm,&timeouts)) > throw IOException(); > > which seems to be oversimplified or some prototype only? > > I think (and I wrote about this already in the past years) that correct > timeout handling is one of the challenges, so I think this should be > prototyped first - for each system flavor - before cementation of the > (JNI-) interfaces. Personally, I would vote to form it in a way allowing > to be implemented on embedded devices, for example. > > Another big challenge is to prove a rewrite fully working (and probably > compatible to the old implementation) on "all" the supported OSes. Not a > big problem for linux and windows, just use some thousand lines test > code, test drivers and serial loopbacks etc, but for the exotic > platforms, probably a high number of, this probably won't be too easy... > (there are more challenges, such as being comfortable and threadsafe > [are read and write permitted at the same time?], detailed and helpful > exceptions on user API level [not necessarily on JNI/JNA layer], how to > have a configurable threadsafe logging/tracing [maybe also from native > code to assist porting / testing on exotic OSes, such as OSes where the > developers have no direct access too, which can be quite hard to usually > leads to good log messages], just to name a few.). > > So even it might seem easy for one platform and I agree with Micheal > that > >>> * yay! let's start a rewrite > is unlikely to succeede soon... > > However, when considering this, before IMHO a powerful Java API has to > be defined, because according to my experiences for implementing > non-trivial protocols InputStream/OutputStream might not be > comfortable/powerfull enough (eventually I consider both wrong) and have > some InputStream derivation available as wrapper (so applications can > use InputStream and whatever high-level-API they want). > The JNI interface shall make such a powerful implementation possible, > thus the interface of it is driving the JNI interface design and thus I > think it had to be done first. > > All this surely requires much work: agreements on the APIs, safeness for > the users, design, documentation, all the implementations and the > testing. As long as such bug amount of work cannot be spent, for example > if some employee would get half a year time paid for it or so :-), > probably it is unlikely to progress on this. > > Otherwise, I'm afraid, patches, improvements, new design ideas and even > rewrites wouldn't become complete and thus won't form a new rxtx version > (3.0); thus either collect dust in some forgotten CVS branch or could > generate a split... > >> I can't imagine other ports taking >> much longer than that - especially since POSIX-based code can >> be shared between ports. > Things are more complex than they seem to be... > > I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select > on serial ports isn't supported; maybe it is non-trivial to "map" (like > mapping select() to WaitForMultipleObjects() which might have different > semantics etc.) or maybe some different approach has to be used. A > system may have POSIX like termios interfaces but not support timeouts > or have any other interoperability bug... > You never run out of things that can go wrong. And if something can go > wrong, it will... :-) > > Or, as Michael wrote: > >>> I seriously don't believe anyone will come up with anything better > anytime soon. > > oki, > > Steffen > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Kustaa.Nyholm at planmeca.com Tue Mar 1 04:57:02 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 13:57:02 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: On 3/1/11 13:13, "Adrian Crum" wrote: >The javax.comm API specification requires one event monitor thread per >port. I don't like the idea of having a thread per port either, but one >of the rewrite's design goals is strict conformance to the specification. Ah, had not spotted that requirement. > >The 50 mS polling interval is just a placeholder. The final design of >that is yet to be decided. > >In Windows, you have two choices for I/O: overlapped and non-overlapped. >In overlapped I/O a thread is blocked, waiting for something to happen. >In non-overlapped I/O a thread does not block. I chose non-overlapped >I/O to avoid thread blocking at the OS level - instead, the thread >blocking is kept in Java. > >-Adrian thanks for the explanation. br Kusti From iqzw2r602 at sneakemail.com Tue Mar 1 05:08:17 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:08:17 +1100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <32684-1298981297-704398@sneakemail.com> This reminds me of a nasty problem I had with overlapped I/O on windows with jpathwatch. You can't start an I/O request in one thread and then do the check if that request completed in another thread. Very strange things happen when you attempt that; made me change the design of the Windows implementation quite drastically (one thread on a command queue that executes requests from other threads instead of letting them wildly call into GetOverlappedResult()). Out of curiosity: Did you come across that too? Or are all requests handled in the same thread they're issued? Cheers, Uwe On Tue, Mar 1, 2011 at 10:13 PM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > The javax.comm API specification requires one event monitor thread per > port. I don't like the idea of having a thread per port either, but one of > the rewrite's design goals is strict conformance to the specification. > > The 50 mS polling interval is just a placeholder. The final design of that > is yet to be decided. > > In Windows, you have two choices for I/O: overlapped and non-overlapped. In > overlapped I/O a thread is blocked, waiting for something to happen. In > non-overlapped I/O a thread does not block. I chose non-overlapped I/O to > avoid thread blocking at the OS level - instead, the thread blocking is kept > in Java. > > -Adrian > > > On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > >> Adrian, >> >> had a look at your code/rewrite and it looks rather clean/nice. >> >> I was looking at the code to gain insight (not related to the >> rewrite) into what is involved in serial port programming >> in Windows. Or rather, to refresh my memory and see how others have >> done, because I've been there done that. >> >> So my questions are just to satisfy my curiosity, not to criticize >> or suggest improvements. >> >> 1) It looks like a new thread (EventMonitor) is created for >> each Serial port, is that correct? >> >> Many people seem to try to avoid using many threads in this sort >> of situation, and like to use something like unix select(). >> I personally find using threads more natural and better impedance >> match to the problem being solved here. I guess 'many people' above >> >> refers to those implementing thousands of connections and >> who cannot live with the overhead and limited number of threads >> available. >> >> 2) The EventMonitor basically polls for events at 50 msec interval? >> >> 3) There is a comment in the source code near the sleep(50) : >> >> // Sufficient up to 19200 baud >> >> >> I'm sure you thought about this carefully, so again not >> criticizing, but seeking to understand how or why, because >> at 50 msec would seem to limit through in some cases. Like >> if you send one byte and need to wait for one to return, >> then this limits speed to 200 chars/sec? >> >> 4) I've done something similar to a few years back from >> Java using JNI to access Win32 API serial port, and >> I seem to recall that I had threading issues ie when >> I submitted a read (ReadFile) and there was no data coming >> in, the thread would not only block but also consume a >> lot of CPU cycles ie it was not sleeping properly inside >> the ReadFile call when the serial port blocked. >> >> Im a bit fuzzy about the details after five years, so my question is >> have you checked if there an issue here? >> >> >> 5) AFAIK the select() on Windows does not work serial ports >> but there is some other mechanism (events?) to implement the >> same functionality, did you consider that? Probably, so you >> decided against it, why? >> >> >> br Kusti >> >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 05:37:07 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:37:07 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <1142-1298983027-957144@sneakemail.com> On Tue, Mar 1, 2011 at 1:32 PM, Adrian Crum wrote: > Just to make sure I'm understanding you correctly, anyone porting RxTx to > a new platform would have to do the following: > > 1. Write their own Java implementation of an abstract Dispatcher class. > yep. I'd probably put all my calls to native OS wrappers in there two, looks the most straight-forward to me. > 2. Write a native (JNI or JNA) interface for the abstract class > implementation. > yes. For POSIX you'd probably only write one piece of code that provides implementations for open(), close(), and friends. You can compile that on all posix platforms (yeah, the devil is in the detail, but it's very little code, still). So this does open() (when using ***, but you can also use +++) // Unix.java class Unix{ public static native int open(String filename, int flags, int mode); .... } // Unix.cpp JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) { const char* pathname = env->GetStringUTFChars(jpathname, 0); if(pathname == 0) return -1; // java throws an out of memory error in this case int result = open(pathname, flags, mode); Unix_cacheErrno(); // handle interference between JVM and errno; env->ReleaseStringUTFChars(jpathname, pathname); return result; } .... 3. Write all of the native (or non-native) code to implement the native > interface. > Not sure what you mean by that. I've done the OS wrappers in step 2. step 1. implements that Dispatcher. What else do I need? > Is that correct? If yes, how is that easier than the simple implementation > the current rewrite design uses? > Yes, except for 3 (see above). How it is easier: I can debug the Java code directly. I can step from the read() call of an input stream directly into the guts of the RXTX implementation on my platform and see e.g. why it's hanging, because I see all the way up the call stack right where it calls Unix.read(). You can't easily do that with a fat native library, especially if you have no second set of devtools installed (the ones for native development). And I bet anyone knowing both languages can write it faster in Java, with less bugs. > On a side note: there is no requirement to write native code using C++. If > C++ is a real obstacle to adoption, then regular C could be used instead. In > that case, there would be a Dispatcher.c file that contains function > protoypes that need to be implemented. Dispatcher.c would still maintain the > same role as Dispatcher.cpp - which is to shield native code developers from > the details of JNI. Just build out the missing functions using C data types > and you're ready to go. > As I said, whatever works for you. Java works for me better than C++ in this case... Cheers, Uwe -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Mar 1 08:26:41 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 16:26:41 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> > The javax.comm API specification requires one event monitor > thread per port. Where does it require this? Do you mean "All the events received by this listener are generated by one dedicated thread that belongs to the SerialPort object. "? I think this is an implementation detail, isn't it? At least it is mentioned after "The current implementation only allows one listener per SerialPort". A bit bad that javadoc does not distinguish between API spec and implementation documentation. Also I don't think that TooManyListenersException MUST be thrown (I think it CAN be thrown). > I don't like the idea of having a thread per > port either, but one of the rewrite's design goals is strict > conformance to the specification. (but not necessarily on JNI layer) > The 50 mS polling interval is just a placeholder. The final > design of that is yet to be decided. I though no polling would be wanted; what could be the placeholder stand for? Do you mean a different interval duration or do you mean something completely different? > In Windows, you have two choices for I/O: overlapped and > non-overlapped. > In overlapped I/O a thread is blocked, waiting for something > to happen. > In non-overlapped I/O a thread does not block. I chose > non-overlapped I/O to avoid thread blocking at the OS level - > instead, the thread blocking is kept in Java. Isn't "overlapped" (asynchronous) I/O meaning that you invoke some ReadFile(..., &overlapped, ...) INSTEAD of performing a synchronous (blocking) function call blocking the thread? As far as I see, W32_Support.cpp uses CreateFile without FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O operations are serialized, even if the calls to the read and write functions specify an OVERLAPPED structure." [1] and "A synchronous handle behaves such that I/O function calls using that handle are blocked until they complete" [2] Given that CCOMTIMEOUTS get: "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the bytes that have already been received, even if no bytes have been received." [3] It looks likes this implementation relies on polling, which probably would waste much computing power. What did I miss? oki, Steffen [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro nous_and_asynchronous_i_o_handles [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 09:23:47 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:23:47 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6D1D93.6090306@sandglass-software.com> Unfortunately, the javax.comm API specification includes a lot of implementation details. That is one of the weaknesses of the specification in my opinion. The bottom line is, anyone wanting to use RxTx as a javax.comm implementation is going to expect it to do the things the specification says it does. -Adrian On 3/1/2011 7:26 AM, Steffen DETTMER wrote: >> The javax.comm API specification requires one event monitor >> thread per port. > Where does it require this? > > Do you mean "All the events received by this listener are generated > by one dedicated thread that belongs to the SerialPort object. "? > > I think this is an implementation detail, isn't it? At least it is > mentioned after "The current implementation only allows one listener per > SerialPort". A bit bad that javadoc does not distinguish between API > spec and implementation documentation. Also I don't think that > TooManyListenersException MUST be thrown (I think it CAN be thrown). > >> I don't like the idea of having a thread per >> port either, but one of the rewrite's design goals is strict >> conformance to the specification. > (but not necessarily on JNI layer) > >> The 50 mS polling interval is just a placeholder. The final >> design of that is yet to be decided. > I though no polling would be wanted; what could be the placeholder stand > for? Do you mean a different interval duration or do you mean something > completely different? > >> In Windows, you have two choices for I/O: overlapped and >> non-overlapped. >> In overlapped I/O a thread is blocked, waiting for something >> to happen. >> In non-overlapped I/O a thread does not block. I chose >> non-overlapped I/O to avoid thread blocking at the OS level - >> instead, the thread blocking is kept in Java. > Isn't "overlapped" (asynchronous) I/O meaning that you invoke some > ReadFile(...,&overlapped, ...) > INSTEAD of performing a synchronous (blocking) function call blocking > the thread? > > As far as I see, W32_Support.cpp uses CreateFile without > FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O > operations are serialized, even if the calls to the read and write > functions specify an OVERLAPPED structure." [1] and "A synchronous > handle behaves such that I/O function calls using that handle are > blocked until they complete" [2] > > Given that CCOMTIMEOUTS get: > "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values > for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier > members, specifies that the read operation is to return immediately with > the bytes that have already been received, even if no bytes have been > received." [3] > > It looks likes this implementation relies on polling, which probably > would waste much computing power. > > What did I miss? > > oki, > > Steffen > > [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx > [2] > http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro > nous_and_asynchronous_i_o_handles > [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at sandglass-software.com Tue Mar 1 09:55:29 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:55:29 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <1142-1298983027-957144@sneakemail.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> Message-ID: <4D6D2501.1020803@sandglass-software.com> That code duplicates what is in Dispatcher.cpp. A Unix port would only need to implement CommPortFactory::getInstance(portName, portType). -Adrian On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 15:07:46 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 2 Mar 2011 09:07:46 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6D2501.1020803@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> <4D6D2501.1020803@sandglass-software.com> Message-ID: <23749-1299017266-991798@sneakemail.com> What is this duplicating? A Unix port will need to call open() anyways (just so we're talking about the same thing here: open() is the Unix equivalent of CreateFile()) On Wed, Mar 2, 2011 at 3:55 AM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > That code duplicates what is in Dispatcher.cpp. A Unix port would only > need to implement CommPortFactory::getInstance(portName, portType). > > -Adrian > > > On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Tue Mar 1 22:53:07 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 00:53:07 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: Hi, I haven't seen any response to my question below. Is this not the right place to ask? If not, where would be a better place to ask? Any suggestions? Thanks, Ryan On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >> Hi, >> >> I have a receive thread that does nothing but call read() on the serial >> port input stream. It works fine for a while but after running for a long >> time it eventually returns -1 which means EOF. This is my first problem, as >> the device I'm talking to runs forever, I don't know why it would return -1. >> I am calling disableReceiveThreshold() and disableReceiveTimeout() at >> initialization which according to the documentation means read will return >> as soon as any data is available and it will block forever when data is not >> available, so -1 should never be returned from read, right? >> >> I have been unable to figure out why read returns -1 after a long while >> but I have found that if I kill my application and restart it everything >> works fine again. Therefore I tried to work around the problem by having my >> code close the port and reopen it when read returns -1. My second problem is >> that in this case when I call close() on the port it blocks forever. I did >> find this old bug >> >> http://bugzilla.qbang.org/show_bug.cgi?id=53 >> >> which describes close() hanging on OSX, but it says that bug was fixed >> with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have >> any idea why read might be returning -1 in the first place? If I can avoid >> that I don't care about close() hanging because I would never close the >> port. If not, does anyone know why close() might block forever and how I can >> prevent this? I'm using RXTX version 2.1-7. >> >> Thanks, >> -- >> Ryan >> >> > > > -- > Ryan Boder > 1 614 598-6339 > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Mar 2 01:34:48 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 2 Mar 2011 10:34:48 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/2/11 07:53, "Ryan Boder" wrote: Can you / have you made a simple test to ensure that rxtx is the issue? Can you write a simple C-program to see if this exhibits the same problem? I've never encountered this sort of problem with rxtx, it mostly just works. But I'm on Mac so can't say about Windows (7) br Kusti >Hi, > >I haven't seen any response to my question below. Is this not the right >place to ask? If not, where would be a better place to ask? Any >suggestions? > >Thanks, >Ryan > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > >I mis-spoke, I don't have my own thread calling read, I am calling >read in the event handler after receiving a >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be >accurate though. > >Ryan > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >Hi, > >I have a receive thread that does nothing but call read() on the serial >port input stream. It works fine for a while but after running for a long >time it eventually returns -1 which means EOF. This is my first problem, >as the device I'm talking to runs forever, I don't know why it would >return -1. I am calling disableReceiveThreshold() and >disableReceiveTimeout() at initialization which according to the >documentation means read will return as soon as any data is available and >it will block forever when data is not available, so -1 should never be >returned from read, right? > >I have been unable to figure out why read returns -1 after a long while >but I have found that if I kill my application and restart it everything >works fine again. Therefore I tried to work around the problem by having >my code close the port and reopen it when read returns -1. My second >problem is that in this case when I call close() on the port it blocks >forever. I did find this old bug > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > >which describes close() hanging on OSX, but it says that bug was fixed >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone >have any idea why read might be returning -1 in the first place? If I can >avoid that I don't care about close() hanging because I would never close >the port. If not, does anyone know why close() might block forever and >how I can prevent this? I'm using RXTX version 2.1-7. > >Thanks, >-- >Ryan > > > > > > > > > >-- >Ryan Boder >1 614 598-6339 > > > > > > >-- >Ryan Boder >1 614 598-6339 > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From Steffen.DETTMER at ingenico.com Wed Mar 2 03:08:57 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:08:57 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <32684-1298981297-704398@sneakemail.com> References: <4D6CD4DE.7040501@sandglass-software.com> <32684-1298981297-704398@sneakemail.com> Message-ID: <20110302100857.GB8030@elberon.bln.de.ingenico.com> * iqzw2r602 at sneakemail.com wrote on Tue, Mar 01, 2011 at 23:08 +1100: > This reminds me of a nasty problem I had with overlapped I/O on windows Yeah, those thousands of complex, difficult to use and exception-containing WinAPI is really hard to use... About strange effects on overlapped&multithreading, MSDN has: `the calling thread uses the GetOverlappedResult function or one of the wait functions' [1] also also mentiones I/O Completion Ports [2], and later continues: `If an application reuses OVERLAPPED structures on multiple threads and calls GetOverlappedResult with the bWait parameter set to TRUE, the application must ensure that the associated event is set before the application reuses the structure. This can be accomplished by using the WaitForSingleObject function after calling GetOverlappedResult to force the thread to wait until the operation completes. Note that the event object must be a manual-reset event object. If an autoreset event object is used, calling GetOverlappedResult with the bWait parameter set to TRUE causes the function to be blocked indefinitely.' also [1] oki, Steffen [1] http://msdn.microsoft.com/en-us/library/ms686358%28v=vs.85%29.aspx [2] http://msdn.microsoft.com/en-us/library/aa365198%28v=vs.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:15:11 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:15:11 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6D1D93.6090306@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> <4D6D1D93.6090306@sandglass-software.com> Message-ID: <20110302101511.GC8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 08:23 -0800: > Unfortunately, the javax.comm API specification includes a lot of > implementation details. That is one of the weaknesses of the > specification in my opinion. The bottom line is, anyone wanting to use > RxTx as a javax.comm implementation is going to expect it to do the > things the specification says it does. Yeah ok, but even then the implementation could check for the TooManyListenersException situations (if it really is required to support applications relying on that exception) but internally use just a single I/O thread waiting for events on any open file descriptors. Of course an implementation supporting all sort of concurrency could become quite complex (especially if open-read-close should work fast, I think would be difficult to implement, because a new file descriptors had to be added to the waitFor/select list, and who knows how systems behave here in detail...). oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:25:15 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:25:15 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6CDB22.9070401@sandglass-software.com> References: <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> <4D6CDB22.9070401@sandglass-software.com> Message-ID: <20110302102515.GD8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 03:40 -0800: > * from some older mail: > > My question would be: Why would you do that? The rewrite does > > most of the work for you - all you have to do is implement > > two C++ virtual classes and two C++ functions. > > > > In Windows that took me a few hours. > > Every journey begins with a single step. Yes, of course, but then it shouldn't be used as base for new effort estimations like `In Windows that took a few hours' ;-) (BTW, calling a single step `the rewrite' may sound a bit ambitious ;)) But of course a prototype demonstrating something can be really helpful, sure. I just wanted to tell that interfaces should be easy to use and powerful at the same time and may non-trivial initial considerations before starting to implement them. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From ryan.boder at gmail.com Wed Mar 2 18:44:35 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:44:35 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: While running the tests you requested I may have stumbled on the problem, I just don't know how to fix it. According to the documentation, if both the receive timeout and receive threshold are disabled then read() should block forever until data is available. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#getInputStream%28%29 On my system using RXTX read() is returning -1 when no data is available even though I have disabled both thresholds. The reason my program was running fine for a while without this problem showing up is that I was using the DATA_AVAILABLE event to be notified when data is available and only calling read() to read an entire frame whenever the DATA_AVAILABLE event occurred, until eventually my device (I'm guessing) probably took longer than normal to send the entire data frame and therefore I called read when no data was available and it returned -1. The following Java program demonstrates my problem, it returns -1 as soon as no data is available, even though I think it should block until data is available. import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; public class Main implements SerialPortEventListener { public static void main(String[] args) throws Exception { new Main().run(); } private void run() throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier("COM4"); SerialPort port = (SerialPort) portIdentifier.open(Main.class.getName(), 2000); port.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); port.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); port.disableReceiveThreshold(); port.disableReceiveTimeout(); BufferedInputStream in = new BufferedInputStream(port.getInputStream()); BufferedOutputStream out = new BufferedOutputStream(port.getOutputStream()); port.addEventListener(this); Thread.sleep(1000); out.write(new byte[] {0x02, 0x60}); out.flush(); while (true) { int x = in.read(); if (x == -1) { System.out.println("EOF"); Thread.sleep(1000000000); } String s = Integer.toHexString(x & 0xFF); if (s.length() == 1) s = "0" + s; System.out.print(s + " "); System.out.flush(); } } public void serialEvent(SerialPortEvent arg0) { System.out.println("Serial port event"); } } However, the follow C# program ran all day today without ever read ever returning -1, as I would expect. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.IO.Ports; using System.Threading; namespace RXTXReadTest1 { class Program { static void Main(string[] args) { new Program().run(); } private void run() { SerialPort port = new SerialPort("COM4", 19200, Parity.None, 8, StopBits.One); port.Open(); port.Write(new byte[] { 0x02, 0x60 }, 0, 2); while (true) { int x = port.ReadByte(); if (x == -1) { Console.WriteLine("EOF"); Thread.Sleep(1000000000); } String s = x.ToString("X"); if (s.Length == 1 ) s = "0" + s; Console.Out.Write(s + " "); Console.Out.Flush(); } } } } Now I am experimenting with what happens if I set the receive timeout to it's maximum value (apparently 1600ms) and only call read() when I am expecting data. Hopefully it will never be more than 1600ms late. This is still only a work around, not solving the problem. Am I doing something wrong in my code above or is RXTX retuning -1 when it should be blocking? Thanks, Ryan On Wed, Mar 2, 2011 at 3:34 AM, Kustaa Nyholm wrote: > On 3/2/11 07:53, "Ryan Boder" wrote: > Can you / have you made a simple test to ensure that rxtx is the issue? > > Can you write a simple C-program to see if this exhibits the same problem? > > I've never encountered this sort of problem with rxtx, it mostly just > works. > > But I'm on Mac so can't say about Windows (7) > > br Kusti > > > > > >Hi, > > > >I haven't seen any response to my question below. Is this not the right > >place to ask? If not, where would be a better place to ask? Any > >suggestions? > > > >Thanks, > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder > wrote: > > > >I mis-spoke, I don't have my own thread calling read, I am calling > >read in the event handler after receiving a > >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be > >accurate though. > > > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder > wrote: > > > >Hi, > > > >I have a receive thread that does nothing but call read() on the serial > >port input stream. It works fine for a while but after running for a long > >time it eventually returns -1 which means EOF. This is my first problem, > >as the device I'm talking to runs forever, I don't know why it would > >return -1. I am calling disableReceiveThreshold() and > >disableReceiveTimeout() at initialization which according to the > >documentation means read will return as soon as any data is available and > >it will block forever when data is not available, so -1 should never be > >returned from read, right? > > > >I have been unable to figure out why read returns -1 after a long while > >but I have found that if I kill my application and restart it everything > >works fine again. Therefore I tried to work around the problem by having > >my code close the port and reopen it when read returns -1. My second > >problem is that in this case when I call close() on the port it blocks > >forever. I did find this old bug > > > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > > > >which describes close() hanging on OSX, but it says that bug was fixed > >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone > >have any idea why read might be returning -1 in the first place? If I can > >avoid that I don't care about close() hanging because I would never close > >the port. If not, does anyone know why close() might block forever and > >how I can prevent this? I'm using RXTX version 2.1-7. > > > >Thanks, > >-- > >Ryan > > > > > > > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Wed Mar 2 18:46:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:46:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: <-1051064942000733580@unknownmsgid> References: <-1051064942000733580@unknownmsgid> Message-ID: It is USB and seems very reliable with the C# test program in my previous email. On Wed, Mar 2, 2011 at 6:58 PM, Bruce Griffith wrote: > How reliable is your serial port ? is it USB or Bluetooth? > > > > Bruce Griffith > > 303-532-4778 > > > > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On Behalf > Of *Ryan Boder > *Sent:* Tuesday, 01 March 2011 10:53 PM > *To:* rxtx at qbang.org > *Subject:* Re: [Rxtx] RXTX serial port read() returns -1 unexpectedly and > then blocks forever on close() > > > > Hi, > > I haven't seen any response to my question below. Is this not the right > place to ask? If not, where would be a better place to ask? Any suggestions? > > Thanks, > Ryan > > On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > > Hi, > > I have a receive thread that does nothing but call read() on the serial > port input stream. It works fine for a while but after running for a long > time it eventually returns -1 which means EOF. This is my first problem, as > the device I'm talking to runs forever, I don't know why it would return -1. > I am calling disableReceiveThreshold() and disableReceiveTimeout() at > initialization which according to the documentation means read will return > as soon as any data is available and it will block forever when data is not > available, so -1 should never be returned from read, right? > > I have been unable to figure out why read returns -1 after a long while but > I have found that if I kill my application and restart it everything works > fine again. Therefore I tried to work around the problem by having my code > close the port and reopen it when read returns -1. My second problem is that > in this case when I call close() on the port it blocks forever. I did find > this old bug > > http://bugzilla.qbang.org/show_bug.cgi?id=53 > > which describes close() hanging on OSX, but it says that bug was fixed with > a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have any > idea why read might be returning -1 in the first place? If I can avoid that > I don't care about close() hanging because I would never close the port. If > not, does anyone know why close() might block forever and how I can prevent > this? I'm using RXTX version 2.1-7. > > Thanks, > -- > Ryan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Mar 3 02:50:20 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 3 Mar 2011 09:50:20 +0000 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: So if -1 is unexpectedly returned from read, and we have demonstrated that your USB-serial adapter can actually causes this to happen in RXTX, why not just ignore the -1 value? What happens when you try this? As for a hang on close, are your closing your port from within your serial event handler? I know that this can cause some serious problems. Regards, Michael Erskine. From Kustaa.Nyholm at planmeca.com Thu Mar 3 03:39:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 12:39:34 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 03:44, "Ryan Boder" wrote: >While running the tests you requested I may have stumbled on the problem, >I just don't know how to fix it. According to the documentation, if both >the receive timeout and receive threshold are disabled then read() should >block forever until data is available. > >http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/re >ference/api/javax/comm/CommPort.html#getInputStream%28%29 > >On my system using RXTX read() is returning -1 when no data is available >even though I have disabled both thresholds. The reason my program was >running fine for a while without this problem showing up is that I was >using the DATA_AVAILABLE event to be notified when data is available and >only calling read() to read an entire frame whenever the DATA_AVAILABLE >event occurred, until eventually my device (I'm guessing) probably took >longer than normal to send the entire data frame and therefore I called >read when no data was available and it returned -1. As a workaround have you tried to perform another read() if it returns -1? The javadoc says (see getInputStream): "Note, however, that framing errors may cause the Timeout and Threshold values to complete prematurely without raising an exception." I read this as a hint that read might return even if no data is available. Because of the above and that read() can only return -1 or the byte received it would be somewhat logical to return -1 in case of framing error ? I'm not claiming that my interpretation of the specification, such as it is, is correct, just speculating that the behavior could be something like that. It might give you some more insight if you used the read(bytes[],int,int) method, because this can and will return 0 in case of timeout (and presumably might do so in case of framing error, maybe some other error condition too). That might allow you to handle or work around the problem in this case. You have not shown your complete code (no need) but your comments and the example makes me wonder if the code is otherwise as it should be, meaning are you assuming that when you get the DATA_AVAILABLE event all of your frame has arrived and that you can just blindly read it away from the input stream? That is not guaranteed of course. Also using read(), instead of read(bytes[],int,int), is not very efficient and might be masking other problems as mused above. BTE you can print a byte in hex with leading zeros more easily with: System.out.printf("%02X",x); br Kusti From ryan.boder at gmail.com Thu Mar 3 07:56:16 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:56:16 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 5:39 AM, Kustaa Nyholm wrote: > > As a workaround have you tried to perform another read() if it returns -1? > I tried that and it did work sometimes but not all the time. > > The javadoc says (see getInputStream): > > "Note, however, that framing errors may cause the Timeout and Threshold > values to complete prematurely without raising an exception." > > I read this as a hint that read might return even if no data is available. > > Because of the above and that read() can only return -1 or the byte > received > it would be somewhat logical to return -1 in case of framing error ? > > I'm not claiming that my interpretation of the specification, such as it > is, > is correct, just speculating that the behavior could be something like > that. > Receive framing is not enabled by default. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#enableReceiveFraming%28int%29 My choice of word might be misleading, when I said frame I just meant a contiguous message from the device. I am not enabling receive framing. Can you have a framing error when receive framing is disabled? > > It might give you some more insight if you used the read(bytes[],int,int) > method, because > this can and will return 0 in case of timeout (and presumably might do so > in case of framing > error, maybe some other error condition too). > > That might allow you to handle or work around the problem in this case. > > You have not shown your complete code (no need) but your comments and the > example > makes me wonder if the code is otherwise as it should be, meaning are you > assuming > that when you get the DATA_AVAILABLE event all of your frame has arrived > and that > you can just blindly read it away from the input stream? That is not > guaranteed of course. > I'm not assuming the entire message has arrived, I'm just assuming it either has arrived or will arrive soon which is why I'm using a (supposedly) blocking read(). > > Also using read(), instead of read(bytes[],int,int), is not very efficient > and > might be masking other problems as mused above. > True, I'm reading one byte at a time because I don't know how long the message will be until I read and parse some of it. I suppose I can use read(bytes[],int,int) once I figure out how long the message will be. > > BTE you can print a byte in hex with leading zeros more easily with: > > > System.out.printf("%02X",x); > I did it the dumb way in that test program so I could copy and paste the code from C# to Java without having to figure out how to do the same in C# which I'm not as familiar with. Thanks and BR, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 07:58:24 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:58:24 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: Yes I was doing the close in the serial event handler, I didn't realize that caused a problem. Thanks, I'll fix it. On Thu, Mar 3, 2011 at 4:50 AM, Michael Erskine wrote: > So if -1 is unexpectedly returned from read, and we have demonstrated > that your USB-serial adapter can actually causes this to happen in > RXTX, why not just ignore the -1 value? What happens when you try > this? As for a hang on close, are your closing your port from within > your serial event handler? I know that this can cause some serious > problems. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 11:48:20 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 13:48:20 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm wrote: > On 3/3/11 16:56, "Ryan Boder" wrote: > > > >I'm not assuming the entire message has arrived, I'm just assuming it > >either has arrived or will arrive soon which is why I'm using a > >(supposedly) blocking read(). > > > I've been giving this some further thought. > > It does not feel healthy to block without timeout, especially > from within a thread that is essentially internal to the rxtx. > > I've never done that, I always use a time out, read(byte[],int,int) > for the expected number of bytes, check how much I got and issue > more reads until I get everything. > > You have not described how your communication works so I'm only > speculating. > > If your device needs some response to send more bytes (from your > code it looks like this is not the case) then a missing byte > would block your read and prevent you from responding and > getting more data. But as said, looks like that is not the case. > > Anyway, if this was my problem, I would enable the timeout > and use read(byte[],int,int) and loop until I get what I need. > You are right, I should and will use a timeout. In fact, my program has been running flawlessly for 12 hours and the only change I made was to enable a timeout, no change in the logic at all. Without the timeout read() was returning -1 usually after it ran for an hour or two. I will change the code to make use of the timeout and handle it appropriately. It still seems to me that RXTX's behavior doesn't match the documentation when rx timeout and rx threshold are disabled read() should block until data is available instead of immediately returning -1. I don't believe that a framing error is occurring immediately every time data is not available causing read() to return -1. Especially since the C# test program above runs all day with no error and the Java program above runs all day with no error when a timeout is enabled. To me it seems like enabling the timeout is what is causing read() to block until data is available, even if only for 1600ms, and without the timeout read() is returning -1 immediately when it should be blocking. Thanks for all the help and best regards, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Thu Mar 3 13:02:30 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 22:02:30 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 20:48, "Ryan Boder" wrote: >On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm > wrote: > >On 3/3/11 16:56, "Ryan Boder" wrote: >> > >>I'm not assuming the entire message has arrived, I'm just assuming it >>either has arrived or will arrive soon which is why I'm using a >>(supposedly) blocking read(). > > > >I've been giving this some further thought. > >It does not feel healthy to block without timeout, especially >from within a thread that is essentially internal to the rxtx. > >I've never done that, I always use a time out, read(byte[],int,int) >for the expected number of bytes, check how much I got and issue >more reads until I get everything. > >You have not described how your communication works so I'm only >speculating. > >If your device needs some response to send more bytes (from your >code it looks like this is not the case) then a missing byte >would block your read and prevent you from responding and >getting more data. But as said, looks like that is not the case. > >Anyway, if this was my problem, I would enable the timeout >and use read(byte[],int,int) and loop until I get what I need. > > > > >You are right, I should and will use a timeout. In fact, my program has >been running flawlessly for 12 hours and the only change I made was to >enable a timeout, no change in the logic at all. Without the timeout >read() was returning -1 usually after it ran for an hour or two. I will >change the code to make use of the timeout and handle it appropriately. That's nice! > >It still seems to me that RXTX's behavior doesn't match the documentation >when rx timeout and rx threshold are disabled read() should block until >data is available instead of immediately returning -1. Yeah, it does look like bug. However this might be related to some Windows specific serial port issue. Years ago I had issues with JavaComm (not RxTx) where I did a blocking read and I had huge issues with my program consuming all resources. I curser the Sun and JavaComm and re-code my own SerialPort using JNI to access the Win32 API directly. And I run into the same problems as with the Sun's implementation! So I ditched my code, changed my code to use timeouts and problems disappeared. > I don't believe that a framing error is occurring immediately every time >data is not available causing read() to return -1. Especially since the >C# test program above runs all day with no error and the Java program >above runs all day with no error when a timeout is enabled. I think so too, all things considered I don't really believe in framing errors in this case. > To me it seems like enabling the timeout is what is causing read() to >block until data is available, even if only for 1600ms, and without the >timeout read() is returning -1 immediately when it should be blocking. Yeah, I had a peek at the innards of RxTx Windows serial port a week or so ago and also read MSDN documentation about serial ports and the way overlapped and non-overlapped (non blocking and blocking) IO is handled is a way different. So yeah, it can well be that there is an issue lurking there somewhere inside RxTx in Windows. > > >Thanks for all the help and best regards, >-- >Ryan Boder I'm happy if I was of any assistance. br Kusti From tjarvi at qbang.org Thu Mar 3 18:52:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Mar 2011 18:52:50 -0700 (MST) Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: >> Without the timeout >> read() was returning -1 usually after it ran for an hour or two. There is a big hammer in rxtx causing that behavior. >> It still seems to me that RXTX's behavior doesn't match the documentation >> when rx timeout and rx threshold are disabled read() should block until >> data is available instead of immediately returning -1. > > Yeah, it does look like bug. However this might be related to some > Windows specific serial port issue. Years ago I had issues with > JavaComm (not RxTx) where I did a blocking read and I had huge > issues with my program consuming all resources. I curser the Sun > and JavaComm and re-code my own SerialPort using JNI to access > the Win32 API directly. And I run into the same problems as > with the Sun's implementation! So I ditched my code, changed > my code to use timeouts and problems disappeared. > > >> To me it seems like enabling the timeout is what is causing read() to >> block until data is available, even if only for 1600ms, and without the >> timeout read() is returning -1 immediately when it should be blocking. > > Yeah, I had a peek at the innards of RxTx Windows serial port a week > or so ago and also read MSDN documentation about serial ports and > the way overlapped and non-overlapped (non blocking and blocking) > IO is handled is a way different. So yeah, it can well be that > there is an issue lurking there somewhere inside RxTx in Windows. > > Yes. RXTX was patched to behave the way it does. I don't fully understand the issue behind the patch. Marc noticed the odd behavior as well and offered a fix which was greeted with resistance. The windows implementation was done without real documentatino of the windows API. I think I had an example from the late 80's early 90's on Microsoft's site and some API documentation that was obviously not microsofts in Europe. Wayne Roberts had a real need for windows support and fixed some major issues it had. My interest at the time was mingw32. I then cleaned it up for some specific uses I had later. The read returning -1 when it should block didn't impact anybody and appeared to help some people. It isnt the documented behavior though. There could be all sorts of latent bugs in that code but in the real world, it gets by in almost all use cases. Its a hack but it worked for 100's of thousands of people over a 14 year period. Maybe its time to revisit the code but there is more risk than gain for most people. How do you move forward and avoid the risk? Some have expressed interests in coding C++ or other efforts. I'm all for such efforts but feel some unit tests that work with a null modem cables are the only thing that will move rxtx (and perhaps CommAPI) forward. If we have a test suite in place as a qualification for implementations, progress can be made in the right direction regardless of the implementation details. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Fri Mar 4 02:57:16 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 4 Mar 2011 11:57:16 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/4/11 03:52, "Trent Jarvi" wrote: >Yes. RXTX was patched to behave the way it does. I don't fully >understand the issue behind the patch. Marc noticed the odd behavior as >well and offered a fix which was greeted with resistance. > >The windows implementation was done without real documentatino of the >windows API. I think I had an example from the late 80's early 90's on >Microsoft's site and some API documentation that was obviously not >microsofts in Europe. Wayne Roberts had a real need for windows support >and fixed some major issues it had. My interest at the time was mingw32. >I then cleaned it up for some specific uses I had later. The read >returning -1 when it should block didn't impact anybody and appeared to >help some people. It isnt the documented behavior though. > >There could be all sorts of latent bugs in that code but in the real >world, it gets by in almost all use cases. I think so too, never had any problems with it. > Its a hack but it worked for 100's of thousands of people over a 14 year >period. Yeah! Thanks for everyone who has contributed over the years, job well done! >Maybe its time to >revisit the code but there is more risk than gain for most people. How >do >you move forward and avoid the risk? My view is that it is quite risky and rather pointless to move forward, other than fixing bugs that really affect people. At the moment the major issue IMO is just that it seems (not been following this too carefully, so maybe I'm wrong, so in case this FUD, my apologies) that 'official' binaries are not available. I think the rewrite, tempting as it is in some respects is not the way forward. Just gentle maintenance to iron out real issues and then get the binaries out. br Kusti From ryan.boder at gmail.com Fri Mar 4 07:24:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Fri, 4 Mar 2011 09:24:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 8:52 PM, Trent Jarvi wrote: > > The windows implementation was done without real documentatino of the > windows API. I think I had an example from the late 80's early 90's on > Microsoft's site and some API documentation that was obviously not > microsofts in Europe. Wayne Roberts had a real need for windows support and > fixed some major issues it had. My interest at the time was mingw32. I then > cleaned it up for some specific uses I had later. The read returning -1 > when it should block didn't impact anybody and appeared to help some people. > It isnt the documented behavior though. > > There could be all sorts of latent bugs in that code but in the real world, > it gets by in almost all use cases. Its a hack but it worked for 100's of > thousands of people over a 14 year period. Maybe its time to revisit the > code but there is more risk than gain for most people. How do you move > forward and avoid the risk? > The safest and easiest solution would be to add a javadoc comment to disableReceiveTimeout explaining the difference between the RXTX behavior and Sunacle's documented behavior so that when someone uses the method in an IDE like Eclipse a little box would pop up informing them. Generating javadoc HTML and hosting it on the RXTX website would go a long way too, when something behaves differently than I expect the first thing I do is look for the javadoc online. -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From kharrington at neuronrobotics.com Mon Mar 7 10:47:26 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 12:47:26 -0500 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! Message-ID: Hey all, this is just a heads up that i have made a fork of rxtxSerial. Some of the features we have added: * Self deployment of native libraries ( all native code is stored inside the jar and deployed at runtime). No more manual install of native code. * Arm Cortex support (Gumstix) * Android Support (requires a rooted phone for now) * Google Code (SVN) repository for easy code and jar access * Single makefile compile (simplifies the compilation of project binaries) * Ant build script for jar creation * Removal of partialy implemented code to streamline the lib for just serial port access * Full Eclipse integration, for testing application code against sources. And a bunch of bug fixes: * Fixed the memory access error that causes OSX to crash the JVM when serial.close() is cvalled * Fixed the windows serial port zombie bind that prevents re-accessing serial ports when exiting on an exception * Fixed erronious printouts of native library mis-match To check it out, take a look at our page here: http://code.google.com/p/nrjavaserial/ From Kustaa.Nyholm at planmeca.com Mon Mar 7 11:46:26 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Mar 2011 20:46:26 +0200 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: Message-ID: On 3/7/11 19:47, "Kevin Harrington NR" wrote: >Hey all, this is just a heads up that i have made a fork of >rxtxSerial. Some of the features we have added great! If also does what it says on the tin: brilliant! Congrats and thanks. br Kusti From jmsachs at gmail.com Mon Mar 7 12:50:33 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 14:50:33 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: > From: Kevin Harrington NR > To: rxtx at qbang.org > Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > Hey all, this is just a heads up that i have made a fork of > rxtxSerial. Some of the features we have added: > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with a ten-foot pole. From Kustaa.Nyholm at planmeca.com Mon Mar 7 13:10:43 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Mar 2011 22:10:43 +0200 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: Message-ID: On 3/7/11 21:50, "Jason Sachs" wrote: > >Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >a ten-foot pole. >_______________________________________________ Oh crap, makes it useless for me and many others. Also I see no provision in RxTx license to change it so how could anyone change it to GPLv3? br Kusti From showard314 at gmail.com Mon Mar 7 13:24:08 2011 From: showard314 at gmail.com (Scott Howard) Date: Mon, 7 Mar 2011 15:24:08 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 3:10 PM, Kustaa Nyholm wrote: > Also I see no provision in RxTx license to change > it so how could anyone change it to GPLv3? I think this is allowed: 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. From jmsachs at gmail.com Mon Mar 7 13:24:47 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 15:24:47 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 2:50 PM, Jason Sachs wrote: >> From: Kevin Harrington NR >> To: rxtx at qbang.org >> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> > > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with > a ten-foot pole. > Let me back up a second (perhaps to make up for my lack of diplomacy) and state that I think any progress w/ rxtx is good. If an rxtx fork were LGPL (or some other non-spreading open source license) and leading in a good direction, I'd gladly return the favor by posting any improvements or bugfixes I found to the community. --Jason From jmsachs at gmail.com Mon Mar 7 13:36:13 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 15:36:13 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: Kevin: could you clarify the license? http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java has the RXTX 2.1 license (LGPL v 2.1 + Linking Over Controlled Interface.) but http://code.google.com/p/nrjavaserial/ says GPLv3. --Jason From kharrington at neuronrobotics.com Mon Mar 7 14:00:02 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 16:00:02 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: The one downside to google code is that it does not allow custom licensing. You have to pick from a drop-down list. Treat the licences on the files themselves as the licence to be concerned with, and ignore the "project licence". Sorry for the confusion. On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: > Kevin: could you clarify the license? > > http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java > has the RXTX 2.1 license > (LGPL v 2.1 + Linking Over Controlled Interface.) > > but http://code.google.com/p/nrjavaserial/ says GPLv3. > > --Jason > From iqzw2r602 at sneakemail.com Mon Mar 7 14:08:18 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 8 Mar 2011 08:08:18 +1100 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: References: Message-ID: <11253-1299532098-811882@sneakemail.com> Nice! Out of curiosity, did you use the patch that I sent Trent about two years ago to do the native library loading, or did you implement your own solution? Cheers, Uwe On Tue, Mar 8, 2011 at 5:46 AM, Kustaa Nyholm Kustaa.Nyholm-at-planmeca.com| rxtx.org mailing list/Example Allow| wrote: > On 3/7/11 19:47, "Kevin Harrington NR" > wrote: > > >Hey all, this is just a heads up that i have made a fork of > >rxtxSerial. Some of the features we have added > > > > great! If also does what it says on the tin: brilliant! > > Congrats and thanks. > > br Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aawolfe at gmail.com Mon Mar 7 15:31:47 2011 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 7 Mar 2011 17:31:47 -0500 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR wrote: > Hey all, this is just a heads up that i have made a fork of > rxtxSerial. Some of the features we have added: > > * Self deployment of native libraries ( all native code is stored > inside the jar and deployed at runtime). No more manual install of > native code. > * Arm Cortex support (Gumstix) > * Android Support (requires a rooted phone for now) > * Google Code (SVN) repository for easy code and jar access > * Single makefile compile (simplifies the compilation of project binaries) > * Ant build script for jar creation > * Removal of partialy implemented code to streamline the lib for just > serial port access > * Full Eclipse integration, for testing application code against sources. > > And a bunch of bug fixes: > > * Fixed the memory access error that causes OSX to crash the JVM when > serial.close() is cvalled > * Fixed the windows serial port zombie bind that prevents re-accessing > serial ports when exiting on an exception > * Fixed erronious printouts of native library mis-match > > To check it out, take a look at our page here: > > http://code.google.com/p/nrjavaserial/ This is interesting, getting the native libs set up has been an issue for some of my users. Will have to check it out. Out of curiosity, what Android devices provide a serial port? Or are there some that allow USB host mode and then a usb-serial adapter? I have only an Android cell phone, don't think it can do anything serial but would love to be wrong about that. From jfh at greenhousepc.com Mon Mar 7 15:54:39 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 15:54:39 -0700 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! Message-ID: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Mon Mar 7 16:53:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Mar 2011 16:53:50 -0700 (MST) Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: Hi Kevin, Until Google fixes the options as developers have requested, I'd suggest the least misleading dropdown option is "Other Open Source" with a clarification about LGPL 2.1 on the project page. If you are not supporting the CommAPI SPI interface that was available prior to the current JSR so that applications work in the javax.comm namespace, there is no need for the linking over controlled interfaces exception. RXTX 2.0 is used in that fashion but RXTX 2.1 is not. The exception explicitly states it can be removed if the source has been modified. The license is then explicitly OSI reviewed and approved as Google requests but is not in their drop down box as it should be and is for the GPL v2. http://opensource.org/licenses/alphabetical http://opensource.org/licenses/lgpl-2.1 The drawback would be that the library effectively could never be used in that SPI/controlled interface fashion again. On Mon, 7 Mar 2011, Kevin Harrington NR wrote: > The one downside to google code is that it does not allow custom > licensing. You have to pick from a drop-down list. Treat the licences > on the files themselves as the licence to be concerned with, and > ignore the "project licence". Sorry for the confusion. > > On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >> Kevin: could you clarify the license? >> >> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >> has the RXTX 2.1 license >> (LGPL v 2.1 + Linking Over Controlled Interface.) >> >> but http://code.google.com/p/nrjavaserial/ says GPLv3. >> >> --Jason >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From hakcenter at gmail.com Mon Mar 7 18:55:57 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 17:55:57 -0800 Subject: [Rxtx] Latency Woes Message-ID: <4D758CAD.2010602@gmail.com> I have finally deduced my slow data logging to a latency issue. I write software for dsms, and the protocol is request / receive, you cannot do more than 1 sensor at a time. So when you log multiple sensors, +20ms per item, sampling rate drops like a rock. I was wondering if there is any ideas besides going completely native with my application to reduce latency. With or without events I don't care at this point I need to kill as much of the latency as possible. Realistically I need no more than 1ms. From adrian.crum at sandglass-software.com Mon Mar 7 19:08:21 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Mon, 07 Mar 2011 18:08:21 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D758CAD.2010602@gmail.com> References: <4D758CAD.2010602@gmail.com> Message-ID: <4D758F95.90800@sandglass-software.com> Drop the requests into a queue, and then have a separate thread service the queue. -Adrian On 3/7/2011 5:55 PM, Curtis Hacker wrote: > I have finally deduced my slow data logging to a latency issue. > > I write software for dsms, and the protocol is request / receive, you > cannot do more than 1 sensor at a time. So when you log multiple > sensors, +20ms per item, sampling rate drops like a rock. > > I was wondering if there is any ideas besides going completely native > with my application to reduce latency. With or without events I don't > care at this point I need to kill as much of the latency as possible. > Realistically I need no more than 1ms. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From hakcenter at gmail.com Mon Mar 7 19:24:16 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 18:24:16 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D758F95.90800@sandglass-software.com> References: <4D758CAD.2010602@gmail.com> <4D758F95.90800@sandglass-software.com> Message-ID: <4D759350.8060402@gmail.com> Sample code ? I don't necessarily want to read the byte I just wrote, but wait till the que depth is 2. Setup a thread without a sleep timer: if (in.available() > 1) { do_stuff(); } ?? On 03/07/11 18:08, Adrian Crum wrote: > Drop the requests into a queue, and then have a separate thread > service the queue. > > -Adrian > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: >> I have finally deduced my slow data logging to a latency issue. >> >> I write software for dsms, and the protocol is request / receive, you >> cannot do more than 1 sensor at a time. So when you log multiple >> sensors, +20ms per item, sampling rate drops like a rock. >> >> I was wondering if there is any ideas besides going completely native >> with my application to reduce latency. With or without events I don't >> care at this point I need to kill as much of the latency as possible. >> Realistically I need no more than 1ms. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adrian.crum at sandglass-software.com Mon Mar 7 19:46:02 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Mon, 07 Mar 2011 18:46:02 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D759350.8060402@gmail.com> References: <4D758CAD.2010602@gmail.com> <4D758F95.90800@sandglass-software.com> <4D759350.8060402@gmail.com> Message-ID: <4D75986A.6020003@sandglass-software.com> http://download.oracle.com/javase/tutorial/essential/concurrency/executors.html -Adrian On 3/7/2011 6:24 PM, Curtis Hacker wrote: > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: >> Drop the requests into a queue, and then have a separate thread >> service the queue. >> >> -Adrian >> >> On 3/7/2011 5:55 PM, Curtis Hacker wrote: >>> I have finally deduced my slow data logging to a latency issue. >>> >>> I write software for dsms, and the protocol is request / receive, >>> you cannot do more than 1 sensor at a time. So when you log multiple >>> sensors, +20ms per item, sampling rate drops like a rock. >>> >>> I was wondering if there is any ideas besides going completely >>> native with my application to reduce latency. With or without events >>> I don't care at this point I need to kill as much of the latency as >>> possible. Realistically I need no more than 1ms. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Mon Mar 7 19:50:45 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 19:50:45 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Mon Mar 7 20:04:01 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 19:04:01 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> Message-ID: <4D759CA1.8010903@gmail.com> I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. in.read(data, 0, 2); ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? On 03/07/11 18:50, jfh at greenhousepc.com wrote: > Curtis, > > No, I assume he means a real queue, not just "don't read all the bytes > at once." However, if you know you can process some number of > requests in some amount of time, allowing data to pile up (receiver > FIFO space permitting) can be a valid strategy. Inserting gobs of > Thread.yield() and notify() can help pep things up as well. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Mon, March 07, 2011 8:24 pm > To: rxtx at qbang.org > > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: > > Drop the requests into a queue, and then have a separate thread > > service the queue. > > > > -Adrian > > > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: > >> I have finally deduced my slow data logging to a latency issue. > >> > >> I write software for dsms, and the protocol is request / > receive, you > >> cannot do more than 1 sensor at a time. So when you log multiple > >> sensors, +20ms per item, sampling rate drops like a rock. > >> > >> I was wondering if there is any ideas besides going completely > native > >> with my application to reduce latency. With or without events I > don't > >> care at this point I need to kill as much of the latency as > possible. > >> Realistically I need no more than 1ms. > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From bartley at cmu.edu Mon Mar 7 20:08:05 2011 From: bartley at cmu.edu (Chris Bartley) Date: Mon, 7 Mar 2011 22:08:05 -0500 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> Message-ID: <9B1804F9-DBD0-476D-9345-806D00065A97@cmu.edu> We use a queue for all our request/response serial communications, and have found it really easy to work with. Code is here: http://code.google.com/p/create-lab-commons/source/browse/trunk/java/code/serial/src/edu/cmu/ri/createlab/serial/SerialPortCommandExecutionQueue.java It's assuming a command & response scheme that's specific to the protocol we use to talk to our robots, but it should be easy to modify for your needs. Hope this helps. Let me know if you have questions. Chris On Mar 7, 2011, at 9:50 PM, wrote: > Curtis, > > No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > Date: Mon, March 07, 2011 8:24 pm > To: rxtx at qbang.org > > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: > > Drop the requests into a queue, and then have a separate thread > > service the queue. > > > > -Adrian > > > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: > >> I have finally deduced my slow data logging to a latency issue. > >> > >> I write software for dsms, and the protocol is request / receive, you > >> cannot do more than 1 sensor at a time. So when you log multiple > >> sensors, +20ms per item, sampling rate drops like a rock. > >> > >> I was wondering if there is any ideas besides going completely native > >> with my application to reduce latency. With or without events I don't > >> care at this point I need to kill as much of the latency as possible. > >> Realistically I need no more than 1ms. > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Mon Mar 7 20:51:17 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 20:51:17 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110307205116.8ef0e5b4a80cef441275a6330ffad77d.9b325137d1.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From kharrington at neuronrobotics.com Mon Mar 7 20:55:23 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 22:55:23 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 7 In-Reply-To: References: Message-ID: To answer a few of you, I have changed the license to "Other open source license" as suggested. My company is modifying and maintaining this fork to support our robotics development library (http://code.google.com/p/nr-sdk/ http://dev.neuronrobotics.com). We will be implementing the standard serial port interface only, as it is the only one we need or care about. As for where the implementation came from, i would have to refer to my other developer to answer that. I wrote the build scripts and make files, as well as streamlining the C build process. I have remover the configure script, as it ends up being more confusing then compiling 3 C files needs to be. if you guys want to bring any of this into the main line, that's cool, but up to you to port over. Our fork will be focusing on polishing up the serial interface,and hopefully making it faster. I hope some of you will find our improvements useful! On Mon, Mar 7, 2011 at 6:53 PM, wrote: > Send Rxtx mailing list submissions to > ? ? ? ?rxtx at qbang.org > > To subscribe or unsubscribe via the World Wide Web, visit > ? ? ? ?http://mailman.qbang.org/mailman/listinfo/rxtx > or, via email, send a message with subject or body 'help' to > ? ? ? ?rxtx-request at qbang.org > > You can reach the person managing the list at > ? ? ? ?rxtx-owner at qbang.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Rxtx digest..." > > > Today's Topics: > > ? 1. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 2. Re: Rxtx Digest, Vol 43, Issue 6 (Kustaa Nyholm) > ? 3. Re: Rxtx Digest, Vol 43, Issue 6 (Scott Howard) > ? 4. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 5. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 6. Re: Rxtx Digest, Vol 43, Issue 6 (Kevin Harrington NR) > ? 7. Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! > ? ? ?(iqzw2r602 at sneakemail.com) > ? 8. Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! > ? ? ?(Aaron Wolfe) > ? 9. Re: [SPAM] Re: ?NRJavaSerial, a fork of rxtx that fixes the > ? ? ?papercuts! (jfh at greenhousepc.com) > ?10. Re: Rxtx Digest, Vol 43, Issue 6 (Trent Jarvi) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 7 Mar 2011 14:50:33 -0500 > From: Jason Sachs > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > >> From: Kevin Harrington NR >> To: rxtx at qbang.org >> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> > > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with > a ten-foot pole. > > > ------------------------------ > > Message: 2 > Date: Mon, 7 Mar 2011 22:10:43 +0200 > From: Kustaa Nyholm > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > On 3/7/11 21:50, "Jason Sachs" wrote: >> >>Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >>a ten-foot pole. >>_______________________________________________ > > Oh crap, makes it useless for me and many others. > > Also I see no provision in RxTx license to change > it so how could anyone change it to GPLv3? > > br Kusti > > > > ------------------------------ > > Message: 3 > Date: Mon, 7 Mar 2011 15:24:08 -0500 > From: Scott Howard > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 3:10 PM, Kustaa Nyholm > wrote: >> Also I see no provision in RxTx license to change >> it so how could anyone change it to GPLv3? > > I think this is allowed: > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. ?To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. ?(If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) ?Do not make any other change in > these notices. > > ? Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > ? This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > > ------------------------------ > > Message: 4 > Date: Mon, 7 Mar 2011 15:24:47 -0500 > From: Jason Sachs > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 2:50 PM, Jason Sachs wrote: >>> From: Kevin Harrington NR >>> To: rxtx at qbang.org >>> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >>> Message-ID: >>> ? ? ? ? >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> Hey all, this is just a heads up that i have made a fork of >>> rxtxSerial. Some of the features we have added: >>> >> >> Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >> a ten-foot pole. >> > > Let me back up a second (perhaps to make up for my lack of diplomacy) > and state that I think any progress w/ rxtx is good. > > If an rxtx fork were LGPL (or some other non-spreading open source > license) and leading in a good direction, I'd gladly return the favor > by posting any improvements or bugfixes I found to the community. > > --Jason > > > ------------------------------ > > Message: 5 > Date: Mon, 7 Mar 2011 15:36:13 -0500 > From: Jason Sachs > To: rxtx at qbang.org, kharrington at neuronrobotics.com > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > Kevin: could you clarify the license? > > http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java > has the RXTX 2.1 license > (LGPL v 2.1 + Linking Over Controlled Interface.) > > but http://code.google.com/p/nrjavaserial/ says GPLv3. > > --Jason > > > ------------------------------ > > Message: 6 > Date: Mon, 7 Mar 2011 16:00:02 -0500 > From: Kevin Harrington NR > To: Jason Sachs > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > The one downside to google code is that it does not allow custom > licensing. You have to pick from a drop-down list. Treat the licences > on the files themselves as the licence to be concerned with, and > ignore the "project licence". Sorry for the confusion. > > On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >> Kevin: could you clarify the license? >> >> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >> has the RXTX 2.1 license >> (LGPL v 2.1 + Linking Over Controlled Interface.) >> >> but http://code.google.com/p/nrjavaserial/ says GPLv3. >> >> --Jason >> > > > ------------------------------ > > Message: 7 > Date: Tue, 8 Mar 2011 08:08:18 +1100 > From: iqzw2r602 at sneakemail.com > To: Rxtx at qbang.org > Subject: Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > ? ? ? ?papercuts! > Message-ID: <11253-1299532098-811882 at sneakemail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Nice! > > Out of curiosity, did you use the patch that I sent Trent about two years > ago to do the native library loading, or did you implement your own > solution? > > Cheers, > > Uwe > > On Tue, Mar 8, 2011 at 5:46 AM, Kustaa Nyholm Kustaa.Nyholm-at-planmeca.com| > rxtx.org mailing list/Example Allow| wrote: > >> On 3/7/11 19:47, "Kevin Harrington NR" >> wrote: >> >> >Hey all, this is just a heads up that i have made a fork of >> >rxtxSerial. Some of the features we have added >> >> >> >> great! If also does what it says on the tin: brilliant! >> >> Congrats and thanks. >> >> br Kusti >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 8 > Date: Mon, 7 Mar 2011 17:31:47 -0500 > From: Aaron Wolfe > To: rxtx at qbang.org > Subject: Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > ? ? ? ?papercuts! > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR > wrote: >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> >> * Self deployment of native libraries ( all native code is stored >> inside the jar and deployed at runtime). No more manual install of >> native code. >> * Arm Cortex support (Gumstix) >> * Android Support (requires a rooted phone for now) >> * Google Code (SVN) repository for easy code and jar access >> * Single makefile compile (simplifies the compilation of project binaries) >> * Ant build script for jar creation >> * Removal of partialy implemented code to streamline the lib for just >> serial port access >> * Full Eclipse integration, for testing application code against sources. >> >> And a bunch of bug fixes: >> >> * Fixed the memory access error that causes OSX to crash the JVM when >> serial.close() is cvalled >> * Fixed the windows serial port zombie bind that prevents re-accessing >> serial ports when exiting on an exception >> * Fixed erronious printouts of native library mis-match >> >> To check it out, take a look at our page here: >> >> http://code.google.com/p/nrjavaserial/ > > This is interesting, getting the native libs set up has been an issue > for some of my users. ?Will have to check it out. > > Out of curiosity, what Android devices provide a serial port? ?Or are > there some that allow USB host mode and then a usb-serial adapter? ?I > have only an Android cell phone, don't think it can do anything serial > but would love to be wrong about that. > > > ------------------------------ > > Message: 9 > Date: Mon, 07 Mar 2011 15:54:39 -0700 > From: > To: aaron at aaronwolfe.com, rxtx at qbang.org > Subject: Re: [Rxtx] [SPAM] Re: ?NRJavaSerial, a fork of rxtx that > ? ? ? ?fixes the papercuts! > Message-ID: > ? ? ? ?<20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe at email13.secureserver.net> > > Content-Type: text/plain; charset="us-ascii" > > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 10 > Date: Mon, 7 Mar 2011 16:53:50 -0700 (MST) > From: Trent Jarvi > To: rxtx at qbang.org > Cc: Jason Sachs > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > Hi Kevin, > > Until Google fixes the options as developers have requested, I'd suggest > the least misleading dropdown option is "Other Open Source" with a > clarification about LGPL 2.1 on the project page. > > If you are not supporting the CommAPI SPI interface that was available > prior to the current JSR so that applications work in the javax.comm > namespace, there is no need for the linking over controlled interfaces > exception. ?RXTX 2.0 is used in that fashion but RXTX 2.1 is not. ?The > exception explicitly states it can be removed if the source has been > modified. ?The license is then explicitly OSI reviewed and approved as > Google requests but is not in their drop down box as it should be and is > for the GPL v2. > > ? ? ? ?http://opensource.org/licenses/alphabetical > ? ? ? ?http://opensource.org/licenses/lgpl-2.1 > > The drawback would be that the library effectively could never be used in > that SPI/controlled interface fashion again. > > On Mon, 7 Mar 2011, Kevin Harrington NR wrote: > >> The one downside to google code is that it does not allow custom >> licensing. You have to pick from a drop-down list. Treat the licences >> on the files themselves as the licence to be concerned with, and >> ignore the "project licence". Sorry for the confusion. >> >> On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >>> Kevin: could you clarify the license? >>> >>> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >>> has the RXTX 2.1 license >>> (LGPL v 2.1 + Linking Over Controlled Interface.) >>> >>> but http://code.google.com/p/nrjavaserial/ says GPLv3. >>> >>> --Jason >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > ------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > End of Rxtx Digest, Vol 43, Issue 7 > *********************************** > From Kustaa.Nyholm at planmeca.com Mon Mar 7 21:43:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 8 Mar 2011 06:43:57 +0200 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307205116.8ef0e5b4a80cef441275a6330ffad77d.9b325137d1.wbe@email13.secureserver.net> Message-ID: On 3/8/11 05:51, "jfh at greenhousepc.com" wrote: >Curtis, > > >None of that is relevant, as long as the UART is reasonable and the code >implements a proper half duplex protocol. > >If I understand correctly, you send a byte, the sensor sends back two >bytes. So long as you don't send the next byte until the two bytes are >in the UART receiver FIFO, you're fine. You don't have to actually >=read= them, just know they are available. To the OP, are you using a serial USB port, like FTDI? This has a built in latency of 10ms ie nothing is actually sent out of the device if you send less than 64 bytes until 10 msec timeout. This has nothing to do with RxTx. If you search the list archives you'll find more about this issue and IIRC someone reported that there is some diver parameter you can tweak to get rid of that latency. I'm sure the FTDI people had a good reason for this but it really brings down the communication speed if your protocol uses short messages and need to wait for a response. Sorry if this has already been mentioned or if this is not relevant, I've not been paying attention to this thread. br Kusti From bob_jacobsen at lbl.gov Tue Mar 8 00:02:28 2011 From: bob_jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 8 Mar 2011 00:02:28 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D759CA1.8010903@gmail.com> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> Message-ID: If you're transferring three bytes total at 1953 baud, it's going to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to wait 20msec to get the data back instead of 15.4 msec doesn't seem to be as big a problem as you're making it sound. Bob On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. > > To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. > > So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. > > in.read(data, 0, 2); > ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? > > On 03/07/11 18:50, jfh at greenhousepc.com wrote: >> Curtis, >> >> No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker >> Date: Mon, March 07, 2011 8:24 pm >> To: rxtx at qbang.org >> >> Sample code ? >> >> I don't necessarily want to read the byte I just wrote, but wait till >> the que depth is 2. >> >> Setup a thread without a sleep timer: >> if (in.available() > 1) { >> do_stuff(); >> } >> >> ?? >> >> On 03/07/11 18:08, Adrian Crum wrote: >> > Drop the requests into a queue, and then have a separate thread >> > service the queue. >> > >> > -Adrian >> > >> > On 3/7/2011 5:55 PM, Curtis Hacker wrote: >> >> I have finally deduced my slow data logging to a latency issue. >> >> >> >> I write software for dsms, and the protocol is request / receive, you >> >> cannot do more than 1 sensor at a time. So when you log multiple >> >> sensors, +20ms per item, sampling rate drops like a rock. >> >> >> >> I was wondering if there is any ideas besides going completely native >> >> with my application to reduce latency. With or without events I don't >> >> care at this point I need to kill as much of the latency as possible. >> >> Realistically I need no more than 1ms. >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From hakcenter at gmail.com Tue Mar 8 01:33:24 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 00:33:24 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> Message-ID: <4D75E9D4.5090307@gmail.com> I am going to try a couple things today and hopefully figure something out. Bob I don't want to pop your bubble, but a native application named 'TunerPro' can sample the same data, over 30 sensors, in less than 25ms. I've exchanged some emails with the author and it is a native C, polling, no events just timeouts. Kusta thanks for the FTDI notice, I believe that is tunable, however I have a particular user using a Keyspan converter and verified sampling rate with 'TunerPro' and its just off the charts. Chris thank you, I'll look into the queing. On 03/07/11 23:02, Bob Jacobsen wrote: > If you're transferring three bytes total at 1953 baud, it's going to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to wait 20msec to get the data back instead of 15.4 msec doesn't seem to be as big a problem as you're making it sound. > > Bob > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > >> I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. >> >> To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. >> >> So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. >> >> in.read(data, 0, 2); >> ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? >> >> On 03/07/11 18:50, jfh at greenhousepc.com wrote: >>> Curtis, >>> >>> No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. >>> -- >>> Julie Haugh >>> Senior Design Engineer >>> greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype From msemtd at googlemail.com Tue Mar 8 01:50:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 8 Mar 2011 08:50:15 +0000 Subject: [Rxtx] Latency Woes In-Reply-To: <4D75E9D4.5090307@gmail.com> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> <4D75E9D4.5090307@gmail.com> Message-ID: On 8 March 2011 08:33, Curtis Hacker wrote: > I am going to try a couple things today and hopefully figure something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than 25ms. > I've exchanged some emails with the author and it is a native C, polling, no > events just timeouts. Perhaps the author of TunerPro will let you use his native code - sounds just what you need. Regards, Michael Erskine. From jfh at greenhousepc.com Tue Mar 8 04:00:18 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 04:00:18 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 12:33:35 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 11:33:35 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> Message-ID: <4D76848F.5080809@gmail.com> Cable schematic: http://i1106.photobucket.com/albums/h377/vigilart/jackal%20logging%20set%20up/RS232SCHEMATIC.jpg 0.00268554 TunerPro.exe IOCTL_SERIAL_SET_BAUD_RATE VCP0 SUCCESS Rate: 1952 0.00305178 TunerPro.exe IOCTL_SERIAL_SET_RTS VCP0 SUCCESS 0.00297524 TunerPro.exe IOCTL_SERIAL_SET_DTR VCP0 SUCCESS 0.00297384 TunerPro.exe IOCTL_SERIAL_SET_LINE_CONTROL VCP0 SUCCESS StopBits: 1 Parity: NONE WordLength: 8 0.00000335 TunerPro.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 0.00202540 TunerPro.exe IOCTL_SERIAL_SET_HANDFLOW VCP0 SUCCESS Shake:1 Replace:40 XonLimit:2048 XoffLimit:512 0.00000335 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:300 RM:0 RC:2000 WM:0 WC:110 0.00000279 TunerPro.exe IOCTL_SERIAL_SET_QUEUE_SIZE VCP0 SUCCESS InSize: 1024 OutSize: 512 0.00000307 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000279 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:300 RM:0 RC:2000 WM:0 WC:110 0.00000307 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:75 RM:0 RC:400 WM:0 WC:300 0.00000559 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: RXCLEAR 0.00000335 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: TXCLEAR 0.00064980 TunerPro.exe IRP_MJ_WRITE VCP0 SUCCESS Length 1: . 0.01498738 TunerPro.exe IRP_MJ_READ VCP0 SUCCESS Length 1: . 0.00000363 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:200 RM:0 RC:20 WM:0 WC:300 0.02042774 TunerPro.exe IRP_MJ_READ VCP0 TIMEOUT Length 0: That is time on the left side. Now I'm with you on timing, it doesn't make a lot of sense, but that is how the logs come out. You can view the logs yourself. Tunerpro log : http://www.ds-map.net/tunerpro_log.csv My apps log : http://www.ds-map.net/my_log.csv 2nd app log : http://www.ds-map.net/my_log2.csv All these logs, were done from the same car, same cable. I have some older logs with some palm software, that was 13 sensors, and had a total 45-55ms between each set of 13. More info about the car / ecu at http://mmcdlogger.sourceforge.net Disassembly on the ecu: [SS1:SS0] is baud rate divider, 00(16) 01(128) 10(1024) 11(4096), assuming basic clock of 2MHZ, we get 125000baud, 15625baud, 1953baud, 488baud In any event, I attempted a no sleep thread, that waited till in.available > 1, and it wasn't any faster than running the events. Then I tried a read write thread, that slept from 1ms to 30ms after it wrote (so it wouldn't read what it just wrote). And couldn't get it doing much. I wish I had more of an understanding of all of this, which is why I'm asking for help. On 03/08/11 03:00, jfh at greenhousepc.com wrote: > Curtis, > > At the risk of being told "No, they really say it can be done", 30 > sensors is 30 * 3 character times (are you sure it's not a single byte > response?). At 1953 baud, a single character time is 10 bits * (1 / > 1953) seconds, or 15.4ms as Bob pointed out. 30 * 15.4ms is 460ms, > and that assumes everything works perfectly, no turnaround times, etc. > > If you can come up with some other way to make the math work, I'd love > to hear it. > > Short and sweet -- just because TunerPro can talk to an ECM/ECU that > is running faster than 1953 baud doesn't mean your Mitsubishi (or > whatever car you've got that runs at 1953 baud) runs at that faster > baud rate. > > Also, are you sure your data cable is correct? What cable are you > using? What's the schematic? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 2:33 am > To: rxtx at qbang.org > > I am going to try a couple things today and hopefully figure > something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than > 25ms. > I've exchanged some emails with the author and it is a native C, > polling, no events just timeouts. > > Kusta thanks for the FTDI notice, I believe that is tunable, > however I > have a particular user using a Keyspan converter and verified > sampling > rate with 'TunerPro' and its just off the charts. > > Chris thank you, I'll look into the queing. > > On 03/07/11 23:02, Bob Jacobsen wrote: > > If you're transferring three bytes total at 1953 baud, it's going > to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to > wait 20msec to get the data back instead of 15.4 msec doesn't seem > to be as big a problem as you're making it sound. > > > > Bob > > > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > > > >> I guess I'm gunna need some serious help with this then, because > of the scenario I'm stuck with. > >> > >> To communicate there is only 1 data line, rx/tx tied together > with a diode protecting the tx. No RTS/CTS handshaking nothing.. > >> > >> So the ecu can't process the next byte of info, without you > pulling the 2 bytes back. I wish this was standard, but even the > baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard > spot with this.. > >> > >> in.read(data , 0, 2); > >> ^ would the above wait till the timeout to read 2 bytes ? or > read 1 byte wait for the 2nd ? or just read the 1 ?? > >> > >> On 03/07/11 18:50, jfh at greenhousepc.com > wrote: > >>> Curtis, > >>> > >>> No, I assume he means a real queue, not just "don't read all > the bytes at once." However, if you know you can process some > number of requests in some amount of time, allowing data to pile > up (receiver FIFO space permitting) can be a valid strategy. > Inserting gobs of Thread.yield() and notify() can help pep things > up as well. > >>> -- > >>> Julie Haugh > >>> Senior Design Engineer > >>> greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 13:12:03 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 12:12:03 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> Message-ID: <4D768D93.1030504@gmail.com> So I looked over the Tunerpro log again today.. is it me or does it appear to be reusing values ? On 03/08/11 03:00, jfh at greenhousepc.com wrote: > Curtis, > > At the risk of being told "No, they really say it can be done", 30 > sensors is 30 * 3 character times (are you sure it's not a single byte > response?). At 1953 baud, a single character time is 10 bits * (1 / > 1953) seconds, or 15.4ms as Bob pointed out. 30 * 15.4ms is 460ms, > and that assumes everything works perfectly, no turnaround times, etc. > > If you can come up with some other way to make the math work, I'd love > to hear it. > > Short and sweet -- just because TunerPro can talk to an ECM/ECU that > is running faster than 1953 baud doesn't mean your Mitsubishi (or > whatever car you've got that runs at 1953 baud) runs at that faster > baud rate. > > Also, are you sure your data cable is correct? What cable are you > using? What's the schematic? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 2:33 am > To: rxtx at qbang.org > > I am going to try a couple things today and hopefully figure > something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than > 25ms. > I've exchanged some emails with the author and it is a native C, > polling, no events just timeouts. > > Kusta thanks for the FTDI notice, I believe that is tunable, > however I > have a particular user using a Keyspan converter and verified > sampling > rate with 'TunerPro' and its just off the charts. > > Chris thank you, I'll look into the queing. > > On 03/07/11 23:02, Bob Jacobsen wrote: > > If you're transferring three bytes total at 1953 baud, it's going > to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to > wait 20msec to get the data back instead of 15.4 msec doesn't seem > to be as big a problem as you're making it sound. > > > > Bob > > > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > > > >> I guess I'm gunna need some serious help with this then, because > of the scenario I'm stuck with. > >> > >> To communicate there is only 1 data line, rx/tx tied together > with a diode protecting the tx. No RTS/CTS handshaking nothing.. > >> > >> So the ecu can't process the next byte of info, without you > pulling the 2 bytes back. I wish this was standard, but even the > baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard > spot with this.. > >> > >> in.read(data , 0, 2); > >> ^ would the above wait till the timeout to read 2 bytes ? or > read 1 byte wait for the 2nd ? or just read the 1 ?? > >> > >> On 03/07/11 18:50, jfh at greenhousepc.com > wrote: > >>> Curtis, > >>> > >>> No, I assume he means a real queue, not just "don't read all > the bytes at once." However, if you know you can process some > number of requests in some amount of time, allowing data to pile > up (receiver FIFO space permitting) can be a valid strategy. > Inserting gobs of Thread.yield() and notify() can help pep things > up as well. > >>> -- > >>> Julie Haugh > >>> Senior Design Engineer > >>> greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 13:51:13 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 13:51:13 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308135113.8ef0e5b4a80cef441275a6330ffad77d.a5fff5bbc7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From bob_jacobsen at lbl.gov Tue Mar 8 14:14:57 2011 From: bob_jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 8 Mar 2011 14:14:57 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D76848F.5080809@gmail.com> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> Message-ID: <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > Tunerpro log : http://www.ds-map.net/tunerpro_log.csv It's only reading one sensor per line. Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT changed in lines 16 and 40; every 24 lines but at a different phase. GramsRev in lines 23 and 47; every 24 lines, at yet another phase. Looks like (69-1) readings in 1.30 seconds = 19msec per reading. Arithmetic still works! Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From hakcenter at gmail.com Tue Mar 8 14:27:12 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 13:27:12 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> Message-ID: <4D769F30.9050807@gmail.com> Thank you guys, cause I was really worried there. I guess another win for math today hahaha. So what is the imposed latency that rxtx has ? maybe 5-10ms ? On 03/08/11 13:14, Bob Jacobsen wrote: > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > It's only reading one sensor per line. > > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT changed in lines 16 and 40; every 24 lines but at a different phase. GramsRev in lines 23 and 47; every 24 lines, at yet another phase. > > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. Arithmetic still works! > > Bob > -- > Bob Jacobsen, LBNL > Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue Mar 8 14:07:24 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Mar 2011 14:07:24 -0700 (MST) Subject: [Rxtx] Latency Woes In-Reply-To: <4D769F30.9050807@gmail.com> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> <4D769F30.9050807@gmail.com> Message-ID: Hi Curtis While not your exact question, a simple test I performed can give you a ballpark idea. Writing a byte to a loopback at 9600 baud and displaying elapsed time on the data available event takes ~10 ms round trip in a large application. There are occasional 20 ms latencies. I used a typical linux desktop to try it just now without any special considerations. Windows NT was a little faster - maybe 8 ms - when I tried several years ago. On Tue, 8 Mar 2011, Curtis Hacker wrote: > Thank you guys, cause I was really worried there. I guess another win for > math today hahaha. So what is the imposed latency that rxtx has ? maybe > 5-10ms ? > > On 03/08/11 13:14, Bob Jacobsen wrote: >> On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >>> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> It's only reading one sensor per line. >> >> Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT >> changed in lines 16 and 40; every 24 lines but at a different phase. >> GramsRev in lines 23 and 47; every 24 lines, at yet another phase. >> >> Looks like (69-1) readings in 1.30 seconds = 19msec per reading. >> Arithmetic still works! >> >> Bob >> -- >> Bob Jacobsen, LBNL >> Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >> JacobsenRG >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Wei.Shen at Honeywell.com Tue Mar 8 15:15:32 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Tue, 8 Mar 2011 17:15:32 -0500 Subject: [Rxtx] [rxtx] disconnect event Message-ID: <83B3B1411349194D9D05821CEF48E78C02284B17@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 16:05:12 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 16:05:12 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 16:26:15 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 15:26:15 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> References: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> Message-ID: <4D76BB17.2090305@gmail.com> So if I could get the baud up 15625, theoretical maximum latency is 1.92ms ? Basically 500 samples/sec ? 125000, theoretical maximum latency is 0.24ms ? Basically 4167 samples/sec ? Keeping the protocol the same. On 03/08/11 15:05, jfh at greenhousepc.com wrote: > Curtis, > > It's nowhere near that bad. I'd measured it once before, and I > believe it's sub-millisecond. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 3:27 pm > To: rxtx at qbang.org > > Thank you guys, cause I was really worried there. I guess another win > for math today hahaha. So what is the imposed latency that rxtx has ? > maybe 5-10ms ? > > On 03/08/11 13:14, Bob Jacobsen wrote: > > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > > It's only reading one sensor per line. > > > > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 > lines. IAT changed in lines 16 and 40; every 24 lines but at a > different phase. GramsRev in lines 23 and 47; every 24 lines, at > yet another phase. > > > > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. > Arithmetic still works! > > > > Bob > > -- > > Bob Jacobsen, LBNL > > Bob_Jacobsen at lbl.gov > +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Tue Mar 8 17:40:36 2011 From: jredman at ergotech.com (Jim Redman) Date: Tue, 08 Mar 2011 17:40:36 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D76BB17.2090305@gmail.com> References: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> <4D76BB17.2090305@gmail.com> Message-ID: <4D76CC84.9040307@ergotech.com> How long does it take the device to generate a response? Increasing the baud rate may not help you much if the device takes a significant amount of time to process the request. On 03/08/2011 04:26 PM, Curtis Hacker wrote: > So if I could get the baud up > 15625, theoretical maximum latency is 1.92ms ? Basically 500 samples/sec ? > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 samples/sec ? > > Keeping the protocol the same. > > On 03/08/11 15:05, jfh at greenhousepc.com wrote: >> Curtis, >> >> It's nowhere near that bad. I'd measured it once before, and I >> believe it's sub-millisecond. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker > >> Date: Tue, March 08, 2011 3:27 pm >> To: rxtx at qbang.org >> >> Thank you guys, cause I was really worried there. I guess another win >> for math today hahaha. So what is the imposed latency that rxtx has ? >> maybe 5-10ms ? >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> > It's only reading one sensor per line. >> > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 >> lines. IAT changed in lines 16 and 40; every 24 lines but at a >> different phase. GramsRev in lines 23 and 47; every 24 lines, at >> yet another phase. >> > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. >> Arithmetic still works! >> > >> > Bob >> > -- >> > Bob Jacobsen, LBNL >> > Bob_Jacobsen at lbl.gov >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 jfh at greenhousepc.com Tue Mar 8 17:58:24 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 17:58:24 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 18:06:04 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 18:06:04 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 18:14:14 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 17:14:14 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> References: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> Message-ID: <4D76D466.7060303@gmail.com> I can edit the ECU eeprom to change the baud rate divisor to bump it up from 1953, to 15625 or 125000. But as Jim asked how fast the device can respond.. not very fast in its stock form. I can recode a lot of the eeprom for the ecu to alter the ecus baud rate, and put the response code into its own interrupt. I just wanted to make sure that in order to lower latency and increase sampling rate. I have to increase the baud rate of the ecu and the user right ? Or change the protocol.. to respond with more sensors per request. On 03/08/11 16:58, jfh at greenhousepc.com wrote: > Unless the ECU can auto-detect the baud rate, it won't even work. > > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Jim Redman > > Date: Tue, March 08, 2011 6:40 pm > To: rxtx at qbang.org > > How long does it take the device to generate a response? > > Increasing the baud rate may not help you much if the device takes a > significant amount of time to process the request. > > > On 03/08/2011 04:26 PM, Curtis Hacker wrote: > > So if I could get the baud up > > 15625, theoretical maximum latency is 1.92ms ? Basically 500 > samples/sec ? > > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 > samples/sec ? > > > > Keeping the protocol the same. > > > > On 03/08/11 15:05, jfh at greenhousepc.com > wrote: > >> Curtis, > >> > >> It's nowhere near that bad. I'd measured it once before, and I > >> believe it's sub-millisecond. > >> -- > >> Julie Haugh > >> Senior Design Engineer > >> greenHouse Computers, LLC // jfh at greenhousepc.com > > >> ; // > greenHousePC on Skype > >> > >> > >> -------- Original Message -------- > >> Subject: Re: [Rxtx] Latency Woes > >> From: Curtis Hacker > > >> Date: Tue, March 08, 2011 3:27 pm > >> To: rxtx at qbang.org > >> > >> Thank you guys, cause I was really worried there. I guess > another win > >> for math today hahaha. So what is the imposed latency that rxtx > has ? > >> maybe 5-10ms ? > >> > >> On 03/08/11 13:14, Bob Jacobsen wrote: > >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > >> > It's only reading one sensor per line. > >> > > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 > >> lines. IAT changed in lines 16 and 40; every 24 lines but at a > >> different phase. GramsRev in lines 23 and 47; every 24 lines, at > >> yet another phase. > >> > > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. > >> Arithmetic still works! > >> > > >> > Bob > >> > -- > >> > Bob Jacobsen, LBNL > >> > Bob_Jacobsen at lbl.gov > > >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > >> > > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Tue Mar 8 18:19:14 2011 From: jredman at ergotech.com (Jim Redman) Date: Tue, 08 Mar 2011 18:19:14 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> References: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> Message-ID: <4D76D592.9000802@ergotech.com> I'm no expert on this, but isn't the underlying ODB-II CAN bus or something similar. They always seem to require a dongle that converts to something. I know you can get serial, bluetooth, USB, etc. converters. I've seen serial dongles that claim multiple baud rates, so I suspect that whatever's providing the conversion may significantly affect the performance. A big second on the required timing comment. I suspect some intelligent consideration of what values change quickly (RPM, Speed, maybe things like fuel pressure) and read values like fuel levels, coolant temps, etc. much less frequently. On 03/08/2011 06:06 PM, jfh at greenhousepc.com wrote: > Curtis, > > You can't just increase the baud rate and have the device adapt to that > rate. Embedded systems tend to have their communications parameters > either hard coded in a memory location or else they are using a hardware > timebase. You're welcome to try increasing the baud rate, but there is > no guarantee it will even work. > > Whoever designed the ECU probably selected the baud rate for a good > reason. My suggestion would be to look at how the sensor values are all > laid out and go from there. Also, look at what the sensor represent and > consider the physical properties of what is being measured. It's > extremely unlikely that, for example, the coolant temperature is going > to rise more than 1* per second. If that much. Some values might change > more often, but do they really matter on a sub-second measurement basis? > > Part of software =engineering= is understanding the problem. Anyone can > sling code in the hope it works. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 5:26 pm > To: rxtx at qbang.org > > So if I could get the baud up > 15625, theoretical maximum latency is 1.92ms ? Basically 500 > samples/sec ? > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 > samples/sec ? > > Keeping the protocol the same. > > On 03/08/11 15:05, jfh at greenhousepc.com wrote: >> Curtis, >> >> It's nowhere near that bad. I'd measured it once before, and I >> believe it's sub-millisecond. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker > > >> Date: Tue, March 08, 2011 3:27 pm >> To: rxtx at qbang.org >> >> Thank you guys, cause I was really worried there. I guess >> another win >> for math today hahaha. So what is the imposed latency that >> rxtx has ? >> maybe 5-10ms ? >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> > It's only reading one sensor per line. >> > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every >> 24 lines. IAT changed in lines 16 and 40; every 24 lines but >> at a different phase. GramsRev in lines 23 and 47; every 24 >> lines, at yet another phase. >> > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per >> reading. Arithmetic still works! >> > >> > Bob >> > -- >> > Bob Jacobsen, LBNL >> > Bob_Jacobsen at lbl.gov >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > ------------------------------------------------------------------------ > _______________________________________________ > Rxtx mailing list > Rxtx 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 jfh at greenhousepc.com Tue Mar 8 18:32:28 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 18:32:28 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 19:45:00 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 18:45:00 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> References: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> Message-ID: <4D76E9AC.8050909@gmail.com> Julie, I really am not looking at the practicality of it. I was just wondering if that is how it works. I don't know a whole lot about rs232, which is the main reason I've been on this mailing list for a couple years. I have full control over the ecu eeprom code, I can change its baud rate, I can re-write the logging interface, I could update the ADC's on the ecu in the interface so that when you request said sensor it updates the ADC then replies it. But I wanted to know if the underlying issue with a 2mhz/8mhz processor is the baud rate keeping sampling down ? On 03/08/11 17:32, jfh at greenhousepc.com wrote: > Curtis, > > You also have to look at the response time of the sensor itself. > > Seriously -- look at what the sensors are reporting and determine if > the underlying physical property can actually change that rapidly. > And even if it can, do you really need to know that. > > I built drag bikes in the 70's and I drive sports cars in my old age. > You don't really need millisecond sampling rates for every single last > sensor coming out of the engine. Boost pressure, fuel pressure, > manifold pressure and RPMs are probably high frequency sensors if you > want to tweak the motor for turbo lag or something, but other than > that, are you really going to be able to make sense of all that data? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 7:14 pm > To: rxtx at qbang.org > > I can edit the ECU eeprom to change the baud rate divisor to bump > it up from 1953, to 15625 or 125000. But as Jim asked how fast the > device can respond.. not very fast in its stock form. > > I can recode a lot of the eeprom for the ecu to alter the ecus > baud rate, and put the response code into its own interrupt. > > I just wanted to make sure that in order to lower latency and > increase sampling rate. I have to increase the baud rate of the > ecu and the user right ? Or change the protocol.. to respond with > more sensors per request. > > On 03/08/11 16:58, jfh at greenhousepc.com wrote: >> Unless the ECU can auto-detect the baud rate, it won't even work. >> >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Jim Redman > > >> Date: Tue, March 08, 2011 6:40 pm >> To: rxtx at qbang.org >> >> How long does it take the device to generate a response? >> >> Increasing the baud rate may not help you much if the device >> takes a >> significant amount of time to process the request. >> >> >> On 03/08/2011 04:26 PM, Curtis Hacker wrote: >> > So if I could get the baud up >> > 15625, theoretical maximum latency is 1.92ms ? Basically 500 >> samples/sec ? >> > 125000, theoretical maximum latency is 0.24ms ? Basically >> 4167 samples/sec ? >> > >> > Keeping the protocol the same. >> > >> > On 03/08/11 15:05, jfh at greenhousepc.com >> wrote: >> >> Curtis, >> >> >> >> It's nowhere near that bad. I'd measured it once before, and I >> >> believe it's sub-millisecond. >> >> -- >> >> Julie Haugh >> >> Senior Design Engineer >> >> greenHouse Computers, LLC // jfh at greenhousepc.com >> >> >> ; // >> greenHousePC on Skype >> >> >> >> >> >> -------- Original Message -------- >> >> Subject: Re: [Rxtx] Latency Woes >> >> From: Curtis Hacker > > >> >> Date: Tue, March 08, 2011 3:27 pm >> >> To: rxtx at qbang.org >> >> >> >> >> Thank you guys, cause I was really worried there. I guess >> another win >> >> for math today hahaha. So what is the imposed latency that >> rxtx has ? >> >> maybe 5-10ms ? >> >> >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> >> > It's only reading one sensor per line. >> >> > >> >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; >> every 24 >> >> lines. IAT changed in lines 16 and 40; every 24 lines but at a >> >> different phase. GramsRev in lines 23 and 47; every 24 >> lines, at >> >> yet another phase. >> >> > >> >> > Looks like (69-1) readings in 1.30 seconds = 19msec per >> reading. >> >> Arithmetic still works! >> >> > >> >> > Bob >> >> > -- >> >> > Bob Jacobsen, LBNL >> >> > Bob_Jacobsen at lbl.gov >> >> >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Rxtx mailing list >> >> > Rxtx at qbang.org >> >> >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > ------------------------------------------------------------------------ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 20:43:11 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 20:43:11 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308204311.8ef0e5b4a80cef441275a6330ffad77d.e9b135168c.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From andrea.antonello at gmail.com Wed Mar 9 06:50:07 2011 From: andrea.antonello at gmail.com (andrea antonello) Date: Wed, 9 Mar 2011 14:50:07 +0100 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> References: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> Message-ID: Has anyone tried the lib? I am not sure if it is appropriate to write to the list about this, if not, I apologize. I wanted to try your fork out for our application which is an eclipse rcp plugin based one. It has been easy to substitute the 6 plugins with your library (that is one of the things I like). But then when I run it, it tries to load it from: ---- Loading: /tmp/libNRJavaSerial_moovida_0/libNRJavaSerial.so Trying to load: NRJavaSerial Trying to load: libNRJavaSerial Trying to load: rxtxSerial ---- So it is extracting the native lib to a tmp folder. But that one is not in the library path, so it fails. Is there any docs to try the lib out? Thanks, Andrea On Mon, Mar 7, 2011 at 11:54 PM, wrote: > Aaron, > > It should be possible for an Android to do BlueTooth serial.? If I were > looking for a serial solution, that's how I'd go. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on > Skype > > -------- Original Message -------- > Subject: [SPAM] Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > papercuts! > From: Aaron Wolfe > Date: Mon, March 07, 2011 4:31 pm > To: rxtx at qbang.org > > On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR > wrote: >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> >> * Self deployment of native libraries ( all native code is stored >> inside the jar and deployed at runtime). No more manual install of >> native code. >> * Arm Cortex support (Gumstix) >> * Android Support (requires a rooted phone for now) >> * Google Code (SVN) repository for easy code and jar access >> * Single makefile compile (simplifies the compilation of project binaries) >> * Ant build script for jar creation >> * Removal of partialy implemented code to streamline the lib for just >> serial port access >> * Full Eclipse integration, for testing application code against sources. >> >> And a bunch of bug fixes: >> >> * Fixed the memory access error that causes OSX to crash the JVM when >> serial.close() is cvalled >> * Fixed the windows serial port zombie bind that prevents re-accessing >> serial ports when exiting on an exception >> * Fixed erronious printouts of native library mis-match >> >> To check it out, take a look at our page here: >> >> http://code.google.com/p/nrjavaserial/ > > This is interesting, getting the native libs set up has been an issue > for some of my users. Will have to check it out. > > Out of curiosity, what Android devices provide a serial port? Or are > there some that allow USB host mode and then a usb-serial adapter? I > have only an Android cell phone, don't think it can do anything serial > but would love to be wrong 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 Cougar at CasaDelGato.Com Wed Mar 9 10:02:24 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 09 Mar 2011 09:02:24 -0800 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> References: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> Message-ID: <4D77B2A0.8020004@CasaDelGato.Com> On 3/7/2011 2:54 PM, jfh at greenhousepc.com wrote: > Aaron, > > It should be possible for an Android to do BlueTooth serial. If I > were looking for a serial solution, that's how I'd go. Actually, I can't figure out WHY you would need RxTx on an Android device. The built in bluetooth support works just fine with a serial-bluetooth converter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Mar 1 00:54:17 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 09:54:17 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> Message-ID: Adrian, had a look at your code/rewrite and it looks rather clean/nice. I was looking at the code to gain insight (not related to the rewrite) into what is involved in serial port programming in Windows. Or rather, to refresh my memory and see how others have done, because I've been there done that. So my questions are just to satisfy my curiosity, not to criticize or suggest improvements. 1) It looks like a new thread (EventMonitor) is created for each Serial port, is that correct? Many people seem to try to avoid using many threads in this sort of situation, and like to use something like unix select(). I personally find using threads more natural and better impedance match to the problem being solved here. I guess 'many people' above refers to those implementing thousands of connections and who cannot live with the overhead and limited number of threads available. 2) The EventMonitor basically polls for events at 50 msec interval? 3) There is a comment in the source code near the sleep(50) : // Sufficient up to 19200 baud I'm sure you thought about this carefully, so again not criticizing, but seeking to understand how or why, because at 50 msec would seem to limit through in some cases. Like if you send one byte and need to wait for one to return, then this limits speed to 200 chars/sec? 4) I've done something similar to a few years back from Java using JNI to access Win32 API serial port, and I seem to recall that I had threading issues ie when I submitted a read (ReadFile) and there was no data coming in, the thread would not only block but also consume a lot of CPU cycles ie it was not sleeping properly inside the ReadFile call when the serial port blocked. Im a bit fuzzy about the details after five years, so my question is have you checked if there an issue here? 5) AFAIK the select() on Windows does not work serial ports but there is some other mechanism (events?) to implement the same functionality, did you consider that? Probably, so you decided against it, why? br Kusti From adrian.crum at sandglass-software.com Tue Mar 1 04:13:34 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:13:34 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: References: Message-ID: <4D6CD4DE.7040501@sandglass-software.com> The javax.comm API specification requires one event monitor thread per port. I don't like the idea of having a thread per port either, but one of the rewrite's design goals is strict conformance to the specification. The 50 mS polling interval is just a placeholder. The final design of that is yet to be decided. In Windows, you have two choices for I/O: overlapped and non-overlapped. In overlapped I/O a thread is blocked, waiting for something to happen. In non-overlapped I/O a thread does not block. I chose non-overlapped I/O to avoid thread blocking at the OS level - instead, the thread blocking is kept in Java. -Adrian On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > Adrian, > > had a look at your code/rewrite and it looks rather clean/nice. > > I was looking at the code to gain insight (not related to the > rewrite) into what is involved in serial port programming > in Windows. Or rather, to refresh my memory and see how others have > done, because I've been there done that. > > So my questions are just to satisfy my curiosity, not to criticize > or suggest improvements. > > 1) It looks like a new thread (EventMonitor) is created for > each Serial port, is that correct? > > Many people seem to try to avoid using many threads in this sort > of situation, and like to use something like unix select(). > I personally find using threads more natural and better impedance > match to the problem being solved here. I guess 'many people' above > > refers to those implementing thousands of connections and > who cannot live with the overhead and limited number of threads > available. > > 2) The EventMonitor basically polls for events at 50 msec interval? > > 3) There is a comment in the source code near the sleep(50) : > > // Sufficient up to 19200 baud > > > I'm sure you thought about this carefully, so again not > criticizing, but seeking to understand how or why, because > at 50 msec would seem to limit through in some cases. Like > if you send one byte and need to wait for one to return, > then this limits speed to 200 chars/sec? > > 4) I've done something similar to a few years back from > Java using JNI to access Win32 API serial port, and > I seem to recall that I had threading issues ie when > I submitted a read (ReadFile) and there was no data coming > in, the thread would not only block but also consume a > lot of CPU cycles ie it was not sleeping properly inside > the ReadFile call when the serial port blocked. > > Im a bit fuzzy about the details after five years, so my question is > have you checked if there an issue here? > > > 5) AFAIK the select() on Windows does not work serial ports > but there is some other mechanism (events?) to implement the > same functionality, did you consider that? Probably, so you > decided against it, why? > > > br Kusti > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Tue Mar 1 04:25:23 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:25:23 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C2E90.9010601@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > My question would be: Why would you do that? The rewrite does > most of the work for you - all you have to do is implement > two C++ virtual classes and two C++ functions. You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? I just took a short look, maybe it could be discussed further, but I don't think I like it much. BTW, the main interface defined there is called gnu.io.Dispatcher? I thought the package names should be used in a way to avoid clashes, e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name space authority :)). > In Windows that took me a few hours. where is the implementation? I found commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp with things like const bool SerialPortImpl::isDataAvailable() const { // Needs implementation return true; } and timeouts.ReadIntervalTimeout = MAXDWORD;* timeouts.ReadTotalTimeoutMultiplier = 0; timeouts.ReadTotalTimeoutConstant = 0; timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 0; if (!SetCommTimeouts(hComm, &timeouts)) throw IOException(); which seems to be oversimplified or some prototype only? I think (and I wrote about this already in the past years) that correct timeout handling is one of the challenges, so I think this should be prototyped first - for each system flavor - before cementation of the (JNI-) interfaces. Personally, I would vote to form it in a way allowing to be implemented on embedded devices, for example. Another big challenge is to prove a rewrite fully working (and probably compatible to the old implementation) on "all" the supported OSes. Not a big problem for linux and windows, just use some thousand lines test code, test drivers and serial loopbacks etc, but for the exotic platforms, probably a high number of, this probably won't be too easy... (there are more challenges, such as being comfortable and threadsafe [are read and write permitted at the same time?], detailed and helpful exceptions on user API level [not necessarily on JNI/JNA layer], how to have a configurable threadsafe logging/tracing [maybe also from native code to assist porting / testing on exotic OSes, such as OSes where the developers have no direct access too, which can be quite hard to usually leads to good log messages], just to name a few.). So even it might seem easy for one platform and I agree with Micheal that > > * yay! let's start a rewrite is unlikely to succeede soon... However, when considering this, before IMHO a powerful Java API has to be defined, because according to my experiences for implementing non-trivial protocols InputStream/OutputStream might not be comfortable/powerfull enough (eventually I consider both wrong) and have some InputStream derivation available as wrapper (so applications can use InputStream and whatever high-level-API they want). The JNI interface shall make such a powerful implementation possible, thus the interface of it is driving the JNI interface design and thus I think it had to be done first. All this surely requires much work: agreements on the APIs, safeness for the users, design, documentation, all the implementations and the testing. As long as such bug amount of work cannot be spent, for example if some employee would get half a year time paid for it or so :-), probably it is unlikely to progress on this. Otherwise, I'm afraid, patches, improvements, new design ideas and even rewrites wouldn't become complete and thus won't form a new rxtx version (3.0); thus either collect dust in some forgotten CVS branch or could generate a split... > I can't imagine other ports taking > much longer than that - especially since POSIX-based code can > be shared between ports. Things are more complex than they seem to be... I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select on serial ports isn't supported; maybe it is non-trivial to "map" (like mapping select() to WaitForMultipleObjects() which might have different semantics etc.) or maybe some different approach has to be used. A system may have POSIX like termios interfaces but not support timeouts or have any other interoperability bug... You never run out of things that can go wrong. And if something can go wrong, it will... :-) Or, as Michael wrote: > > I seriously don't believe anyone will come up with anything better anytime soon. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue Mar 1 04:39:37 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:39:37 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com><13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED6B@COSNPREXC3.usr.ingenico.loc> > 3. Write all of the native (or non-native) code to implement > the native interface. > > Is that correct? If yes, how is that easier than the simple > implementation the current rewrite design uses? To have it complete, reliable, traceable, maintainable and well tested, it is much more work, I'm afraid. A prototype can be done within a few days (maybe on one day), but getting it right (including a passed review) IMHO is a completely different story. In the end you may end up with an average of ten lines per day, when assuming four major native packs (common, win, mac, termios/select) with let's say just 5000 lines each (with logging messages and detailed exceptions this is not much) we would have to estimate a total effort of nine man-years (20000/10/220)... oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 04:40:18 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:40:18 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6CDB22.9070401@sandglass-software.com> Every journey begins with a single step. -Adrian On 3/1/2011 3:25 AM, Steffen DETTMER wrote: > * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> My question would be: Why would you do that? The rewrite does >> most of the work for you - all you have to do is implement >> two C++ virtual classes and two C++ functions. > You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? > I just took a short look, maybe it could be discussed further, > but I don't think I like it much. > BTW, the main interface defined there is called gnu.io.Dispatcher? > I thought the package names should be used in a way to avoid clashes, > e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name > space authority :)). > >> In Windows that took me a few hours. > where is the implementation? > I found > commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp > with things like > > const bool SerialPortImpl::isDataAvailable() const > { > // Needs implementation > return true; > } > > and > > timeouts.ReadIntervalTimeout = MAXDWORD;* > timeouts.ReadTotalTimeoutMultiplier = 0; > timeouts.ReadTotalTimeoutConstant = 0; > timeouts.WriteTotalTimeoutMultiplier = 0; > timeouts.WriteTotalTimeoutConstant = 0; > if (!SetCommTimeouts(hComm,&timeouts)) > throw IOException(); > > which seems to be oversimplified or some prototype only? > > I think (and I wrote about this already in the past years) that correct > timeout handling is one of the challenges, so I think this should be > prototyped first - for each system flavor - before cementation of the > (JNI-) interfaces. Personally, I would vote to form it in a way allowing > to be implemented on embedded devices, for example. > > Another big challenge is to prove a rewrite fully working (and probably > compatible to the old implementation) on "all" the supported OSes. Not a > big problem for linux and windows, just use some thousand lines test > code, test drivers and serial loopbacks etc, but for the exotic > platforms, probably a high number of, this probably won't be too easy... > (there are more challenges, such as being comfortable and threadsafe > [are read and write permitted at the same time?], detailed and helpful > exceptions on user API level [not necessarily on JNI/JNA layer], how to > have a configurable threadsafe logging/tracing [maybe also from native > code to assist porting / testing on exotic OSes, such as OSes where the > developers have no direct access too, which can be quite hard to usually > leads to good log messages], just to name a few.). > > So even it might seem easy for one platform and I agree with Micheal > that > >>> * yay! let's start a rewrite > is unlikely to succeede soon... > > However, when considering this, before IMHO a powerful Java API has to > be defined, because according to my experiences for implementing > non-trivial protocols InputStream/OutputStream might not be > comfortable/powerfull enough (eventually I consider both wrong) and have > some InputStream derivation available as wrapper (so applications can > use InputStream and whatever high-level-API they want). > The JNI interface shall make such a powerful implementation possible, > thus the interface of it is driving the JNI interface design and thus I > think it had to be done first. > > All this surely requires much work: agreements on the APIs, safeness for > the users, design, documentation, all the implementations and the > testing. As long as such bug amount of work cannot be spent, for example > if some employee would get half a year time paid for it or so :-), > probably it is unlikely to progress on this. > > Otherwise, I'm afraid, patches, improvements, new design ideas and even > rewrites wouldn't become complete and thus won't form a new rxtx version > (3.0); thus either collect dust in some forgotten CVS branch or could > generate a split... > >> I can't imagine other ports taking >> much longer than that - especially since POSIX-based code can >> be shared between ports. > Things are more complex than they seem to be... > > I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select > on serial ports isn't supported; maybe it is non-trivial to "map" (like > mapping select() to WaitForMultipleObjects() which might have different > semantics etc.) or maybe some different approach has to be used. A > system may have POSIX like termios interfaces but not support timeouts > or have any other interoperability bug... > You never run out of things that can go wrong. And if something can go > wrong, it will... :-) > > Or, as Michael wrote: > >>> I seriously don't believe anyone will come up with anything better > anytime soon. > > oki, > > Steffen > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Kustaa.Nyholm at planmeca.com Tue Mar 1 04:57:02 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 13:57:02 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: On 3/1/11 13:13, "Adrian Crum" wrote: >The javax.comm API specification requires one event monitor thread per >port. I don't like the idea of having a thread per port either, but one >of the rewrite's design goals is strict conformance to the specification. Ah, had not spotted that requirement. > >The 50 mS polling interval is just a placeholder. The final design of >that is yet to be decided. > >In Windows, you have two choices for I/O: overlapped and non-overlapped. >In overlapped I/O a thread is blocked, waiting for something to happen. >In non-overlapped I/O a thread does not block. I chose non-overlapped >I/O to avoid thread blocking at the OS level - instead, the thread >blocking is kept in Java. > >-Adrian thanks for the explanation. br Kusti From iqzw2r602 at sneakemail.com Tue Mar 1 05:08:17 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:08:17 +1100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <32684-1298981297-704398@sneakemail.com> This reminds me of a nasty problem I had with overlapped I/O on windows with jpathwatch. You can't start an I/O request in one thread and then do the check if that request completed in another thread. Very strange things happen when you attempt that; made me change the design of the Windows implementation quite drastically (one thread on a command queue that executes requests from other threads instead of letting them wildly call into GetOverlappedResult()). Out of curiosity: Did you come across that too? Or are all requests handled in the same thread they're issued? Cheers, Uwe On Tue, Mar 1, 2011 at 10:13 PM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > The javax.comm API specification requires one event monitor thread per > port. I don't like the idea of having a thread per port either, but one of > the rewrite's design goals is strict conformance to the specification. > > The 50 mS polling interval is just a placeholder. The final design of that > is yet to be decided. > > In Windows, you have two choices for I/O: overlapped and non-overlapped. In > overlapped I/O a thread is blocked, waiting for something to happen. In > non-overlapped I/O a thread does not block. I chose non-overlapped I/O to > avoid thread blocking at the OS level - instead, the thread blocking is kept > in Java. > > -Adrian > > > On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > >> Adrian, >> >> had a look at your code/rewrite and it looks rather clean/nice. >> >> I was looking at the code to gain insight (not related to the >> rewrite) into what is involved in serial port programming >> in Windows. Or rather, to refresh my memory and see how others have >> done, because I've been there done that. >> >> So my questions are just to satisfy my curiosity, not to criticize >> or suggest improvements. >> >> 1) It looks like a new thread (EventMonitor) is created for >> each Serial port, is that correct? >> >> Many people seem to try to avoid using many threads in this sort >> of situation, and like to use something like unix select(). >> I personally find using threads more natural and better impedance >> match to the problem being solved here. I guess 'many people' above >> >> refers to those implementing thousands of connections and >> who cannot live with the overhead and limited number of threads >> available. >> >> 2) The EventMonitor basically polls for events at 50 msec interval? >> >> 3) There is a comment in the source code near the sleep(50) : >> >> // Sufficient up to 19200 baud >> >> >> I'm sure you thought about this carefully, so again not >> criticizing, but seeking to understand how or why, because >> at 50 msec would seem to limit through in some cases. Like >> if you send one byte and need to wait for one to return, >> then this limits speed to 200 chars/sec? >> >> 4) I've done something similar to a few years back from >> Java using JNI to access Win32 API serial port, and >> I seem to recall that I had threading issues ie when >> I submitted a read (ReadFile) and there was no data coming >> in, the thread would not only block but also consume a >> lot of CPU cycles ie it was not sleeping properly inside >> the ReadFile call when the serial port blocked. >> >> Im a bit fuzzy about the details after five years, so my question is >> have you checked if there an issue here? >> >> >> 5) AFAIK the select() on Windows does not work serial ports >> but there is some other mechanism (events?) to implement the >> same functionality, did you consider that? Probably, so you >> decided against it, why? >> >> >> br Kusti >> >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 05:37:07 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:37:07 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <1142-1298983027-957144@sneakemail.com> On Tue, Mar 1, 2011 at 1:32 PM, Adrian Crum wrote: > Just to make sure I'm understanding you correctly, anyone porting RxTx to > a new platform would have to do the following: > > 1. Write their own Java implementation of an abstract Dispatcher class. > yep. I'd probably put all my calls to native OS wrappers in there two, looks the most straight-forward to me. > 2. Write a native (JNI or JNA) interface for the abstract class > implementation. > yes. For POSIX you'd probably only write one piece of code that provides implementations for open(), close(), and friends. You can compile that on all posix platforms (yeah, the devil is in the detail, but it's very little code, still). So this does open() (when using ***, but you can also use +++) // Unix.java class Unix{ public static native int open(String filename, int flags, int mode); .... } // Unix.cpp JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) { const char* pathname = env->GetStringUTFChars(jpathname, 0); if(pathname == 0) return -1; // java throws an out of memory error in this case int result = open(pathname, flags, mode); Unix_cacheErrno(); // handle interference between JVM and errno; env->ReleaseStringUTFChars(jpathname, pathname); return result; } .... 3. Write all of the native (or non-native) code to implement the native > interface. > Not sure what you mean by that. I've done the OS wrappers in step 2. step 1. implements that Dispatcher. What else do I need? > Is that correct? If yes, how is that easier than the simple implementation > the current rewrite design uses? > Yes, except for 3 (see above). How it is easier: I can debug the Java code directly. I can step from the read() call of an input stream directly into the guts of the RXTX implementation on my platform and see e.g. why it's hanging, because I see all the way up the call stack right where it calls Unix.read(). You can't easily do that with a fat native library, especially if you have no second set of devtools installed (the ones for native development). And I bet anyone knowing both languages can write it faster in Java, with less bugs. > On a side note: there is no requirement to write native code using C++. If > C++ is a real obstacle to adoption, then regular C could be used instead. In > that case, there would be a Dispatcher.c file that contains function > protoypes that need to be implemented. Dispatcher.c would still maintain the > same role as Dispatcher.cpp - which is to shield native code developers from > the details of JNI. Just build out the missing functions using C data types > and you're ready to go. > As I said, whatever works for you. Java works for me better than C++ in this case... Cheers, Uwe -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Mar 1 08:26:41 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 16:26:41 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> > The javax.comm API specification requires one event monitor > thread per port. Where does it require this? Do you mean "All the events received by this listener are generated by one dedicated thread that belongs to the SerialPort object. "? I think this is an implementation detail, isn't it? At least it is mentioned after "The current implementation only allows one listener per SerialPort". A bit bad that javadoc does not distinguish between API spec and implementation documentation. Also I don't think that TooManyListenersException MUST be thrown (I think it CAN be thrown). > I don't like the idea of having a thread per > port either, but one of the rewrite's design goals is strict > conformance to the specification. (but not necessarily on JNI layer) > The 50 mS polling interval is just a placeholder. The final > design of that is yet to be decided. I though no polling would be wanted; what could be the placeholder stand for? Do you mean a different interval duration or do you mean something completely different? > In Windows, you have two choices for I/O: overlapped and > non-overlapped. > In overlapped I/O a thread is blocked, waiting for something > to happen. > In non-overlapped I/O a thread does not block. I chose > non-overlapped I/O to avoid thread blocking at the OS level - > instead, the thread blocking is kept in Java. Isn't "overlapped" (asynchronous) I/O meaning that you invoke some ReadFile(..., &overlapped, ...) INSTEAD of performing a synchronous (blocking) function call blocking the thread? As far as I see, W32_Support.cpp uses CreateFile without FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O operations are serialized, even if the calls to the read and write functions specify an OVERLAPPED structure." [1] and "A synchronous handle behaves such that I/O function calls using that handle are blocked until they complete" [2] Given that CCOMTIMEOUTS get: "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the bytes that have already been received, even if no bytes have been received." [3] It looks likes this implementation relies on polling, which probably would waste much computing power. What did I miss? oki, Steffen [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro nous_and_asynchronous_i_o_handles [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 09:23:47 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:23:47 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6D1D93.6090306@sandglass-software.com> Unfortunately, the javax.comm API specification includes a lot of implementation details. That is one of the weaknesses of the specification in my opinion. The bottom line is, anyone wanting to use RxTx as a javax.comm implementation is going to expect it to do the things the specification says it does. -Adrian On 3/1/2011 7:26 AM, Steffen DETTMER wrote: >> The javax.comm API specification requires one event monitor >> thread per port. > Where does it require this? > > Do you mean "All the events received by this listener are generated > by one dedicated thread that belongs to the SerialPort object. "? > > I think this is an implementation detail, isn't it? At least it is > mentioned after "The current implementation only allows one listener per > SerialPort". A bit bad that javadoc does not distinguish between API > spec and implementation documentation. Also I don't think that > TooManyListenersException MUST be thrown (I think it CAN be thrown). > >> I don't like the idea of having a thread per >> port either, but one of the rewrite's design goals is strict >> conformance to the specification. > (but not necessarily on JNI layer) > >> The 50 mS polling interval is just a placeholder. The final >> design of that is yet to be decided. > I though no polling would be wanted; what could be the placeholder stand > for? Do you mean a different interval duration or do you mean something > completely different? > >> In Windows, you have two choices for I/O: overlapped and >> non-overlapped. >> In overlapped I/O a thread is blocked, waiting for something >> to happen. >> In non-overlapped I/O a thread does not block. I chose >> non-overlapped I/O to avoid thread blocking at the OS level - >> instead, the thread blocking is kept in Java. > Isn't "overlapped" (asynchronous) I/O meaning that you invoke some > ReadFile(...,&overlapped, ...) > INSTEAD of performing a synchronous (blocking) function call blocking > the thread? > > As far as I see, W32_Support.cpp uses CreateFile without > FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O > operations are serialized, even if the calls to the read and write > functions specify an OVERLAPPED structure." [1] and "A synchronous > handle behaves such that I/O function calls using that handle are > blocked until they complete" [2] > > Given that CCOMTIMEOUTS get: > "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values > for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier > members, specifies that the read operation is to return immediately with > the bytes that have already been received, even if no bytes have been > received." [3] > > It looks likes this implementation relies on polling, which probably > would waste much computing power. > > What did I miss? > > oki, > > Steffen > > [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx > [2] > http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro > nous_and_asynchronous_i_o_handles > [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at sandglass-software.com Tue Mar 1 09:55:29 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:55:29 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <1142-1298983027-957144@sneakemail.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> Message-ID: <4D6D2501.1020803@sandglass-software.com> That code duplicates what is in Dispatcher.cpp. A Unix port would only need to implement CommPortFactory::getInstance(portName, portType). -Adrian On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 15:07:46 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 2 Mar 2011 09:07:46 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6D2501.1020803@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> <4D6D2501.1020803@sandglass-software.com> Message-ID: <23749-1299017266-991798@sneakemail.com> What is this duplicating? A Unix port will need to call open() anyways (just so we're talking about the same thing here: open() is the Unix equivalent of CreateFile()) On Wed, Mar 2, 2011 at 3:55 AM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > That code duplicates what is in Dispatcher.cpp. A Unix port would only > need to implement CommPortFactory::getInstance(portName, portType). > > -Adrian > > > On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Tue Mar 1 22:53:07 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 00:53:07 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: Hi, I haven't seen any response to my question below. Is this not the right place to ask? If not, where would be a better place to ask? Any suggestions? Thanks, Ryan On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >> Hi, >> >> I have a receive thread that does nothing but call read() on the serial >> port input stream. It works fine for a while but after running for a long >> time it eventually returns -1 which means EOF. This is my first problem, as >> the device I'm talking to runs forever, I don't know why it would return -1. >> I am calling disableReceiveThreshold() and disableReceiveTimeout() at >> initialization which according to the documentation means read will return >> as soon as any data is available and it will block forever when data is not >> available, so -1 should never be returned from read, right? >> >> I have been unable to figure out why read returns -1 after a long while >> but I have found that if I kill my application and restart it everything >> works fine again. Therefore I tried to work around the problem by having my >> code close the port and reopen it when read returns -1. My second problem is >> that in this case when I call close() on the port it blocks forever. I did >> find this old bug >> >> http://bugzilla.qbang.org/show_bug.cgi?id=53 >> >> which describes close() hanging on OSX, but it says that bug was fixed >> with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have >> any idea why read might be returning -1 in the first place? If I can avoid >> that I don't care about close() hanging because I would never close the >> port. If not, does anyone know why close() might block forever and how I can >> prevent this? I'm using RXTX version 2.1-7. >> >> Thanks, >> -- >> Ryan >> >> > > > -- > Ryan Boder > 1 614 598-6339 > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Mar 2 01:34:48 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 2 Mar 2011 10:34:48 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/2/11 07:53, "Ryan Boder" wrote: Can you / have you made a simple test to ensure that rxtx is the issue? Can you write a simple C-program to see if this exhibits the same problem? I've never encountered this sort of problem with rxtx, it mostly just works. But I'm on Mac so can't say about Windows (7) br Kusti >Hi, > >I haven't seen any response to my question below. Is this not the right >place to ask? If not, where would be a better place to ask? Any >suggestions? > >Thanks, >Ryan > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > >I mis-spoke, I don't have my own thread calling read, I am calling >read in the event handler after receiving a >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be >accurate though. > >Ryan > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >Hi, > >I have a receive thread that does nothing but call read() on the serial >port input stream. It works fine for a while but after running for a long >time it eventually returns -1 which means EOF. This is my first problem, >as the device I'm talking to runs forever, I don't know why it would >return -1. I am calling disableReceiveThreshold() and >disableReceiveTimeout() at initialization which according to the >documentation means read will return as soon as any data is available and >it will block forever when data is not available, so -1 should never be >returned from read, right? > >I have been unable to figure out why read returns -1 after a long while >but I have found that if I kill my application and restart it everything >works fine again. Therefore I tried to work around the problem by having >my code close the port and reopen it when read returns -1. My second >problem is that in this case when I call close() on the port it blocks >forever. I did find this old bug > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > >which describes close() hanging on OSX, but it says that bug was fixed >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone >have any idea why read might be returning -1 in the first place? If I can >avoid that I don't care about close() hanging because I would never close >the port. If not, does anyone know why close() might block forever and >how I can prevent this? I'm using RXTX version 2.1-7. > >Thanks, >-- >Ryan > > > > > > > > > >-- >Ryan Boder >1 614 598-6339 > > > > > > >-- >Ryan Boder >1 614 598-6339 > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From Steffen.DETTMER at ingenico.com Wed Mar 2 03:08:57 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:08:57 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <32684-1298981297-704398@sneakemail.com> References: <4D6CD4DE.7040501@sandglass-software.com> <32684-1298981297-704398@sneakemail.com> Message-ID: <20110302100857.GB8030@elberon.bln.de.ingenico.com> * iqzw2r602 at sneakemail.com wrote on Tue, Mar 01, 2011 at 23:08 +1100: > This reminds me of a nasty problem I had with overlapped I/O on windows Yeah, those thousands of complex, difficult to use and exception-containing WinAPI is really hard to use... About strange effects on overlapped&multithreading, MSDN has: `the calling thread uses the GetOverlappedResult function or one of the wait functions' [1] also also mentiones I/O Completion Ports [2], and later continues: `If an application reuses OVERLAPPED structures on multiple threads and calls GetOverlappedResult with the bWait parameter set to TRUE, the application must ensure that the associated event is set before the application reuses the structure. This can be accomplished by using the WaitForSingleObject function after calling GetOverlappedResult to force the thread to wait until the operation completes. Note that the event object must be a manual-reset event object. If an autoreset event object is used, calling GetOverlappedResult with the bWait parameter set to TRUE causes the function to be blocked indefinitely.' also [1] oki, Steffen [1] http://msdn.microsoft.com/en-us/library/ms686358%28v=vs.85%29.aspx [2] http://msdn.microsoft.com/en-us/library/aa365198%28v=vs.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:15:11 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:15:11 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6D1D93.6090306@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> <4D6D1D93.6090306@sandglass-software.com> Message-ID: <20110302101511.GC8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 08:23 -0800: > Unfortunately, the javax.comm API specification includes a lot of > implementation details. That is one of the weaknesses of the > specification in my opinion. The bottom line is, anyone wanting to use > RxTx as a javax.comm implementation is going to expect it to do the > things the specification says it does. Yeah ok, but even then the implementation could check for the TooManyListenersException situations (if it really is required to support applications relying on that exception) but internally use just a single I/O thread waiting for events on any open file descriptors. Of course an implementation supporting all sort of concurrency could become quite complex (especially if open-read-close should work fast, I think would be difficult to implement, because a new file descriptors had to be added to the waitFor/select list, and who knows how systems behave here in detail...). oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:25:15 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:25:15 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6CDB22.9070401@sandglass-software.com> References: <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> <4D6CDB22.9070401@sandglass-software.com> Message-ID: <20110302102515.GD8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 03:40 -0800: > * from some older mail: > > My question would be: Why would you do that? The rewrite does > > most of the work for you - all you have to do is implement > > two C++ virtual classes and two C++ functions. > > > > In Windows that took me a few hours. > > Every journey begins with a single step. Yes, of course, but then it shouldn't be used as base for new effort estimations like `In Windows that took a few hours' ;-) (BTW, calling a single step `the rewrite' may sound a bit ambitious ;)) But of course a prototype demonstrating something can be really helpful, sure. I just wanted to tell that interfaces should be easy to use and powerful at the same time and may non-trivial initial considerations before starting to implement them. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From ryan.boder at gmail.com Wed Mar 2 18:44:35 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:44:35 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: While running the tests you requested I may have stumbled on the problem, I just don't know how to fix it. According to the documentation, if both the receive timeout and receive threshold are disabled then read() should block forever until data is available. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#getInputStream%28%29 On my system using RXTX read() is returning -1 when no data is available even though I have disabled both thresholds. The reason my program was running fine for a while without this problem showing up is that I was using the DATA_AVAILABLE event to be notified when data is available and only calling read() to read an entire frame whenever the DATA_AVAILABLE event occurred, until eventually my device (I'm guessing) probably took longer than normal to send the entire data frame and therefore I called read when no data was available and it returned -1. The following Java program demonstrates my problem, it returns -1 as soon as no data is available, even though I think it should block until data is available. import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; public class Main implements SerialPortEventListener { public static void main(String[] args) throws Exception { new Main().run(); } private void run() throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier("COM4"); SerialPort port = (SerialPort) portIdentifier.open(Main.class.getName(), 2000); port.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); port.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); port.disableReceiveThreshold(); port.disableReceiveTimeout(); BufferedInputStream in = new BufferedInputStream(port.getInputStream()); BufferedOutputStream out = new BufferedOutputStream(port.getOutputStream()); port.addEventListener(this); Thread.sleep(1000); out.write(new byte[] {0x02, 0x60}); out.flush(); while (true) { int x = in.read(); if (x == -1) { System.out.println("EOF"); Thread.sleep(1000000000); } String s = Integer.toHexString(x & 0xFF); if (s.length() == 1) s = "0" + s; System.out.print(s + " "); System.out.flush(); } } public void serialEvent(SerialPortEvent arg0) { System.out.println("Serial port event"); } } However, the follow C# program ran all day today without ever read ever returning -1, as I would expect. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.IO.Ports; using System.Threading; namespace RXTXReadTest1 { class Program { static void Main(string[] args) { new Program().run(); } private void run() { SerialPort port = new SerialPort("COM4", 19200, Parity.None, 8, StopBits.One); port.Open(); port.Write(new byte[] { 0x02, 0x60 }, 0, 2); while (true) { int x = port.ReadByte(); if (x == -1) { Console.WriteLine("EOF"); Thread.Sleep(1000000000); } String s = x.ToString("X"); if (s.Length == 1 ) s = "0" + s; Console.Out.Write(s + " "); Console.Out.Flush(); } } } } Now I am experimenting with what happens if I set the receive timeout to it's maximum value (apparently 1600ms) and only call read() when I am expecting data. Hopefully it will never be more than 1600ms late. This is still only a work around, not solving the problem. Am I doing something wrong in my code above or is RXTX retuning -1 when it should be blocking? Thanks, Ryan On Wed, Mar 2, 2011 at 3:34 AM, Kustaa Nyholm wrote: > On 3/2/11 07:53, "Ryan Boder" wrote: > Can you / have you made a simple test to ensure that rxtx is the issue? > > Can you write a simple C-program to see if this exhibits the same problem? > > I've never encountered this sort of problem with rxtx, it mostly just > works. > > But I'm on Mac so can't say about Windows (7) > > br Kusti > > > > > >Hi, > > > >I haven't seen any response to my question below. Is this not the right > >place to ask? If not, where would be a better place to ask? Any > >suggestions? > > > >Thanks, > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder > wrote: > > > >I mis-spoke, I don't have my own thread calling read, I am calling > >read in the event handler after receiving a > >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be > >accurate though. > > > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder > wrote: > > > >Hi, > > > >I have a receive thread that does nothing but call read() on the serial > >port input stream. It works fine for a while but after running for a long > >time it eventually returns -1 which means EOF. This is my first problem, > >as the device I'm talking to runs forever, I don't know why it would > >return -1. I am calling disableReceiveThreshold() and > >disableReceiveTimeout() at initialization which according to the > >documentation means read will return as soon as any data is available and > >it will block forever when data is not available, so -1 should never be > >returned from read, right? > > > >I have been unable to figure out why read returns -1 after a long while > >but I have found that if I kill my application and restart it everything > >works fine again. Therefore I tried to work around the problem by having > >my code close the port and reopen it when read returns -1. My second > >problem is that in this case when I call close() on the port it blocks > >forever. I did find this old bug > > > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > > > >which describes close() hanging on OSX, but it says that bug was fixed > >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone > >have any idea why read might be returning -1 in the first place? If I can > >avoid that I don't care about close() hanging because I would never close > >the port. If not, does anyone know why close() might block forever and > >how I can prevent this? I'm using RXTX version 2.1-7. > > > >Thanks, > >-- > >Ryan > > > > > > > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Wed Mar 2 18:46:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:46:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: <-1051064942000733580@unknownmsgid> References: <-1051064942000733580@unknownmsgid> Message-ID: It is USB and seems very reliable with the C# test program in my previous email. On Wed, Mar 2, 2011 at 6:58 PM, Bruce Griffith wrote: > How reliable is your serial port ? is it USB or Bluetooth? > > > > Bruce Griffith > > 303-532-4778 > > > > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On Behalf > Of *Ryan Boder > *Sent:* Tuesday, 01 March 2011 10:53 PM > *To:* rxtx at qbang.org > *Subject:* Re: [Rxtx] RXTX serial port read() returns -1 unexpectedly and > then blocks forever on close() > > > > Hi, > > I haven't seen any response to my question below. Is this not the right > place to ask? If not, where would be a better place to ask? Any suggestions? > > Thanks, > Ryan > > On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > > Hi, > > I have a receive thread that does nothing but call read() on the serial > port input stream. It works fine for a while but after running for a long > time it eventually returns -1 which means EOF. This is my first problem, as > the device I'm talking to runs forever, I don't know why it would return -1. > I am calling disableReceiveThreshold() and disableReceiveTimeout() at > initialization which according to the documentation means read will return > as soon as any data is available and it will block forever when data is not > available, so -1 should never be returned from read, right? > > I have been unable to figure out why read returns -1 after a long while but > I have found that if I kill my application and restart it everything works > fine again. Therefore I tried to work around the problem by having my code > close the port and reopen it when read returns -1. My second problem is that > in this case when I call close() on the port it blocks forever. I did find > this old bug > > http://bugzilla.qbang.org/show_bug.cgi?id=53 > > which describes close() hanging on OSX, but it says that bug was fixed with > a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have any > idea why read might be returning -1 in the first place? If I can avoid that > I don't care about close() hanging because I would never close the port. If > not, does anyone know why close() might block forever and how I can prevent > this? I'm using RXTX version 2.1-7. > > Thanks, > -- > Ryan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Mar 3 02:50:20 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 3 Mar 2011 09:50:20 +0000 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: So if -1 is unexpectedly returned from read, and we have demonstrated that your USB-serial adapter can actually causes this to happen in RXTX, why not just ignore the -1 value? What happens when you try this? As for a hang on close, are your closing your port from within your serial event handler? I know that this can cause some serious problems. Regards, Michael Erskine. From Kustaa.Nyholm at planmeca.com Thu Mar 3 03:39:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 12:39:34 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 03:44, "Ryan Boder" wrote: >While running the tests you requested I may have stumbled on the problem, >I just don't know how to fix it. According to the documentation, if both >the receive timeout and receive threshold are disabled then read() should >block forever until data is available. > >http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/re >ference/api/javax/comm/CommPort.html#getInputStream%28%29 > >On my system using RXTX read() is returning -1 when no data is available >even though I have disabled both thresholds. The reason my program was >running fine for a while without this problem showing up is that I was >using the DATA_AVAILABLE event to be notified when data is available and >only calling read() to read an entire frame whenever the DATA_AVAILABLE >event occurred, until eventually my device (I'm guessing) probably took >longer than normal to send the entire data frame and therefore I called >read when no data was available and it returned -1. As a workaround have you tried to perform another read() if it returns -1? The javadoc says (see getInputStream): "Note, however, that framing errors may cause the Timeout and Threshold values to complete prematurely without raising an exception." I read this as a hint that read might return even if no data is available. Because of the above and that read() can only return -1 or the byte received it would be somewhat logical to return -1 in case of framing error ? I'm not claiming that my interpretation of the specification, such as it is, is correct, just speculating that the behavior could be something like that. It might give you some more insight if you used the read(bytes[],int,int) method, because this can and will return 0 in case of timeout (and presumably might do so in case of framing error, maybe some other error condition too). That might allow you to handle or work around the problem in this case. You have not shown your complete code (no need) but your comments and the example makes me wonder if the code is otherwise as it should be, meaning are you assuming that when you get the DATA_AVAILABLE event all of your frame has arrived and that you can just blindly read it away from the input stream? That is not guaranteed of course. Also using read(), instead of read(bytes[],int,int), is not very efficient and might be masking other problems as mused above. BTE you can print a byte in hex with leading zeros more easily with: System.out.printf("%02X",x); br Kusti From ryan.boder at gmail.com Thu Mar 3 07:56:16 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:56:16 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 5:39 AM, Kustaa Nyholm wrote: > > As a workaround have you tried to perform another read() if it returns -1? > I tried that and it did work sometimes but not all the time. > > The javadoc says (see getInputStream): > > "Note, however, that framing errors may cause the Timeout and Threshold > values to complete prematurely without raising an exception." > > I read this as a hint that read might return even if no data is available. > > Because of the above and that read() can only return -1 or the byte > received > it would be somewhat logical to return -1 in case of framing error ? > > I'm not claiming that my interpretation of the specification, such as it > is, > is correct, just speculating that the behavior could be something like > that. > Receive framing is not enabled by default. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#enableReceiveFraming%28int%29 My choice of word might be misleading, when I said frame I just meant a contiguous message from the device. I am not enabling receive framing. Can you have a framing error when receive framing is disabled? > > It might give you some more insight if you used the read(bytes[],int,int) > method, because > this can and will return 0 in case of timeout (and presumably might do so > in case of framing > error, maybe some other error condition too). > > That might allow you to handle or work around the problem in this case. > > You have not shown your complete code (no need) but your comments and the > example > makes me wonder if the code is otherwise as it should be, meaning are you > assuming > that when you get the DATA_AVAILABLE event all of your frame has arrived > and that > you can just blindly read it away from the input stream? That is not > guaranteed of course. > I'm not assuming the entire message has arrived, I'm just assuming it either has arrived or will arrive soon which is why I'm using a (supposedly) blocking read(). > > Also using read(), instead of read(bytes[],int,int), is not very efficient > and > might be masking other problems as mused above. > True, I'm reading one byte at a time because I don't know how long the message will be until I read and parse some of it. I suppose I can use read(bytes[],int,int) once I figure out how long the message will be. > > BTE you can print a byte in hex with leading zeros more easily with: > > > System.out.printf("%02X",x); > I did it the dumb way in that test program so I could copy and paste the code from C# to Java without having to figure out how to do the same in C# which I'm not as familiar with. Thanks and BR, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 07:58:24 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:58:24 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: Yes I was doing the close in the serial event handler, I didn't realize that caused a problem. Thanks, I'll fix it. On Thu, Mar 3, 2011 at 4:50 AM, Michael Erskine wrote: > So if -1 is unexpectedly returned from read, and we have demonstrated > that your USB-serial adapter can actually causes this to happen in > RXTX, why not just ignore the -1 value? What happens when you try > this? As for a hang on close, are your closing your port from within > your serial event handler? I know that this can cause some serious > problems. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 11:48:20 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 13:48:20 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm wrote: > On 3/3/11 16:56, "Ryan Boder" wrote: > > > >I'm not assuming the entire message has arrived, I'm just assuming it > >either has arrived or will arrive soon which is why I'm using a > >(supposedly) blocking read(). > > > I've been giving this some further thought. > > It does not feel healthy to block without timeout, especially > from within a thread that is essentially internal to the rxtx. > > I've never done that, I always use a time out, read(byte[],int,int) > for the expected number of bytes, check how much I got and issue > more reads until I get everything. > > You have not described how your communication works so I'm only > speculating. > > If your device needs some response to send more bytes (from your > code it looks like this is not the case) then a missing byte > would block your read and prevent you from responding and > getting more data. But as said, looks like that is not the case. > > Anyway, if this was my problem, I would enable the timeout > and use read(byte[],int,int) and loop until I get what I need. > You are right, I should and will use a timeout. In fact, my program has been running flawlessly for 12 hours and the only change I made was to enable a timeout, no change in the logic at all. Without the timeout read() was returning -1 usually after it ran for an hour or two. I will change the code to make use of the timeout and handle it appropriately. It still seems to me that RXTX's behavior doesn't match the documentation when rx timeout and rx threshold are disabled read() should block until data is available instead of immediately returning -1. I don't believe that a framing error is occurring immediately every time data is not available causing read() to return -1. Especially since the C# test program above runs all day with no error and the Java program above runs all day with no error when a timeout is enabled. To me it seems like enabling the timeout is what is causing read() to block until data is available, even if only for 1600ms, and without the timeout read() is returning -1 immediately when it should be blocking. Thanks for all the help and best regards, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Thu Mar 3 13:02:30 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 22:02:30 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 20:48, "Ryan Boder" wrote: >On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm > wrote: > >On 3/3/11 16:56, "Ryan Boder" wrote: >> > >>I'm not assuming the entire message has arrived, I'm just assuming it >>either has arrived or will arrive soon which is why I'm using a >>(supposedly) blocking read(). > > > >I've been giving this some further thought. > >It does not feel healthy to block without timeout, especially >from within a thread that is essentially internal to the rxtx. > >I've never done that, I always use a time out, read(byte[],int,int) >for the expected number of bytes, check how much I got and issue >more reads until I get everything. > >You have not described how your communication works so I'm only >speculating. > >If your device needs some response to send more bytes (from your >code it looks like this is not the case) then a missing byte >would block your read and prevent you from responding and >getting more data. But as said, looks like that is not the case. > >Anyway, if this was my problem, I would enable the timeout >and use read(byte[],int,int) and loop until I get what I need. > > > > >You are right, I should and will use a timeout. In fact, my program has >been running flawlessly for 12 hours and the only change I made was to >enable a timeout, no change in the logic at all. Without the timeout >read() was returning -1 usually after it ran for an hour or two. I will >change the code to make use of the timeout and handle it appropriately. That's nice! > >It still seems to me that RXTX's behavior doesn't match the documentation >when rx timeout and rx threshold are disabled read() should block until >data is available instead of immediately returning -1. Yeah, it does look like bug. However this might be related to some Windows specific serial port issue. Years ago I had issues with JavaComm (not RxTx) where I did a blocking read and I had huge issues with my program consuming all resources. I curser the Sun and JavaComm and re-code my own SerialPort using JNI to access the Win32 API directly. And I run into the same problems as with the Sun's implementation! So I ditched my code, changed my code to use timeouts and problems disappeared. > I don't believe that a framing error is occurring immediately every time >data is not available causing read() to return -1. Especially since the >C# test program above runs all day with no error and the Java program >above runs all day with no error when a timeout is enabled. I think so too, all things considered I don't really believe in framing errors in this case. > To me it seems like enabling the timeout is what is causing read() to >block until data is available, even if only for 1600ms, and without the >timeout read() is returning -1 immediately when it should be blocking. Yeah, I had a peek at the innards of RxTx Windows serial port a week or so ago and also read MSDN documentation about serial ports and the way overlapped and non-overlapped (non blocking and blocking) IO is handled is a way different. So yeah, it can well be that there is an issue lurking there somewhere inside RxTx in Windows. > > >Thanks for all the help and best regards, >-- >Ryan Boder I'm happy if I was of any assistance. br Kusti From tjarvi at qbang.org Thu Mar 3 18:52:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Mar 2011 18:52:50 -0700 (MST) Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: >> Without the timeout >> read() was returning -1 usually after it ran for an hour or two. There is a big hammer in rxtx causing that behavior. >> It still seems to me that RXTX's behavior doesn't match the documentation >> when rx timeout and rx threshold are disabled read() should block until >> data is available instead of immediately returning -1. > > Yeah, it does look like bug. However this might be related to some > Windows specific serial port issue. Years ago I had issues with > JavaComm (not RxTx) where I did a blocking read and I had huge > issues with my program consuming all resources. I curser the Sun > and JavaComm and re-code my own SerialPort using JNI to access > the Win32 API directly. And I run into the same problems as > with the Sun's implementation! So I ditched my code, changed > my code to use timeouts and problems disappeared. > > >> To me it seems like enabling the timeout is what is causing read() to >> block until data is available, even if only for 1600ms, and without the >> timeout read() is returning -1 immediately when it should be blocking. > > Yeah, I had a peek at the innards of RxTx Windows serial port a week > or so ago and also read MSDN documentation about serial ports and > the way overlapped and non-overlapped (non blocking and blocking) > IO is handled is a way different. So yeah, it can well be that > there is an issue lurking there somewhere inside RxTx in Windows. > > Yes. RXTX was patched to behave the way it does. I don't fully understand the issue behind the patch. Marc noticed the odd behavior as well and offered a fix which was greeted with resistance. The windows implementation was done without real documentatino of the windows API. I think I had an example from the late 80's early 90's on Microsoft's site and some API documentation that was obviously not microsofts in Europe. Wayne Roberts had a real need for windows support and fixed some major issues it had. My interest at the time was mingw32. I then cleaned it up for some specific uses I had later. The read returning -1 when it should block didn't impact anybody and appeared to help some people. It isnt the documented behavior though. There could be all sorts of latent bugs in that code but in the real world, it gets by in almost all use cases. Its a hack but it worked for 100's of thousands of people over a 14 year period. Maybe its time to revisit the code but there is more risk than gain for most people. How do you move forward and avoid the risk? Some have expressed interests in coding C++ or other efforts. I'm all for such efforts but feel some unit tests that work with a null modem cables are the only thing that will move rxtx (and perhaps CommAPI) forward. If we have a test suite in place as a qualification for implementations, progress can be made in the right direction regardless of the implementation details. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Fri Mar 4 02:57:16 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 4 Mar 2011 11:57:16 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/4/11 03:52, "Trent Jarvi" wrote: >Yes. RXTX was patched to behave the way it does. I don't fully >understand the issue behind the patch. Marc noticed the odd behavior as >well and offered a fix which was greeted with resistance. > >The windows implementation was done without real documentatino of the >windows API. I think I had an example from the late 80's early 90's on >Microsoft's site and some API documentation that was obviously not >microsofts in Europe. Wayne Roberts had a real need for windows support >and fixed some major issues it had. My interest at the time was mingw32. >I then cleaned it up for some specific uses I had later. The read >returning -1 when it should block didn't impact anybody and appeared to >help some people. It isnt the documented behavior though. > >There could be all sorts of latent bugs in that code but in the real >world, it gets by in almost all use cases. I think so too, never had any problems with it. > Its a hack but it worked for 100's of thousands of people over a 14 year >period. Yeah! Thanks for everyone who has contributed over the years, job well done! >Maybe its time to >revisit the code but there is more risk than gain for most people. How >do >you move forward and avoid the risk? My view is that it is quite risky and rather pointless to move forward, other than fixing bugs that really affect people. At the moment the major issue IMO is just that it seems (not been following this too carefully, so maybe I'm wrong, so in case this FUD, my apologies) that 'official' binaries are not available. I think the rewrite, tempting as it is in some respects is not the way forward. Just gentle maintenance to iron out real issues and then get the binaries out. br Kusti From ryan.boder at gmail.com Fri Mar 4 07:24:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Fri, 4 Mar 2011 09:24:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 8:52 PM, Trent Jarvi wrote: > > The windows implementation was done without real documentatino of the > windows API. I think I had an example from the late 80's early 90's on > Microsoft's site and some API documentation that was obviously not > microsofts in Europe. Wayne Roberts had a real need for windows support and > fixed some major issues it had. My interest at the time was mingw32. I then > cleaned it up for some specific uses I had later. The read returning -1 > when it should block didn't impact anybody and appeared to help some people. > It isnt the documented behavior though. > > There could be all sorts of latent bugs in that code but in the real world, > it gets by in almost all use cases. Its a hack but it worked for 100's of > thousands of people over a 14 year period. Maybe its time to revisit the > code but there is more risk than gain for most people. How do you move > forward and avoid the risk? > The safest and easiest solution would be to add a javadoc comment to disableReceiveTimeout explaining the difference between the RXTX behavior and Sunacle's documented behavior so that when someone uses the method in an IDE like Eclipse a little box would pop up informing them. Generating javadoc HTML and hosting it on the RXTX website would go a long way too, when something behaves differently than I expect the first thing I do is look for the javadoc online. -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From kharrington at neuronrobotics.com Mon Mar 7 10:47:26 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 12:47:26 -0500 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! Message-ID: Hey all, this is just a heads up that i have made a fork of rxtxSerial. Some of the features we have added: * Self deployment of native libraries ( all native code is stored inside the jar and deployed at runtime). No more manual install of native code. * Arm Cortex support (Gumstix) * Android Support (requires a rooted phone for now) * Google Code (SVN) repository for easy code and jar access * Single makefile compile (simplifies the compilation of project binaries) * Ant build script for jar creation * Removal of partialy implemented code to streamline the lib for just serial port access * Full Eclipse integration, for testing application code against sources. And a bunch of bug fixes: * Fixed the memory access error that causes OSX to crash the JVM when serial.close() is cvalled * Fixed the windows serial port zombie bind that prevents re-accessing serial ports when exiting on an exception * Fixed erronious printouts of native library mis-match To check it out, take a look at our page here: http://code.google.com/p/nrjavaserial/ From Kustaa.Nyholm at planmeca.com Mon Mar 7 11:46:26 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Mar 2011 20:46:26 +0200 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: Message-ID: On 3/7/11 19:47, "Kevin Harrington NR" wrote: >Hey all, this is just a heads up that i have made a fork of >rxtxSerial. Some of the features we have added great! If also does what it says on the tin: brilliant! Congrats and thanks. br Kusti From jmsachs at gmail.com Mon Mar 7 12:50:33 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 14:50:33 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: > From: Kevin Harrington NR > To: rxtx at qbang.org > Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > Hey all, this is just a heads up that i have made a fork of > rxtxSerial. Some of the features we have added: > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with a ten-foot pole. From Kustaa.Nyholm at planmeca.com Mon Mar 7 13:10:43 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Mar 2011 22:10:43 +0200 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: Message-ID: On 3/7/11 21:50, "Jason Sachs" wrote: > >Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >a ten-foot pole. >_______________________________________________ Oh crap, makes it useless for me and many others. Also I see no provision in RxTx license to change it so how could anyone change it to GPLv3? br Kusti From showard314 at gmail.com Mon Mar 7 13:24:08 2011 From: showard314 at gmail.com (Scott Howard) Date: Mon, 7 Mar 2011 15:24:08 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 3:10 PM, Kustaa Nyholm wrote: > Also I see no provision in RxTx license to change > it so how could anyone change it to GPLv3? I think this is allowed: 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. From jmsachs at gmail.com Mon Mar 7 13:24:47 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 15:24:47 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 2:50 PM, Jason Sachs wrote: >> From: Kevin Harrington NR >> To: rxtx at qbang.org >> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> > > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with > a ten-foot pole. > Let me back up a second (perhaps to make up for my lack of diplomacy) and state that I think any progress w/ rxtx is good. If an rxtx fork were LGPL (or some other non-spreading open source license) and leading in a good direction, I'd gladly return the favor by posting any improvements or bugfixes I found to the community. --Jason From jmsachs at gmail.com Mon Mar 7 13:36:13 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 15:36:13 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: Kevin: could you clarify the license? http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java has the RXTX 2.1 license (LGPL v 2.1 + Linking Over Controlled Interface.) but http://code.google.com/p/nrjavaserial/ says GPLv3. --Jason From kharrington at neuronrobotics.com Mon Mar 7 14:00:02 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 16:00:02 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: The one downside to google code is that it does not allow custom licensing. You have to pick from a drop-down list. Treat the licences on the files themselves as the licence to be concerned with, and ignore the "project licence". Sorry for the confusion. On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: > Kevin: could you clarify the license? > > http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java > has the RXTX 2.1 license > (LGPL v 2.1 + Linking Over Controlled Interface.) > > but http://code.google.com/p/nrjavaserial/ says GPLv3. > > --Jason > From iqzw2r602 at sneakemail.com Mon Mar 7 14:08:18 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 8 Mar 2011 08:08:18 +1100 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: References: Message-ID: <11253-1299532098-811882@sneakemail.com> Nice! Out of curiosity, did you use the patch that I sent Trent about two years ago to do the native library loading, or did you implement your own solution? Cheers, Uwe On Tue, Mar 8, 2011 at 5:46 AM, Kustaa Nyholm Kustaa.Nyholm-at-planmeca.com| rxtx.org mailing list/Example Allow| wrote: > On 3/7/11 19:47, "Kevin Harrington NR" > wrote: > > >Hey all, this is just a heads up that i have made a fork of > >rxtxSerial. Some of the features we have added > > > > great! If also does what it says on the tin: brilliant! > > Congrats and thanks. > > br Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aawolfe at gmail.com Mon Mar 7 15:31:47 2011 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 7 Mar 2011 17:31:47 -0500 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR wrote: > Hey all, this is just a heads up that i have made a fork of > rxtxSerial. Some of the features we have added: > > * Self deployment of native libraries ( all native code is stored > inside the jar and deployed at runtime). No more manual install of > native code. > * Arm Cortex support (Gumstix) > * Android Support (requires a rooted phone for now) > * Google Code (SVN) repository for easy code and jar access > * Single makefile compile (simplifies the compilation of project binaries) > * Ant build script for jar creation > * Removal of partialy implemented code to streamline the lib for just > serial port access > * Full Eclipse integration, for testing application code against sources. > > And a bunch of bug fixes: > > * Fixed the memory access error that causes OSX to crash the JVM when > serial.close() is cvalled > * Fixed the windows serial port zombie bind that prevents re-accessing > serial ports when exiting on an exception > * Fixed erronious printouts of native library mis-match > > To check it out, take a look at our page here: > > http://code.google.com/p/nrjavaserial/ This is interesting, getting the native libs set up has been an issue for some of my users. Will have to check it out. Out of curiosity, what Android devices provide a serial port? Or are there some that allow USB host mode and then a usb-serial adapter? I have only an Android cell phone, don't think it can do anything serial but would love to be wrong about that. From jfh at greenhousepc.com Mon Mar 7 15:54:39 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 15:54:39 -0700 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! Message-ID: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Mon Mar 7 16:53:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Mar 2011 16:53:50 -0700 (MST) Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: Hi Kevin, Until Google fixes the options as developers have requested, I'd suggest the least misleading dropdown option is "Other Open Source" with a clarification about LGPL 2.1 on the project page. If you are not supporting the CommAPI SPI interface that was available prior to the current JSR so that applications work in the javax.comm namespace, there is no need for the linking over controlled interfaces exception. RXTX 2.0 is used in that fashion but RXTX 2.1 is not. The exception explicitly states it can be removed if the source has been modified. The license is then explicitly OSI reviewed and approved as Google requests but is not in their drop down box as it should be and is for the GPL v2. http://opensource.org/licenses/alphabetical http://opensource.org/licenses/lgpl-2.1 The drawback would be that the library effectively could never be used in that SPI/controlled interface fashion again. On Mon, 7 Mar 2011, Kevin Harrington NR wrote: > The one downside to google code is that it does not allow custom > licensing. You have to pick from a drop-down list. Treat the licences > on the files themselves as the licence to be concerned with, and > ignore the "project licence". Sorry for the confusion. > > On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >> Kevin: could you clarify the license? >> >> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >> has the RXTX 2.1 license >> (LGPL v 2.1 + Linking Over Controlled Interface.) >> >> but http://code.google.com/p/nrjavaserial/ says GPLv3. >> >> --Jason >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From hakcenter at gmail.com Mon Mar 7 18:55:57 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 17:55:57 -0800 Subject: [Rxtx] Latency Woes Message-ID: <4D758CAD.2010602@gmail.com> I have finally deduced my slow data logging to a latency issue. I write software for dsms, and the protocol is request / receive, you cannot do more than 1 sensor at a time. So when you log multiple sensors, +20ms per item, sampling rate drops like a rock. I was wondering if there is any ideas besides going completely native with my application to reduce latency. With or without events I don't care at this point I need to kill as much of the latency as possible. Realistically I need no more than 1ms. From adrian.crum at sandglass-software.com Mon Mar 7 19:08:21 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Mon, 07 Mar 2011 18:08:21 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D758CAD.2010602@gmail.com> References: <4D758CAD.2010602@gmail.com> Message-ID: <4D758F95.90800@sandglass-software.com> Drop the requests into a queue, and then have a separate thread service the queue. -Adrian On 3/7/2011 5:55 PM, Curtis Hacker wrote: > I have finally deduced my slow data logging to a latency issue. > > I write software for dsms, and the protocol is request / receive, you > cannot do more than 1 sensor at a time. So when you log multiple > sensors, +20ms per item, sampling rate drops like a rock. > > I was wondering if there is any ideas besides going completely native > with my application to reduce latency. With or without events I don't > care at this point I need to kill as much of the latency as possible. > Realistically I need no more than 1ms. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From hakcenter at gmail.com Mon Mar 7 19:24:16 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 18:24:16 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D758F95.90800@sandglass-software.com> References: <4D758CAD.2010602@gmail.com> <4D758F95.90800@sandglass-software.com> Message-ID: <4D759350.8060402@gmail.com> Sample code ? I don't necessarily want to read the byte I just wrote, but wait till the que depth is 2. Setup a thread without a sleep timer: if (in.available() > 1) { do_stuff(); } ?? On 03/07/11 18:08, Adrian Crum wrote: > Drop the requests into a queue, and then have a separate thread > service the queue. > > -Adrian > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: >> I have finally deduced my slow data logging to a latency issue. >> >> I write software for dsms, and the protocol is request / receive, you >> cannot do more than 1 sensor at a time. So when you log multiple >> sensors, +20ms per item, sampling rate drops like a rock. >> >> I was wondering if there is any ideas besides going completely native >> with my application to reduce latency. With or without events I don't >> care at this point I need to kill as much of the latency as possible. >> Realistically I need no more than 1ms. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adrian.crum at sandglass-software.com Mon Mar 7 19:46:02 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Mon, 07 Mar 2011 18:46:02 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D759350.8060402@gmail.com> References: <4D758CAD.2010602@gmail.com> <4D758F95.90800@sandglass-software.com> <4D759350.8060402@gmail.com> Message-ID: <4D75986A.6020003@sandglass-software.com> http://download.oracle.com/javase/tutorial/essential/concurrency/executors.html -Adrian On 3/7/2011 6:24 PM, Curtis Hacker wrote: > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: >> Drop the requests into a queue, and then have a separate thread >> service the queue. >> >> -Adrian >> >> On 3/7/2011 5:55 PM, Curtis Hacker wrote: >>> I have finally deduced my slow data logging to a latency issue. >>> >>> I write software for dsms, and the protocol is request / receive, >>> you cannot do more than 1 sensor at a time. So when you log multiple >>> sensors, +20ms per item, sampling rate drops like a rock. >>> >>> I was wondering if there is any ideas besides going completely >>> native with my application to reduce latency. With or without events >>> I don't care at this point I need to kill as much of the latency as >>> possible. Realistically I need no more than 1ms. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Mon Mar 7 19:50:45 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 19:50:45 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Mon Mar 7 20:04:01 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 19:04:01 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> Message-ID: <4D759CA1.8010903@gmail.com> I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. in.read(data, 0, 2); ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? On 03/07/11 18:50, jfh at greenhousepc.com wrote: > Curtis, > > No, I assume he means a real queue, not just "don't read all the bytes > at once." However, if you know you can process some number of > requests in some amount of time, allowing data to pile up (receiver > FIFO space permitting) can be a valid strategy. Inserting gobs of > Thread.yield() and notify() can help pep things up as well. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Mon, March 07, 2011 8:24 pm > To: rxtx at qbang.org > > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: > > Drop the requests into a queue, and then have a separate thread > > service the queue. > > > > -Adrian > > > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: > >> I have finally deduced my slow data logging to a latency issue. > >> > >> I write software for dsms, and the protocol is request / > receive, you > >> cannot do more than 1 sensor at a time. So when you log multiple > >> sensors, +20ms per item, sampling rate drops like a rock. > >> > >> I was wondering if there is any ideas besides going completely > native > >> with my application to reduce latency. With or without events I > don't > >> care at this point I need to kill as much of the latency as > possible. > >> Realistically I need no more than 1ms. > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From bartley at cmu.edu Mon Mar 7 20:08:05 2011 From: bartley at cmu.edu (Chris Bartley) Date: Mon, 7 Mar 2011 22:08:05 -0500 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> Message-ID: <9B1804F9-DBD0-476D-9345-806D00065A97@cmu.edu> We use a queue for all our request/response serial communications, and have found it really easy to work with. Code is here: http://code.google.com/p/create-lab-commons/source/browse/trunk/java/code/serial/src/edu/cmu/ri/createlab/serial/SerialPortCommandExecutionQueue.java It's assuming a command & response scheme that's specific to the protocol we use to talk to our robots, but it should be easy to modify for your needs. Hope this helps. Let me know if you have questions. Chris On Mar 7, 2011, at 9:50 PM, wrote: > Curtis, > > No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > Date: Mon, March 07, 2011 8:24 pm > To: rxtx at qbang.org > > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: > > Drop the requests into a queue, and then have a separate thread > > service the queue. > > > > -Adrian > > > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: > >> I have finally deduced my slow data logging to a latency issue. > >> > >> I write software for dsms, and the protocol is request / receive, you > >> cannot do more than 1 sensor at a time. So when you log multiple > >> sensors, +20ms per item, sampling rate drops like a rock. > >> > >> I was wondering if there is any ideas besides going completely native > >> with my application to reduce latency. With or without events I don't > >> care at this point I need to kill as much of the latency as possible. > >> Realistically I need no more than 1ms. > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Mon Mar 7 20:51:17 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 20:51:17 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110307205116.8ef0e5b4a80cef441275a6330ffad77d.9b325137d1.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From kharrington at neuronrobotics.com Mon Mar 7 20:55:23 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 22:55:23 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 7 In-Reply-To: References: Message-ID: To answer a few of you, I have changed the license to "Other open source license" as suggested. My company is modifying and maintaining this fork to support our robotics development library (http://code.google.com/p/nr-sdk/ http://dev.neuronrobotics.com). We will be implementing the standard serial port interface only, as it is the only one we need or care about. As for where the implementation came from, i would have to refer to my other developer to answer that. I wrote the build scripts and make files, as well as streamlining the C build process. I have remover the configure script, as it ends up being more confusing then compiling 3 C files needs to be. if you guys want to bring any of this into the main line, that's cool, but up to you to port over. Our fork will be focusing on polishing up the serial interface,and hopefully making it faster. I hope some of you will find our improvements useful! On Mon, Mar 7, 2011 at 6:53 PM, wrote: > Send Rxtx mailing list submissions to > ? ? ? ?rxtx at qbang.org > > To subscribe or unsubscribe via the World Wide Web, visit > ? ? ? ?http://mailman.qbang.org/mailman/listinfo/rxtx > or, via email, send a message with subject or body 'help' to > ? ? ? ?rxtx-request at qbang.org > > You can reach the person managing the list at > ? ? ? ?rxtx-owner at qbang.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Rxtx digest..." > > > Today's Topics: > > ? 1. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 2. Re: Rxtx Digest, Vol 43, Issue 6 (Kustaa Nyholm) > ? 3. Re: Rxtx Digest, Vol 43, Issue 6 (Scott Howard) > ? 4. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 5. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 6. Re: Rxtx Digest, Vol 43, Issue 6 (Kevin Harrington NR) > ? 7. Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! > ? ? ?(iqzw2r602 at sneakemail.com) > ? 8. Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! > ? ? ?(Aaron Wolfe) > ? 9. Re: [SPAM] Re: ?NRJavaSerial, a fork of rxtx that fixes the > ? ? ?papercuts! (jfh at greenhousepc.com) > ?10. Re: Rxtx Digest, Vol 43, Issue 6 (Trent Jarvi) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 7 Mar 2011 14:50:33 -0500 > From: Jason Sachs > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > >> From: Kevin Harrington NR >> To: rxtx at qbang.org >> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> > > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with > a ten-foot pole. > > > ------------------------------ > > Message: 2 > Date: Mon, 7 Mar 2011 22:10:43 +0200 > From: Kustaa Nyholm > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > On 3/7/11 21:50, "Jason Sachs" wrote: >> >>Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >>a ten-foot pole. >>_______________________________________________ > > Oh crap, makes it useless for me and many others. > > Also I see no provision in RxTx license to change > it so how could anyone change it to GPLv3? > > br Kusti > > > > ------------------------------ > > Message: 3 > Date: Mon, 7 Mar 2011 15:24:08 -0500 > From: Scott Howard > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 3:10 PM, Kustaa Nyholm > wrote: >> Also I see no provision in RxTx license to change >> it so how could anyone change it to GPLv3? > > I think this is allowed: > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. ?To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. ?(If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) ?Do not make any other change in > these notices. > > ? Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > ? This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > > ------------------------------ > > Message: 4 > Date: Mon, 7 Mar 2011 15:24:47 -0500 > From: Jason Sachs > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 2:50 PM, Jason Sachs wrote: >>> From: Kevin Harrington NR >>> To: rxtx at qbang.org >>> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >>> Message-ID: >>> ? ? ? ? >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> Hey all, this is just a heads up that i have made a fork of >>> rxtxSerial. Some of the features we have added: >>> >> >> Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >> a ten-foot pole. >> > > Let me back up a second (perhaps to make up for my lack of diplomacy) > and state that I think any progress w/ rxtx is good. > > If an rxtx fork were LGPL (or some other non-spreading open source > license) and leading in a good direction, I'd gladly return the favor > by posting any improvements or bugfixes I found to the community. > > --Jason > > > ------------------------------ > > Message: 5 > Date: Mon, 7 Mar 2011 15:36:13 -0500 > From: Jason Sachs > To: rxtx at qbang.org, kharrington at neuronrobotics.com > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > Kevin: could you clarify the license? > > http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java > has the RXTX 2.1 license > (LGPL v 2.1 + Linking Over Controlled Interface.) > > but http://code.google.com/p/nrjavaserial/ says GPLv3. > > --Jason > > > ------------------------------ > > Message: 6 > Date: Mon, 7 Mar 2011 16:00:02 -0500 > From: Kevin Harrington NR > To: Jason Sachs > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > The one downside to google code is that it does not allow custom > licensing. You have to pick from a drop-down list. Treat the licences > on the files themselves as the licence to be concerned with, and > ignore the "project licence". Sorry for the confusion. > > On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >> Kevin: could you clarify the license? >> >> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >> has the RXTX 2.1 license >> (LGPL v 2.1 + Linking Over Controlled Interface.) >> >> but http://code.google.com/p/nrjavaserial/ says GPLv3. >> >> --Jason >> > > > ------------------------------ > > Message: 7 > Date: Tue, 8 Mar 2011 08:08:18 +1100 > From: iqzw2r602 at sneakemail.com > To: Rxtx at qbang.org > Subject: Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > ? ? ? ?papercuts! > Message-ID: <11253-1299532098-811882 at sneakemail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Nice! > > Out of curiosity, did you use the patch that I sent Trent about two years > ago to do the native library loading, or did you implement your own > solution? > > Cheers, > > Uwe > > On Tue, Mar 8, 2011 at 5:46 AM, Kustaa Nyholm Kustaa.Nyholm-at-planmeca.com| > rxtx.org mailing list/Example Allow| wrote: > >> On 3/7/11 19:47, "Kevin Harrington NR" >> wrote: >> >> >Hey all, this is just a heads up that i have made a fork of >> >rxtxSerial. Some of the features we have added >> >> >> >> great! If also does what it says on the tin: brilliant! >> >> Congrats and thanks. >> >> br Kusti >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 8 > Date: Mon, 7 Mar 2011 17:31:47 -0500 > From: Aaron Wolfe > To: rxtx at qbang.org > Subject: Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > ? ? ? ?papercuts! > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR > wrote: >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> >> * Self deployment of native libraries ( all native code is stored >> inside the jar and deployed at runtime). No more manual install of >> native code. >> * Arm Cortex support (Gumstix) >> * Android Support (requires a rooted phone for now) >> * Google Code (SVN) repository for easy code and jar access >> * Single makefile compile (simplifies the compilation of project binaries) >> * Ant build script for jar creation >> * Removal of partialy implemented code to streamline the lib for just >> serial port access >> * Full Eclipse integration, for testing application code against sources. >> >> And a bunch of bug fixes: >> >> * Fixed the memory access error that causes OSX to crash the JVM when >> serial.close() is cvalled >> * Fixed the windows serial port zombie bind that prevents re-accessing >> serial ports when exiting on an exception >> * Fixed erronious printouts of native library mis-match >> >> To check it out, take a look at our page here: >> >> http://code.google.com/p/nrjavaserial/ > > This is interesting, getting the native libs set up has been an issue > for some of my users. ?Will have to check it out. > > Out of curiosity, what Android devices provide a serial port? ?Or are > there some that allow USB host mode and then a usb-serial adapter? ?I > have only an Android cell phone, don't think it can do anything serial > but would love to be wrong about that. > > > ------------------------------ > > Message: 9 > Date: Mon, 07 Mar 2011 15:54:39 -0700 > From: > To: aaron at aaronwolfe.com, rxtx at qbang.org > Subject: Re: [Rxtx] [SPAM] Re: ?NRJavaSerial, a fork of rxtx that > ? ? ? ?fixes the papercuts! > Message-ID: > ? ? ? ?<20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe at email13.secureserver.net> > > Content-Type: text/plain; charset="us-ascii" > > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 10 > Date: Mon, 7 Mar 2011 16:53:50 -0700 (MST) > From: Trent Jarvi > To: rxtx at qbang.org > Cc: Jason Sachs > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > Hi Kevin, > > Until Google fixes the options as developers have requested, I'd suggest > the least misleading dropdown option is "Other Open Source" with a > clarification about LGPL 2.1 on the project page. > > If you are not supporting the CommAPI SPI interface that was available > prior to the current JSR so that applications work in the javax.comm > namespace, there is no need for the linking over controlled interfaces > exception. ?RXTX 2.0 is used in that fashion but RXTX 2.1 is not. ?The > exception explicitly states it can be removed if the source has been > modified. ?The license is then explicitly OSI reviewed and approved as > Google requests but is not in their drop down box as it should be and is > for the GPL v2. > > ? ? ? ?http://opensource.org/licenses/alphabetical > ? ? ? ?http://opensource.org/licenses/lgpl-2.1 > > The drawback would be that the library effectively could never be used in > that SPI/controlled interface fashion again. > > On Mon, 7 Mar 2011, Kevin Harrington NR wrote: > >> The one downside to google code is that it does not allow custom >> licensing. You have to pick from a drop-down list. Treat the licences >> on the files themselves as the licence to be concerned with, and >> ignore the "project licence". Sorry for the confusion. >> >> On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >>> Kevin: could you clarify the license? >>> >>> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >>> has the RXTX 2.1 license >>> (LGPL v 2.1 + Linking Over Controlled Interface.) >>> >>> but http://code.google.com/p/nrjavaserial/ says GPLv3. >>> >>> --Jason >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > ------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > End of Rxtx Digest, Vol 43, Issue 7 > *********************************** > From Kustaa.Nyholm at planmeca.com Mon Mar 7 21:43:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 8 Mar 2011 06:43:57 +0200 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307205116.8ef0e5b4a80cef441275a6330ffad77d.9b325137d1.wbe@email13.secureserver.net> Message-ID: On 3/8/11 05:51, "jfh at greenhousepc.com" wrote: >Curtis, > > >None of that is relevant, as long as the UART is reasonable and the code >implements a proper half duplex protocol. > >If I understand correctly, you send a byte, the sensor sends back two >bytes. So long as you don't send the next byte until the two bytes are >in the UART receiver FIFO, you're fine. You don't have to actually >=read= them, just know they are available. To the OP, are you using a serial USB port, like FTDI? This has a built in latency of 10ms ie nothing is actually sent out of the device if you send less than 64 bytes until 10 msec timeout. This has nothing to do with RxTx. If you search the list archives you'll find more about this issue and IIRC someone reported that there is some diver parameter you can tweak to get rid of that latency. I'm sure the FTDI people had a good reason for this but it really brings down the communication speed if your protocol uses short messages and need to wait for a response. Sorry if this has already been mentioned or if this is not relevant, I've not been paying attention to this thread. br Kusti From bob_jacobsen at lbl.gov Tue Mar 8 00:02:28 2011 From: bob_jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 8 Mar 2011 00:02:28 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D759CA1.8010903@gmail.com> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> Message-ID: If you're transferring three bytes total at 1953 baud, it's going to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to wait 20msec to get the data back instead of 15.4 msec doesn't seem to be as big a problem as you're making it sound. Bob On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. > > To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. > > So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. > > in.read(data, 0, 2); > ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? > > On 03/07/11 18:50, jfh at greenhousepc.com wrote: >> Curtis, >> >> No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker >> Date: Mon, March 07, 2011 8:24 pm >> To: rxtx at qbang.org >> >> Sample code ? >> >> I don't necessarily want to read the byte I just wrote, but wait till >> the que depth is 2. >> >> Setup a thread without a sleep timer: >> if (in.available() > 1) { >> do_stuff(); >> } >> >> ?? >> >> On 03/07/11 18:08, Adrian Crum wrote: >> > Drop the requests into a queue, and then have a separate thread >> > service the queue. >> > >> > -Adrian >> > >> > On 3/7/2011 5:55 PM, Curtis Hacker wrote: >> >> I have finally deduced my slow data logging to a latency issue. >> >> >> >> I write software for dsms, and the protocol is request / receive, you >> >> cannot do more than 1 sensor at a time. So when you log multiple >> >> sensors, +20ms per item, sampling rate drops like a rock. >> >> >> >> I was wondering if there is any ideas besides going completely native >> >> with my application to reduce latency. With or without events I don't >> >> care at this point I need to kill as much of the latency as possible. >> >> Realistically I need no more than 1ms. >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From hakcenter at gmail.com Tue Mar 8 01:33:24 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 00:33:24 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> Message-ID: <4D75E9D4.5090307@gmail.com> I am going to try a couple things today and hopefully figure something out. Bob I don't want to pop your bubble, but a native application named 'TunerPro' can sample the same data, over 30 sensors, in less than 25ms. I've exchanged some emails with the author and it is a native C, polling, no events just timeouts. Kusta thanks for the FTDI notice, I believe that is tunable, however I have a particular user using a Keyspan converter and verified sampling rate with 'TunerPro' and its just off the charts. Chris thank you, I'll look into the queing. On 03/07/11 23:02, Bob Jacobsen wrote: > If you're transferring three bytes total at 1953 baud, it's going to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to wait 20msec to get the data back instead of 15.4 msec doesn't seem to be as big a problem as you're making it sound. > > Bob > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > >> I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. >> >> To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. >> >> So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. >> >> in.read(data, 0, 2); >> ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? >> >> On 03/07/11 18:50, jfh at greenhousepc.com wrote: >>> Curtis, >>> >>> No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. >>> -- >>> Julie Haugh >>> Senior Design Engineer >>> greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype From msemtd at googlemail.com Tue Mar 8 01:50:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 8 Mar 2011 08:50:15 +0000 Subject: [Rxtx] Latency Woes In-Reply-To: <4D75E9D4.5090307@gmail.com> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> <4D75E9D4.5090307@gmail.com> Message-ID: On 8 March 2011 08:33, Curtis Hacker wrote: > I am going to try a couple things today and hopefully figure something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than 25ms. > I've exchanged some emails with the author and it is a native C, polling, no > events just timeouts. Perhaps the author of TunerPro will let you use his native code - sounds just what you need. Regards, Michael Erskine. From jfh at greenhousepc.com Tue Mar 8 04:00:18 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 04:00:18 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 12:33:35 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 11:33:35 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> Message-ID: <4D76848F.5080809@gmail.com> Cable schematic: http://i1106.photobucket.com/albums/h377/vigilart/jackal%20logging%20set%20up/RS232SCHEMATIC.jpg 0.00268554 TunerPro.exe IOCTL_SERIAL_SET_BAUD_RATE VCP0 SUCCESS Rate: 1952 0.00305178 TunerPro.exe IOCTL_SERIAL_SET_RTS VCP0 SUCCESS 0.00297524 TunerPro.exe IOCTL_SERIAL_SET_DTR VCP0 SUCCESS 0.00297384 TunerPro.exe IOCTL_SERIAL_SET_LINE_CONTROL VCP0 SUCCESS StopBits: 1 Parity: NONE WordLength: 8 0.00000335 TunerPro.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 0.00202540 TunerPro.exe IOCTL_SERIAL_SET_HANDFLOW VCP0 SUCCESS Shake:1 Replace:40 XonLimit:2048 XoffLimit:512 0.00000335 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:300 RM:0 RC:2000 WM:0 WC:110 0.00000279 TunerPro.exe IOCTL_SERIAL_SET_QUEUE_SIZE VCP0 SUCCESS InSize: 1024 OutSize: 512 0.00000307 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000279 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:300 RM:0 RC:2000 WM:0 WC:110 0.00000307 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:75 RM:0 RC:400 WM:0 WC:300 0.00000559 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: RXCLEAR 0.00000335 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: TXCLEAR 0.00064980 TunerPro.exe IRP_MJ_WRITE VCP0 SUCCESS Length 1: . 0.01498738 TunerPro.exe IRP_MJ_READ VCP0 SUCCESS Length 1: . 0.00000363 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:200 RM:0 RC:20 WM:0 WC:300 0.02042774 TunerPro.exe IRP_MJ_READ VCP0 TIMEOUT Length 0: That is time on the left side. Now I'm with you on timing, it doesn't make a lot of sense, but that is how the logs come out. You can view the logs yourself. Tunerpro log : http://www.ds-map.net/tunerpro_log.csv My apps log : http://www.ds-map.net/my_log.csv 2nd app log : http://www.ds-map.net/my_log2.csv All these logs, were done from the same car, same cable. I have some older logs with some palm software, that was 13 sensors, and had a total 45-55ms between each set of 13. More info about the car / ecu at http://mmcdlogger.sourceforge.net Disassembly on the ecu: [SS1:SS0] is baud rate divider, 00(16) 01(128) 10(1024) 11(4096), assuming basic clock of 2MHZ, we get 125000baud, 15625baud, 1953baud, 488baud In any event, I attempted a no sleep thread, that waited till in.available > 1, and it wasn't any faster than running the events. Then I tried a read write thread, that slept from 1ms to 30ms after it wrote (so it wouldn't read what it just wrote). And couldn't get it doing much. I wish I had more of an understanding of all of this, which is why I'm asking for help. On 03/08/11 03:00, jfh at greenhousepc.com wrote: > Curtis, > > At the risk of being told "No, they really say it can be done", 30 > sensors is 30 * 3 character times (are you sure it's not a single byte > response?). At 1953 baud, a single character time is 10 bits * (1 / > 1953) seconds, or 15.4ms as Bob pointed out. 30 * 15.4ms is 460ms, > and that assumes everything works perfectly, no turnaround times, etc. > > If you can come up with some other way to make the math work, I'd love > to hear it. > > Short and sweet -- just because TunerPro can talk to an ECM/ECU that > is running faster than 1953 baud doesn't mean your Mitsubishi (or > whatever car you've got that runs at 1953 baud) runs at that faster > baud rate. > > Also, are you sure your data cable is correct? What cable are you > using? What's the schematic? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 2:33 am > To: rxtx at qbang.org > > I am going to try a couple things today and hopefully figure > something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than > 25ms. > I've exchanged some emails with the author and it is a native C, > polling, no events just timeouts. > > Kusta thanks for the FTDI notice, I believe that is tunable, > however I > have a particular user using a Keyspan converter and verified > sampling > rate with 'TunerPro' and its just off the charts. > > Chris thank you, I'll look into the queing. > > On 03/07/11 23:02, Bob Jacobsen wrote: > > If you're transferring three bytes total at 1953 baud, it's going > to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to > wait 20msec to get the data back instead of 15.4 msec doesn't seem > to be as big a problem as you're making it sound. > > > > Bob > > > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > > > >> I guess I'm gunna need some serious help with this then, because > of the scenario I'm stuck with. > >> > >> To communicate there is only 1 data line, rx/tx tied together > with a diode protecting the tx. No RTS/CTS handshaking nothing.. > >> > >> So the ecu can't process the next byte of info, without you > pulling the 2 bytes back. I wish this was standard, but even the > baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard > spot with this.. > >> > >> in.read(data , 0, 2); > >> ^ would the above wait till the timeout to read 2 bytes ? or > read 1 byte wait for the 2nd ? or just read the 1 ?? > >> > >> On 03/07/11 18:50, jfh at greenhousepc.com > wrote: > >>> Curtis, > >>> > >>> No, I assume he means a real queue, not just "don't read all > the bytes at once." However, if you know you can process some > number of requests in some amount of time, allowing data to pile > up (receiver FIFO space permitting) can be a valid strategy. > Inserting gobs of Thread.yield() and notify() can help pep things > up as well. > >>> -- > >>> Julie Haugh > >>> Senior Design Engineer > >>> greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 13:12:03 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 12:12:03 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> Message-ID: <4D768D93.1030504@gmail.com> So I looked over the Tunerpro log again today.. is it me or does it appear to be reusing values ? On 03/08/11 03:00, jfh at greenhousepc.com wrote: > Curtis, > > At the risk of being told "No, they really say it can be done", 30 > sensors is 30 * 3 character times (are you sure it's not a single byte > response?). At 1953 baud, a single character time is 10 bits * (1 / > 1953) seconds, or 15.4ms as Bob pointed out. 30 * 15.4ms is 460ms, > and that assumes everything works perfectly, no turnaround times, etc. > > If you can come up with some other way to make the math work, I'd love > to hear it. > > Short and sweet -- just because TunerPro can talk to an ECM/ECU that > is running faster than 1953 baud doesn't mean your Mitsubishi (or > whatever car you've got that runs at 1953 baud) runs at that faster > baud rate. > > Also, are you sure your data cable is correct? What cable are you > using? What's the schematic? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 2:33 am > To: rxtx at qbang.org > > I am going to try a couple things today and hopefully figure > something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than > 25ms. > I've exchanged some emails with the author and it is a native C, > polling, no events just timeouts. > > Kusta thanks for the FTDI notice, I believe that is tunable, > however I > have a particular user using a Keyspan converter and verified > sampling > rate with 'TunerPro' and its just off the charts. > > Chris thank you, I'll look into the queing. > > On 03/07/11 23:02, Bob Jacobsen wrote: > > If you're transferring three bytes total at 1953 baud, it's going > to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to > wait 20msec to get the data back instead of 15.4 msec doesn't seem > to be as big a problem as you're making it sound. > > > > Bob > > > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > > > >> I guess I'm gunna need some serious help with this then, because > of the scenario I'm stuck with. > >> > >> To communicate there is only 1 data line, rx/tx tied together > with a diode protecting the tx. No RTS/CTS handshaking nothing.. > >> > >> So the ecu can't process the next byte of info, without you > pulling the 2 bytes back. I wish this was standard, but even the > baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard > spot with this.. > >> > >> in.read(data , 0, 2); > >> ^ would the above wait till the timeout to read 2 bytes ? or > read 1 byte wait for the 2nd ? or just read the 1 ?? > >> > >> On 03/07/11 18:50, jfh at greenhousepc.com > wrote: > >>> Curtis, > >>> > >>> No, I assume he means a real queue, not just "don't read all > the bytes at once." However, if you know you can process some > number of requests in some amount of time, allowing data to pile > up (receiver FIFO space permitting) can be a valid strategy. > Inserting gobs of Thread.yield() and notify() can help pep things > up as well. > >>> -- > >>> Julie Haugh > >>> Senior Design Engineer > >>> greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 13:51:13 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 13:51:13 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308135113.8ef0e5b4a80cef441275a6330ffad77d.a5fff5bbc7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From bob_jacobsen at lbl.gov Tue Mar 8 14:14:57 2011 From: bob_jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 8 Mar 2011 14:14:57 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D76848F.5080809@gmail.com> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> Message-ID: <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > Tunerpro log : http://www.ds-map.net/tunerpro_log.csv It's only reading one sensor per line. Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT changed in lines 16 and 40; every 24 lines but at a different phase. GramsRev in lines 23 and 47; every 24 lines, at yet another phase. Looks like (69-1) readings in 1.30 seconds = 19msec per reading. Arithmetic still works! Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From hakcenter at gmail.com Tue Mar 8 14:27:12 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 13:27:12 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> Message-ID: <4D769F30.9050807@gmail.com> Thank you guys, cause I was really worried there. I guess another win for math today hahaha. So what is the imposed latency that rxtx has ? maybe 5-10ms ? On 03/08/11 13:14, Bob Jacobsen wrote: > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > It's only reading one sensor per line. > > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT changed in lines 16 and 40; every 24 lines but at a different phase. GramsRev in lines 23 and 47; every 24 lines, at yet another phase. > > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. Arithmetic still works! > > Bob > -- > Bob Jacobsen, LBNL > Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue Mar 8 14:07:24 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Mar 2011 14:07:24 -0700 (MST) Subject: [Rxtx] Latency Woes In-Reply-To: <4D769F30.9050807@gmail.com> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> <4D769F30.9050807@gmail.com> Message-ID: Hi Curtis While not your exact question, a simple test I performed can give you a ballpark idea. Writing a byte to a loopback at 9600 baud and displaying elapsed time on the data available event takes ~10 ms round trip in a large application. There are occasional 20 ms latencies. I used a typical linux desktop to try it just now without any special considerations. Windows NT was a little faster - maybe 8 ms - when I tried several years ago. On Tue, 8 Mar 2011, Curtis Hacker wrote: > Thank you guys, cause I was really worried there. I guess another win for > math today hahaha. So what is the imposed latency that rxtx has ? maybe > 5-10ms ? > > On 03/08/11 13:14, Bob Jacobsen wrote: >> On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >>> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> It's only reading one sensor per line. >> >> Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT >> changed in lines 16 and 40; every 24 lines but at a different phase. >> GramsRev in lines 23 and 47; every 24 lines, at yet another phase. >> >> Looks like (69-1) readings in 1.30 seconds = 19msec per reading. >> Arithmetic still works! >> >> Bob >> -- >> Bob Jacobsen, LBNL >> Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >> JacobsenRG >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Wei.Shen at Honeywell.com Tue Mar 8 15:15:32 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Tue, 8 Mar 2011 17:15:32 -0500 Subject: [Rxtx] [rxtx] disconnect event Message-ID: <83B3B1411349194D9D05821CEF48E78C02284B17@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 16:05:12 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 16:05:12 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 16:26:15 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 15:26:15 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> References: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> Message-ID: <4D76BB17.2090305@gmail.com> So if I could get the baud up 15625, theoretical maximum latency is 1.92ms ? Basically 500 samples/sec ? 125000, theoretical maximum latency is 0.24ms ? Basically 4167 samples/sec ? Keeping the protocol the same. On 03/08/11 15:05, jfh at greenhousepc.com wrote: > Curtis, > > It's nowhere near that bad. I'd measured it once before, and I > believe it's sub-millisecond. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 3:27 pm > To: rxtx at qbang.org > > Thank you guys, cause I was really worried there. I guess another win > for math today hahaha. So what is the imposed latency that rxtx has ? > maybe 5-10ms ? > > On 03/08/11 13:14, Bob Jacobsen wrote: > > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > > It's only reading one sensor per line. > > > > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 > lines. IAT changed in lines 16 and 40; every 24 lines but at a > different phase. GramsRev in lines 23 and 47; every 24 lines, at > yet another phase. > > > > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. > Arithmetic still works! > > > > Bob > > -- > > Bob Jacobsen, LBNL > > Bob_Jacobsen at lbl.gov > +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Tue Mar 8 17:40:36 2011 From: jredman at ergotech.com (Jim Redman) Date: Tue, 08 Mar 2011 17:40:36 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D76BB17.2090305@gmail.com> References: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> <4D76BB17.2090305@gmail.com> Message-ID: <4D76CC84.9040307@ergotech.com> How long does it take the device to generate a response? Increasing the baud rate may not help you much if the device takes a significant amount of time to process the request. On 03/08/2011 04:26 PM, Curtis Hacker wrote: > So if I could get the baud up > 15625, theoretical maximum latency is 1.92ms ? Basically 500 samples/sec ? > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 samples/sec ? > > Keeping the protocol the same. > > On 03/08/11 15:05, jfh at greenhousepc.com wrote: >> Curtis, >> >> It's nowhere near that bad. I'd measured it once before, and I >> believe it's sub-millisecond. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker > >> Date: Tue, March 08, 2011 3:27 pm >> To: rxtx at qbang.org >> >> Thank you guys, cause I was really worried there. I guess another win >> for math today hahaha. So what is the imposed latency that rxtx has ? >> maybe 5-10ms ? >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> > It's only reading one sensor per line. >> > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 >> lines. IAT changed in lines 16 and 40; every 24 lines but at a >> different phase. GramsRev in lines 23 and 47; every 24 lines, at >> yet another phase. >> > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. >> Arithmetic still works! >> > >> > Bob >> > -- >> > Bob Jacobsen, LBNL >> > Bob_Jacobsen at lbl.gov >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 jfh at greenhousepc.com Tue Mar 8 17:58:24 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 17:58:24 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 18:06:04 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 18:06:04 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 18:14:14 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 17:14:14 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> References: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> Message-ID: <4D76D466.7060303@gmail.com> I can edit the ECU eeprom to change the baud rate divisor to bump it up from 1953, to 15625 or 125000. But as Jim asked how fast the device can respond.. not very fast in its stock form. I can recode a lot of the eeprom for the ecu to alter the ecus baud rate, and put the response code into its own interrupt. I just wanted to make sure that in order to lower latency and increase sampling rate. I have to increase the baud rate of the ecu and the user right ? Or change the protocol.. to respond with more sensors per request. On 03/08/11 16:58, jfh at greenhousepc.com wrote: > Unless the ECU can auto-detect the baud rate, it won't even work. > > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Jim Redman > > Date: Tue, March 08, 2011 6:40 pm > To: rxtx at qbang.org > > How long does it take the device to generate a response? > > Increasing the baud rate may not help you much if the device takes a > significant amount of time to process the request. > > > On 03/08/2011 04:26 PM, Curtis Hacker wrote: > > So if I could get the baud up > > 15625, theoretical maximum latency is 1.92ms ? Basically 500 > samples/sec ? > > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 > samples/sec ? > > > > Keeping the protocol the same. > > > > On 03/08/11 15:05, jfh at greenhousepc.com > wrote: > >> Curtis, > >> > >> It's nowhere near that bad. I'd measured it once before, and I > >> believe it's sub-millisecond. > >> -- > >> Julie Haugh > >> Senior Design Engineer > >> greenHouse Computers, LLC // jfh at greenhousepc.com > > >> ; // > greenHousePC on Skype > >> > >> > >> -------- Original Message -------- > >> Subject: Re: [Rxtx] Latency Woes > >> From: Curtis Hacker > > >> Date: Tue, March 08, 2011 3:27 pm > >> To: rxtx at qbang.org > >> > >> Thank you guys, cause I was really worried there. I guess > another win > >> for math today hahaha. So what is the imposed latency that rxtx > has ? > >> maybe 5-10ms ? > >> > >> On 03/08/11 13:14, Bob Jacobsen wrote: > >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > >> > It's only reading one sensor per line. > >> > > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 > >> lines. IAT changed in lines 16 and 40; every 24 lines but at a > >> different phase. GramsRev in lines 23 and 47; every 24 lines, at > >> yet another phase. > >> > > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. > >> Arithmetic still works! > >> > > >> > Bob > >> > -- > >> > Bob Jacobsen, LBNL > >> > Bob_Jacobsen at lbl.gov > > >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > >> > > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Tue Mar 8 18:19:14 2011 From: jredman at ergotech.com (Jim Redman) Date: Tue, 08 Mar 2011 18:19:14 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> References: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> Message-ID: <4D76D592.9000802@ergotech.com> I'm no expert on this, but isn't the underlying ODB-II CAN bus or something similar. They always seem to require a dongle that converts to something. I know you can get serial, bluetooth, USB, etc. converters. I've seen serial dongles that claim multiple baud rates, so I suspect that whatever's providing the conversion may significantly affect the performance. A big second on the required timing comment. I suspect some intelligent consideration of what values change quickly (RPM, Speed, maybe things like fuel pressure) and read values like fuel levels, coolant temps, etc. much less frequently. On 03/08/2011 06:06 PM, jfh at greenhousepc.com wrote: > Curtis, > > You can't just increase the baud rate and have the device adapt to that > rate. Embedded systems tend to have their communications parameters > either hard coded in a memory location or else they are using a hardware > timebase. You're welcome to try increasing the baud rate, but there is > no guarantee it will even work. > > Whoever designed the ECU probably selected the baud rate for a good > reason. My suggestion would be to look at how the sensor values are all > laid out and go from there. Also, look at what the sensor represent and > consider the physical properties of what is being measured. It's > extremely unlikely that, for example, the coolant temperature is going > to rise more than 1* per second. If that much. Some values might change > more often, but do they really matter on a sub-second measurement basis? > > Part of software =engineering= is understanding the problem. Anyone can > sling code in the hope it works. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 5:26 pm > To: rxtx at qbang.org > > So if I could get the baud up > 15625, theoretical maximum latency is 1.92ms ? Basically 500 > samples/sec ? > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 > samples/sec ? > > Keeping the protocol the same. > > On 03/08/11 15:05, jfh at greenhousepc.com wrote: >> Curtis, >> >> It's nowhere near that bad. I'd measured it once before, and I >> believe it's sub-millisecond. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker > > >> Date: Tue, March 08, 2011 3:27 pm >> To: rxtx at qbang.org >> >> Thank you guys, cause I was really worried there. I guess >> another win >> for math today hahaha. So what is the imposed latency that >> rxtx has ? >> maybe 5-10ms ? >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> > It's only reading one sensor per line. >> > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every >> 24 lines. IAT changed in lines 16 and 40; every 24 lines but >> at a different phase. GramsRev in lines 23 and 47; every 24 >> lines, at yet another phase. >> > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per >> reading. Arithmetic still works! >> > >> > Bob >> > -- >> > Bob Jacobsen, LBNL >> > Bob_Jacobsen at lbl.gov >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > ------------------------------------------------------------------------ > _______________________________________________ > Rxtx mailing list > Rxtx 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 jfh at greenhousepc.com Tue Mar 8 18:32:28 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 18:32:28 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 19:45:00 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 18:45:00 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> References: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> Message-ID: <4D76E9AC.8050909@gmail.com> Julie, I really am not looking at the practicality of it. I was just wondering if that is how it works. I don't know a whole lot about rs232, which is the main reason I've been on this mailing list for a couple years. I have full control over the ecu eeprom code, I can change its baud rate, I can re-write the logging interface, I could update the ADC's on the ecu in the interface so that when you request said sensor it updates the ADC then replies it. But I wanted to know if the underlying issue with a 2mhz/8mhz processor is the baud rate keeping sampling down ? On 03/08/11 17:32, jfh at greenhousepc.com wrote: > Curtis, > > You also have to look at the response time of the sensor itself. > > Seriously -- look at what the sensors are reporting and determine if > the underlying physical property can actually change that rapidly. > And even if it can, do you really need to know that. > > I built drag bikes in the 70's and I drive sports cars in my old age. > You don't really need millisecond sampling rates for every single last > sensor coming out of the engine. Boost pressure, fuel pressure, > manifold pressure and RPMs are probably high frequency sensors if you > want to tweak the motor for turbo lag or something, but other than > that, are you really going to be able to make sense of all that data? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 7:14 pm > To: rxtx at qbang.org > > I can edit the ECU eeprom to change the baud rate divisor to bump > it up from 1953, to 15625 or 125000. But as Jim asked how fast the > device can respond.. not very fast in its stock form. > > I can recode a lot of the eeprom for the ecu to alter the ecus > baud rate, and put the response code into its own interrupt. > > I just wanted to make sure that in order to lower latency and > increase sampling rate. I have to increase the baud rate of the > ecu and the user right ? Or change the protocol.. to respond with > more sensors per request. > > On 03/08/11 16:58, jfh at greenhousepc.com wrote: >> Unless the ECU can auto-detect the baud rate, it won't even work. >> >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Jim Redman > > >> Date: Tue, March 08, 2011 6:40 pm >> To: rxtx at qbang.org >> >> How long does it take the device to generate a response? >> >> Increasing the baud rate may not help you much if the device >> takes a >> significant amount of time to process the request. >> >> >> On 03/08/2011 04:26 PM, Curtis Hacker wrote: >> > So if I could get the baud up >> > 15625, theoretical maximum latency is 1.92ms ? Basically 500 >> samples/sec ? >> > 125000, theoretical maximum latency is 0.24ms ? Basically >> 4167 samples/sec ? >> > >> > Keeping the protocol the same. >> > >> > On 03/08/11 15:05, jfh at greenhousepc.com >> wrote: >> >> Curtis, >> >> >> >> It's nowhere near that bad. I'd measured it once before, and I >> >> believe it's sub-millisecond. >> >> -- >> >> Julie Haugh >> >> Senior Design Engineer >> >> greenHouse Computers, LLC // jfh at greenhousepc.com >> >> >> ; // >> greenHousePC on Skype >> >> >> >> >> >> -------- Original Message -------- >> >> Subject: Re: [Rxtx] Latency Woes >> >> From: Curtis Hacker > > >> >> Date: Tue, March 08, 2011 3:27 pm >> >> To: rxtx at qbang.org >> >> >> >> >> Thank you guys, cause I was really worried there. I guess >> another win >> >> for math today hahaha. So what is the imposed latency that >> rxtx has ? >> >> maybe 5-10ms ? >> >> >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> >> > It's only reading one sensor per line. >> >> > >> >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; >> every 24 >> >> lines. IAT changed in lines 16 and 40; every 24 lines but at a >> >> different phase. GramsRev in lines 23 and 47; every 24 >> lines, at >> >> yet another phase. >> >> > >> >> > Looks like (69-1) readings in 1.30 seconds = 19msec per >> reading. >> >> Arithmetic still works! >> >> > >> >> > Bob >> >> > -- >> >> > Bob Jacobsen, LBNL >> >> > Bob_Jacobsen at lbl.gov >> >> >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Rxtx mailing list >> >> > Rxtx at qbang.org >> >> >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > ------------------------------------------------------------------------ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 20:43:11 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 20:43:11 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308204311.8ef0e5b4a80cef441275a6330ffad77d.e9b135168c.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From andrea.antonello at gmail.com Wed Mar 9 06:50:07 2011 From: andrea.antonello at gmail.com (andrea antonello) Date: Wed, 9 Mar 2011 14:50:07 +0100 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> References: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> Message-ID: Has anyone tried the lib? I am not sure if it is appropriate to write to the list about this, if not, I apologize. I wanted to try your fork out for our application which is an eclipse rcp plugin based one. It has been easy to substitute the 6 plugins with your library (that is one of the things I like). But then when I run it, it tries to load it from: ---- Loading: /tmp/libNRJavaSerial_moovida_0/libNRJavaSerial.so Trying to load: NRJavaSerial Trying to load: libNRJavaSerial Trying to load: rxtxSerial ---- So it is extracting the native lib to a tmp folder. But that one is not in the library path, so it fails. Is there any docs to try the lib out? Thanks, Andrea On Mon, Mar 7, 2011 at 11:54 PM, wrote: > Aaron, > > It should be possible for an Android to do BlueTooth serial.? If I were > looking for a serial solution, that's how I'd go. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on > Skype > > -------- Original Message -------- > Subject: [SPAM] Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > papercuts! > From: Aaron Wolfe > Date: Mon, March 07, 2011 4:31 pm > To: rxtx at qbang.org > > On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR > wrote: >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> >> * Self deployment of native libraries ( all native code is stored >> inside the jar and deployed at runtime). No more manual install of >> native code. >> * Arm Cortex support (Gumstix) >> * Android Support (requires a rooted phone for now) >> * Google Code (SVN) repository for easy code and jar access >> * Single makefile compile (simplifies the compilation of project binaries) >> * Ant build script for jar creation >> * Removal of partialy implemented code to streamline the lib for just >> serial port access >> * Full Eclipse integration, for testing application code against sources. >> >> And a bunch of bug fixes: >> >> * Fixed the memory access error that causes OSX to crash the JVM when >> serial.close() is cvalled >> * Fixed the windows serial port zombie bind that prevents re-accessing >> serial ports when exiting on an exception >> * Fixed erronious printouts of native library mis-match >> >> To check it out, take a look at our page here: >> >> http://code.google.com/p/nrjavaserial/ > > This is interesting, getting the native libs set up has been an issue > for some of my users. Will have to check it out. > > Out of curiosity, what Android devices provide a serial port? Or are > there some that allow USB host mode and then a usb-serial adapter? I > have only an Android cell phone, don't think it can do anything serial > but would love to be wrong 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 Cougar at CasaDelGato.Com Wed Mar 9 10:02:24 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 09 Mar 2011 09:02:24 -0800 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> References: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> Message-ID: <4D77B2A0.8020004@CasaDelGato.Com> On 3/7/2011 2:54 PM, jfh at greenhousepc.com wrote: > Aaron, > > It should be possible for an Android to do BlueTooth serial. If I > were looking for a serial solution, that's how I'd go. Actually, I can't figure out WHY you would need RxTx on an Android device. The built in bluetooth support works just fine with a serial-bluetooth converter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Mar 1 00:54:17 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 09:54:17 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> Message-ID: Adrian, had a look at your code/rewrite and it looks rather clean/nice. I was looking at the code to gain insight (not related to the rewrite) into what is involved in serial port programming in Windows. Or rather, to refresh my memory and see how others have done, because I've been there done that. So my questions are just to satisfy my curiosity, not to criticize or suggest improvements. 1) It looks like a new thread (EventMonitor) is created for each Serial port, is that correct? Many people seem to try to avoid using many threads in this sort of situation, and like to use something like unix select(). I personally find using threads more natural and better impedance match to the problem being solved here. I guess 'many people' above refers to those implementing thousands of connections and who cannot live with the overhead and limited number of threads available. 2) The EventMonitor basically polls for events at 50 msec interval? 3) There is a comment in the source code near the sleep(50) : // Sufficient up to 19200 baud I'm sure you thought about this carefully, so again not criticizing, but seeking to understand how or why, because at 50 msec would seem to limit through in some cases. Like if you send one byte and need to wait for one to return, then this limits speed to 200 chars/sec? 4) I've done something similar to a few years back from Java using JNI to access Win32 API serial port, and I seem to recall that I had threading issues ie when I submitted a read (ReadFile) and there was no data coming in, the thread would not only block but also consume a lot of CPU cycles ie it was not sleeping properly inside the ReadFile call when the serial port blocked. Im a bit fuzzy about the details after five years, so my question is have you checked if there an issue here? 5) AFAIK the select() on Windows does not work serial ports but there is some other mechanism (events?) to implement the same functionality, did you consider that? Probably, so you decided against it, why? br Kusti From adrian.crum at sandglass-software.com Tue Mar 1 04:13:34 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:13:34 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: References: Message-ID: <4D6CD4DE.7040501@sandglass-software.com> The javax.comm API specification requires one event monitor thread per port. I don't like the idea of having a thread per port either, but one of the rewrite's design goals is strict conformance to the specification. The 50 mS polling interval is just a placeholder. The final design of that is yet to be decided. In Windows, you have two choices for I/O: overlapped and non-overlapped. In overlapped I/O a thread is blocked, waiting for something to happen. In non-overlapped I/O a thread does not block. I chose non-overlapped I/O to avoid thread blocking at the OS level - instead, the thread blocking is kept in Java. -Adrian On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > Adrian, > > had a look at your code/rewrite and it looks rather clean/nice. > > I was looking at the code to gain insight (not related to the > rewrite) into what is involved in serial port programming > in Windows. Or rather, to refresh my memory and see how others have > done, because I've been there done that. > > So my questions are just to satisfy my curiosity, not to criticize > or suggest improvements. > > 1) It looks like a new thread (EventMonitor) is created for > each Serial port, is that correct? > > Many people seem to try to avoid using many threads in this sort > of situation, and like to use something like unix select(). > I personally find using threads more natural and better impedance > match to the problem being solved here. I guess 'many people' above > > refers to those implementing thousands of connections and > who cannot live with the overhead and limited number of threads > available. > > 2) The EventMonitor basically polls for events at 50 msec interval? > > 3) There is a comment in the source code near the sleep(50) : > > // Sufficient up to 19200 baud > > > I'm sure you thought about this carefully, so again not > criticizing, but seeking to understand how or why, because > at 50 msec would seem to limit through in some cases. Like > if you send one byte and need to wait for one to return, > then this limits speed to 200 chars/sec? > > 4) I've done something similar to a few years back from > Java using JNI to access Win32 API serial port, and > I seem to recall that I had threading issues ie when > I submitted a read (ReadFile) and there was no data coming > in, the thread would not only block but also consume a > lot of CPU cycles ie it was not sleeping properly inside > the ReadFile call when the serial port blocked. > > Im a bit fuzzy about the details after five years, so my question is > have you checked if there an issue here? > > > 5) AFAIK the select() on Windows does not work serial ports > but there is some other mechanism (events?) to implement the > same functionality, did you consider that? Probably, so you > decided against it, why? > > > br Kusti > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Tue Mar 1 04:25:23 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:25:23 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C2E90.9010601@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > My question would be: Why would you do that? The rewrite does > most of the work for you - all you have to do is implement > two C++ virtual classes and two C++ functions. You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? I just took a short look, maybe it could be discussed further, but I don't think I like it much. BTW, the main interface defined there is called gnu.io.Dispatcher? I thought the package names should be used in a way to avoid clashes, e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name space authority :)). > In Windows that took me a few hours. where is the implementation? I found commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp with things like const bool SerialPortImpl::isDataAvailable() const { // Needs implementation return true; } and timeouts.ReadIntervalTimeout = MAXDWORD;* timeouts.ReadTotalTimeoutMultiplier = 0; timeouts.ReadTotalTimeoutConstant = 0; timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 0; if (!SetCommTimeouts(hComm, &timeouts)) throw IOException(); which seems to be oversimplified or some prototype only? I think (and I wrote about this already in the past years) that correct timeout handling is one of the challenges, so I think this should be prototyped first - for each system flavor - before cementation of the (JNI-) interfaces. Personally, I would vote to form it in a way allowing to be implemented on embedded devices, for example. Another big challenge is to prove a rewrite fully working (and probably compatible to the old implementation) on "all" the supported OSes. Not a big problem for linux and windows, just use some thousand lines test code, test drivers and serial loopbacks etc, but for the exotic platforms, probably a high number of, this probably won't be too easy... (there are more challenges, such as being comfortable and threadsafe [are read and write permitted at the same time?], detailed and helpful exceptions on user API level [not necessarily on JNI/JNA layer], how to have a configurable threadsafe logging/tracing [maybe also from native code to assist porting / testing on exotic OSes, such as OSes where the developers have no direct access too, which can be quite hard to usually leads to good log messages], just to name a few.). So even it might seem easy for one platform and I agree with Micheal that > > * yay! let's start a rewrite is unlikely to succeede soon... However, when considering this, before IMHO a powerful Java API has to be defined, because according to my experiences for implementing non-trivial protocols InputStream/OutputStream might not be comfortable/powerfull enough (eventually I consider both wrong) and have some InputStream derivation available as wrapper (so applications can use InputStream and whatever high-level-API they want). The JNI interface shall make such a powerful implementation possible, thus the interface of it is driving the JNI interface design and thus I think it had to be done first. All this surely requires much work: agreements on the APIs, safeness for the users, design, documentation, all the implementations and the testing. As long as such bug amount of work cannot be spent, for example if some employee would get half a year time paid for it or so :-), probably it is unlikely to progress on this. Otherwise, I'm afraid, patches, improvements, new design ideas and even rewrites wouldn't become complete and thus won't form a new rxtx version (3.0); thus either collect dust in some forgotten CVS branch or could generate a split... > I can't imagine other ports taking > much longer than that - especially since POSIX-based code can > be shared between ports. Things are more complex than they seem to be... I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select on serial ports isn't supported; maybe it is non-trivial to "map" (like mapping select() to WaitForMultipleObjects() which might have different semantics etc.) or maybe some different approach has to be used. A system may have POSIX like termios interfaces but not support timeouts or have any other interoperability bug... You never run out of things that can go wrong. And if something can go wrong, it will... :-) Or, as Michael wrote: > > I seriously don't believe anyone will come up with anything better anytime soon. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue Mar 1 04:39:37 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:39:37 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com><13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED6B@COSNPREXC3.usr.ingenico.loc> > 3. Write all of the native (or non-native) code to implement > the native interface. > > Is that correct? If yes, how is that easier than the simple > implementation the current rewrite design uses? To have it complete, reliable, traceable, maintainable and well tested, it is much more work, I'm afraid. A prototype can be done within a few days (maybe on one day), but getting it right (including a passed review) IMHO is a completely different story. In the end you may end up with an average of ten lines per day, when assuming four major native packs (common, win, mac, termios/select) with let's say just 5000 lines each (with logging messages and detailed exceptions this is not much) we would have to estimate a total effort of nine man-years (20000/10/220)... oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 04:40:18 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:40:18 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6CDB22.9070401@sandglass-software.com> Every journey begins with a single step. -Adrian On 3/1/2011 3:25 AM, Steffen DETTMER wrote: > * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> My question would be: Why would you do that? The rewrite does >> most of the work for you - all you have to do is implement >> two C++ virtual classes and two C++ functions. > You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? > I just took a short look, maybe it could be discussed further, > but I don't think I like it much. > BTW, the main interface defined there is called gnu.io.Dispatcher? > I thought the package names should be used in a way to avoid clashes, > e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name > space authority :)). > >> In Windows that took me a few hours. > where is the implementation? > I found > commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp > with things like > > const bool SerialPortImpl::isDataAvailable() const > { > // Needs implementation > return true; > } > > and > > timeouts.ReadIntervalTimeout = MAXDWORD;* > timeouts.ReadTotalTimeoutMultiplier = 0; > timeouts.ReadTotalTimeoutConstant = 0; > timeouts.WriteTotalTimeoutMultiplier = 0; > timeouts.WriteTotalTimeoutConstant = 0; > if (!SetCommTimeouts(hComm,&timeouts)) > throw IOException(); > > which seems to be oversimplified or some prototype only? > > I think (and I wrote about this already in the past years) that correct > timeout handling is one of the challenges, so I think this should be > prototyped first - for each system flavor - before cementation of the > (JNI-) interfaces. Personally, I would vote to form it in a way allowing > to be implemented on embedded devices, for example. > > Another big challenge is to prove a rewrite fully working (and probably > compatible to the old implementation) on "all" the supported OSes. Not a > big problem for linux and windows, just use some thousand lines test > code, test drivers and serial loopbacks etc, but for the exotic > platforms, probably a high number of, this probably won't be too easy... > (there are more challenges, such as being comfortable and threadsafe > [are read and write permitted at the same time?], detailed and helpful > exceptions on user API level [not necessarily on JNI/JNA layer], how to > have a configurable threadsafe logging/tracing [maybe also from native > code to assist porting / testing on exotic OSes, such as OSes where the > developers have no direct access too, which can be quite hard to usually > leads to good log messages], just to name a few.). > > So even it might seem easy for one platform and I agree with Micheal > that > >>> * yay! let's start a rewrite > is unlikely to succeede soon... > > However, when considering this, before IMHO a powerful Java API has to > be defined, because according to my experiences for implementing > non-trivial protocols InputStream/OutputStream might not be > comfortable/powerfull enough (eventually I consider both wrong) and have > some InputStream derivation available as wrapper (so applications can > use InputStream and whatever high-level-API they want). > The JNI interface shall make such a powerful implementation possible, > thus the interface of it is driving the JNI interface design and thus I > think it had to be done first. > > All this surely requires much work: agreements on the APIs, safeness for > the users, design, documentation, all the implementations and the > testing. As long as such bug amount of work cannot be spent, for example > if some employee would get half a year time paid for it or so :-), > probably it is unlikely to progress on this. > > Otherwise, I'm afraid, patches, improvements, new design ideas and even > rewrites wouldn't become complete and thus won't form a new rxtx version > (3.0); thus either collect dust in some forgotten CVS branch or could > generate a split... > >> I can't imagine other ports taking >> much longer than that - especially since POSIX-based code can >> be shared between ports. > Things are more complex than they seem to be... > > I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select > on serial ports isn't supported; maybe it is non-trivial to "map" (like > mapping select() to WaitForMultipleObjects() which might have different > semantics etc.) or maybe some different approach has to be used. A > system may have POSIX like termios interfaces but not support timeouts > or have any other interoperability bug... > You never run out of things that can go wrong. And if something can go > wrong, it will... :-) > > Or, as Michael wrote: > >>> I seriously don't believe anyone will come up with anything better > anytime soon. > > oki, > > Steffen > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Kustaa.Nyholm at planmeca.com Tue Mar 1 04:57:02 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 13:57:02 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: On 3/1/11 13:13, "Adrian Crum" wrote: >The javax.comm API specification requires one event monitor thread per >port. I don't like the idea of having a thread per port either, but one >of the rewrite's design goals is strict conformance to the specification. Ah, had not spotted that requirement. > >The 50 mS polling interval is just a placeholder. The final design of >that is yet to be decided. > >In Windows, you have two choices for I/O: overlapped and non-overlapped. >In overlapped I/O a thread is blocked, waiting for something to happen. >In non-overlapped I/O a thread does not block. I chose non-overlapped >I/O to avoid thread blocking at the OS level - instead, the thread >blocking is kept in Java. > >-Adrian thanks for the explanation. br Kusti From iqzw2r602 at sneakemail.com Tue Mar 1 05:08:17 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:08:17 +1100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <32684-1298981297-704398@sneakemail.com> This reminds me of a nasty problem I had with overlapped I/O on windows with jpathwatch. You can't start an I/O request in one thread and then do the check if that request completed in another thread. Very strange things happen when you attempt that; made me change the design of the Windows implementation quite drastically (one thread on a command queue that executes requests from other threads instead of letting them wildly call into GetOverlappedResult()). Out of curiosity: Did you come across that too? Or are all requests handled in the same thread they're issued? Cheers, Uwe On Tue, Mar 1, 2011 at 10:13 PM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > The javax.comm API specification requires one event monitor thread per > port. I don't like the idea of having a thread per port either, but one of > the rewrite's design goals is strict conformance to the specification. > > The 50 mS polling interval is just a placeholder. The final design of that > is yet to be decided. > > In Windows, you have two choices for I/O: overlapped and non-overlapped. In > overlapped I/O a thread is blocked, waiting for something to happen. In > non-overlapped I/O a thread does not block. I chose non-overlapped I/O to > avoid thread blocking at the OS level - instead, the thread blocking is kept > in Java. > > -Adrian > > > On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > >> Adrian, >> >> had a look at your code/rewrite and it looks rather clean/nice. >> >> I was looking at the code to gain insight (not related to the >> rewrite) into what is involved in serial port programming >> in Windows. Or rather, to refresh my memory and see how others have >> done, because I've been there done that. >> >> So my questions are just to satisfy my curiosity, not to criticize >> or suggest improvements. >> >> 1) It looks like a new thread (EventMonitor) is created for >> each Serial port, is that correct? >> >> Many people seem to try to avoid using many threads in this sort >> of situation, and like to use something like unix select(). >> I personally find using threads more natural and better impedance >> match to the problem being solved here. I guess 'many people' above >> >> refers to those implementing thousands of connections and >> who cannot live with the overhead and limited number of threads >> available. >> >> 2) The EventMonitor basically polls for events at 50 msec interval? >> >> 3) There is a comment in the source code near the sleep(50) : >> >> // Sufficient up to 19200 baud >> >> >> I'm sure you thought about this carefully, so again not >> criticizing, but seeking to understand how or why, because >> at 50 msec would seem to limit through in some cases. Like >> if you send one byte and need to wait for one to return, >> then this limits speed to 200 chars/sec? >> >> 4) I've done something similar to a few years back from >> Java using JNI to access Win32 API serial port, and >> I seem to recall that I had threading issues ie when >> I submitted a read (ReadFile) and there was no data coming >> in, the thread would not only block but also consume a >> lot of CPU cycles ie it was not sleeping properly inside >> the ReadFile call when the serial port blocked. >> >> Im a bit fuzzy about the details after five years, so my question is >> have you checked if there an issue here? >> >> >> 5) AFAIK the select() on Windows does not work serial ports >> but there is some other mechanism (events?) to implement the >> same functionality, did you consider that? Probably, so you >> decided against it, why? >> >> >> br Kusti >> >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 05:37:07 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:37:07 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <1142-1298983027-957144@sneakemail.com> On Tue, Mar 1, 2011 at 1:32 PM, Adrian Crum wrote: > Just to make sure I'm understanding you correctly, anyone porting RxTx to > a new platform would have to do the following: > > 1. Write their own Java implementation of an abstract Dispatcher class. > yep. I'd probably put all my calls to native OS wrappers in there two, looks the most straight-forward to me. > 2. Write a native (JNI or JNA) interface for the abstract class > implementation. > yes. For POSIX you'd probably only write one piece of code that provides implementations for open(), close(), and friends. You can compile that on all posix platforms (yeah, the devil is in the detail, but it's very little code, still). So this does open() (when using ***, but you can also use +++) // Unix.java class Unix{ public static native int open(String filename, int flags, int mode); .... } // Unix.cpp JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) { const char* pathname = env->GetStringUTFChars(jpathname, 0); if(pathname == 0) return -1; // java throws an out of memory error in this case int result = open(pathname, flags, mode); Unix_cacheErrno(); // handle interference between JVM and errno; env->ReleaseStringUTFChars(jpathname, pathname); return result; } .... 3. Write all of the native (or non-native) code to implement the native > interface. > Not sure what you mean by that. I've done the OS wrappers in step 2. step 1. implements that Dispatcher. What else do I need? > Is that correct? If yes, how is that easier than the simple implementation > the current rewrite design uses? > Yes, except for 3 (see above). How it is easier: I can debug the Java code directly. I can step from the read() call of an input stream directly into the guts of the RXTX implementation on my platform and see e.g. why it's hanging, because I see all the way up the call stack right where it calls Unix.read(). You can't easily do that with a fat native library, especially if you have no second set of devtools installed (the ones for native development). And I bet anyone knowing both languages can write it faster in Java, with less bugs. > On a side note: there is no requirement to write native code using C++. If > C++ is a real obstacle to adoption, then regular C could be used instead. In > that case, there would be a Dispatcher.c file that contains function > protoypes that need to be implemented. Dispatcher.c would still maintain the > same role as Dispatcher.cpp - which is to shield native code developers from > the details of JNI. Just build out the missing functions using C data types > and you're ready to go. > As I said, whatever works for you. Java works for me better than C++ in this case... Cheers, Uwe -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Mar 1 08:26:41 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 16:26:41 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> > The javax.comm API specification requires one event monitor > thread per port. Where does it require this? Do you mean "All the events received by this listener are generated by one dedicated thread that belongs to the SerialPort object. "? I think this is an implementation detail, isn't it? At least it is mentioned after "The current implementation only allows one listener per SerialPort". A bit bad that javadoc does not distinguish between API spec and implementation documentation. Also I don't think that TooManyListenersException MUST be thrown (I think it CAN be thrown). > I don't like the idea of having a thread per > port either, but one of the rewrite's design goals is strict > conformance to the specification. (but not necessarily on JNI layer) > The 50 mS polling interval is just a placeholder. The final > design of that is yet to be decided. I though no polling would be wanted; what could be the placeholder stand for? Do you mean a different interval duration or do you mean something completely different? > In Windows, you have two choices for I/O: overlapped and > non-overlapped. > In overlapped I/O a thread is blocked, waiting for something > to happen. > In non-overlapped I/O a thread does not block. I chose > non-overlapped I/O to avoid thread blocking at the OS level - > instead, the thread blocking is kept in Java. Isn't "overlapped" (asynchronous) I/O meaning that you invoke some ReadFile(..., &overlapped, ...) INSTEAD of performing a synchronous (blocking) function call blocking the thread? As far as I see, W32_Support.cpp uses CreateFile without FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O operations are serialized, even if the calls to the read and write functions specify an OVERLAPPED structure." [1] and "A synchronous handle behaves such that I/O function calls using that handle are blocked until they complete" [2] Given that CCOMTIMEOUTS get: "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the bytes that have already been received, even if no bytes have been received." [3] It looks likes this implementation relies on polling, which probably would waste much computing power. What did I miss? oki, Steffen [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro nous_and_asynchronous_i_o_handles [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 09:23:47 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:23:47 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6D1D93.6090306@sandglass-software.com> Unfortunately, the javax.comm API specification includes a lot of implementation details. That is one of the weaknesses of the specification in my opinion. The bottom line is, anyone wanting to use RxTx as a javax.comm implementation is going to expect it to do the things the specification says it does. -Adrian On 3/1/2011 7:26 AM, Steffen DETTMER wrote: >> The javax.comm API specification requires one event monitor >> thread per port. > Where does it require this? > > Do you mean "All the events received by this listener are generated > by one dedicated thread that belongs to the SerialPort object. "? > > I think this is an implementation detail, isn't it? At least it is > mentioned after "The current implementation only allows one listener per > SerialPort". A bit bad that javadoc does not distinguish between API > spec and implementation documentation. Also I don't think that > TooManyListenersException MUST be thrown (I think it CAN be thrown). > >> I don't like the idea of having a thread per >> port either, but one of the rewrite's design goals is strict >> conformance to the specification. > (but not necessarily on JNI layer) > >> The 50 mS polling interval is just a placeholder. The final >> design of that is yet to be decided. > I though no polling would be wanted; what could be the placeholder stand > for? Do you mean a different interval duration or do you mean something > completely different? > >> In Windows, you have two choices for I/O: overlapped and >> non-overlapped. >> In overlapped I/O a thread is blocked, waiting for something >> to happen. >> In non-overlapped I/O a thread does not block. I chose >> non-overlapped I/O to avoid thread blocking at the OS level - >> instead, the thread blocking is kept in Java. > Isn't "overlapped" (asynchronous) I/O meaning that you invoke some > ReadFile(...,&overlapped, ...) > INSTEAD of performing a synchronous (blocking) function call blocking > the thread? > > As far as I see, W32_Support.cpp uses CreateFile without > FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O > operations are serialized, even if the calls to the read and write > functions specify an OVERLAPPED structure." [1] and "A synchronous > handle behaves such that I/O function calls using that handle are > blocked until they complete" [2] > > Given that CCOMTIMEOUTS get: > "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values > for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier > members, specifies that the read operation is to return immediately with > the bytes that have already been received, even if no bytes have been > received." [3] > > It looks likes this implementation relies on polling, which probably > would waste much computing power. > > What did I miss? > > oki, > > Steffen > > [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx > [2] > http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro > nous_and_asynchronous_i_o_handles > [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at sandglass-software.com Tue Mar 1 09:55:29 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:55:29 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <1142-1298983027-957144@sneakemail.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> Message-ID: <4D6D2501.1020803@sandglass-software.com> That code duplicates what is in Dispatcher.cpp. A Unix port would only need to implement CommPortFactory::getInstance(portName, portType). -Adrian On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 15:07:46 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 2 Mar 2011 09:07:46 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6D2501.1020803@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> <4D6D2501.1020803@sandglass-software.com> Message-ID: <23749-1299017266-991798@sneakemail.com> What is this duplicating? A Unix port will need to call open() anyways (just so we're talking about the same thing here: open() is the Unix equivalent of CreateFile()) On Wed, Mar 2, 2011 at 3:55 AM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > That code duplicates what is in Dispatcher.cpp. A Unix port would only > need to implement CommPortFactory::getInstance(portName, portType). > > -Adrian > > > On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Tue Mar 1 22:53:07 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 00:53:07 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: Hi, I haven't seen any response to my question below. Is this not the right place to ask? If not, where would be a better place to ask? Any suggestions? Thanks, Ryan On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >> Hi, >> >> I have a receive thread that does nothing but call read() on the serial >> port input stream. It works fine for a while but after running for a long >> time it eventually returns -1 which means EOF. This is my first problem, as >> the device I'm talking to runs forever, I don't know why it would return -1. >> I am calling disableReceiveThreshold() and disableReceiveTimeout() at >> initialization which according to the documentation means read will return >> as soon as any data is available and it will block forever when data is not >> available, so -1 should never be returned from read, right? >> >> I have been unable to figure out why read returns -1 after a long while >> but I have found that if I kill my application and restart it everything >> works fine again. Therefore I tried to work around the problem by having my >> code close the port and reopen it when read returns -1. My second problem is >> that in this case when I call close() on the port it blocks forever. I did >> find this old bug >> >> http://bugzilla.qbang.org/show_bug.cgi?id=53 >> >> which describes close() hanging on OSX, but it says that bug was fixed >> with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have >> any idea why read might be returning -1 in the first place? If I can avoid >> that I don't care about close() hanging because I would never close the >> port. If not, does anyone know why close() might block forever and how I can >> prevent this? I'm using RXTX version 2.1-7. >> >> Thanks, >> -- >> Ryan >> >> > > > -- > Ryan Boder > 1 614 598-6339 > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Mar 2 01:34:48 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 2 Mar 2011 10:34:48 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/2/11 07:53, "Ryan Boder" wrote: Can you / have you made a simple test to ensure that rxtx is the issue? Can you write a simple C-program to see if this exhibits the same problem? I've never encountered this sort of problem with rxtx, it mostly just works. But I'm on Mac so can't say about Windows (7) br Kusti >Hi, > >I haven't seen any response to my question below. Is this not the right >place to ask? If not, where would be a better place to ask? Any >suggestions? > >Thanks, >Ryan > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > >I mis-spoke, I don't have my own thread calling read, I am calling >read in the event handler after receiving a >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be >accurate though. > >Ryan > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >Hi, > >I have a receive thread that does nothing but call read() on the serial >port input stream. It works fine for a while but after running for a long >time it eventually returns -1 which means EOF. This is my first problem, >as the device I'm talking to runs forever, I don't know why it would >return -1. I am calling disableReceiveThreshold() and >disableReceiveTimeout() at initialization which according to the >documentation means read will return as soon as any data is available and >it will block forever when data is not available, so -1 should never be >returned from read, right? > >I have been unable to figure out why read returns -1 after a long while >but I have found that if I kill my application and restart it everything >works fine again. Therefore I tried to work around the problem by having >my code close the port and reopen it when read returns -1. My second >problem is that in this case when I call close() on the port it blocks >forever. I did find this old bug > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > >which describes close() hanging on OSX, but it says that bug was fixed >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone >have any idea why read might be returning -1 in the first place? If I can >avoid that I don't care about close() hanging because I would never close >the port. If not, does anyone know why close() might block forever and >how I can prevent this? I'm using RXTX version 2.1-7. > >Thanks, >-- >Ryan > > > > > > > > > >-- >Ryan Boder >1 614 598-6339 > > > > > > >-- >Ryan Boder >1 614 598-6339 > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From Steffen.DETTMER at ingenico.com Wed Mar 2 03:08:57 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:08:57 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <32684-1298981297-704398@sneakemail.com> References: <4D6CD4DE.7040501@sandglass-software.com> <32684-1298981297-704398@sneakemail.com> Message-ID: <20110302100857.GB8030@elberon.bln.de.ingenico.com> * iqzw2r602 at sneakemail.com wrote on Tue, Mar 01, 2011 at 23:08 +1100: > This reminds me of a nasty problem I had with overlapped I/O on windows Yeah, those thousands of complex, difficult to use and exception-containing WinAPI is really hard to use... About strange effects on overlapped&multithreading, MSDN has: `the calling thread uses the GetOverlappedResult function or one of the wait functions' [1] also also mentiones I/O Completion Ports [2], and later continues: `If an application reuses OVERLAPPED structures on multiple threads and calls GetOverlappedResult with the bWait parameter set to TRUE, the application must ensure that the associated event is set before the application reuses the structure. This can be accomplished by using the WaitForSingleObject function after calling GetOverlappedResult to force the thread to wait until the operation completes. Note that the event object must be a manual-reset event object. If an autoreset event object is used, calling GetOverlappedResult with the bWait parameter set to TRUE causes the function to be blocked indefinitely.' also [1] oki, Steffen [1] http://msdn.microsoft.com/en-us/library/ms686358%28v=vs.85%29.aspx [2] http://msdn.microsoft.com/en-us/library/aa365198%28v=vs.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:15:11 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:15:11 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6D1D93.6090306@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> <4D6D1D93.6090306@sandglass-software.com> Message-ID: <20110302101511.GC8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 08:23 -0800: > Unfortunately, the javax.comm API specification includes a lot of > implementation details. That is one of the weaknesses of the > specification in my opinion. The bottom line is, anyone wanting to use > RxTx as a javax.comm implementation is going to expect it to do the > things the specification says it does. Yeah ok, but even then the implementation could check for the TooManyListenersException situations (if it really is required to support applications relying on that exception) but internally use just a single I/O thread waiting for events on any open file descriptors. Of course an implementation supporting all sort of concurrency could become quite complex (especially if open-read-close should work fast, I think would be difficult to implement, because a new file descriptors had to be added to the waitFor/select list, and who knows how systems behave here in detail...). oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:25:15 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:25:15 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6CDB22.9070401@sandglass-software.com> References: <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> <4D6CDB22.9070401@sandglass-software.com> Message-ID: <20110302102515.GD8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 03:40 -0800: > * from some older mail: > > My question would be: Why would you do that? The rewrite does > > most of the work for you - all you have to do is implement > > two C++ virtual classes and two C++ functions. > > > > In Windows that took me a few hours. > > Every journey begins with a single step. Yes, of course, but then it shouldn't be used as base for new effort estimations like `In Windows that took a few hours' ;-) (BTW, calling a single step `the rewrite' may sound a bit ambitious ;)) But of course a prototype demonstrating something can be really helpful, sure. I just wanted to tell that interfaces should be easy to use and powerful at the same time and may non-trivial initial considerations before starting to implement them. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From ryan.boder at gmail.com Wed Mar 2 18:44:35 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:44:35 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: While running the tests you requested I may have stumbled on the problem, I just don't know how to fix it. According to the documentation, if both the receive timeout and receive threshold are disabled then read() should block forever until data is available. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#getInputStream%28%29 On my system using RXTX read() is returning -1 when no data is available even though I have disabled both thresholds. The reason my program was running fine for a while without this problem showing up is that I was using the DATA_AVAILABLE event to be notified when data is available and only calling read() to read an entire frame whenever the DATA_AVAILABLE event occurred, until eventually my device (I'm guessing) probably took longer than normal to send the entire data frame and therefore I called read when no data was available and it returned -1. The following Java program demonstrates my problem, it returns -1 as soon as no data is available, even though I think it should block until data is available. import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; public class Main implements SerialPortEventListener { public static void main(String[] args) throws Exception { new Main().run(); } private void run() throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier("COM4"); SerialPort port = (SerialPort) portIdentifier.open(Main.class.getName(), 2000); port.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); port.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); port.disableReceiveThreshold(); port.disableReceiveTimeout(); BufferedInputStream in = new BufferedInputStream(port.getInputStream()); BufferedOutputStream out = new BufferedOutputStream(port.getOutputStream()); port.addEventListener(this); Thread.sleep(1000); out.write(new byte[] {0x02, 0x60}); out.flush(); while (true) { int x = in.read(); if (x == -1) { System.out.println("EOF"); Thread.sleep(1000000000); } String s = Integer.toHexString(x & 0xFF); if (s.length() == 1) s = "0" + s; System.out.print(s + " "); System.out.flush(); } } public void serialEvent(SerialPortEvent arg0) { System.out.println("Serial port event"); } } However, the follow C# program ran all day today without ever read ever returning -1, as I would expect. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.IO.Ports; using System.Threading; namespace RXTXReadTest1 { class Program { static void Main(string[] args) { new Program().run(); } private void run() { SerialPort port = new SerialPort("COM4", 19200, Parity.None, 8, StopBits.One); port.Open(); port.Write(new byte[] { 0x02, 0x60 }, 0, 2); while (true) { int x = port.ReadByte(); if (x == -1) { Console.WriteLine("EOF"); Thread.Sleep(1000000000); } String s = x.ToString("X"); if (s.Length == 1 ) s = "0" + s; Console.Out.Write(s + " "); Console.Out.Flush(); } } } } Now I am experimenting with what happens if I set the receive timeout to it's maximum value (apparently 1600ms) and only call read() when I am expecting data. Hopefully it will never be more than 1600ms late. This is still only a work around, not solving the problem. Am I doing something wrong in my code above or is RXTX retuning -1 when it should be blocking? Thanks, Ryan On Wed, Mar 2, 2011 at 3:34 AM, Kustaa Nyholm wrote: > On 3/2/11 07:53, "Ryan Boder" wrote: > Can you / have you made a simple test to ensure that rxtx is the issue? > > Can you write a simple C-program to see if this exhibits the same problem? > > I've never encountered this sort of problem with rxtx, it mostly just > works. > > But I'm on Mac so can't say about Windows (7) > > br Kusti > > > > > >Hi, > > > >I haven't seen any response to my question below. Is this not the right > >place to ask? If not, where would be a better place to ask? Any > >suggestions? > > > >Thanks, > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder > wrote: > > > >I mis-spoke, I don't have my own thread calling read, I am calling > >read in the event handler after receiving a > >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be > >accurate though. > > > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder > wrote: > > > >Hi, > > > >I have a receive thread that does nothing but call read() on the serial > >port input stream. It works fine for a while but after running for a long > >time it eventually returns -1 which means EOF. This is my first problem, > >as the device I'm talking to runs forever, I don't know why it would > >return -1. I am calling disableReceiveThreshold() and > >disableReceiveTimeout() at initialization which according to the > >documentation means read will return as soon as any data is available and > >it will block forever when data is not available, so -1 should never be > >returned from read, right? > > > >I have been unable to figure out why read returns -1 after a long while > >but I have found that if I kill my application and restart it everything > >works fine again. Therefore I tried to work around the problem by having > >my code close the port and reopen it when read returns -1. My second > >problem is that in this case when I call close() on the port it blocks > >forever. I did find this old bug > > > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > > > >which describes close() hanging on OSX, but it says that bug was fixed > >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone > >have any idea why read might be returning -1 in the first place? If I can > >avoid that I don't care about close() hanging because I would never close > >the port. If not, does anyone know why close() might block forever and > >how I can prevent this? I'm using RXTX version 2.1-7. > > > >Thanks, > >-- > >Ryan > > > > > > > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Wed Mar 2 18:46:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:46:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: <-1051064942000733580@unknownmsgid> References: <-1051064942000733580@unknownmsgid> Message-ID: It is USB and seems very reliable with the C# test program in my previous email. On Wed, Mar 2, 2011 at 6:58 PM, Bruce Griffith wrote: > How reliable is your serial port ? is it USB or Bluetooth? > > > > Bruce Griffith > > 303-532-4778 > > > > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On Behalf > Of *Ryan Boder > *Sent:* Tuesday, 01 March 2011 10:53 PM > *To:* rxtx at qbang.org > *Subject:* Re: [Rxtx] RXTX serial port read() returns -1 unexpectedly and > then blocks forever on close() > > > > Hi, > > I haven't seen any response to my question below. Is this not the right > place to ask? If not, where would be a better place to ask? Any suggestions? > > Thanks, > Ryan > > On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > > Hi, > > I have a receive thread that does nothing but call read() on the serial > port input stream. It works fine for a while but after running for a long > time it eventually returns -1 which means EOF. This is my first problem, as > the device I'm talking to runs forever, I don't know why it would return -1. > I am calling disableReceiveThreshold() and disableReceiveTimeout() at > initialization which according to the documentation means read will return > as soon as any data is available and it will block forever when data is not > available, so -1 should never be returned from read, right? > > I have been unable to figure out why read returns -1 after a long while but > I have found that if I kill my application and restart it everything works > fine again. Therefore I tried to work around the problem by having my code > close the port and reopen it when read returns -1. My second problem is that > in this case when I call close() on the port it blocks forever. I did find > this old bug > > http://bugzilla.qbang.org/show_bug.cgi?id=53 > > which describes close() hanging on OSX, but it says that bug was fixed with > a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have any > idea why read might be returning -1 in the first place? If I can avoid that > I don't care about close() hanging because I would never close the port. If > not, does anyone know why close() might block forever and how I can prevent > this? I'm using RXTX version 2.1-7. > > Thanks, > -- > Ryan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Mar 3 02:50:20 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 3 Mar 2011 09:50:20 +0000 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: So if -1 is unexpectedly returned from read, and we have demonstrated that your USB-serial adapter can actually causes this to happen in RXTX, why not just ignore the -1 value? What happens when you try this? As for a hang on close, are your closing your port from within your serial event handler? I know that this can cause some serious problems. Regards, Michael Erskine. From Kustaa.Nyholm at planmeca.com Thu Mar 3 03:39:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 12:39:34 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 03:44, "Ryan Boder" wrote: >While running the tests you requested I may have stumbled on the problem, >I just don't know how to fix it. According to the documentation, if both >the receive timeout and receive threshold are disabled then read() should >block forever until data is available. > >http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/re >ference/api/javax/comm/CommPort.html#getInputStream%28%29 > >On my system using RXTX read() is returning -1 when no data is available >even though I have disabled both thresholds. The reason my program was >running fine for a while without this problem showing up is that I was >using the DATA_AVAILABLE event to be notified when data is available and >only calling read() to read an entire frame whenever the DATA_AVAILABLE >event occurred, until eventually my device (I'm guessing) probably took >longer than normal to send the entire data frame and therefore I called >read when no data was available and it returned -1. As a workaround have you tried to perform another read() if it returns -1? The javadoc says (see getInputStream): "Note, however, that framing errors may cause the Timeout and Threshold values to complete prematurely without raising an exception." I read this as a hint that read might return even if no data is available. Because of the above and that read() can only return -1 or the byte received it would be somewhat logical to return -1 in case of framing error ? I'm not claiming that my interpretation of the specification, such as it is, is correct, just speculating that the behavior could be something like that. It might give you some more insight if you used the read(bytes[],int,int) method, because this can and will return 0 in case of timeout (and presumably might do so in case of framing error, maybe some other error condition too). That might allow you to handle or work around the problem in this case. You have not shown your complete code (no need) but your comments and the example makes me wonder if the code is otherwise as it should be, meaning are you assuming that when you get the DATA_AVAILABLE event all of your frame has arrived and that you can just blindly read it away from the input stream? That is not guaranteed of course. Also using read(), instead of read(bytes[],int,int), is not very efficient and might be masking other problems as mused above. BTE you can print a byte in hex with leading zeros more easily with: System.out.printf("%02X",x); br Kusti From ryan.boder at gmail.com Thu Mar 3 07:56:16 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:56:16 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 5:39 AM, Kustaa Nyholm wrote: > > As a workaround have you tried to perform another read() if it returns -1? > I tried that and it did work sometimes but not all the time. > > The javadoc says (see getInputStream): > > "Note, however, that framing errors may cause the Timeout and Threshold > values to complete prematurely without raising an exception." > > I read this as a hint that read might return even if no data is available. > > Because of the above and that read() can only return -1 or the byte > received > it would be somewhat logical to return -1 in case of framing error ? > > I'm not claiming that my interpretation of the specification, such as it > is, > is correct, just speculating that the behavior could be something like > that. > Receive framing is not enabled by default. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#enableReceiveFraming%28int%29 My choice of word might be misleading, when I said frame I just meant a contiguous message from the device. I am not enabling receive framing. Can you have a framing error when receive framing is disabled? > > It might give you some more insight if you used the read(bytes[],int,int) > method, because > this can and will return 0 in case of timeout (and presumably might do so > in case of framing > error, maybe some other error condition too). > > That might allow you to handle or work around the problem in this case. > > You have not shown your complete code (no need) but your comments and the > example > makes me wonder if the code is otherwise as it should be, meaning are you > assuming > that when you get the DATA_AVAILABLE event all of your frame has arrived > and that > you can just blindly read it away from the input stream? That is not > guaranteed of course. > I'm not assuming the entire message has arrived, I'm just assuming it either has arrived or will arrive soon which is why I'm using a (supposedly) blocking read(). > > Also using read(), instead of read(bytes[],int,int), is not very efficient > and > might be masking other problems as mused above. > True, I'm reading one byte at a time because I don't know how long the message will be until I read and parse some of it. I suppose I can use read(bytes[],int,int) once I figure out how long the message will be. > > BTE you can print a byte in hex with leading zeros more easily with: > > > System.out.printf("%02X",x); > I did it the dumb way in that test program so I could copy and paste the code from C# to Java without having to figure out how to do the same in C# which I'm not as familiar with. Thanks and BR, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 07:58:24 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 09:58:24 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: Yes I was doing the close in the serial event handler, I didn't realize that caused a problem. Thanks, I'll fix it. On Thu, Mar 3, 2011 at 4:50 AM, Michael Erskine wrote: > So if -1 is unexpectedly returned from read, and we have demonstrated > that your USB-serial adapter can actually causes this to happen in > RXTX, why not just ignore the -1 value? What happens when you try > this? As for a hang on close, are your closing your port from within > your serial event handler? I know that this can cause some serious > problems. > > Regards, > Michael Erskine. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Thu Mar 3 11:48:20 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Thu, 3 Mar 2011 13:48:20 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm wrote: > On 3/3/11 16:56, "Ryan Boder" wrote: > > > >I'm not assuming the entire message has arrived, I'm just assuming it > >either has arrived or will arrive soon which is why I'm using a > >(supposedly) blocking read(). > > > I've been giving this some further thought. > > It does not feel healthy to block without timeout, especially > from within a thread that is essentially internal to the rxtx. > > I've never done that, I always use a time out, read(byte[],int,int) > for the expected number of bytes, check how much I got and issue > more reads until I get everything. > > You have not described how your communication works so I'm only > speculating. > > If your device needs some response to send more bytes (from your > code it looks like this is not the case) then a missing byte > would block your read and prevent you from responding and > getting more data. But as said, looks like that is not the case. > > Anyway, if this was my problem, I would enable the timeout > and use read(byte[],int,int) and loop until I get what I need. > You are right, I should and will use a timeout. In fact, my program has been running flawlessly for 12 hours and the only change I made was to enable a timeout, no change in the logic at all. Without the timeout read() was returning -1 usually after it ran for an hour or two. I will change the code to make use of the timeout and handle it appropriately. It still seems to me that RXTX's behavior doesn't match the documentation when rx timeout and rx threshold are disabled read() should block until data is available instead of immediately returning -1. I don't believe that a framing error is occurring immediately every time data is not available causing read() to return -1. Especially since the C# test program above runs all day with no error and the Java program above runs all day with no error when a timeout is enabled. To me it seems like enabling the timeout is what is causing read() to block until data is available, even if only for 1600ms, and without the timeout read() is returning -1 immediately when it should be blocking. Thanks for all the help and best regards, -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Thu Mar 3 13:02:30 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 22:02:30 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 20:48, "Ryan Boder" wrote: >On Thu, Mar 3, 2011 at 1:08 PM, Kustaa Nyholm > wrote: > >On 3/3/11 16:56, "Ryan Boder" wrote: >> > >>I'm not assuming the entire message has arrived, I'm just assuming it >>either has arrived or will arrive soon which is why I'm using a >>(supposedly) blocking read(). > > > >I've been giving this some further thought. > >It does not feel healthy to block without timeout, especially >from within a thread that is essentially internal to the rxtx. > >I've never done that, I always use a time out, read(byte[],int,int) >for the expected number of bytes, check how much I got and issue >more reads until I get everything. > >You have not described how your communication works so I'm only >speculating. > >If your device needs some response to send more bytes (from your >code it looks like this is not the case) then a missing byte >would block your read and prevent you from responding and >getting more data. But as said, looks like that is not the case. > >Anyway, if this was my problem, I would enable the timeout >and use read(byte[],int,int) and loop until I get what I need. > > > > >You are right, I should and will use a timeout. In fact, my program has >been running flawlessly for 12 hours and the only change I made was to >enable a timeout, no change in the logic at all. Without the timeout >read() was returning -1 usually after it ran for an hour or two. I will >change the code to make use of the timeout and handle it appropriately. That's nice! > >It still seems to me that RXTX's behavior doesn't match the documentation >when rx timeout and rx threshold are disabled read() should block until >data is available instead of immediately returning -1. Yeah, it does look like bug. However this might be related to some Windows specific serial port issue. Years ago I had issues with JavaComm (not RxTx) where I did a blocking read and I had huge issues with my program consuming all resources. I curser the Sun and JavaComm and re-code my own SerialPort using JNI to access the Win32 API directly. And I run into the same problems as with the Sun's implementation! So I ditched my code, changed my code to use timeouts and problems disappeared. > I don't believe that a framing error is occurring immediately every time >data is not available causing read() to return -1. Especially since the >C# test program above runs all day with no error and the Java program >above runs all day with no error when a timeout is enabled. I think so too, all things considered I don't really believe in framing errors in this case. > To me it seems like enabling the timeout is what is causing read() to >block until data is available, even if only for 1600ms, and without the >timeout read() is returning -1 immediately when it should be blocking. Yeah, I had a peek at the innards of RxTx Windows serial port a week or so ago and also read MSDN documentation about serial ports and the way overlapped and non-overlapped (non blocking and blocking) IO is handled is a way different. So yeah, it can well be that there is an issue lurking there somewhere inside RxTx in Windows. > > >Thanks for all the help and best regards, >-- >Ryan Boder I'm happy if I was of any assistance. br Kusti From tjarvi at qbang.org Thu Mar 3 18:52:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 3 Mar 2011 18:52:50 -0700 (MST) Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: >> Without the timeout >> read() was returning -1 usually after it ran for an hour or two. There is a big hammer in rxtx causing that behavior. >> It still seems to me that RXTX's behavior doesn't match the documentation >> when rx timeout and rx threshold are disabled read() should block until >> data is available instead of immediately returning -1. > > Yeah, it does look like bug. However this might be related to some > Windows specific serial port issue. Years ago I had issues with > JavaComm (not RxTx) where I did a blocking read and I had huge > issues with my program consuming all resources. I curser the Sun > and JavaComm and re-code my own SerialPort using JNI to access > the Win32 API directly. And I run into the same problems as > with the Sun's implementation! So I ditched my code, changed > my code to use timeouts and problems disappeared. > > >> To me it seems like enabling the timeout is what is causing read() to >> block until data is available, even if only for 1600ms, and without the >> timeout read() is returning -1 immediately when it should be blocking. > > Yeah, I had a peek at the innards of RxTx Windows serial port a week > or so ago and also read MSDN documentation about serial ports and > the way overlapped and non-overlapped (non blocking and blocking) > IO is handled is a way different. So yeah, it can well be that > there is an issue lurking there somewhere inside RxTx in Windows. > > Yes. RXTX was patched to behave the way it does. I don't fully understand the issue behind the patch. Marc noticed the odd behavior as well and offered a fix which was greeted with resistance. The windows implementation was done without real documentatino of the windows API. I think I had an example from the late 80's early 90's on Microsoft's site and some API documentation that was obviously not microsofts in Europe. Wayne Roberts had a real need for windows support and fixed some major issues it had. My interest at the time was mingw32. I then cleaned it up for some specific uses I had later. The read returning -1 when it should block didn't impact anybody and appeared to help some people. It isnt the documented behavior though. There could be all sorts of latent bugs in that code but in the real world, it gets by in almost all use cases. Its a hack but it worked for 100's of thousands of people over a 14 year period. Maybe its time to revisit the code but there is more risk than gain for most people. How do you move forward and avoid the risk? Some have expressed interests in coding C++ or other efforts. I'm all for such efforts but feel some unit tests that work with a null modem cables are the only thing that will move rxtx (and perhaps CommAPI) forward. If we have a test suite in place as a qualification for implementations, progress can be made in the right direction regardless of the implementation details. -- Trent Jarvi tjarvi at qbang.org From Kustaa.Nyholm at planmeca.com Fri Mar 4 02:57:16 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Fri, 4 Mar 2011 11:57:16 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/4/11 03:52, "Trent Jarvi" wrote: >Yes. RXTX was patched to behave the way it does. I don't fully >understand the issue behind the patch. Marc noticed the odd behavior as >well and offered a fix which was greeted with resistance. > >The windows implementation was done without real documentatino of the >windows API. I think I had an example from the late 80's early 90's on >Microsoft's site and some API documentation that was obviously not >microsofts in Europe. Wayne Roberts had a real need for windows support >and fixed some major issues it had. My interest at the time was mingw32. >I then cleaned it up for some specific uses I had later. The read >returning -1 when it should block didn't impact anybody and appeared to >help some people. It isnt the documented behavior though. > >There could be all sorts of latent bugs in that code but in the real >world, it gets by in almost all use cases. I think so too, never had any problems with it. > Its a hack but it worked for 100's of thousands of people over a 14 year >period. Yeah! Thanks for everyone who has contributed over the years, job well done! >Maybe its time to >revisit the code but there is more risk than gain for most people. How >do >you move forward and avoid the risk? My view is that it is quite risky and rather pointless to move forward, other than fixing bugs that really affect people. At the moment the major issue IMO is just that it seems (not been following this too carefully, so maybe I'm wrong, so in case this FUD, my apologies) that 'official' binaries are not available. I think the rewrite, tempting as it is in some respects is not the way forward. Just gentle maintenance to iron out real issues and then get the binaries out. br Kusti From ryan.boder at gmail.com Fri Mar 4 07:24:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Fri, 4 Mar 2011 09:24:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 8:52 PM, Trent Jarvi wrote: > > The windows implementation was done without real documentatino of the > windows API. I think I had an example from the late 80's early 90's on > Microsoft's site and some API documentation that was obviously not > microsofts in Europe. Wayne Roberts had a real need for windows support and > fixed some major issues it had. My interest at the time was mingw32. I then > cleaned it up for some specific uses I had later. The read returning -1 > when it should block didn't impact anybody and appeared to help some people. > It isnt the documented behavior though. > > There could be all sorts of latent bugs in that code but in the real world, > it gets by in almost all use cases. Its a hack but it worked for 100's of > thousands of people over a 14 year period. Maybe its time to revisit the > code but there is more risk than gain for most people. How do you move > forward and avoid the risk? > The safest and easiest solution would be to add a javadoc comment to disableReceiveTimeout explaining the difference between the RXTX behavior and Sunacle's documented behavior so that when someone uses the method in an IDE like Eclipse a little box would pop up informing them. Generating javadoc HTML and hosting it on the RXTX website would go a long way too, when something behaves differently than I expect the first thing I do is look for the javadoc online. -- Ryan Boder -------------- next part -------------- An HTML attachment was scrubbed... URL: From kharrington at neuronrobotics.com Mon Mar 7 10:47:26 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 12:47:26 -0500 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! Message-ID: Hey all, this is just a heads up that i have made a fork of rxtxSerial. Some of the features we have added: * Self deployment of native libraries ( all native code is stored inside the jar and deployed at runtime). No more manual install of native code. * Arm Cortex support (Gumstix) * Android Support (requires a rooted phone for now) * Google Code (SVN) repository for easy code and jar access * Single makefile compile (simplifies the compilation of project binaries) * Ant build script for jar creation * Removal of partialy implemented code to streamline the lib for just serial port access * Full Eclipse integration, for testing application code against sources. And a bunch of bug fixes: * Fixed the memory access error that causes OSX to crash the JVM when serial.close() is cvalled * Fixed the windows serial port zombie bind that prevents re-accessing serial ports when exiting on an exception * Fixed erronious printouts of native library mis-match To check it out, take a look at our page here: http://code.google.com/p/nrjavaserial/ From Kustaa.Nyholm at planmeca.com Mon Mar 7 11:46:26 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Mar 2011 20:46:26 +0200 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: Message-ID: On 3/7/11 19:47, "Kevin Harrington NR" wrote: >Hey all, this is just a heads up that i have made a fork of >rxtxSerial. Some of the features we have added great! If also does what it says on the tin: brilliant! Congrats and thanks. br Kusti From jmsachs at gmail.com Mon Mar 7 12:50:33 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 14:50:33 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: > From: Kevin Harrington NR > To: rxtx at qbang.org > Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > Hey all, this is just a heads up that i have made a fork of > rxtxSerial. Some of the features we have added: > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with a ten-foot pole. From Kustaa.Nyholm at planmeca.com Mon Mar 7 13:10:43 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Mon, 7 Mar 2011 22:10:43 +0200 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: Message-ID: On 3/7/11 21:50, "Jason Sachs" wrote: > >Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >a ten-foot pole. >_______________________________________________ Oh crap, makes it useless for me and many others. Also I see no provision in RxTx license to change it so how could anyone change it to GPLv3? br Kusti From showard314 at gmail.com Mon Mar 7 13:24:08 2011 From: showard314 at gmail.com (Scott Howard) Date: Mon, 7 Mar 2011 15:24:08 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 3:10 PM, Kustaa Nyholm wrote: > Also I see no provision in RxTx license to change > it so how could anyone change it to GPLv3? I think this is allowed: 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. Once this change is made in a given copy, it is irreversible for that copy, so the ordinary GNU General Public License applies to all subsequent copies and derivative works made from that copy. This option is useful when you wish to copy part of the code of the Library into a program that is not a library. From jmsachs at gmail.com Mon Mar 7 13:24:47 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 15:24:47 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 2:50 PM, Jason Sachs wrote: >> From: Kevin Harrington NR >> To: rxtx at qbang.org >> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> > > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with > a ten-foot pole. > Let me back up a second (perhaps to make up for my lack of diplomacy) and state that I think any progress w/ rxtx is good. If an rxtx fork were LGPL (or some other non-spreading open source license) and leading in a good direction, I'd gladly return the favor by posting any improvements or bugfixes I found to the community. --Jason From jmsachs at gmail.com Mon Mar 7 13:36:13 2011 From: jmsachs at gmail.com (Jason Sachs) Date: Mon, 7 Mar 2011 15:36:13 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: Kevin: could you clarify the license? http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java has the RXTX 2.1 license (LGPL v 2.1 + Linking Over Controlled Interface.) but http://code.google.com/p/nrjavaserial/ says GPLv3. --Jason From kharrington at neuronrobotics.com Mon Mar 7 14:00:02 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 16:00:02 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: The one downside to google code is that it does not allow custom licensing. You have to pick from a drop-down list. Treat the licences on the files themselves as the licence to be concerned with, and ignore the "project licence". Sorry for the confusion. On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: > Kevin: could you clarify the license? > > http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java > has the RXTX 2.1 license > (LGPL v 2.1 + Linking Over Controlled Interface.) > > but http://code.google.com/p/nrjavaserial/ says GPLv3. > > --Jason > From iqzw2r602 at sneakemail.com Mon Mar 7 14:08:18 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 8 Mar 2011 08:08:18 +1100 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: References: Message-ID: <11253-1299532098-811882@sneakemail.com> Nice! Out of curiosity, did you use the patch that I sent Trent about two years ago to do the native library loading, or did you implement your own solution? Cheers, Uwe On Tue, Mar 8, 2011 at 5:46 AM, Kustaa Nyholm Kustaa.Nyholm-at-planmeca.com| rxtx.org mailing list/Example Allow| wrote: > On 3/7/11 19:47, "Kevin Harrington NR" > wrote: > > >Hey all, this is just a heads up that i have made a fork of > >rxtxSerial. Some of the features we have added > > > > great! If also does what it says on the tin: brilliant! > > Congrats and thanks. > > br Kusti > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aawolfe at gmail.com Mon Mar 7 15:31:47 2011 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 7 Mar 2011 17:31:47 -0500 Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR wrote: > Hey all, this is just a heads up that i have made a fork of > rxtxSerial. Some of the features we have added: > > * Self deployment of native libraries ( all native code is stored > inside the jar and deployed at runtime). No more manual install of > native code. > * Arm Cortex support (Gumstix) > * Android Support (requires a rooted phone for now) > * Google Code (SVN) repository for easy code and jar access > * Single makefile compile (simplifies the compilation of project binaries) > * Ant build script for jar creation > * Removal of partialy implemented code to streamline the lib for just > serial port access > * Full Eclipse integration, for testing application code against sources. > > And a bunch of bug fixes: > > * Fixed the memory access error that causes OSX to crash the JVM when > serial.close() is cvalled > * Fixed the windows serial port zombie bind that prevents re-accessing > serial ports when exiting on an exception > * Fixed erronious printouts of native library mis-match > > To check it out, take a look at our page here: > > http://code.google.com/p/nrjavaserial/ This is interesting, getting the native libs set up has been an issue for some of my users. Will have to check it out. Out of curiosity, what Android devices provide a serial port? Or are there some that allow USB host mode and then a usb-serial adapter? I have only an Android cell phone, don't think it can do anything serial but would love to be wrong about that. From jfh at greenhousepc.com Mon Mar 7 15:54:39 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 15:54:39 -0700 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! Message-ID: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From tjarvi at qbang.org Mon Mar 7 16:53:50 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 7 Mar 2011 16:53:50 -0700 (MST) Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 6 In-Reply-To: References: Message-ID: Hi Kevin, Until Google fixes the options as developers have requested, I'd suggest the least misleading dropdown option is "Other Open Source" with a clarification about LGPL 2.1 on the project page. If you are not supporting the CommAPI SPI interface that was available prior to the current JSR so that applications work in the javax.comm namespace, there is no need for the linking over controlled interfaces exception. RXTX 2.0 is used in that fashion but RXTX 2.1 is not. The exception explicitly states it can be removed if the source has been modified. The license is then explicitly OSI reviewed and approved as Google requests but is not in their drop down box as it should be and is for the GPL v2. http://opensource.org/licenses/alphabetical http://opensource.org/licenses/lgpl-2.1 The drawback would be that the library effectively could never be used in that SPI/controlled interface fashion again. On Mon, 7 Mar 2011, Kevin Harrington NR wrote: > The one downside to google code is that it does not allow custom > licensing. You have to pick from a drop-down list. Treat the licences > on the files themselves as the licence to be concerned with, and > ignore the "project licence". Sorry for the confusion. > > On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >> Kevin: could you clarify the license? >> >> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >> has the RXTX 2.1 license >> (LGPL v 2.1 + Linking Over Controlled Interface.) >> >> but http://code.google.com/p/nrjavaserial/ says GPLv3. >> >> --Jason >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From hakcenter at gmail.com Mon Mar 7 18:55:57 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 17:55:57 -0800 Subject: [Rxtx] Latency Woes Message-ID: <4D758CAD.2010602@gmail.com> I have finally deduced my slow data logging to a latency issue. I write software for dsms, and the protocol is request / receive, you cannot do more than 1 sensor at a time. So when you log multiple sensors, +20ms per item, sampling rate drops like a rock. I was wondering if there is any ideas besides going completely native with my application to reduce latency. With or without events I don't care at this point I need to kill as much of the latency as possible. Realistically I need no more than 1ms. From adrian.crum at sandglass-software.com Mon Mar 7 19:08:21 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Mon, 07 Mar 2011 18:08:21 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D758CAD.2010602@gmail.com> References: <4D758CAD.2010602@gmail.com> Message-ID: <4D758F95.90800@sandglass-software.com> Drop the requests into a queue, and then have a separate thread service the queue. -Adrian On 3/7/2011 5:55 PM, Curtis Hacker wrote: > I have finally deduced my slow data logging to a latency issue. > > I write software for dsms, and the protocol is request / receive, you > cannot do more than 1 sensor at a time. So when you log multiple > sensors, +20ms per item, sampling rate drops like a rock. > > I was wondering if there is any ideas besides going completely native > with my application to reduce latency. With or without events I don't > care at this point I need to kill as much of the latency as possible. > Realistically I need no more than 1ms. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From hakcenter at gmail.com Mon Mar 7 19:24:16 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 18:24:16 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D758F95.90800@sandglass-software.com> References: <4D758CAD.2010602@gmail.com> <4D758F95.90800@sandglass-software.com> Message-ID: <4D759350.8060402@gmail.com> Sample code ? I don't necessarily want to read the byte I just wrote, but wait till the que depth is 2. Setup a thread without a sleep timer: if (in.available() > 1) { do_stuff(); } ?? On 03/07/11 18:08, Adrian Crum wrote: > Drop the requests into a queue, and then have a separate thread > service the queue. > > -Adrian > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: >> I have finally deduced my slow data logging to a latency issue. >> >> I write software for dsms, and the protocol is request / receive, you >> cannot do more than 1 sensor at a time. So when you log multiple >> sensors, +20ms per item, sampling rate drops like a rock. >> >> I was wondering if there is any ideas besides going completely native >> with my application to reduce latency. With or without events I don't >> care at this point I need to kill as much of the latency as possible. >> Realistically I need no more than 1ms. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From adrian.crum at sandglass-software.com Mon Mar 7 19:46:02 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Mon, 07 Mar 2011 18:46:02 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <4D759350.8060402@gmail.com> References: <4D758CAD.2010602@gmail.com> <4D758F95.90800@sandglass-software.com> <4D759350.8060402@gmail.com> Message-ID: <4D75986A.6020003@sandglass-software.com> http://download.oracle.com/javase/tutorial/essential/concurrency/executors.html -Adrian On 3/7/2011 6:24 PM, Curtis Hacker wrote: > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: >> Drop the requests into a queue, and then have a separate thread >> service the queue. >> >> -Adrian >> >> On 3/7/2011 5:55 PM, Curtis Hacker wrote: >>> I have finally deduced my slow data logging to a latency issue. >>> >>> I write software for dsms, and the protocol is request / receive, >>> you cannot do more than 1 sensor at a time. So when you log multiple >>> sensors, +20ms per item, sampling rate drops like a rock. >>> >>> I was wondering if there is any ideas besides going completely >>> native with my application to reduce latency. With or without events >>> I don't care at this point I need to kill as much of the latency as >>> possible. Realistically I need no more than 1ms. >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx at qbang.org >>> http://mailman.qbang.org/mailman/listinfo/rxtx >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Mon Mar 7 19:50:45 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 19:50:45 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Mon Mar 7 20:04:01 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Mon, 07 Mar 2011 19:04:01 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> Message-ID: <4D759CA1.8010903@gmail.com> I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. in.read(data, 0, 2); ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? On 03/07/11 18:50, jfh at greenhousepc.com wrote: > Curtis, > > No, I assume he means a real queue, not just "don't read all the bytes > at once." However, if you know you can process some number of > requests in some amount of time, allowing data to pile up (receiver > FIFO space permitting) can be a valid strategy. Inserting gobs of > Thread.yield() and notify() can help pep things up as well. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Mon, March 07, 2011 8:24 pm > To: rxtx at qbang.org > > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: > > Drop the requests into a queue, and then have a separate thread > > service the queue. > > > > -Adrian > > > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: > >> I have finally deduced my slow data logging to a latency issue. > >> > >> I write software for dsms, and the protocol is request / > receive, you > >> cannot do more than 1 sensor at a time. So when you log multiple > >> sensors, +20ms per item, sampling rate drops like a rock. > >> > >> I was wondering if there is any ideas besides going completely > native > >> with my application to reduce latency. With or without events I > don't > >> care at this point I need to kill as much of the latency as > possible. > >> Realistically I need no more than 1ms. > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From bartley at cmu.edu Mon Mar 7 20:08:05 2011 From: bartley at cmu.edu (Chris Bartley) Date: Mon, 7 Mar 2011 22:08:05 -0500 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> Message-ID: <9B1804F9-DBD0-476D-9345-806D00065A97@cmu.edu> We use a queue for all our request/response serial communications, and have found it really easy to work with. Code is here: http://code.google.com/p/create-lab-commons/source/browse/trunk/java/code/serial/src/edu/cmu/ri/createlab/serial/SerialPortCommandExecutionQueue.java It's assuming a command & response scheme that's specific to the protocol we use to talk to our robots, but it should be easy to modify for your needs. Hope this helps. Let me know if you have questions. Chris On Mar 7, 2011, at 9:50 PM, wrote: > Curtis, > > No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > Date: Mon, March 07, 2011 8:24 pm > To: rxtx at qbang.org > > Sample code ? > > I don't necessarily want to read the byte I just wrote, but wait till > the que depth is 2. > > Setup a thread without a sleep timer: > if (in.available() > 1) { > do_stuff(); > } > > ?? > > On 03/07/11 18:08, Adrian Crum wrote: > > Drop the requests into a queue, and then have a separate thread > > service the queue. > > > > -Adrian > > > > On 3/7/2011 5:55 PM, Curtis Hacker wrote: > >> I have finally deduced my slow data logging to a latency issue. > >> > >> I write software for dsms, and the protocol is request / receive, you > >> cannot do more than 1 sensor at a time. So when you log multiple > >> sensors, +20ms per item, sampling rate drops like a rock. > >> > >> I was wondering if there is any ideas besides going completely native > >> with my application to reduce latency. With or without events I don't > >> care at this point I need to kill as much of the latency as possible. > >> Realistically I need no more than 1ms. > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From jfh at greenhousepc.com Mon Mar 7 20:51:17 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Mon, 07 Mar 2011 20:51:17 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110307205116.8ef0e5b4a80cef441275a6330ffad77d.9b325137d1.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From kharrington at neuronrobotics.com Mon Mar 7 20:55:23 2011 From: kharrington at neuronrobotics.com (Kevin Harrington NR) Date: Mon, 7 Mar 2011 22:55:23 -0500 Subject: [Rxtx] Rxtx Digest, Vol 43, Issue 7 In-Reply-To: References: Message-ID: To answer a few of you, I have changed the license to "Other open source license" as suggested. My company is modifying and maintaining this fork to support our robotics development library (http://code.google.com/p/nr-sdk/ http://dev.neuronrobotics.com). We will be implementing the standard serial port interface only, as it is the only one we need or care about. As for where the implementation came from, i would have to refer to my other developer to answer that. I wrote the build scripts and make files, as well as streamlining the C build process. I have remover the configure script, as it ends up being more confusing then compiling 3 C files needs to be. if you guys want to bring any of this into the main line, that's cool, but up to you to port over. Our fork will be focusing on polishing up the serial interface,and hopefully making it faster. I hope some of you will find our improvements useful! On Mon, Mar 7, 2011 at 6:53 PM, wrote: > Send Rxtx mailing list submissions to > ? ? ? ?rxtx at qbang.org > > To subscribe or unsubscribe via the World Wide Web, visit > ? ? ? ?http://mailman.qbang.org/mailman/listinfo/rxtx > or, via email, send a message with subject or body 'help' to > ? ? ? ?rxtx-request at qbang.org > > You can reach the person managing the list at > ? ? ? ?rxtx-owner at qbang.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Rxtx digest..." > > > Today's Topics: > > ? 1. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 2. Re: Rxtx Digest, Vol 43, Issue 6 (Kustaa Nyholm) > ? 3. Re: Rxtx Digest, Vol 43, Issue 6 (Scott Howard) > ? 4. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 5. Re: Rxtx Digest, Vol 43, Issue 6 (Jason Sachs) > ? 6. Re: Rxtx Digest, Vol 43, Issue 6 (Kevin Harrington NR) > ? 7. Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! > ? ? ?(iqzw2r602 at sneakemail.com) > ? 8. Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! > ? ? ?(Aaron Wolfe) > ? 9. Re: [SPAM] Re: ?NRJavaSerial, a fork of rxtx that fixes the > ? ? ?papercuts! (jfh at greenhousepc.com) > ?10. Re: Rxtx Digest, Vol 43, Issue 6 (Trent Jarvi) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 7 Mar 2011 14:50:33 -0500 > From: Jason Sachs > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > >> From: Kevin Harrington NR >> To: rxtx at qbang.org >> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >> Message-ID: >> ? ? ? ? >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> > > Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with > a ten-foot pole. > > > ------------------------------ > > Message: 2 > Date: Mon, 7 Mar 2011 22:10:43 +0200 > From: Kustaa Nyholm > To: "rxtx at qbang.org" > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > On 3/7/11 21:50, "Jason Sachs" wrote: >> >>Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >>a ten-foot pole. >>_______________________________________________ > > Oh crap, makes it useless for me and many others. > > Also I see no provision in RxTx license to change > it so how could anyone change it to GPLv3? > > br Kusti > > > > ------------------------------ > > Message: 3 > Date: Mon, 7 Mar 2011 15:24:08 -0500 > From: Scott Howard > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 3:10 PM, Kustaa Nyholm > wrote: >> Also I see no provision in RxTx license to change >> it so how could anyone change it to GPLv3? > > I think this is allowed: > > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. ?To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. ?(If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) ?Do not make any other change in > these notices. > > ? Once this change is made in a given copy, it is irreversible for > that copy, so the ordinary GNU General Public License applies to all > subsequent copies and derivative works made from that copy. > > ? This option is useful when you wish to copy part of the code of > the Library into a program that is not a library. > > > ------------------------------ > > Message: 4 > Date: Mon, 7 Mar 2011 15:24:47 -0500 > From: Jason Sachs > To: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 2:50 PM, Jason Sachs wrote: >>> From: Kevin Harrington NR >>> To: rxtx at qbang.org >>> Subject: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the papercuts! >>> Message-ID: >>> ? ? ? ? >>> Content-Type: text/plain; charset=ISO-8859-1 >>> >>> Hey all, this is just a heads up that i have made a fork of >>> rxtxSerial. Some of the features we have added: >>> >> >> Why GPLv3 rather than LGPL? Our company won't touch GPL libraries with >> a ten-foot pole. >> > > Let me back up a second (perhaps to make up for my lack of diplomacy) > and state that I think any progress w/ rxtx is good. > > If an rxtx fork were LGPL (or some other non-spreading open source > license) and leading in a good direction, I'd gladly return the favor > by posting any improvements or bugfixes I found to the community. > > --Jason > > > ------------------------------ > > Message: 5 > Date: Mon, 7 Mar 2011 15:36:13 -0500 > From: Jason Sachs > To: rxtx at qbang.org, kharrington at neuronrobotics.com > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > Kevin: could you clarify the license? > > http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java > has the RXTX 2.1 license > (LGPL v 2.1 + Linking Over Controlled Interface.) > > but http://code.google.com/p/nrjavaserial/ says GPLv3. > > --Jason > > > ------------------------------ > > Message: 6 > Date: Mon, 7 Mar 2011 16:00:02 -0500 > From: Kevin Harrington NR > To: Jason Sachs > Cc: rxtx at qbang.org > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > The one downside to google code is that it does not allow custom > licensing. You have to pick from a drop-down list. Treat the licences > on the files themselves as the licence to be concerned with, and > ignore the "project licence". Sorry for the confusion. > > On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >> Kevin: could you clarify the license? >> >> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >> has the RXTX 2.1 license >> (LGPL v 2.1 + Linking Over Controlled Interface.) >> >> but http://code.google.com/p/nrjavaserial/ says GPLv3. >> >> --Jason >> > > > ------------------------------ > > Message: 7 > Date: Tue, 8 Mar 2011 08:08:18 +1100 > From: iqzw2r602 at sneakemail.com > To: Rxtx at qbang.org > Subject: Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > ? ? ? ?papercuts! > Message-ID: <11253-1299532098-811882 at sneakemail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Nice! > > Out of curiosity, did you use the patch that I sent Trent about two years > ago to do the native library loading, or did you implement your own > solution? > > Cheers, > > Uwe > > On Tue, Mar 8, 2011 at 5:46 AM, Kustaa Nyholm Kustaa.Nyholm-at-planmeca.com| > rxtx.org mailing list/Example Allow| wrote: > >> On 3/7/11 19:47, "Kevin Harrington NR" >> wrote: >> >> >Hey all, this is just a heads up that i have made a fork of >> >rxtxSerial. Some of the features we have added >> >> >> >> great! If also does what it says on the tin: brilliant! >> >> Congrats and thanks. >> >> br Kusti >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 8 > Date: Mon, 7 Mar 2011 17:31:47 -0500 > From: Aaron Wolfe > To: rxtx at qbang.org > Subject: Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > ? ? ? ?papercuts! > Message-ID: > ? ? ? ? > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR > wrote: >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> >> * Self deployment of native libraries ( all native code is stored >> inside the jar and deployed at runtime). No more manual install of >> native code. >> * Arm Cortex support (Gumstix) >> * Android Support (requires a rooted phone for now) >> * Google Code (SVN) repository for easy code and jar access >> * Single makefile compile (simplifies the compilation of project binaries) >> * Ant build script for jar creation >> * Removal of partialy implemented code to streamline the lib for just >> serial port access >> * Full Eclipse integration, for testing application code against sources. >> >> And a bunch of bug fixes: >> >> * Fixed the memory access error that causes OSX to crash the JVM when >> serial.close() is cvalled >> * Fixed the windows serial port zombie bind that prevents re-accessing >> serial ports when exiting on an exception >> * Fixed erronious printouts of native library mis-match >> >> To check it out, take a look at our page here: >> >> http://code.google.com/p/nrjavaserial/ > > This is interesting, getting the native libs set up has been an issue > for some of my users. ?Will have to check it out. > > Out of curiosity, what Android devices provide a serial port? ?Or are > there some that allow USB host mode and then a usb-serial adapter? ?I > have only an Android cell phone, don't think it can do anything serial > but would love to be wrong about that. > > > ------------------------------ > > Message: 9 > Date: Mon, 07 Mar 2011 15:54:39 -0700 > From: > To: aaron at aaronwolfe.com, rxtx at qbang.org > Subject: Re: [Rxtx] [SPAM] Re: ?NRJavaSerial, a fork of rxtx that > ? ? ? ?fixes the papercuts! > Message-ID: > ? ? ? ?<20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe at email13.secureserver.net> > > Content-Type: text/plain; charset="us-ascii" > > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 10 > Date: Mon, 7 Mar 2011 16:53:50 -0700 (MST) > From: Trent Jarvi > To: rxtx at qbang.org > Cc: Jason Sachs > Subject: Re: [Rxtx] Rxtx Digest, Vol 43, Issue 6 > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > Hi Kevin, > > Until Google fixes the options as developers have requested, I'd suggest > the least misleading dropdown option is "Other Open Source" with a > clarification about LGPL 2.1 on the project page. > > If you are not supporting the CommAPI SPI interface that was available > prior to the current JSR so that applications work in the javax.comm > namespace, there is no need for the linking over controlled interfaces > exception. ?RXTX 2.0 is used in that fashion but RXTX 2.1 is not. ?The > exception explicitly states it can be removed if the source has been > modified. ?The license is then explicitly OSI reviewed and approved as > Google requests but is not in their drop down box as it should be and is > for the GPL v2. > > ? ? ? ?http://opensource.org/licenses/alphabetical > ? ? ? ?http://opensource.org/licenses/lgpl-2.1 > > The drawback would be that the library effectively could never be used in > that SPI/controlled interface fashion again. > > On Mon, 7 Mar 2011, Kevin Harrington NR wrote: > >> The one downside to google code is that it does not allow custom >> licensing. You have to pick from a drop-down list. Treat the licences >> on the files themselves as the licence to be concerned with, and >> ignore the "project licence". Sorry for the confusion. >> >> On Mon, Mar 7, 2011 at 3:36 PM, Jason Sachs wrote: >>> Kevin: could you clarify the license? >>> >>> http://nrjavaserial.googlecode.com/svn/trunk/nrjavaserial/src/main/java/gnu/io/CommPort.java >>> has the RXTX 2.1 license >>> (LGPL v 2.1 + Linking Over Controlled Interface.) >>> >>> but http://code.google.com/p/nrjavaserial/ says GPLv3. >>> >>> --Jason >>> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > > ------------------------------ > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > End of Rxtx Digest, Vol 43, Issue 7 > *********************************** > From Kustaa.Nyholm at planmeca.com Mon Mar 7 21:43:57 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 8 Mar 2011 06:43:57 +0200 Subject: [Rxtx] Latency Woes In-Reply-To: <20110307205116.8ef0e5b4a80cef441275a6330ffad77d.9b325137d1.wbe@email13.secureserver.net> Message-ID: On 3/8/11 05:51, "jfh at greenhousepc.com" wrote: >Curtis, > > >None of that is relevant, as long as the UART is reasonable and the code >implements a proper half duplex protocol. > >If I understand correctly, you send a byte, the sensor sends back two >bytes. So long as you don't send the next byte until the two bytes are >in the UART receiver FIFO, you're fine. You don't have to actually >=read= them, just know they are available. To the OP, are you using a serial USB port, like FTDI? This has a built in latency of 10ms ie nothing is actually sent out of the device if you send less than 64 bytes until 10 msec timeout. This has nothing to do with RxTx. If you search the list archives you'll find more about this issue and IIRC someone reported that there is some diver parameter you can tweak to get rid of that latency. I'm sure the FTDI people had a good reason for this but it really brings down the communication speed if your protocol uses short messages and need to wait for a response. Sorry if this has already been mentioned or if this is not relevant, I've not been paying attention to this thread. br Kusti From bob_jacobsen at lbl.gov Tue Mar 8 00:02:28 2011 From: bob_jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 8 Mar 2011 00:02:28 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D759CA1.8010903@gmail.com> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> Message-ID: If you're transferring three bytes total at 1953 baud, it's going to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to wait 20msec to get the data back instead of 15.4 msec doesn't seem to be as big a problem as you're making it sound. Bob On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. > > To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. > > So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. > > in.read(data, 0, 2); > ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? > > On 03/07/11 18:50, jfh at greenhousepc.com wrote: >> Curtis, >> >> No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker >> Date: Mon, March 07, 2011 8:24 pm >> To: rxtx at qbang.org >> >> Sample code ? >> >> I don't necessarily want to read the byte I just wrote, but wait till >> the que depth is 2. >> >> Setup a thread without a sleep timer: >> if (in.available() > 1) { >> do_stuff(); >> } >> >> ?? >> >> On 03/07/11 18:08, Adrian Crum wrote: >> > Drop the requests into a queue, and then have a separate thread >> > service the queue. >> > >> > -Adrian >> > >> > On 3/7/2011 5:55 PM, Curtis Hacker wrote: >> >> I have finally deduced my slow data logging to a latency issue. >> >> >> >> I write software for dsms, and the protocol is request / receive, you >> >> cannot do more than 1 sensor at a time. So when you log multiple >> >> sensors, +20ms per item, sampling rate drops like a rock. >> >> >> >> I was wondering if there is any ideas besides going completely native >> >> with my application to reduce latency. With or without events I don't >> >> care at this point I need to kill as much of the latency as possible. >> >> Realistically I need no more than 1ms. >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From hakcenter at gmail.com Tue Mar 8 01:33:24 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 00:33:24 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> Message-ID: <4D75E9D4.5090307@gmail.com> I am going to try a couple things today and hopefully figure something out. Bob I don't want to pop your bubble, but a native application named 'TunerPro' can sample the same data, over 30 sensors, in less than 25ms. I've exchanged some emails with the author and it is a native C, polling, no events just timeouts. Kusta thanks for the FTDI notice, I believe that is tunable, however I have a particular user using a Keyspan converter and verified sampling rate with 'TunerPro' and its just off the charts. Chris thank you, I'll look into the queing. On 03/07/11 23:02, Bob Jacobsen wrote: > If you're transferring three bytes total at 1953 baud, it's going to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to wait 20msec to get the data back instead of 15.4 msec doesn't seem to be as big a problem as you're making it sound. > > Bob > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > >> I guess I'm gunna need some serious help with this then, because of the scenario I'm stuck with. >> >> To communicate there is only 1 data line, rx/tx tied together with a diode protecting the tx. No RTS/CTS handshaking nothing.. >> >> So the ecu can't process the next byte of info, without you pulling the 2 bytes back. I wish this was standard, but even the baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard spot with this.. >> >> in.read(data, 0, 2); >> ^ would the above wait till the timeout to read 2 bytes ? or read 1 byte wait for the 2nd ? or just read the 1 ?? >> >> On 03/07/11 18:50, jfh at greenhousepc.com wrote: >>> Curtis, >>> >>> No, I assume he means a real queue, not just "don't read all the bytes at once." However, if you know you can process some number of requests in some amount of time, allowing data to pile up (receiver FIFO space permitting) can be a valid strategy. Inserting gobs of Thread.yield() and notify() can help pep things up as well. >>> -- >>> Julie Haugh >>> Senior Design Engineer >>> greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on Skype From msemtd at googlemail.com Tue Mar 8 01:50:15 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Tue, 8 Mar 2011 08:50:15 +0000 Subject: [Rxtx] Latency Woes In-Reply-To: <4D75E9D4.5090307@gmail.com> References: <20110307195044.8ef0e5b4a80cef441275a6330ffad77d.b6a7f9a7c4.wbe@email13.secureserver.net> <4D759CA1.8010903@gmail.com> <4D75E9D4.5090307@gmail.com> Message-ID: On 8 March 2011 08:33, Curtis Hacker wrote: > I am going to try a couple things today and hopefully figure something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than 25ms. > I've exchanged some emails with the author and it is a native C, polling, no > events just timeouts. Perhaps the author of TunerPro will let you use his native code - sounds just what you need. Regards, Michael Erskine. From jfh at greenhousepc.com Tue Mar 8 04:00:18 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 04:00:18 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 12:33:35 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 11:33:35 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> Message-ID: <4D76848F.5080809@gmail.com> Cable schematic: http://i1106.photobucket.com/albums/h377/vigilart/jackal%20logging%20set%20up/RS232SCHEMATIC.jpg 0.00268554 TunerPro.exe IOCTL_SERIAL_SET_BAUD_RATE VCP0 SUCCESS Rate: 1952 0.00305178 TunerPro.exe IOCTL_SERIAL_SET_RTS VCP0 SUCCESS 0.00297524 TunerPro.exe IOCTL_SERIAL_SET_DTR VCP0 SUCCESS 0.00297384 TunerPro.exe IOCTL_SERIAL_SET_LINE_CONTROL VCP0 SUCCESS StopBits: 1 Parity: NONE WordLength: 8 0.00000335 TunerPro.exe IOCTL_SERIAL_SET_CHAR VCP0 SUCCESS EOF:0 ERR:0 BRK:0 EVT:0 XON:11 XOFF:13 0.00202540 TunerPro.exe IOCTL_SERIAL_SET_HANDFLOW VCP0 SUCCESS Shake:1 Replace:40 XonLimit:2048 XoffLimit:512 0.00000335 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:300 RM:0 RC:2000 WM:0 WC:110 0.00000279 TunerPro.exe IOCTL_SERIAL_SET_QUEUE_SIZE VCP0 SUCCESS InSize: 1024 OutSize: 512 0.00000307 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000279 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:300 RM:0 RC:2000 WM:0 WC:110 0.00000307 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:75 RM:0 RC:400 WM:0 WC:300 0.00000559 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: RXCLEAR 0.00000335 TunerPro.exe IOCTL_SERIAL_PURGE VCP0 SUCCESS Purge: TXCLEAR 0.00064980 TunerPro.exe IRP_MJ_WRITE VCP0 SUCCESS Length 1: . 0.01498738 TunerPro.exe IRP_MJ_READ VCP0 SUCCESS Length 1: . 0.00000363 TunerPro.exe IOCTL_SERIAL_GET_TIMEOUTS VCP0 SUCCESS 0.00000307 TunerPro.exe IOCTL_SERIAL_SET_TIMEOUTS VCP0 SUCCESS RI:200 RM:0 RC:20 WM:0 WC:300 0.02042774 TunerPro.exe IRP_MJ_READ VCP0 TIMEOUT Length 0: That is time on the left side. Now I'm with you on timing, it doesn't make a lot of sense, but that is how the logs come out. You can view the logs yourself. Tunerpro log : http://www.ds-map.net/tunerpro_log.csv My apps log : http://www.ds-map.net/my_log.csv 2nd app log : http://www.ds-map.net/my_log2.csv All these logs, were done from the same car, same cable. I have some older logs with some palm software, that was 13 sensors, and had a total 45-55ms between each set of 13. More info about the car / ecu at http://mmcdlogger.sourceforge.net Disassembly on the ecu: [SS1:SS0] is baud rate divider, 00(16) 01(128) 10(1024) 11(4096), assuming basic clock of 2MHZ, we get 125000baud, 15625baud, 1953baud, 488baud In any event, I attempted a no sleep thread, that waited till in.available > 1, and it wasn't any faster than running the events. Then I tried a read write thread, that slept from 1ms to 30ms after it wrote (so it wouldn't read what it just wrote). And couldn't get it doing much. I wish I had more of an understanding of all of this, which is why I'm asking for help. On 03/08/11 03:00, jfh at greenhousepc.com wrote: > Curtis, > > At the risk of being told "No, they really say it can be done", 30 > sensors is 30 * 3 character times (are you sure it's not a single byte > response?). At 1953 baud, a single character time is 10 bits * (1 / > 1953) seconds, or 15.4ms as Bob pointed out. 30 * 15.4ms is 460ms, > and that assumes everything works perfectly, no turnaround times, etc. > > If you can come up with some other way to make the math work, I'd love > to hear it. > > Short and sweet -- just because TunerPro can talk to an ECM/ECU that > is running faster than 1953 baud doesn't mean your Mitsubishi (or > whatever car you've got that runs at 1953 baud) runs at that faster > baud rate. > > Also, are you sure your data cable is correct? What cable are you > using? What's the schematic? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 2:33 am > To: rxtx at qbang.org > > I am going to try a couple things today and hopefully figure > something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than > 25ms. > I've exchanged some emails with the author and it is a native C, > polling, no events just timeouts. > > Kusta thanks for the FTDI notice, I believe that is tunable, > however I > have a particular user using a Keyspan converter and verified > sampling > rate with 'TunerPro' and its just off the charts. > > Chris thank you, I'll look into the queing. > > On 03/07/11 23:02, Bob Jacobsen wrote: > > If you're transferring three bytes total at 1953 baud, it's going > to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to > wait 20msec to get the data back instead of 15.4 msec doesn't seem > to be as big a problem as you're making it sound. > > > > Bob > > > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > > > >> I guess I'm gunna need some serious help with this then, because > of the scenario I'm stuck with. > >> > >> To communicate there is only 1 data line, rx/tx tied together > with a diode protecting the tx. No RTS/CTS handshaking nothing.. > >> > >> So the ecu can't process the next byte of info, without you > pulling the 2 bytes back. I wish this was standard, but even the > baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard > spot with this.. > >> > >> in.read(data , 0, 2); > >> ^ would the above wait till the timeout to read 2 bytes ? or > read 1 byte wait for the 2nd ? or just read the 1 ?? > >> > >> On 03/07/11 18:50, jfh at greenhousepc.com > wrote: > >>> Curtis, > >>> > >>> No, I assume he means a real queue, not just "don't read all > the bytes at once." However, if you know you can process some > number of requests in some amount of time, allowing data to pile > up (receiver FIFO space permitting) can be a valid strategy. > Inserting gobs of Thread.yield() and notify() can help pep things > up as well. > >>> -- > >>> Julie Haugh > >>> Senior Design Engineer > >>> greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 13:12:03 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 12:12:03 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> Message-ID: <4D768D93.1030504@gmail.com> So I looked over the Tunerpro log again today.. is it me or does it appear to be reusing values ? On 03/08/11 03:00, jfh at greenhousepc.com wrote: > Curtis, > > At the risk of being told "No, they really say it can be done", 30 > sensors is 30 * 3 character times (are you sure it's not a single byte > response?). At 1953 baud, a single character time is 10 bits * (1 / > 1953) seconds, or 15.4ms as Bob pointed out. 30 * 15.4ms is 460ms, > and that assumes everything works perfectly, no turnaround times, etc. > > If you can come up with some other way to make the math work, I'd love > to hear it. > > Short and sweet -- just because TunerPro can talk to an ECM/ECU that > is running faster than 1953 baud doesn't mean your Mitsubishi (or > whatever car you've got that runs at 1953 baud) runs at that faster > baud rate. > > Also, are you sure your data cable is correct? What cable are you > using? What's the schematic? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 2:33 am > To: rxtx at qbang.org > > I am going to try a couple things today and hopefully figure > something out. > > Bob I don't want to pop your bubble, but a native application named > 'TunerPro' can sample the same data, over 30 sensors, in less than > 25ms. > I've exchanged some emails with the author and it is a native C, > polling, no events just timeouts. > > Kusta thanks for the FTDI notice, I believe that is tunable, > however I > have a particular user using a Keyspan converter and verified > sampling > rate with 'TunerPro' and its just off the charts. > > Chris thank you, I'll look into the queing. > > On 03/07/11 23:02, Bob Jacobsen wrote: > > If you're transferring three bytes total at 1953 baud, it's going > to take 3*(8+2)*1000/1953 = 15.4 msec no matter what. Having to > wait 20msec to get the data back instead of 15.4 msec doesn't seem > to be as big a problem as you're making it sound. > > > > Bob > > > > On Mar 7, 2011, at 8:04 PM, Curtis Hacker wrote: > > > >> I guess I'm gunna need some serious help with this then, because > of the scenario I'm stuck with. > >> > >> To communicate there is only 1 data line, rx/tx tied together > with a diode protecting the tx. No RTS/CTS handshaking nothing.. > >> > >> So the ecu can't process the next byte of info, without you > pulling the 2 bytes back. I wish this was standard, but even the > baud rate isn't (1953). OBD1.5 crap. I am really stuck in a hard > spot with this.. > >> > >> in.read(data , 0, 2); > >> ^ would the above wait till the timeout to read 2 bytes ? or > read 1 byte wait for the 2nd ? or just read the 1 ?? > >> > >> On 03/07/11 18:50, jfh at greenhousepc.com > wrote: > >>> Curtis, > >>> > >>> No, I assume he means a real queue, not just "don't read all > the bytes at once." However, if you know you can process some > number of requests in some amount of time, allowing data to pile > up (receiver FIFO space permitting) can be a valid strategy. > Inserting gobs of Thread.yield() and notify() can help pep things > up as well. > >>> -- > >>> Julie Haugh > >>> Senior Design Engineer > >>> greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 13:51:13 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 13:51:13 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308135113.8ef0e5b4a80cef441275a6330ffad77d.a5fff5bbc7.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From bob_jacobsen at lbl.gov Tue Mar 8 14:14:57 2011 From: bob_jacobsen at lbl.gov (Bob Jacobsen) Date: Tue, 8 Mar 2011 14:14:57 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D76848F.5080809@gmail.com> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> Message-ID: <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > Tunerpro log : http://www.ds-map.net/tunerpro_log.csv It's only reading one sensor per line. Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT changed in lines 16 and 40; every 24 lines but at a different phase. GramsRev in lines 23 and 47; every 24 lines, at yet another phase. Looks like (69-1) readings in 1.30 seconds = 19msec per reading. Arithmetic still works! Bob -- Bob Jacobsen, LBNL Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From hakcenter at gmail.com Tue Mar 8 14:27:12 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 13:27:12 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> Message-ID: <4D769F30.9050807@gmail.com> Thank you guys, cause I was really worried there. I guess another win for math today hahaha. So what is the imposed latency that rxtx has ? maybe 5-10ms ? On 03/08/11 13:14, Bob Jacobsen wrote: > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > It's only reading one sensor per line. > > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT changed in lines 16 and 40; every 24 lines but at a different phase. GramsRev in lines 23 and 47; every 24 lines, at yet another phase. > > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. Arithmetic still works! > > Bob > -- > Bob Jacobsen, LBNL > Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From tjarvi at qbang.org Tue Mar 8 14:07:24 2011 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 8 Mar 2011 14:07:24 -0700 (MST) Subject: [Rxtx] Latency Woes In-Reply-To: <4D769F30.9050807@gmail.com> References: <20110308040017.8ef0e5b4a80cef441275a6330ffad77d.e6d91bd4a9.wbe@email13.secureserver.net> <4D76848F.5080809@gmail.com> <490A9CB3-EF8F-4DCB-98C9-F6E6100EAFFF@lbl.gov> <4D769F30.9050807@gmail.com> Message-ID: Hi Curtis While not your exact question, a simple test I performed can give you a ballpark idea. Writing a byte to a loopback at 9600 baud and displaying elapsed time on the data available event takes ~10 ms round trip in a large application. There are occasional 20 ms latencies. I used a typical linux desktop to try it just now without any special considerations. Windows NT was a little faster - maybe 8 ms - when I tried several years ago. On Tue, 8 Mar 2011, Curtis Hacker wrote: > Thank you guys, cause I was really worried there. I guess another win for > math today hahaha. So what is the imposed latency that rxtx has ? maybe > 5-10ms ? > > On 03/08/11 13:14, Bob Jacobsen wrote: >> On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >>> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> It's only reading one sensor per line. >> >> Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 lines. IAT >> changed in lines 16 and 40; every 24 lines but at a different phase. >> GramsRev in lines 23 and 47; every 24 lines, at yet another phase. >> >> Looks like (69-1) readings in 1.30 seconds = 19msec per reading. >> Arithmetic still works! >> >> Bob >> -- >> Bob Jacobsen, LBNL >> Bob_Jacobsen at lbl.gov +1-510-486-7355 fax +1-510-643-8497 AIM, Skype >> JacobsenRG >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Wei.Shen at Honeywell.com Tue Mar 8 15:15:32 2011 From: Wei.Shen at Honeywell.com (Shen, Wei (AB21)) Date: Tue, 8 Mar 2011 17:15:32 -0500 Subject: [Rxtx] [rxtx] disconnect event Message-ID: <83B3B1411349194D9D05821CEF48E78C02284B17@DE08EV1001.global.ds.honeywell.com> Hi, Is the UART disconnect event implemented in rxtx-2.1-7r2? If not, can anyone share the port communication recovery mechanism? I tried to close the port after the connection is lost. However, I got port in use exception when I try to reopen the same port the next time. I do not use any event listener. The communication is very simple. Everything is synchronized. It does not send any message until it receives message. Please help. Thanks. Wei Shen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 16:05:12 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 16:05:12 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 16:26:15 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 15:26:15 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> References: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> Message-ID: <4D76BB17.2090305@gmail.com> So if I could get the baud up 15625, theoretical maximum latency is 1.92ms ? Basically 500 samples/sec ? 125000, theoretical maximum latency is 0.24ms ? Basically 4167 samples/sec ? Keeping the protocol the same. On 03/08/11 15:05, jfh at greenhousepc.com wrote: > Curtis, > > It's nowhere near that bad. I'd measured it once before, and I > believe it's sub-millisecond. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 3:27 pm > To: rxtx at qbang.org > > Thank you guys, cause I was really worried there. I guess another win > for math today hahaha. So what is the imposed latency that rxtx has ? > maybe 5-10ms ? > > On 03/08/11 13:14, Bob Jacobsen wrote: > > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > > It's only reading one sensor per line. > > > > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 > lines. IAT changed in lines 16 and 40; every 24 lines but at a > different phase. GramsRev in lines 23 and 47; every 24 lines, at > yet another phase. > > > > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. > Arithmetic still works! > > > > Bob > > -- > > Bob Jacobsen, LBNL > > Bob_Jacobsen at lbl.gov > +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > > > > > > > > > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at qbang.org > > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Tue Mar 8 17:40:36 2011 From: jredman at ergotech.com (Jim Redman) Date: Tue, 08 Mar 2011 17:40:36 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <4D76BB17.2090305@gmail.com> References: <20110308160512.8ef0e5b4a80cef441275a6330ffad77d.f4762000cd.wbe@email13.secureserver.net> <4D76BB17.2090305@gmail.com> Message-ID: <4D76CC84.9040307@ergotech.com> How long does it take the device to generate a response? Increasing the baud rate may not help you much if the device takes a significant amount of time to process the request. On 03/08/2011 04:26 PM, Curtis Hacker wrote: > So if I could get the baud up > 15625, theoretical maximum latency is 1.92ms ? Basically 500 samples/sec ? > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 samples/sec ? > > Keeping the protocol the same. > > On 03/08/11 15:05, jfh at greenhousepc.com wrote: >> Curtis, >> >> It's nowhere near that bad. I'd measured it once before, and I >> believe it's sub-millisecond. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker > >> Date: Tue, March 08, 2011 3:27 pm >> To: rxtx at qbang.org >> >> Thank you guys, cause I was really worried there. I guess another win >> for math today hahaha. So what is the imposed latency that rxtx has ? >> maybe 5-10ms ? >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> > It's only reading one sensor per line. >> > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 >> lines. IAT changed in lines 16 and 40; every 24 lines but at a >> different phase. GramsRev in lines 23 and 47; every 24 lines, at >> yet another phase. >> > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. >> Arithmetic still works! >> > >> > Bob >> > -- >> > Bob Jacobsen, LBNL >> > Bob_Jacobsen at lbl.gov >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx 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 jfh at greenhousepc.com Tue Mar 8 17:58:24 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 17:58:24 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 18:06:04 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 18:06:04 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 18:14:14 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 17:14:14 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> References: <20110308175824.8ef0e5b4a80cef441275a6330ffad77d.416dd012ef.wbe@email13.secureserver.net> Message-ID: <4D76D466.7060303@gmail.com> I can edit the ECU eeprom to change the baud rate divisor to bump it up from 1953, to 15625 or 125000. But as Jim asked how fast the device can respond.. not very fast in its stock form. I can recode a lot of the eeprom for the ecu to alter the ecus baud rate, and put the response code into its own interrupt. I just wanted to make sure that in order to lower latency and increase sampling rate. I have to increase the baud rate of the ecu and the user right ? Or change the protocol.. to respond with more sensors per request. On 03/08/11 16:58, jfh at greenhousepc.com wrote: > Unless the ECU can auto-detect the baud rate, it won't even work. > > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Jim Redman > > Date: Tue, March 08, 2011 6:40 pm > To: rxtx at qbang.org > > How long does it take the device to generate a response? > > Increasing the baud rate may not help you much if the device takes a > significant amount of time to process the request. > > > On 03/08/2011 04:26 PM, Curtis Hacker wrote: > > So if I could get the baud up > > 15625, theoretical maximum latency is 1.92ms ? Basically 500 > samples/sec ? > > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 > samples/sec ? > > > > Keeping the protocol the same. > > > > On 03/08/11 15:05, jfh at greenhousepc.com > wrote: > >> Curtis, > >> > >> It's nowhere near that bad. I'd measured it once before, and I > >> believe it's sub-millisecond. > >> -- > >> Julie Haugh > >> Senior Design Engineer > >> greenHouse Computers, LLC // jfh at greenhousepc.com > > >> ; // > greenHousePC on Skype > >> > >> > >> -------- Original Message -------- > >> Subject: Re: [Rxtx] Latency Woes > >> From: Curtis Hacker > > >> Date: Tue, March 08, 2011 3:27 pm > >> To: rxtx at qbang.org > >> > >> Thank you guys, cause I was really worried there. I guess > another win > >> for math today hahaha. So what is the imposed latency that rxtx > has ? > >> maybe 5-10ms ? > >> > >> On 03/08/11 13:14, Bob Jacobsen wrote: > >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: > >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv > >> > It's only reading one sensor per line. > >> > > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every 24 > >> lines. IAT changed in lines 16 and 40; every 24 lines but at a > >> different phase. GramsRev in lines 23 and 47; every 24 lines, at > >> yet another phase. > >> > > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per reading. > >> Arithmetic still works! > >> > > >> > Bob > >> > -- > >> > Bob Jacobsen, LBNL > >> > Bob_Jacobsen at lbl.gov > > >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG > >> > > >> > > >> > > >> > > >> > > >> > _______________________________________________ > >> > Rxtx mailing list > >> > Rxtx at qbang.org > >> > http://mailman.qbang.org/mailman/listinfo/rxtx > >> > > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx at qbang.org > >> http://mailman.qbang.org/mailman/listinfo/rxtx > >> > >> > >> _______________________________________________ > >> Rxtx mailing list > >> Rxtx 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 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jredman at ergotech.com Tue Mar 8 18:19:14 2011 From: jredman at ergotech.com (Jim Redman) Date: Tue, 08 Mar 2011 18:19:14 -0700 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> References: <20110308180604.8ef0e5b4a80cef441275a6330ffad77d.8e57eb0d09.wbe@email13.secureserver.net> Message-ID: <4D76D592.9000802@ergotech.com> I'm no expert on this, but isn't the underlying ODB-II CAN bus or something similar. They always seem to require a dongle that converts to something. I know you can get serial, bluetooth, USB, etc. converters. I've seen serial dongles that claim multiple baud rates, so I suspect that whatever's providing the conversion may significantly affect the performance. A big second on the required timing comment. I suspect some intelligent consideration of what values change quickly (RPM, Speed, maybe things like fuel pressure) and read values like fuel levels, coolant temps, etc. much less frequently. On 03/08/2011 06:06 PM, jfh at greenhousepc.com wrote: > Curtis, > > You can't just increase the baud rate and have the device adapt to that > rate. Embedded systems tend to have their communications parameters > either hard coded in a memory location or else they are using a hardware > timebase. You're welcome to try increasing the baud rate, but there is > no guarantee it will even work. > > Whoever designed the ECU probably selected the baud rate for a good > reason. My suggestion would be to look at how the sensor values are all > laid out and go from there. Also, look at what the sensor represent and > consider the physical properties of what is being measured. It's > extremely unlikely that, for example, the coolant temperature is going > to rise more than 1* per second. If that much. Some values might change > more often, but do they really matter on a sub-second measurement basis? > > Part of software =engineering= is understanding the problem. Anyone can > sling code in the hope it works. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 5:26 pm > To: rxtx at qbang.org > > So if I could get the baud up > 15625, theoretical maximum latency is 1.92ms ? Basically 500 > samples/sec ? > 125000, theoretical maximum latency is 0.24ms ? Basically 4167 > samples/sec ? > > Keeping the protocol the same. > > On 03/08/11 15:05, jfh at greenhousepc.com wrote: >> Curtis, >> >> It's nowhere near that bad. I'd measured it once before, and I >> believe it's sub-millisecond. >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Curtis Hacker > > >> Date: Tue, March 08, 2011 3:27 pm >> To: rxtx at qbang.org >> >> Thank you guys, cause I was really worried there. I guess >> another win >> for math today hahaha. So what is the imposed latency that >> rxtx has ? >> maybe 5-10ms ? >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> > It's only reading one sensor per line. >> > >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; every >> 24 lines. IAT changed in lines 16 and 40; every 24 lines but >> at a different phase. GramsRev in lines 23 and 47; every 24 >> lines, at yet another phase. >> > >> > Looks like (69-1) readings in 1.30 seconds = 19msec per >> reading. Arithmetic still works! >> > >> > Bob >> > -- >> > Bob Jacobsen, LBNL >> > Bob_Jacobsen at lbl.gov >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> > >> > >> > >> > >> > >> > _______________________________________________ >> > Rxtx mailing list >> > Rxtx at qbang.org >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> > >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > ------------------------------------------------------------------------ > _______________________________________________ > Rxtx mailing list > Rxtx 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 jfh at greenhousepc.com Tue Mar 8 18:32:28 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 18:32:28 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From hakcenter at gmail.com Tue Mar 8 19:45:00 2011 From: hakcenter at gmail.com (Curtis Hacker) Date: Tue, 08 Mar 2011 18:45:00 -0800 Subject: [Rxtx] Latency Woes In-Reply-To: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> References: <20110308183228.8ef0e5b4a80cef441275a6330ffad77d.026e306ead.wbe@email13.secureserver.net> Message-ID: <4D76E9AC.8050909@gmail.com> Julie, I really am not looking at the practicality of it. I was just wondering if that is how it works. I don't know a whole lot about rs232, which is the main reason I've been on this mailing list for a couple years. I have full control over the ecu eeprom code, I can change its baud rate, I can re-write the logging interface, I could update the ADC's on the ecu in the interface so that when you request said sensor it updates the ADC then replies it. But I wanted to know if the underlying issue with a 2mhz/8mhz processor is the baud rate keeping sampling down ? On 03/08/11 17:32, jfh at greenhousepc.com wrote: > Curtis, > > You also have to look at the response time of the sensor itself. > > Seriously -- look at what the sensors are reporting and determine if > the underlying physical property can actually change that rapidly. > And even if it can, do you really need to know that. > > I built drag bikes in the 70's and I drive sports cars in my old age. > You don't really need millisecond sampling rates for every single last > sensor coming out of the engine. Boost pressure, fuel pressure, > manifold pressure and RPMs are probably high frequency sensors if you > want to tweak the motor for turbo lag or something, but other than > that, are you really going to be able to make sense of all that data? > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com > // greenHousePC on Skype > > > -------- Original Message -------- > Subject: Re: [Rxtx] Latency Woes > From: Curtis Hacker > > Date: Tue, March 08, 2011 7:14 pm > To: rxtx at qbang.org > > I can edit the ECU eeprom to change the baud rate divisor to bump > it up from 1953, to 15625 or 125000. But as Jim asked how fast the > device can respond.. not very fast in its stock form. > > I can recode a lot of the eeprom for the ecu to alter the ecus > baud rate, and put the response code into its own interrupt. > > I just wanted to make sure that in order to lower latency and > increase sampling rate. I have to increase the baud rate of the > ecu and the user right ? Or change the protocol.. to respond with > more sensors per request. > > On 03/08/11 16:58, jfh at greenhousepc.com wrote: >> Unless the ECU can auto-detect the baud rate, it won't even work. >> >> -- >> Julie Haugh >> Senior Design Engineer >> greenHouse Computers, LLC // jfh at greenhousepc.com >> // greenHousePC on Skype >> >> >> -------- Original Message -------- >> Subject: Re: [Rxtx] Latency Woes >> From: Jim Redman > > >> Date: Tue, March 08, 2011 6:40 pm >> To: rxtx at qbang.org >> >> How long does it take the device to generate a response? >> >> Increasing the baud rate may not help you much if the device >> takes a >> significant amount of time to process the request. >> >> >> On 03/08/2011 04:26 PM, Curtis Hacker wrote: >> > So if I could get the baud up >> > 15625, theoretical maximum latency is 1.92ms ? Basically 500 >> samples/sec ? >> > 125000, theoretical maximum latency is 0.24ms ? Basically >> 4167 samples/sec ? >> > >> > Keeping the protocol the same. >> > >> > On 03/08/11 15:05, jfh at greenhousepc.com >> wrote: >> >> Curtis, >> >> >> >> It's nowhere near that bad. I'd measured it once before, and I >> >> believe it's sub-millisecond. >> >> -- >> >> Julie Haugh >> >> Senior Design Engineer >> >> greenHouse Computers, LLC // jfh at greenhousepc.com >> >> >> ; // >> greenHousePC on Skype >> >> >> >> >> >> -------- Original Message -------- >> >> Subject: Re: [Rxtx] Latency Woes >> >> From: Curtis Hacker > > >> >> Date: Tue, March 08, 2011 3:27 pm >> >> To: rxtx at qbang.org >> >> >> >> >> Thank you guys, cause I was really worried there. I guess >> another win >> >> for math today hahaha. So what is the imposed latency that >> rxtx has ? >> >> maybe 5-10ms ? >> >> >> >> On 03/08/11 13:14, Bob Jacobsen wrote: >> >> > On Mar 8, 2011, at 12:33 PM, Curtis Hacker wrote: >> >> >> Tunerpro log : http://www.ds-map.net/tunerpro_log.csv >> >> > It's only reading one sensor per line. >> >> > >> >> > Note that e.g. Boost PSI changed in lines 6, 30 and 54; >> every 24 >> >> lines. IAT changed in lines 16 and 40; every 24 lines but at a >> >> different phase. GramsRev in lines 23 and 47; every 24 >> lines, at >> >> yet another phase. >> >> > >> >> > Looks like (69-1) readings in 1.30 seconds = 19msec per >> reading. >> >> Arithmetic still works! >> >> > >> >> > Bob >> >> > -- >> >> > Bob Jacobsen, LBNL >> >> > Bob_Jacobsen at lbl.gov >> >> >> +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Rxtx mailing list >> >> > Rxtx at qbang.org >> >> >> > http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx at qbang.org >> >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> >> >> >> >> _______________________________________________ >> >> Rxtx mailing list >> >> Rxtx 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 >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > ------------------------------------------------------------------------ > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfh at greenhousepc.com Tue Mar 8 20:43:11 2011 From: jfh at greenhousepc.com (jfh at greenhousepc.com) Date: Tue, 08 Mar 2011 20:43:11 -0700 Subject: [Rxtx] Latency Woes Message-ID: <20110308204311.8ef0e5b4a80cef441275a6330ffad77d.e9b135168c.wbe@email13.secureserver.net> An HTML attachment was scrubbed... URL: From andrea.antonello at gmail.com Wed Mar 9 06:50:07 2011 From: andrea.antonello at gmail.com (andrea antonello) Date: Wed, 9 Mar 2011 14:50:07 +0100 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> References: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> Message-ID: Has anyone tried the lib? I am not sure if it is appropriate to write to the list about this, if not, I apologize. I wanted to try your fork out for our application which is an eclipse rcp plugin based one. It has been easy to substitute the 6 plugins with your library (that is one of the things I like). But then when I run it, it tries to load it from: ---- Loading: /tmp/libNRJavaSerial_moovida_0/libNRJavaSerial.so Trying to load: NRJavaSerial Trying to load: libNRJavaSerial Trying to load: rxtxSerial ---- So it is extracting the native lib to a tmp folder. But that one is not in the library path, so it fails. Is there any docs to try the lib out? Thanks, Andrea On Mon, Mar 7, 2011 at 11:54 PM, wrote: > Aaron, > > It should be possible for an Android to do BlueTooth serial.? If I were > looking for a serial solution, that's how I'd go. > -- > Julie Haugh > Senior Design Engineer > greenHouse Computers, LLC // jfh at greenhousepc.com // greenHousePC on > Skype > > -------- Original Message -------- > Subject: [SPAM] Re: [Rxtx] NRJavaSerial, a fork of rxtx that fixes the > papercuts! > From: Aaron Wolfe > Date: Mon, March 07, 2011 4:31 pm > To: rxtx at qbang.org > > On Mon, Mar 7, 2011 at 12:47 PM, Kevin Harrington NR > wrote: >> Hey all, this is just a heads up that i have made a fork of >> rxtxSerial. Some of the features we have added: >> >> * Self deployment of native libraries ( all native code is stored >> inside the jar and deployed at runtime). No more manual install of >> native code. >> * Arm Cortex support (Gumstix) >> * Android Support (requires a rooted phone for now) >> * Google Code (SVN) repository for easy code and jar access >> * Single makefile compile (simplifies the compilation of project binaries) >> * Ant build script for jar creation >> * Removal of partialy implemented code to streamline the lib for just >> serial port access >> * Full Eclipse integration, for testing application code against sources. >> >> And a bunch of bug fixes: >> >> * Fixed the memory access error that causes OSX to crash the JVM when >> serial.close() is cvalled >> * Fixed the windows serial port zombie bind that prevents re-accessing >> serial ports when exiting on an exception >> * Fixed erronious printouts of native library mis-match >> >> To check it out, take a look at our page here: >> >> http://code.google.com/p/nrjavaserial/ > > This is interesting, getting the native libs set up has been an issue > for some of my users. Will have to check it out. > > Out of curiosity, what Android devices provide a serial port? Or are > there some that allow USB host mode and then a usb-serial adapter? I > have only an Android cell phone, don't think it can do anything serial > but would love to be wrong 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 Cougar at CasaDelGato.Com Wed Mar 9 10:02:24 2011 From: Cougar at CasaDelGato.Com (John G. Lussmyer) Date: Wed, 09 Mar 2011 09:02:24 -0800 Subject: [Rxtx] [SPAM] Re: NRJavaSerial, a fork of rxtx that fixes the papercuts! In-Reply-To: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> References: <20110307155437.8ef0e5b4a80cef441275a6330ffad77d.6914b82572.wbe@email13.secureserver.net> Message-ID: <4D77B2A0.8020004@CasaDelGato.Com> On 3/7/2011 2:54 PM, jfh at greenhousepc.com wrote: > Aaron, > > It should be possible for an Android to do BlueTooth serial. If I > were looking for a serial solution, that's how I'd go. Actually, I can't figure out WHY you would need RxTx on an Android device. The built in bluetooth support works just fine with a serial-bluetooth converter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Tue Mar 1 00:54:17 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 09:54:17 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> Message-ID: Adrian, had a look at your code/rewrite and it looks rather clean/nice. I was looking at the code to gain insight (not related to the rewrite) into what is involved in serial port programming in Windows. Or rather, to refresh my memory and see how others have done, because I've been there done that. So my questions are just to satisfy my curiosity, not to criticize or suggest improvements. 1) It looks like a new thread (EventMonitor) is created for each Serial port, is that correct? Many people seem to try to avoid using many threads in this sort of situation, and like to use something like unix select(). I personally find using threads more natural and better impedance match to the problem being solved here. I guess 'many people' above refers to those implementing thousands of connections and who cannot live with the overhead and limited number of threads available. 2) The EventMonitor basically polls for events at 50 msec interval? 3) There is a comment in the source code near the sleep(50) : // Sufficient up to 19200 baud I'm sure you thought about this carefully, so again not criticizing, but seeking to understand how or why, because at 50 msec would seem to limit through in some cases. Like if you send one byte and need to wait for one to return, then this limits speed to 200 chars/sec? 4) I've done something similar to a few years back from Java using JNI to access Win32 API serial port, and I seem to recall that I had threading issues ie when I submitted a read (ReadFile) and there was no data coming in, the thread would not only block but also consume a lot of CPU cycles ie it was not sleeping properly inside the ReadFile call when the serial port blocked. Im a bit fuzzy about the details after five years, so my question is have you checked if there an issue here? 5) AFAIK the select() on Windows does not work serial ports but there is some other mechanism (events?) to implement the same functionality, did you consider that? Probably, so you decided against it, why? br Kusti From adrian.crum at sandglass-software.com Tue Mar 1 04:13:34 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:13:34 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: References: Message-ID: <4D6CD4DE.7040501@sandglass-software.com> The javax.comm API specification requires one event monitor thread per port. I don't like the idea of having a thread per port either, but one of the rewrite's design goals is strict conformance to the specification. The 50 mS polling interval is just a placeholder. The final design of that is yet to be decided. In Windows, you have two choices for I/O: overlapped and non-overlapped. In overlapped I/O a thread is blocked, waiting for something to happen. In non-overlapped I/O a thread does not block. I chose non-overlapped I/O to avoid thread blocking at the OS level - instead, the thread blocking is kept in Java. -Adrian On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > Adrian, > > had a look at your code/rewrite and it looks rather clean/nice. > > I was looking at the code to gain insight (not related to the > rewrite) into what is involved in serial port programming > in Windows. Or rather, to refresh my memory and see how others have > done, because I've been there done that. > > So my questions are just to satisfy my curiosity, not to criticize > or suggest improvements. > > 1) It looks like a new thread (EventMonitor) is created for > each Serial port, is that correct? > > Many people seem to try to avoid using many threads in this sort > of situation, and like to use something like unix select(). > I personally find using threads more natural and better impedance > match to the problem being solved here. I guess 'many people' above > > refers to those implementing thousands of connections and > who cannot live with the overhead and limited number of threads > available. > > 2) The EventMonitor basically polls for events at 50 msec interval? > > 3) There is a comment in the source code near the sleep(50) : > > // Sufficient up to 19200 baud > > > I'm sure you thought about this carefully, so again not > criticizing, but seeking to understand how or why, because > at 50 msec would seem to limit through in some cases. Like > if you send one byte and need to wait for one to return, > then this limits speed to 200 chars/sec? > > 4) I've done something similar to a few years back from > Java using JNI to access Win32 API serial port, and > I seem to recall that I had threading issues ie when > I submitted a read (ReadFile) and there was no data coming > in, the thread would not only block but also consume a > lot of CPU cycles ie it was not sleeping properly inside > the ReadFile call when the serial port blocked. > > Im a bit fuzzy about the details after five years, so my question is > have you checked if there an issue here? > > > 5) AFAIK the select() on Windows does not work serial ports > but there is some other mechanism (events?) to implement the > same functionality, did you consider that? Probably, so you > decided against it, why? > > > br Kusti > > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Tue Mar 1 04:25:23 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:25:23 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C2E90.9010601@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] > My question would be: Why would you do that? The rewrite does > most of the work for you - all you have to do is implement > two C++ virtual classes and two C++ functions. You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? I just took a short look, maybe it could be discussed further, but I don't think I like it much. BTW, the main interface defined there is called gnu.io.Dispatcher? I thought the package names should be used in a way to avoid clashes, e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name space authority :)). > In Windows that took me a few hours. where is the implementation? I found commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp with things like const bool SerialPortImpl::isDataAvailable() const { // Needs implementation return true; } and timeouts.ReadIntervalTimeout = MAXDWORD;* timeouts.ReadTotalTimeoutMultiplier = 0; timeouts.ReadTotalTimeoutConstant = 0; timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 0; if (!SetCommTimeouts(hComm, &timeouts)) throw IOException(); which seems to be oversimplified or some prototype only? I think (and I wrote about this already in the past years) that correct timeout handling is one of the challenges, so I think this should be prototyped first - for each system flavor - before cementation of the (JNI-) interfaces. Personally, I would vote to form it in a way allowing to be implemented on embedded devices, for example. Another big challenge is to prove a rewrite fully working (and probably compatible to the old implementation) on "all" the supported OSes. Not a big problem for linux and windows, just use some thousand lines test code, test drivers and serial loopbacks etc, but for the exotic platforms, probably a high number of, this probably won't be too easy... (there are more challenges, such as being comfortable and threadsafe [are read and write permitted at the same time?], detailed and helpful exceptions on user API level [not necessarily on JNI/JNA layer], how to have a configurable threadsafe logging/tracing [maybe also from native code to assist porting / testing on exotic OSes, such as OSes where the developers have no direct access too, which can be quite hard to usually leads to good log messages], just to name a few.). So even it might seem easy for one platform and I agree with Micheal that > > * yay! let's start a rewrite is unlikely to succeede soon... However, when considering this, before IMHO a powerful Java API has to be defined, because according to my experiences for implementing non-trivial protocols InputStream/OutputStream might not be comfortable/powerfull enough (eventually I consider both wrong) and have some InputStream derivation available as wrapper (so applications can use InputStream and whatever high-level-API they want). The JNI interface shall make such a powerful implementation possible, thus the interface of it is driving the JNI interface design and thus I think it had to be done first. All this surely requires much work: agreements on the APIs, safeness for the users, design, documentation, all the implementations and the testing. As long as such bug amount of work cannot be spent, for example if some employee would get half a year time paid for it or so :-), probably it is unlikely to progress on this. Otherwise, I'm afraid, patches, improvements, new design ideas and even rewrites wouldn't become complete and thus won't form a new rxtx version (3.0); thus either collect dust in some forgotten CVS branch or could generate a split... > I can't imagine other ports taking > much longer than that - especially since POSIX-based code can > be shared between ports. Things are more complex than they seem to be... I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select on serial ports isn't supported; maybe it is non-trivial to "map" (like mapping select() to WaitForMultipleObjects() which might have different semantics etc.) or maybe some different approach has to be used. A system may have POSIX like termios interfaces but not support timeouts or have any other interoperability bug... You never run out of things that can go wrong. And if something can go wrong, it will... :-) Or, as Michael wrote: > > I seriously don't believe anyone will come up with anything better anytime soon. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Tue Mar 1 04:39:37 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 12:39:37 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com><13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BED6B@COSNPREXC3.usr.ingenico.loc> > 3. Write all of the native (or non-native) code to implement > the native interface. > > Is that correct? If yes, how is that easier than the simple > implementation the current rewrite design uses? To have it complete, reliable, traceable, maintainable and well tested, it is much more work, I'm afraid. A prototype can be done within a few days (maybe on one day), but getting it right (including a passed review) IMHO is a completely different story. In the end you may end up with an average of ten lines per day, when assuming four major native packs (common, win, mac, termios/select) with let's say just 5000 lines each (with logging messages and detailed exceptions this is not much) we would have to estimate a total effort of nine man-years (20000/10/220)... oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 04:40:18 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 03:40:18 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6CDB22.9070401@sandglass-software.com> Every journey begins with a single step. -Adrian On 3/1/2011 3:25 AM, Steffen DETTMER wrote: > * rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] >> My question would be: Why would you do that? The rewrite does >> most of the work for you - all you have to do is implement >> two C++ virtual classes and two C++ functions. > You mean the src found in commapi-0-0-1/rxtx-devel/Rewrite2010/? > I just took a short look, maybe it could be discussed further, > but I don't think I like it much. > BTW, the main interface defined there is called gnu.io.Dispatcher? > I thought the package names should be used in a way to avoid clashes, > e.g. org.rxtx.io2.Dispatcher or so (to be agreed with the rxtx.org name > space authority :)). > >> In Windows that took me a few hours. > where is the implementation? > I found > commapi-0-0-1/rxtx-devel/Rewrite2010/src/windows/W32_SerialPort.cpp > with things like > > const bool SerialPortImpl::isDataAvailable() const > { > // Needs implementation > return true; > } > > and > > timeouts.ReadIntervalTimeout = MAXDWORD;* > timeouts.ReadTotalTimeoutMultiplier = 0; > timeouts.ReadTotalTimeoutConstant = 0; > timeouts.WriteTotalTimeoutMultiplier = 0; > timeouts.WriteTotalTimeoutConstant = 0; > if (!SetCommTimeouts(hComm,&timeouts)) > throw IOException(); > > which seems to be oversimplified or some prototype only? > > I think (and I wrote about this already in the past years) that correct > timeout handling is one of the challenges, so I think this should be > prototyped first - for each system flavor - before cementation of the > (JNI-) interfaces. Personally, I would vote to form it in a way allowing > to be implemented on embedded devices, for example. > > Another big challenge is to prove a rewrite fully working (and probably > compatible to the old implementation) on "all" the supported OSes. Not a > big problem for linux and windows, just use some thousand lines test > code, test drivers and serial loopbacks etc, but for the exotic > platforms, probably a high number of, this probably won't be too easy... > (there are more challenges, such as being comfortable and threadsafe > [are read and write permitted at the same time?], detailed and helpful > exceptions on user API level [not necessarily on JNI/JNA layer], how to > have a configurable threadsafe logging/tracing [maybe also from native > code to assist porting / testing on exotic OSes, such as OSes where the > developers have no direct access too, which can be quite hard to usually > leads to good log messages], just to name a few.). > > So even it might seem easy for one platform and I agree with Micheal > that > >>> * yay! let's start a rewrite > is unlikely to succeede soon... > > However, when considering this, before IMHO a powerful Java API has to > be defined, because according to my experiences for implementing > non-trivial protocols InputStream/OutputStream might not be > comfortable/powerfull enough (eventually I consider both wrong) and have > some InputStream derivation available as wrapper (so applications can > use InputStream and whatever high-level-API they want). > The JNI interface shall make such a powerful implementation possible, > thus the interface of it is driving the JNI interface design and thus I > think it had to be done first. > > All this surely requires much work: agreements on the APIs, safeness for > the users, design, documentation, all the implementations and the > testing. As long as such bug amount of work cannot be spent, for example > if some employee would get half a year time paid for it or so :-), > probably it is unlikely to progress on this. > > Otherwise, I'm afraid, patches, improvements, new design ideas and even > rewrites wouldn't become complete and thus won't form a new rxtx version > (3.0); thus either collect dust in some forgotten CVS branch or could > generate a split... > >> I can't imagine other ports taking >> much longer than that - especially since POSIX-based code can >> be shared between ports. > Things are more complex than they seem to be... > > I have no clue what specifics some IRIX 5 or HP-UX 10 has. Maybe select > on serial ports isn't supported; maybe it is non-trivial to "map" (like > mapping select() to WaitForMultipleObjects() which might have different > semantics etc.) or maybe some different approach has to be used. A > system may have POSIX like termios interfaces but not support timeouts > or have any other interoperability bug... > You never run out of things that can go wrong. And if something can go > wrong, it will... :-) > > Or, as Michael wrote: > >>> I seriously don't believe anyone will come up with anything better > anytime soon. > > oki, > > Steffen > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Kustaa.Nyholm at planmeca.com Tue Mar 1 04:57:02 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Tue, 1 Mar 2011 13:57:02 +0200 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: On 3/1/11 13:13, "Adrian Crum" wrote: >The javax.comm API specification requires one event monitor thread per >port. I don't like the idea of having a thread per port either, but one >of the rewrite's design goals is strict conformance to the specification. Ah, had not spotted that requirement. > >The 50 mS polling interval is just a placeholder. The final design of >that is yet to be decided. > >In Windows, you have two choices for I/O: overlapped and non-overlapped. >In overlapped I/O a thread is blocked, waiting for something to happen. >In non-overlapped I/O a thread does not block. I chose non-overlapped >I/O to avoid thread blocking at the OS level - instead, the thread >blocking is kept in Java. > >-Adrian thanks for the explanation. br Kusti From iqzw2r602 at sneakemail.com Tue Mar 1 05:08:17 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:08:17 +1100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <32684-1298981297-704398@sneakemail.com> This reminds me of a nasty problem I had with overlapped I/O on windows with jpathwatch. You can't start an I/O request in one thread and then do the check if that request completed in another thread. Very strange things happen when you attempt that; made me change the design of the Windows implementation quite drastically (one thread on a command queue that executes requests from other threads instead of letting them wildly call into GetOverlappedResult()). Out of curiosity: Did you come across that too? Or are all requests handled in the same thread they're issued? Cheers, Uwe On Tue, Mar 1, 2011 at 10:13 PM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > The javax.comm API specification requires one event monitor thread per > port. I don't like the idea of having a thread per port either, but one of > the rewrite's design goals is strict conformance to the specification. > > The 50 mS polling interval is just a placeholder. The final design of that > is yet to be decided. > > In Windows, you have two choices for I/O: overlapped and non-overlapped. In > overlapped I/O a thread is blocked, waiting for something to happen. In > non-overlapped I/O a thread does not block. I chose non-overlapped I/O to > avoid thread blocking at the OS level - instead, the thread blocking is kept > in Java. > > -Adrian > > > On 2/28/2011 11:54 PM, Kustaa Nyholm wrote: > >> Adrian, >> >> had a look at your code/rewrite and it looks rather clean/nice. >> >> I was looking at the code to gain insight (not related to the >> rewrite) into what is involved in serial port programming >> in Windows. Or rather, to refresh my memory and see how others have >> done, because I've been there done that. >> >> So my questions are just to satisfy my curiosity, not to criticize >> or suggest improvements. >> >> 1) It looks like a new thread (EventMonitor) is created for >> each Serial port, is that correct? >> >> Many people seem to try to avoid using many threads in this sort >> of situation, and like to use something like unix select(). >> I personally find using threads more natural and better impedance >> match to the problem being solved here. I guess 'many people' above >> >> refers to those implementing thousands of connections and >> who cannot live with the overhead and limited number of threads >> available. >> >> 2) The EventMonitor basically polls for events at 50 msec interval? >> >> 3) There is a comment in the source code near the sleep(50) : >> >> // Sufficient up to 19200 baud >> >> >> I'm sure you thought about this carefully, so again not >> criticizing, but seeking to understand how or why, because >> at 50 msec would seem to limit through in some cases. Like >> if you send one byte and need to wait for one to return, >> then this limits speed to 200 chars/sec? >> >> 4) I've done something similar to a few years back from >> Java using JNI to access Win32 API serial port, and >> I seem to recall that I had threading issues ie when >> I submitted a read (ReadFile) and there was no data coming >> in, the thread would not only block but also consume a >> lot of CPU cycles ie it was not sleeping properly inside >> the ReadFile call when the serial port blocked. >> >> Im a bit fuzzy about the details after five years, so my question is >> have you checked if there an issue here? >> >> >> 5) AFAIK the select() on Windows does not work serial ports >> but there is some other mechanism (events?) to implement the >> same functionality, did you consider that? Probably, so you >> decided against it, why? >> >> >> br Kusti >> >> >> >> >> >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 05:37:07 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Tue, 1 Mar 2011 23:37:07 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6C5AAC.3070508@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> Message-ID: <1142-1298983027-957144@sneakemail.com> On Tue, Mar 1, 2011 at 1:32 PM, Adrian Crum wrote: > Just to make sure I'm understanding you correctly, anyone porting RxTx to > a new platform would have to do the following: > > 1. Write their own Java implementation of an abstract Dispatcher class. > yep. I'd probably put all my calls to native OS wrappers in there two, looks the most straight-forward to me. > 2. Write a native (JNI or JNA) interface for the abstract class > implementation. > yes. For POSIX you'd probably only write one piece of code that provides implementations for open(), close(), and friends. You can compile that on all posix platforms (yeah, the devil is in the detail, but it's very little code, still). So this does open() (when using ***, but you can also use +++) // Unix.java class Unix{ public static native int open(String filename, int flags, int mode); .... } // Unix.cpp JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) { const char* pathname = env->GetStringUTFChars(jpathname, 0); if(pathname == 0) return -1; // java throws an out of memory error in this case int result = open(pathname, flags, mode); Unix_cacheErrno(); // handle interference between JVM and errno; env->ReleaseStringUTFChars(jpathname, pathname); return result; } .... 3. Write all of the native (or non-native) code to implement the native > interface. > Not sure what you mean by that. I've done the OS wrappers in step 2. step 1. implements that Dispatcher. What else do I need? > Is that correct? If yes, how is that easier than the simple implementation > the current rewrite design uses? > Yes, except for 3 (see above). How it is easier: I can debug the Java code directly. I can step from the read() call of an input stream directly into the guts of the RXTX implementation on my platform and see e.g. why it's hanging, because I see all the way up the call stack right where it calls Unix.read(). You can't easily do that with a fat native library, especially if you have no second set of devtools installed (the ones for native development). And I bet anyone knowing both languages can write it faster in Java, with less bugs. > On a side note: there is no requirement to write native code using C++. If > C++ is a real obstacle to adoption, then regular C could be used instead. In > that case, there would be a Dispatcher.c file that contains function > protoypes that need to be implemented. Dispatcher.c would still maintain the > same role as Dispatcher.cpp - which is to shield native code developers from > the details of JNI. Just build out the missing functions using C data types > and you're ready to go. > As I said, whatever works for you. Java works for me better than C++ in this case... Cheers, Uwe -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Mar 1 08:26:41 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Mar 2011 16:26:41 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6CD4DE.7040501@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> Message-ID: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> > The javax.comm API specification requires one event monitor > thread per port. Where does it require this? Do you mean "All the events received by this listener are generated by one dedicated thread that belongs to the SerialPort object. "? I think this is an implementation detail, isn't it? At least it is mentioned after "The current implementation only allows one listener per SerialPort". A bit bad that javadoc does not distinguish between API spec and implementation documentation. Also I don't think that TooManyListenersException MUST be thrown (I think it CAN be thrown). > I don't like the idea of having a thread per > port either, but one of the rewrite's design goals is strict > conformance to the specification. (but not necessarily on JNI layer) > The 50 mS polling interval is just a placeholder. The final > design of that is yet to be decided. I though no polling would be wanted; what could be the placeholder stand for? Do you mean a different interval duration or do you mean something completely different? > In Windows, you have two choices for I/O: overlapped and > non-overlapped. > In overlapped I/O a thread is blocked, waiting for something > to happen. > In non-overlapped I/O a thread does not block. I chose > non-overlapped I/O to avoid thread blocking at the OS level - > instead, the thread blocking is kept in Java. Isn't "overlapped" (asynchronous) I/O meaning that you invoke some ReadFile(..., &overlapped, ...) INSTEAD of performing a synchronous (blocking) function call blocking the thread? As far as I see, W32_Support.cpp uses CreateFile without FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O operations are serialized, even if the calls to the read and write functions specify an OVERLAPPED structure." [1] and "A synchronous handle behaves such that I/O function calls using that handle are blocked until they complete" [2] Given that CCOMTIMEOUTS get: "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier members, specifies that the read operation is to return immediately with the bytes that have already been received, even if no bytes have been received." [3] It looks likes this implementation relies on polling, which probably would waste much computing power. What did I miss? oki, Steffen [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx [2] http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro nous_and_asynchronous_i_o_handles [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From adrian.crum at sandglass-software.com Tue Mar 1 09:23:47 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:23:47 -0800 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> Message-ID: <4D6D1D93.6090306@sandglass-software.com> Unfortunately, the javax.comm API specification includes a lot of implementation details. That is one of the weaknesses of the specification in my opinion. The bottom line is, anyone wanting to use RxTx as a javax.comm implementation is going to expect it to do the things the specification says it does. -Adrian On 3/1/2011 7:26 AM, Steffen DETTMER wrote: >> The javax.comm API specification requires one event monitor >> thread per port. > Where does it require this? > > Do you mean "All the events received by this listener are generated > by one dedicated thread that belongs to the SerialPort object. "? > > I think this is an implementation detail, isn't it? At least it is > mentioned after "The current implementation only allows one listener per > SerialPort". A bit bad that javadoc does not distinguish between API > spec and implementation documentation. Also I don't think that > TooManyListenersException MUST be thrown (I think it CAN be thrown). > >> I don't like the idea of having a thread per >> port either, but one of the rewrite's design goals is strict >> conformance to the specification. > (but not necessarily on JNI layer) > >> The 50 mS polling interval is just a placeholder. The final >> design of that is yet to be decided. > I though no polling would be wanted; what could be the placeholder stand > for? Do you mean a different interval duration or do you mean something > completely different? > >> In Windows, you have two choices for I/O: overlapped and >> non-overlapped. >> In overlapped I/O a thread is blocked, waiting for something >> to happen. >> In non-overlapped I/O a thread does not block. I chose >> non-overlapped I/O to avoid thread blocking at the OS level - >> instead, the thread blocking is kept in Java. > Isn't "overlapped" (asynchronous) I/O meaning that you invoke some > ReadFile(...,&overlapped, ...) > INSTEAD of performing a synchronous (blocking) function call blocking > the thread? > > As far as I see, W32_Support.cpp uses CreateFile without > FILE_FLAG_OVERLAPPED and thus "If this flag is not specified, then I/O > operations are serialized, even if the calls to the read and write > functions specify an OVERLAPPED structure." [1] and "A synchronous > handle behaves such that I/O function calls using that handle are > blocked until they complete" [2] > > Given that CCOMTIMEOUTS get: > "ReadIntervalTimeout ... A value of MAXDWORD, combined with zero values > for both the ReadTotalTimeoutConstant and ReadTotalTimeoutMultiplier > members, specifies that the read operation is to return immediately with > the bytes that have already been received, even if no bytes have been > received." [3] > > It looks likes this implementation relies on polling, which probably > would waste much computing power. > > What did I miss? > > oki, > > Steffen > > [1] http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx > [2] > http://msdn.microsoft.com/en-us/library/aa363858%28VS.85%29.aspx#synchro > nous_and_asynchronous_i_o_handles > [3] http://msdn.microsoft.com/en-us/library/aa363190%28VS.85%29.aspx > > > About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. > http://www.ingenico.com/. > This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > P Please consider the environment before printing this e-mail > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From adrian.crum at sandglass-software.com Tue Mar 1 09:55:29 2011 From: adrian.crum at sandglass-software.com (Adrian Crum) Date: Tue, 01 Mar 2011 08:55:29 -0800 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <1142-1298983027-957144@sneakemail.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> Message-ID: <4D6D2501.1020803@sandglass-software.com> That code duplicates what is in Dispatcher.cpp. A Unix port would only need to implement CommPortFactory::getInstance(portName, portType). -Adrian On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iqzw2r602 at sneakemail.com Tue Mar 1 15:07:46 2011 From: iqzw2r602 at sneakemail.com (iqzw2r602 at sneakemail.com) Date: Wed, 2 Mar 2011 09:07:46 +1100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6D2501.1020803@sandglass-software.com> References: <20110219182250.50135rhuq6ig6pkw@sandglass-software.com> <4D613A6C.80304@sandglass-software.com> <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <6175-1298930480-518642@sneakemail.com> <4D6C2E90.9010601@sandglass-software.com> <13486-1298944789-675699@sneakemail.com> <4D6C5AAC.3070508@sandglass-software.com> <1142-1298983027-957144@sneakemail.com> <4D6D2501.1020803@sandglass-software.com> Message-ID: <23749-1299017266-991798@sneakemail.com> What is this duplicating? A Unix port will need to call open() anyways (just so we're talking about the same thing here: open() is the Unix equivalent of CreateFile()) On Wed, Mar 2, 2011 at 3:55 AM, Adrian Crum adrian.crum-at-sandglass-software.com |rxtx.org mailing list/Example Allow| wrote: > That code duplicates what is in Dispatcher.cpp. A Unix port would only > need to implement CommPortFactory::getInstance(portName, portType). > > -Adrian > > > On 3/1/2011 4:37 AM, iqzw2r602 at sneakemail.com wrote: > > JNIEXPORT jint JNICALL Java_name_pachler_nio_file_impl_Unix_open > (JNIEnv* env, jclass, jstring jpathname, jint flags, jint mode) > { > const char* pathname = env->GetStringUTFChars(jpathname, 0); > if(pathname == 0) > return -1; // java throws an out of memory error in this case > int result = open(pathname, flags, mode); > Unix_cacheErrno(); // handle interference between JVM and errno; > env->ReleaseStringUTFChars(jpathname, pathname); > return result; > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Tue Mar 1 22:53:07 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 00:53:07 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: Hi, I haven't seen any response to my question below. Is this not the right place to ask? If not, where would be a better place to ask? Any suggestions? Thanks, Ryan On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >> Hi, >> >> I have a receive thread that does nothing but call read() on the serial >> port input stream. It works fine for a while but after running for a long >> time it eventually returns -1 which means EOF. This is my first problem, as >> the device I'm talking to runs forever, I don't know why it would return -1. >> I am calling disableReceiveThreshold() and disableReceiveTimeout() at >> initialization which according to the documentation means read will return >> as soon as any data is available and it will block forever when data is not >> available, so -1 should never be returned from read, right? >> >> I have been unable to figure out why read returns -1 after a long while >> but I have found that if I kill my application and restart it everything >> works fine again. Therefore I tried to work around the problem by having my >> code close the port and reopen it when read returns -1. My second problem is >> that in this case when I call close() on the port it blocks forever. I did >> find this old bug >> >> http://bugzilla.qbang.org/show_bug.cgi?id=53 >> >> which describes close() hanging on OSX, but it says that bug was fixed >> with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have >> any idea why read might be returning -1 in the first place? If I can avoid >> that I don't care about close() hanging because I would never close the >> port. If not, does anyone know why close() might block forever and how I can >> prevent this? I'm using RXTX version 2.1-7. >> >> Thanks, >> -- >> Ryan >> >> > > > -- > Ryan Boder > 1 614 598-6339 > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Mar 2 01:34:48 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 2 Mar 2011 10:34:48 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/2/11 07:53, "Ryan Boder" wrote: Can you / have you made a simple test to ensure that rxtx is the issue? Can you write a simple C-program to see if this exhibits the same problem? I've never encountered this sort of problem with rxtx, it mostly just works. But I'm on Mac so can't say about Windows (7) br Kusti >Hi, > >I haven't seen any response to my question below. Is this not the right >place to ask? If not, where would be a better place to ask? Any >suggestions? > >Thanks, >Ryan > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > >I mis-spoke, I don't have my own thread calling read, I am calling >read in the event handler after receiving a >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be >accurate though. > >Ryan > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > >Hi, > >I have a receive thread that does nothing but call read() on the serial >port input stream. It works fine for a while but after running for a long >time it eventually returns -1 which means EOF. This is my first problem, >as the device I'm talking to runs forever, I don't know why it would >return -1. I am calling disableReceiveThreshold() and >disableReceiveTimeout() at initialization which according to the >documentation means read will return as soon as any data is available and >it will block forever when data is not available, so -1 should never be >returned from read, right? > >I have been unable to figure out why read returns -1 after a long while >but I have found that if I kill my application and restart it everything >works fine again. Therefore I tried to work around the problem by having >my code close the port and reopen it when read returns -1. My second >problem is that in this case when I call close() on the port it blocks >forever. I did find this old bug > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > >which describes close() hanging on OSX, but it says that bug was fixed >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone >have any idea why read might be returning -1 in the first place? If I can >avoid that I don't care about close() hanging because I would never close >the port. If not, does anyone know why close() might block forever and >how I can prevent this? I'm using RXTX version 2.1-7. > >Thanks, >-- >Ryan > > > > > > > > > >-- >Ryan Boder >1 614 598-6339 > > > > > > >-- >Ryan Boder >1 614 598-6339 > -- Kustaa Nyholm Research Manager, Software Research and Technology Division PLANMECA OY Asentajankatu 6 00880 HELSINKI FINLAND Please note our new telephone and fax numbers! Tel: +358 20 7795 572 (direct) Fax: +358 20 7795 676 GSM: +358 40 580 5193 e-mail: kustaa.nyholm at planmeca.com From Steffen.DETTMER at ingenico.com Wed Mar 2 03:08:57 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:08:57 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <32684-1298981297-704398@sneakemail.com> References: <4D6CD4DE.7040501@sandglass-software.com> <32684-1298981297-704398@sneakemail.com> Message-ID: <20110302100857.GB8030@elberon.bln.de.ingenico.com> * iqzw2r602 at sneakemail.com wrote on Tue, Mar 01, 2011 at 23:08 +1100: > This reminds me of a nasty problem I had with overlapped I/O on windows Yeah, those thousands of complex, difficult to use and exception-containing WinAPI is really hard to use... About strange effects on overlapped&multithreading, MSDN has: `the calling thread uses the GetOverlappedResult function or one of the wait functions' [1] also also mentiones I/O Completion Ports [2], and later continues: `If an application reuses OVERLAPPED structures on multiple threads and calls GetOverlappedResult with the bWait parameter set to TRUE, the application must ensure that the associated event is set before the application reuses the structure. This can be accomplished by using the WaitForSingleObject function after calling GetOverlappedResult to force the thread to wait until the operation completes. Note that the event object must be a manual-reset event object. If an autoreset event object is used, calling GetOverlappedResult with the bWait parameter set to TRUE causes the function to be blocked indefinitely.' also [1] oki, Steffen [1] http://msdn.microsoft.com/en-us/library/ms686358%28v=vs.85%29.aspx [2] http://msdn.microsoft.com/en-us/library/aa365198%28v=vs.85%29.aspx About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:15:11 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:15:11 +0100 Subject: [Rxtx] Questions about the Rewrite2010 In-Reply-To: <4D6D1D93.6090306@sandglass-software.com> References: <4D6CD4DE.7040501@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BEDCB@COSNPREXC3.usr.ingenico.loc> <4D6D1D93.6090306@sandglass-software.com> Message-ID: <20110302101511.GC8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 08:23 -0800: > Unfortunately, the javax.comm API specification includes a lot of > implementation details. That is one of the weaknesses of the > specification in my opinion. The bottom line is, anyone wanting to use > RxTx as a javax.comm implementation is going to expect it to do the > things the specification says it does. Yeah ok, but even then the implementation could check for the TooManyListenersException situations (if it really is required to support applications relying on that exception) but internally use just a single I/O thread waiting for events on any open file descriptors. Of course an implementation supporting all sort of concurrency could become quite complex (especially if open-read-close should work fast, I think would be difficult to implement, because a new file descriptors had to be added to the waitFor/select list, and who knows how systems behave here in detail...). oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From Steffen.DETTMER at ingenico.com Wed Mar 2 03:25:15 2011 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Wed, 2 Mar 2011 11:25:15 +0100 Subject: [Rxtx] Which Java folder in source? In-Reply-To: <4D6CDB22.9070401@sandglass-software.com> References: <4D69AFC3.50008@sandglass-software.com> <23853-1298846836-791608@sneakemail.com> <4D6ADDC0.1020608@sandglass-software.com> <15854-1298893954-139343@sneakemail.com> <4D6BBC06.4090402@sandglass-software.com> <20110228172052.GE10695@elberon.bln.de.ingenico.com> <4D6C2E90.9010601@sandglass-software.com> <41CE2F48A2E9E84B88AEA1196E9662BC5BED66@COSNPREXC3.usr.ingenico.loc> <4D6CDB22.9070401@sandglass-software.com> Message-ID: <20110302102515.GD8030@elberon.bln.de.ingenico.com> * Adrian Crum wrote on Tue, Mar 01, 2011 at 03:40 -0800: > * from some older mail: > > My question would be: Why would you do that? The rewrite does > > most of the work for you - all you have to do is implement > > two C++ virtual classes and two C++ functions. > > > > In Windows that took me a few hours. > > Every journey begins with a single step. Yes, of course, but then it shouldn't be used as base for new effort estimations like `In Windows that took a few hours' ;-) (BTW, calling a single step `the rewrite' may sound a bit ambitious ;)) But of course a prototype demonstrating something can be really helpful, sure. I just wanted to tell that interfaces should be easy to use and powerful at the same time and may non-trivial initial considerations before starting to implement them. oki, Steffen About Ingenico: Ingenico is a leading provider of payment, transaction and business solutions, with over 15 million terminals deployed in more than 125 countries. Over 3,000 employees worldwide support merchants, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From ryan.boder at gmail.com Wed Mar 2 18:44:35 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:44:35 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: Message-ID: While running the tests you requested I may have stumbled on the problem, I just don't know how to fix it. According to the documentation, if both the receive timeout and receive threshold are disabled then read() should block forever until data is available. http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/reference/api/javax/comm/CommPort.html#getInputStream%28%29 On my system using RXTX read() is returning -1 when no data is available even though I have disabled both thresholds. The reason my program was running fine for a while without this problem showing up is that I was using the DATA_AVAILABLE event to be notified when data is available and only calling read() to read an entire frame whenever the DATA_AVAILABLE event occurred, until eventually my device (I'm guessing) probably took longer than normal to send the entire data frame and therefore I called read when no data was available and it returned -1. The following Java program demonstrates my problem, it returns -1 as soon as no data is available, even though I think it should block until data is available. import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; import gnu.io.SerialPortEvent; import gnu.io.SerialPortEventListener; import java.io.BufferedInputStream; import java.io.BufferedOutputStream; public class Main implements SerialPortEventListener { public static void main(String[] args) throws Exception { new Main().run(); } private void run() throws Exception { CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier("COM4"); SerialPort port = (SerialPort) portIdentifier.open(Main.class.getName(), 2000); port.setSerialPortParams(19200, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); port.setFlowControlMode(SerialPort.FLOWCONTROL_NONE); port.disableReceiveThreshold(); port.disableReceiveTimeout(); BufferedInputStream in = new BufferedInputStream(port.getInputStream()); BufferedOutputStream out = new BufferedOutputStream(port.getOutputStream()); port.addEventListener(this); Thread.sleep(1000); out.write(new byte[] {0x02, 0x60}); out.flush(); while (true) { int x = in.read(); if (x == -1) { System.out.println("EOF"); Thread.sleep(1000000000); } String s = Integer.toHexString(x & 0xFF); if (s.length() == 1) s = "0" + s; System.out.print(s + " "); System.out.flush(); } } public void serialEvent(SerialPortEvent arg0) { System.out.println("Serial port event"); } } However, the follow C# program ran all day today without ever read ever returning -1, as I would expect. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.IO.Ports; using System.Threading; namespace RXTXReadTest1 { class Program { static void Main(string[] args) { new Program().run(); } private void run() { SerialPort port = new SerialPort("COM4", 19200, Parity.None, 8, StopBits.One); port.Open(); port.Write(new byte[] { 0x02, 0x60 }, 0, 2); while (true) { int x = port.ReadByte(); if (x == -1) { Console.WriteLine("EOF"); Thread.Sleep(1000000000); } String s = x.ToString("X"); if (s.Length == 1 ) s = "0" + s; Console.Out.Write(s + " "); Console.Out.Flush(); } } } } Now I am experimenting with what happens if I set the receive timeout to it's maximum value (apparently 1600ms) and only call read() when I am expecting data. Hopefully it will never be more than 1600ms late. This is still only a work around, not solving the problem. Am I doing something wrong in my code above or is RXTX retuning -1 when it should be blocking? Thanks, Ryan On Wed, Mar 2, 2011 at 3:34 AM, Kustaa Nyholm wrote: > On 3/2/11 07:53, "Ryan Boder" wrote: > Can you / have you made a simple test to ensure that rxtx is the issue? > > Can you write a simple C-program to see if this exhibits the same problem? > > I've never encountered this sort of problem with rxtx, it mostly just > works. > > But I'm on Mac so can't say about Windows (7) > > br Kusti > > > > > >Hi, > > > >I haven't seen any response to my question below. Is this not the right > >place to ask? If not, where would be a better place to ask? Any > >suggestions? > > > >Thanks, > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder > wrote: > > > >I mis-spoke, I don't have my own thread calling read, I am calling > >read in the event handler after receiving a > >SerialPortEvent.DATA_AVAILABLE event. Everything else I said should be > >accurate though. > > > >Ryan > > > > > >On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder > wrote: > > > >Hi, > > > >I have a receive thread that does nothing but call read() on the serial > >port input stream. It works fine for a while but after running for a long > >time it eventually returns -1 which means EOF. This is my first problem, > >as the device I'm talking to runs forever, I don't know why it would > >return -1. I am calling disableReceiveThreshold() and > >disableReceiveTimeout() at initialization which according to the > >documentation means read will return as soon as any data is available and > >it will block forever when data is not available, so -1 should never be > >returned from read, right? > > > >I have been unable to figure out why read returns -1 after a long while > >but I have found that if I kill my application and restart it everything > >works fine again. Therefore I tried to work around the problem by having > >my code close the port and reopen it when read returns -1. My second > >problem is that in this case when I call close() on the port it blocks > >forever. I did find this old bug > > > >http://bugzilla.qbang.org/show_bug.cgi?id=53 > > > >which describes close() hanging on OSX, but it says that bug was fixed > >with a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone > >have any idea why read might be returning -1 in the first place? If I can > >avoid that I don't care about close() hanging because I would never close > >the port. If not, does anyone know why close() might block forever and > >how I can prevent this? I'm using RXTX version 2.1-7. > > > >Thanks, > >-- > >Ryan > > > > > > > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > > > > > > > > > >-- > >Ryan Boder > >1 614 598-6339 > > > > > -- > Kustaa Nyholm > Research Manager, Software > Research and Technology Division > PLANMECA OY > Asentajankatu 6 > 00880 HELSINKI > FINLAND > > Please note our new telephone and fax numbers! > Tel: +358 20 7795 572 (direct) > Fax: +358 20 7795 676 > GSM: +358 40 580 5193 > e-mail: kustaa.nyholm at planmeca.com > > > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > -- Ryan Boder 1 614 598-6339 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.boder at gmail.com Wed Mar 2 18:46:48 2011 From: ryan.boder at gmail.com (Ryan Boder) Date: Wed, 2 Mar 2011 20:46:48 -0500 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: <-1051064942000733580@unknownmsgid> References: <-1051064942000733580@unknownmsgid> Message-ID: It is USB and seems very reliable with the C# test program in my previous email. On Wed, Mar 2, 2011 at 6:58 PM, Bruce Griffith wrote: > How reliable is your serial port ? is it USB or Bluetooth? > > > > Bruce Griffith > > 303-532-4778 > > > > *From:* rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] *On Behalf > Of *Ryan Boder > *Sent:* Tuesday, 01 March 2011 10:53 PM > *To:* rxtx at qbang.org > *Subject:* Re: [Rxtx] RXTX serial port read() returns -1 unexpectedly and > then blocks forever on close() > > > > Hi, > > I haven't seen any response to my question below. Is this not the right > place to ask? If not, where would be a better place to ask? Any suggestions? > > Thanks, > Ryan > > On Mon, Feb 28, 2011 at 12:34 AM, Ryan Boder wrote: > > I mis-spoke, I don't have my own thread calling read, I am calling read in > the event handler after receiving a SerialPortEvent.DATA_AVAILABLE event. > Everything else I said should be accurate though. > > Ryan > > > > On Mon, Feb 28, 2011 at 12:28 AM, Ryan Boder wrote: > > Hi, > > I have a receive thread that does nothing but call read() on the serial > port input stream. It works fine for a while but after running for a long > time it eventually returns -1 which means EOF. This is my first problem, as > the device I'm talking to runs forever, I don't know why it would return -1. > I am calling disableReceiveThreshold() and disableReceiveTimeout() at > initialization which according to the documentation means read will return > as soon as any data is available and it will block forever when data is not > available, so -1 should never be returned from read, right? > > I have been unable to figure out why read returns -1 after a long while but > I have found that if I kill my application and restart it everything works > fine again. Therefore I tried to work around the problem by having my code > close the port and reopen it when read returns -1. My second problem is that > in this case when I call close() on the port it blocks forever. I did find > this old bug > > http://bugzilla.qbang.org/show_bug.cgi?id=53 > > which describes close() hanging on OSX, but it says that bug was fixed with > a patch in May 2006. Anyway I am on Window 7, not OSX. Does anyone have any > idea why read might be returning -1 in the first place? If I can avoid that > I don't care about close() hanging because I would never close the port. If > not, does anyone know why close() might block forever and how I can prevent > this? I'm using RXTX version 2.1-7. > > Thanks, > -- > Ryan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msemtd at googlemail.com Thu Mar 3 02:50:20 2011 From: msemtd at googlemail.com (Michael Erskine) Date: Thu, 3 Mar 2011 09:50:20 +0000 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: References: <-1051064942000733580@unknownmsgid> Message-ID: So if -1 is unexpectedly returned from read, and we have demonstrated that your USB-serial adapter can actually causes this to happen in RXTX, why not just ignore the -1 value? What happens when you try this? As for a hang on close, are your closing your port from within your serial event handler? I know that this can cause some serious problems. Regards, Michael Erskine. From Kustaa.Nyholm at planmeca.com Thu Mar 3 03:39:34 2011 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Thu, 3 Mar 2011 12:39:34 +0200 Subject: [Rxtx] RXTX serial port read() returns -1 unexpectedly and then blocks forever on close() In-Reply-To: Message-ID: On 3/3/11 03:44, "Ryan Boder" wrote: >While running the tests you requested I may have stumbled on the problem, >I just don't know how to fix it. According to the documentation, if both >the receive timeout and receive threshold are disabled then read() should >block forever until data is available. > >http://download.oracle.com/docs/cd/E17802_01/products/products/javacomm/re >ference/api/javax/comm/CommPort.html#getInputStream%28%29 > >On my system using RXTX read() is returning -1 when no data is available >even though I have disabled both thresholds. The reason my program was >running fine for a while without this problem showing up is that I was >using the DATA_AVAILABLE event to be notified when data is available and >only calling read() to read an entire frame whenever the DATA_AVAILABLE >event occurred, until eventually my device (I'm guessing) probably took >longer than normal to send the entire data frame and therefore I called >read when no data was available and it returned -1. As a workaround have you tried to perform another read() if it returns -1? The javadoc says (see getInputStream): "Note, however, that framing errors may cause the Timeout and Threshold values to complete prematurely without raising an exception." I read this as a hint that read might return even if no data is available. Because of the above and that read() can only return -1 or the byte received it would be somewhat logical to return -1 in case of framing error ? I'm not claiming that my interpretation of the specification, such as it is, is correct, just speculating that the behavior could be something like that. It might give you some more insight if you used the read(bytes[],int,int) method, because this can and will return 0 in case of timeout (and presumably might do so in case of framing